🔍 연구의 필요성

프로그래밍 문제는 함수가 어떤 기능을 수행해야 하는가와 그 함수의 입력이 무엇을 만족해야 하는가를 동시에 말합니다. "리스트는 비어 있으면 안 된다" 같은 조건들이 모여 Contract(함수가 받아들일 입력의 범위를 규정하는 전제조건)를 이룹니다. 그러나 HumanEval, MBPP, EvalPlus는 이미 모든 조건을 만족하는 valid input만 이용해 측정하므로, 기능이 맞는지는 재도 코드가 Contract를 enforcement하는지는 모릅니다.

Contract를 만족하는 프로그램은 같은 함수 하나로 두 조건을 충족해야 합니다. valid input에는 올바른 출력을 내고, contract-violating input은 의도적으로 거부해야 합니다. 두 요구는 서로를 밀어냅니다. enforcement가 불완전하면 거부해야 할 contract-violating input이 조용히 통과하고, enforcement가 과도하면 valid input까지 거부해 기능 정확도가 떨어집니다. 게다가 Contract 조건은 기능 요구사항과 같은 산문 안에 섞여 있어 모델이 스스로 식별해야 합니다. 명세를 나누지 않은 채 한 번에 생성하도록 요구하면 두 목표가 경쟁하고, 실제로 기존 기법들은 Base 대비 SSR을 −9.04% ~ −0.45% 만큼 오히려 떨어뜨립니다.

기존 연구는 이 문제의 절반씩만 다룹니다. 한 갈래는 contract condition을 뽑아내는 데 집중합니다. 코드나 자연어로부터 precondition·postcondition을 생성해내지만, 뽑아낸 contract condition이 얼마나 정확한지를 볼 뿐 그것이 실제 코드 안에서 지켜지는지는 확인하지 않습니다. 다른 갈래는 contract condition을 미리 받아서 코드를 만듭니다. 이때는 contract condition이 기능 요구사항과 이미 분리된 상태로 주어지므로, 산문 속에 섞인 것을 찾아내는 일 자체가 과제가 되지 않습니다. 한쪽은 contract condition을 찾되 지키게 만들지 않고, 다른 쪽은 지키게 하되 찾을 필요가 없는 셈입니다. CodeTree나 SpecFix는 기능 테스트 신호만으로 탐색하기 때문에 Contract가 시야 밖에 있고, ContractEval은 평가 세팅을 세웠을 뿐 생성 방법은 제시하지 않았습니다.

우리는 이 공백을 메우기 위해 SLICE를 제시합니다. SLICE는 reference solution도 held-out test도 쓰지 않고 자연어 명세만으로 동작하며, Contract enforcement와 기능 구현을 명세 수준에서 분리해 각각 다른 생성 단계에 맡깁니다.

✨ SLICE이란?

SLICE (Specification-Level Isolation of Contract Enforcement)는 자연어 문제 명세만을 입력으로 받아, 기능 구현과 Contract enforcement를 서로 다른 생성 단계에 맡기는 파이프라인입니다. 출력은 두 개의 산출물이 아니라, input-validation assertion이 진입부에 붙은 완성된 함수 하나입니다. reference solution도, held-out test도 사용하지 않으며 명세에 이미 적혀 있는 예시만 실행 신호로 씁니다.

SLICE는 한 번의 생성이 동시에 감당해야 했던 세 과제를 명시적으로 분리합니다.

1. Graph-Based Specification Structuring (명세에서 Contract를 떼어내기)

<aside> 📌

• 결정론적 파서가 명세를 문장·세미콜론 경계로 나눠 description segment를 만들고, 15개 functional marker와 7개 example-preservation marker로 라벨을 붙임
• LLM이 명세에 진술된 contract condition 집합을 추출하고, segment와 condition을 노드로 하는 specification graph를 구성
• grounding은 두 기준이 동시에 성립할 때만 연결: semantic correspondence(임베딩 cosine ≥ 0.75)와 lexical grounding(내용어 중첩 ≥ 45%)
• functional·example 라벨이 없는 contract-only segment만 제거하고 구두점을 정리해 functional view를 만듬. </aside>

2. Functional Body Generation (기능 본문만 따로 만들고 고르기)

<aside> 📌

• functional view로부터 후보 5개 생성 — greedy 1개 + temperature 0.7 sampling 4개
• 명세 안의 예시(doctest, assert 줄, f(a) = b 형태 산문)를 실행 가능한 check로 이용해 execution score로 순위 매김
• 동점은 **diff-lp (동점 후보들이 서로 다른 줄에 대해서만 평균 token log probability를 계산)**로 우열을 매김 . 공유되는 줄을 제외해 후보를 가르는 구현 선택에만 점수를 집중시킴 </aside>

3. Contract Assertion Generation (Contract만 보고 검증 코드를 붙이기)

<aside> 📌

• 선택된 함수 본문과 앞서 추출한 contract condition 집합을 함께 주고, condition 하나당 input-validation assertion 하나를 생성
• condition 목록은 명세에 없는 Contract을 생성하는 것을 막고, 앞서 선택된 함수 본문은 assertion이 실제 파라미터 이름과 구현 선택에 맞춰지게 함
• screening: 명세의 example input을 거부하는 assertion은 제거해 over-rejection을 차단 </aside>

평가 지표 (Metric)

<aside> 📌

• SSR (Specification Satisfaction Rate): 같은 함수 하나가 모든 valid input에 정답을 내고 동시에 모든 contract-violating input을 의도적으로 거부한 태스크의 비율.
• pass@1: assertion이 붙은 완성 함수의 valid input 기능 정확도
• CSR (Contract Satisfaction Rate): 모든 contract-violating input을 거부한 태스크의 비율 </aside>