3.1 Selection : 허나 LLM의 판단으로는 정확한 예측이 힘들다는 것을 발견하여, 구분을 잘하도록 하기 힘들다.(표3) -> 사실 adaptive input symthesis와 크게 차이나 보이지는 않긴함... LLM judge써도 괜찮았던거 아닌가...
5.2 그래서? -> naive한 검색 방법은 성능을 올리는데 부족하다는 것을 보임. ICL자체는 좋으나 성능이 예제 품질과 효율성에 민감함.
0. Abstract
수학 분야에서는 연구가 되었으나, 코드 생성 분야에는 충분한 연구가 없었음.
코드 분야에서 coverage와 선택 정확도를 향상시키는 test-time scaling 프레임 워크를 제안함.
1. Introduction
test time compute은 모델 성능을 향상시킴. 특히 수학에서 잘 작동한다.
- 세개의 측면이 있는데
- parallel sampling : 커버리지를 증가시킴
- sequantial refinement : 개별 샘플을 향상시키고
- Reward model : 검색을 좀더 효율적으로 함
- 수학과 달리 코드에서는 충분히 연구되지 않았다.
- 코드 생성의 도전과제는
- 코드 검증은 정확하게 확인하기 위해서는 대규모 테스트 케이스 실행이 필요함.
-> test time scaling 복잡성을 증가시키고, reward model의 설계를 복잡하게 만든다.
- 코드 검증은 정확하게 확인하기 위해서는 대규모 테스트 케이스 실행이 필요함.
- 코드 생성의 장점은
- 프로그램을 실행해 정확한 출력과 오류 메시지를 얻을 수 있어, grounding을 하기 쉬움
- 코드 생성의 도전과제는
- (Figure 2) s* 제안 : 실행을 통한 반복적 디버깅을 통해 sequential scaling을 만들어 parallel scling의 한계를 뛰어넘는다.
- 1. paralle sampling : 생성된 여러 샘플들로 테스크 케이스에 실행되는 출력/오류 메시지를 얻고, 다시 모델의 입력으로 들어감.
- 2. adaptive input synthesis라는 방법을 통해 솔루션 비교를 하고 좋은 솔루션을 찾음.
2. Related Work
- Test time scaling for llms :
- Parallel scaling : 여러 솔루션을 생성 하고 최선의 것을 선택
- sequantial scaling : 모델이 여러 단계에 걸쳐 추론을 개선하도록 장려 - CoT, 반복적인 재고와 수정, 과 같은 방법.
- Test time scaling for code Generation : 기존 방법들은 parallel scaling, sequantial scaling 둘 중 하나만 진행함. 반면 이 연구는 두개의 조합임.
- Hybrid Test-Time Scaling
- Concurrent Work : CodeMonkeys는 병렬로 여러 샘플 생성하고 샘플 수정함. 반면 이 연구는 공개 테스트의 피드백을 통해 개선함.
3. Method
코딩 문제는 설명과 테스트 케이스(public, private)로 구성된다. Private 테스트는 모델이 접근할 수 없고, public 테스트는 약 2개 정도이고 prompt로 제공됨, private 테스트는 많음(약 200개)
3.1 The S* Framework
Generation, Selection 단계로 구성되어 있음.
Stage 1: Generation
- Parallel scaling(N개 생성)을 하여 커버리지를 확보
- Sequantial scaling : 각 샘플은 공개 테스트 케이스에서 실행 결과에 따라, sequential하게 수정된다.
Stage 2: Selection
- N개의 솔루션이 생성되었으면, 이 단게에서는 최상의 것을 식별하는 것임. 공개 테스트는 이미 생성 단계에서 사용되어 추가적인 평가가 필요함.
- LLM as a Judge : 솔루션들을 비교하기 위해 사전 훈련된 지식에 의존
- 생성된 테스트 케이스를 사용
- 허나 LLM의 판단으로는 정확한 예측이 힘들다는 것을 발견하여, 구분을 잘하도록 하기 힘들다.(표3) -> 사실 adaptive input symthesis와 크게 차이나 보이지는 않긴함... LLM judge써도 괜찮았던거 아닌가...
- 따라서 adaptive input synthesis를 제안함.
- LLM에게 입력 데이터를 만들도록 프롬프팅
- 입력을 실행하고 실행 출력을 기반으로 N개의 샘플을 클러스터링함.
- 클러스터간 pair비교를 수행
- 각 비교에 대해 LLM에게 distinguishing inputs를 만들도록 프롬프트.
- 두개 코드 샘플이 서로 다른 행동을 보이도록 설계된 테스트 입력을 의미함. - 생성된 input과 생성된 솔루션을 실행하고 성능이 더 좋았던 우수한 것을 선택함.
4. Evaluation
- 결론 : S*는 모델, 유형 등 모든 부분에서 일반적으로 성능을 향상시킴. 또한 coverage와 선택 정확도 모두 향상시켜 기존 널리 사용되는 test-time scaling방법 능가함.
4.1 Experiment Setup
모델 : 12개(reasoning, non reasoning)
벤치마크 : LiveCodeBench등
베이스라인 : o1-preview, o1-high, o1-mini
세부사항 : temperature(0.7, without top-p sampling), generate 16, 2 debugging on pulic test.
4.2 Main Results
4.3 Comparison to Other Test-Time Methods
인기 있는 test-time scaling 방법인 majority voting과 self-debugging과 비교.
4.4 Results on Other Benchmark
5. Ablation Studis
5.1 Parallel Sampling Hyper-Parameters
- temperature : 적당한 temperature가 성능을 향상시킴(높으면 성능 저하함). 0.2~0.7 사이가 적절함. 0.7을 넘으면 성능 하락하는데, 노이즈를 발생시켜서 그런것이 아닐까 추측함.
- sampling : parallel 수를 늘리면 모델 성능이 크게 향상된다
5.2 Impact of In-Context Examples
- ICL을 다양하게 보강하면 성능이 올라갈까?
-> 상위 k개의 유사한 프롬프트를 검색하고 실험. - Qwen2.5-32B의 경우 64개를 제외하고는 대부분 경우에서 zero-shot보다 비슷하거나 더 나쁜 성능을 보임.
- 그래서? -> naive한 검색 방법은 성능을 올리는데 부족하다는 것을 보임. ICL자체는 좋으나 성능이 예제 품질과 효율성에 민감함.
5.3 Impact of Different Selection Policy (Table3. Selection부분에 첨부함)
- Public Only : public test만을 사용
- Generated Tests : public test사용하고, GPT-4o mini를 사용해 테스트 케이스 생성하고, 가장 많은 테스트 케이스 통과하는 샘플 선택
- LLM Judge : public test만을 사용, 가장 많은 테스트 통과한 샘플들중 pairwise로 좋은 케이스 선택
- Adaptive Input Synthesis : 연구에서 제안하는 방법
-> 결론 : Generated Tests 접근 방식은 개선이 별로 없음. model-generated오류 때문인데, 오류가 잘못 선택된 입력에 적용되면 선택 프로세스에 상당한 노이즈를 도입하여 결국 성능을 저하시킴.