AI바라기의 인공지능

LLM : 논문 리뷰 : s1: Simple test-time scaling 본문

논문리뷰

LLM : 논문 리뷰 : s1: Simple test-time scaling

AI바라기 2025. 2. 3. 13:16
더보기

s1: Simple test-time scaling 논문 정리 노트

Purpose of the Paper:

기존의 Large Language Model (LM) 성능 향상은 주로 train-time compute 확장에 의존해왔습니다. 하지만 최근 OpenAI의 o1 모델은 test-time compute를 추가하여 성능을 향상시키는 test-time scaling이라는 새로운 패러다임을 제시했습니다. 문제는 OpenAI가 o1 모델의 구체적인 방법론을 공개하지 않아, 재현 연구에 어려움이 있었다는 점입니다.

본 논문은 test-time scaling을 달성하는 가장 단순한 접근 방식을 탐색하고, 동시에 강력한 추론 성능을 확보하는 것을 목표로 합니다. 특히, 복잡한 Reinforcement Learning (RL) 기반 방법론 대신, Supervised Fine-tuning (SFT)과 budget forcing이라는 간단한 기법을 통해 test-time scaling을 효과적으로 구현하고자 합니다. 핵심은 **적은 데이터(1,000개)**로도 test-time scaling과 강력한 추론 성능을 동시에 얻을 수 있는 방법을 찾는 것입니다.

Key Contributions:

  • s1K Dataset: 1,000개의 고품질, 다양성, 난이도를 고려하여 엄선된 추론 데이터셋 s1K를 구축했습니다. 이 데이터셋은 ablation study를 통해 데이터 큐레이션의 중요성을 강조합니다.
  • Budget Forcing: 모델의 thinking duration을 제어하는 간단하면서도 효과적인 test-time 기법인 budget forcing을 제안했습니다. 이는 모델의 thinking process를 강제로 종료시키거나 연장시키는 방식으로 구현됩니다.
  • s1-32B Model: Qwen2.5-32B-Instruct 모델을 s1K 데이터셋으로 SFT하고 budget forcing을 적용한 s1-32B 모델을 개발했습니다. s1-32B는 경쟁적인 성능을 보이며, 특히 sample efficiency 측면에서 뛰어납니다.
  • Test-time Scaling 재현: s1-32B 모델을 통해 OpenAI o1 모델의 test-time scaling behavior를 오픈 소스 방식으로 재현하는 데 성공했습니다. 이는 간단한 방법론으로도 test-time scaling이 가능하다는 것을 보여줍니다.
  • Evaluation Metrics 제안: test-time scaling 방법을 평가하기 위한 새로운 metrics인 Control, Scaling, Performance를 제안하여, 단순한 성능뿐만 아니라 controllability와 scaling slope까지 고려하는 종합적인 평가를 가능하게 했습니다.

Novelty:

  • Simplicity: 본 논문은 복잡한 RL이나 multi-agent approaches 대신, SFT와 budget forcing이라는 극도로 단순한 기법을 사용하여 test-time scaling을 달성했다는 점에서 novelty를 가집니다.
  • Sample Efficiency:1,000개의 데이터만으로 강력한 추론 모델을 fine-tuning하고 test-time scaling을 구현했다는 점은 매우 novel합니다. 이는 large-scale 데이터에 의존하는 기존 방식과 대조됩니다.
  • Open-source 재현: closed-source 모델인 o1의 test-time scaling을 open-source 모델과 방법론으로 재현했다는 점에서 연구 재현성과 접근성을 높였습니다.
  • Budget Forcing 기법: "Wait" token appending과 thinking token delimiter를 활용한 budget forcing 기법은 test-time compute를 제어하는 새롭고 직관적인 방법입니다.

Experimental Highlights:

  • s1-32B 모델 성능: s1-32B 모델은 Competition Math (AIME24) 문제에서 o1-preview 모델을 최대 27% 능가하는 성능을 보였습니다. PhD-Level Science Questions (GPQA Diamond)에서도 경쟁력 있는 성능을 입증했습니다.
  • Budget Forcing 효과: budget forcing을 통해 s1-32B 모델은 test-time compute 증가에 따라 성능이 지속적으로 향상되는 뚜렷한 scaling behavior를 보였습니다. 특히 AIME24에서 test-time intervention 없이 50%에서 57%로 성능이 향상되는 extrapolation 효과를 확인했습니다.
  • Data Ablation Study: s1K 데이터셋 구축 시 Quality, Difficulty, Diversity 세 가지 기준을 조합하는 것이 중요함을 ablation study를 통해 입증했습니다. Random selection, longest reasoning trace selection, diversity only selection 등 단일 기준으로는 성능이 크게 저하되었습니다.
  • Test-time Scaling Method Ablation: budget forcing이 token-conditional control, step-conditional control, class-conditional control, rejection sampling 등 다른 test-time scaling 방법론보다 controllability, scaling slope, 성능 면에서 우수함을 실험적으로 보였습니다.
  • Parallel Scaling 한계: majority voting과 REBASE를 활용한 parallel scaling은 sequential scaling 방식인 budget forcing에 비해 test-time compute 확장에 따른 성능 향상폭이 제한적이었습니다.

Limitations:

  • Context Window 제한: budget forcing을 통한 sequential scaling은 언어 모델의 context window 크기에 의해 궁극적으로 제한될 수 있습니다. 모델이 생성하는 thinking tokens가 context window를 초과하면 성능 저하가 발생할 수 있습니다.
  • 모델 Flattening: test-time compute를 지속적으로 늘려도 성능이 일정 수준 이상으로 향상되지 않고 flatten out 되는 현상이 관찰되었습니다. 이는 budget forcing 자체의 한계일 수 있습니다.
  • Simple Reasoning Task 중심: s1K 데이터셋과 실험은 주로 reasoning-intensive tasks, 특히 수학 문제에 집중되어 있습니다. 다른 유형의 reasoning tasks나 broader NLP tasks에 대한 일반화 가능성은 추가적인 연구가 필요합니다.
  • Budget Forcing 파라미터: budget forcing 기법에서 "Wait" token appending 횟수, thinking token delimiter 사용 시점 등 hyperparameter 튜닝에 대한 추가 연구가 필요합니다.

Future Work:

  • Extrapolation 한계 극복: budget forcing의 extrapolation 한계를 극복하기 위해 다양한 string rotation, frequency penalties, temperature 조절 등 추가적인 기법 연구가 필요합니다.
  • RL 기반 모델과의 결합: Reinforcement Learning으로 학습된 reasoning model에 budget forcing을 적용했을 때 test-time scaling 효과가 더욱 향상될 수 있는지 탐구하는 것은 흥미로운 연구 방향입니다.
  • Parallel Scaling과의 통합: sequential scaling과 parallel scaling의 장점을 결합하여 test-time compute extrapolation을 더욱 효과적으로 달성하는 방법을 연구할 필요가 있습니다. REBASE와 같은 tree search 기반 방법론과의 통합 가능성을 탐색할 수 있습니다.
  • Metrics 고도화: 제안된 Control, Scaling, Performance metrics를 더욱 발전시키고, test-time scaling의 다양한 측면을 포괄적으로 평가할 수 있는 새로운 metrics 개발이 필요합니다.
  • Simple Reasoning 기법 확장: 본 논문에서 제시된 simple reasoning 기법을 broader reasoning tasks 및 실용적인 문제 해결에 적용하고 확장하는 연구가 중요합니다.

 

 

 

 

Abstract

Test-time scaling은 성능 향상을 위해 추가적인 test-time compute를 사용하는 언어 모델링의 유망한 새로운 접근 방식입니다. 최근 OpenAI의 o1 모델이 이러한 능력을 보여주었지만, 그 방법론을 공개적으로 공유하지 않아 많은 복제 노력이 있었습니다. 우리는 test-time scaling과 강력한 reasoning 성능을 달성하기 위한 가장 간단한 접근 방식을 모색합니다. 첫째, 우리는 ablation을 통해 검증한 세 가지 기준(난이도, 다양성, 품질)에 의존하는 reasoning traces와 함께 짝을 이룬 1,000개의 질문으로 구성된 작은 dataset s1K를 선별합니다. 둘째, 모델이 종료하려고 할 때 모델의 thinking process를 강제로 종료하거나 생성에 "Wait"를 여러 번 추가하여 늘림으로써 test-time compute를 제어하는 budget forcing을 개발합니다. 이를 통해 모델은 답변을 다시 확인하여 종종 부정확한 reasoning 단계를 수정할 수 있습니다. s1K에서 Qwen2.5-32B-Instruct language model을 supervised finetuning하고 budget forcing을 장착한 후, 우리 모델 s1-32B는 경쟁 math 질문에서 o1-preview를 최대 27%까지 능가합니다 (MATH 및 AIME24). 또한 budget forcing으로 s1-32B를 scaling하면 test-time intervention 없이 성능을 extrapolation할 수 있습니다. AIME24에서 50%에서 57%로 향상됩니다.

 

 

1. Introduction

더보기

지난 몇 년 동안 language model (LM)의 성능 향상은 대규모 self-supervised pretraining을 사용하여 train-time compute를 확장하는 데 크게 의존했습니다 (Kaplan et al., 2020; Hoffmann et al., 2022). 이러한 강력한 모델의 생성은 그 위에 구축된 새로운 scaling paradigm의 발판을 마련했습니다: test-time scaling. 이 접근 방식의 목표는 더 나은 결과를 얻기 위해 test time에 compute를 늘리는 것입니다. 이 아이디어를 탐구한 많은 연구가 있었고 (Snell et al., 2024; Wu et al., 2024b; Welleck et al., 2024), 이 paradigm의 타당성은 최근 OpenAI o1 (OpenAI, 2024)에 의해 검증되었습니다. o1은 test-time compute를 scaling함으로써 일관된 이점을 얻어 강력한 reasoning 성능을 보여주었습니다. OpenAI는 그들의 접근 방식을 대규모 reinforcement learning (RL)을 사용하는 것으로 설명하며 상당한 양의 데이터를 사용함을 암시합니다 (OpenAI, 2024). 이로 인해 Monte Carlo Tree Search (Gao et al., 2024b; Zhang et al., 2024a), multi-agent 접근 방식 (Huang et al., 2024b) 등과 같은 기술에 의존하여 해당 모델을 복제하려는 다양한 시도가 있었습니다 (Huang et al., 2024b; Gao et al., 2024b; Zhang et al., 2024a; Wang et al., 2024a). 이러한 접근 방식 중에서 DeepSeek R1 (DeepSeek-AI et al., 2025)은 수백만 개의 샘플과 여러 training 단계를 통해 reinforcement learning을 사용하여 o1 수준의 성능을 성공적으로 복제했습니다. 그러나 많은 o1 복제 시도에도 불구하고 명확한 test-time scaling 동작을 공개적으로 복제한 것은 없습니다. 따라서 우리는 다음과 같이 질문합니다. test-time scaling과 강력한 reasoning 성능을 모두 달성하는 가장 간단한 접근 방식은 무엇일까요?

우리는 next-token prediction과 budget forcing이라고 부르는 간단한 test-time 기술을 통해 thinking duration을 제어하여 1,000개의 샘플만으로 training하면 더 많은 test-time compute로 성능이 scaling되는 강력한 reasoning model을 얻을 수 있음을 보여줍니다. 특히, 우리는 Gemini Thinking Experimental (Google, 2024)에서 추출한 reasoning traces와 답변과 함께 짝을 이룬 1,000개의 신중하게 선별된 질문으로 구성된 s1K를 구성합니다. 우리는 16개의 H100 GPU에서 단 26분의 training만 필요한 작은 dataset에서 off-the-shelf pretrained model의 supervised fine-tuning (SFT)을 수행합니다. training 후, 우리는 budget forcing을 사용하여 모델이 소비하는 test-time compute의 양을 제어합니다. (I) 모델이 원하는 제한보다 많은 thinking token을 생성하면 end-of-thinking token delimiter를 추가하여 thinking process를 강제로 종료합니다. 이런 식으로 thinking을 종료하면 모델은 답변 생성을 시작합니다. (II) 모델이 문제에 더 많은 test-time compute를 소비하기를 원하면 end-of-thinking token delimiter 생성을 억제하고 대신 모델의 현재 reasoning trace에 "Wait"를 추가하여 추가 탐색을 장려합니다. 이 간단한 레시피 (1,000개 샘플에 대한 SFT 및 test-time budget forcing)를 갖춘 우리 모델 s1-32B는 test-time scaling을 보여줍니다 (그림 1). 또한 s1-32B는 가장 sample-efficient한 reasoning model이며 OpenAI의 o1-preview와 같은 closed-source model보다 성능이 뛰어납니다 (그림 2). 우리는 (a) 1,000개 (1K) reasoning 샘플 선택과 (b) test-time scaling을 목표로 하는 광범위한 ablation 실험을 수행합니다. (a)의 경우, 선택 알고리즘에 난이도, 다양성 및 품질 측정값을 공동으로 통합하는 것이 중요함을 발견했습니다. 무작위 선택, 가장 긴 reasoning trace가 있는 샘플 선택 또는 최대한 다양한 샘플만 선택하는 것은 모두 평균적으로 AIME24에서 훨씬 더 나쁜 성능 (평균적으로 약 -30%)으로 이어집니다. s1K의 상위 집합인 59K 예제의 전체 데이터 풀에서 training해도 1K 선택에 비해 상당한 이점을 제공하지 않습니다. 이는 신중한 데이터 선택의 중요성을 강조하며 instruction tuning에 대한 이전 연구 결과를 반영합니다 (Zhou et al., 2023). (b)의 경우, 다양한 접근 방식을 비교하기 위해 test-time scaling 방법에 대한 desiderata를 정의합니다. Budget forcing은 강력한 성능으로 이어지는 명확한 positive slope를 가진 완벽한 제어 가능성을 가지고 있기 때문에 최고의 scaling을 제공합니다.

 

요약하면, 우리의 기여는 다음과 같습니다. 우리는 sample-efficient한 reasoning dataset (§2)과 test-time scaling (§3)을 생성하는 간단한 방법을 개발합니다. 이를 바탕으로 o1-preview와 경쟁력 있는 s1-32B를 구축합니다 (§4). 우리는 데이터 (§5.1)와 test-time scaling (§5.2)의 미묘한 차이점을 ablate합니다. 우리는 간단한 reasoning에 대한 향후 연구를 동기 부여하기 위한 논의로 마무리합니다 (§6). 우리의 코드, 모델 및 데이터는 open-source로 제공될 예정입니다.

 

Introduction 정리 노트: 핵심 요약

배경

  • 최근 몇 년간 Language Model (LM) 성능 향상은 대규모 self-supervised pretraining과 train-time compute 확장에 의존
  • 강력한 모델 개발로 새로운 scaling paradigm: test-time scaling 등장
  • Test-time scaling은 더 나은 결과를 위해 test time에 compute를 늘리는 것을 목표로 함
  • OpenAI의 o1 모델이 test-time compute scaling을 통해 강력한 reasoning 성능을 보여줌
  • o1의 방법론이 공개되지 않아 다양한 복제 시도 (Monte Carlo Tree Search, multi-agent 등)가 있었지만, 명확한 test-time scaling 동작을 성공적으로 복제한 사례는 없음

문제 제기

  • Test-time scaling과 강력한 reasoning 성능을 모두 달성하는 가장 간단한 접근 방식은 무엇인가?

핵심 아이디어

  • Next-token prediction과 budget forcing (간단한 test-time 기술)을 통해 thinking duration을 조절하여 1,000개의 샘플만으로 강력한 reasoning 모델을 학습 가능
  • s1K: Gemini Thinking Experimental에서 추출한 reasoning trace와 답변 쌍으로 구성된 1,000개의 질문 dataset
  • Budget forcing:
    • 모델이 thinking token을 제한 이상으로 생성하면 end-of-thinking token delimiter를 추가하여 thinking process 강제 종료
    • 더 많은 compute를 사용하고 싶다면 end-of-thinking token delimiter 생성을 억제하고 "Wait" token을 추가하여 추가 탐색 유도

주요 결과

  • s1-32B 모델은 test-time scaling을 보여줌 (그림 1)
  • s1-32B는 sample-efficient하며 OpenAI o1-preview를 능가 (그림 2)
  • 1,000개의 reasoning 샘플 선택 시 난이도, 다양성, 품질을 함께 고려하는 것이 중요
  • Budget forcing은 test-time scaling 방법론으로서 완벽한 제어 가능성과 강력한 성능을 제공

기여

  • Sample-efficient reasoning dataset (§2)과 test-time scaling (§3)을 생성하는 간단한 방법 개발
  • o1-preview와 경쟁력 있는 s1-32B 모델 구축 (§4)
  • 데이터 (§5.1)와 test-time scaling (§5.2)의 중요 요소 분석
  • 간단한 reasoning에 대한 향후 연구 동기 부여 (§6)

 

2. Reasoning data curation to create s1K

더보기

이 섹션에서는 먼저 §2.1에서 대규모 dataset을 생성하는 과정, 그리고 §2.2에서 이를 필터링하여 s1K를 만드는 과정을 설명합니다.

2.1. Initial collection of 59K samples

우리는 세 가지 핵심 원칙에 따라 16개의 다양한 소스에서 초기 59,029개의 질문을 수집합니다. 품질: Datasets은 높은 품질이어야 합니다. 우리는 항상 샘플을 검사하고, 예를 들어 형식이 잘못된 datasets은 무시합니다. 난이도: Datasets은 어려워야 하며 상당한 reasoning 노력이 필요합니다. 다양성: Datasets은 다양한 reasoning 작업을 포괄하기 위해 다양한 분야에서 파생되어야 합니다. 우리는 두 가지 범주의 datasets을 수집합니다.

기존 datasets의 선별: 가장 큰 소스는 온라인 웹사이트의 30,660개의 수학 문제로 구성된 NuminaMATH (LI et al., 2024)입니다. 또한 과거 AIME 문제 (1983-2021)를 포함합니다. 다양성을 높이기 위해 다양한 올림피아드의 천문학, 생물학, 화학, 컴퓨터 과학, 지리학, 수학, 물리학에 걸쳐 4,250개의 질문이 있는 OlympicArena (Huang et al., 2024a)를 추가합니다. OmniMath (Gao et al., 2024a)는 4,238개의 경쟁 수준의 수학 문제를 추가합니다. 또한 영어, 법률 및 논리를 다루는 SAT 및 LSAT와 같은 표준화된 시험의 질문을 특징으로 하는 AGIEval (Zhong et al., 2023)의 2,385개의 문제를 포함합니다. 다른 소스는 §B의 표 6을 참조하십시오.

양적 reasoning의 새로운 datasets: 기존 datasets을 보완하기 위해 두 개의 원본 datasets을 만듭니다. s1-prob는 Stanford University의 통계학과 박사 과정 자격 시험 (https://statistics.stanford.edu)의 확률 섹션에서 어려운 증명을 다루는 손으로 쓴 해설과 함께 182개의 질문으로 구성됩니다. 확률 자격 시험은 매년 개최되며 전문가 수준의 수학 문제 해결 능력을 요구합니다. s1-teasers는 양적 거래 포지션의 인터뷰 질문에서 흔히 사용되는 23개의 어려운 브레인 티저로 구성됩니다. 각 샘플은 PuzzledQuant (https://www.puzzledquant.com/)에서%EC%97%90%EC%84%9C) 가져온 문제와 해설로 구성됩니다. 우리는 가장 높은 난이도 ("Hard")의 예만 사용합니다.

각 질문에 대해 Google Gemini Flash Thinking API (Google, 2024)를 사용하여 reasoning trace와 해설을 생성하고 reasoning trace와 응답을 추출합니다. 이를 통해 질문, 생성된 reasoning trace 및 생성된 해설의 59K triplets이 생성됩니다. 우리 dataset의 예는 §C.2에 있습니다. 우리는 8-grams를 사용하여 평가 질문 (MATH500, GPQA Diamond, AIME24; §B.5)에 대해 모든 샘플을 오염 제거하고 데이터를 중복 제거합니다.

2.2. Final selection of 1K samples

59K개의 질문 풀에서 직접 training할 수도 있지만, 우리의 목표는 최소한의 자원으로 가장 간단한 접근 방식을 찾는 것입니다. 따라서 우리는 세 가지 핵심 데이터 원칙인 품질, 난이도 및 다양성에 의존하는 3단계 필터링을 거쳐 최소 1,000개의 샘플에 도달합니다.

품질: 먼저 API 오류가 발생한 질문을 제거하여 dataset을 54,116개의 샘플로 줄입니다. 다음으로 ASCII 아트 다이어그램, 존재하지 않는 이미지 참조 또는 일관성 없는 질문 번호 매기기와 같은 형식 문제와 함께 문자열 패턴을 포함하는지 확인하여 품질이 낮은 예제를 필터링하여 dataset을 51,581개의 예제로 줄입니다. 이 풀에서 최종 1,000개의 샘플에 대해 추가 필터링이 필요하지 않다고 인식되는 datasets에서 384개의 샘플을 식별합니다 (자세한 내용은 §B.4 참조).

난이도: 난이도를 위해 모델 성능과 reasoning trace 길이라는 두 가지 지표를 사용합니다. 각 질문에 대해 Qwen2.5-7B-Instruct와 Qwen2.5-32B-Instruct (Qwen et al., 2024)의 두 가지 모델을 평가하고, 각 시도를 참조 해설과 비교하는 Claude 3.5 Sonnet으로 정확성을 평가합니다 (채점 프로토콜은 §B.3 참조). Qwen2.5 토크나이저를 사용하여 각 reasoning trace의 토큰 길이를 측정하여 문제 난이도를 나타냅니다. 이는 더 어려운 문제가 더 많은 thinking token을 필요로 한다는 가정에 의존합니다. 채점을 바탕으로 Qwen2.5-7B-Instruct 또는 Qwen2.5-32B-Instruct가 올바르게 해결할 수 있는 질문은 너무 쉬울 수 있으므로 제거합니다. 두 가지 모델을 사용함으로써 모델 중 하나의 쉬운 질문에 대한 드문 실수로 인해 쉬운 샘플이 필터링되지 않을 가능성을 줄입니다. 이를 통해 총 샘플 수는 24,496개로 줄어들며 다양성을 기반으로 다음 라운드의 하위 샘플링을 위한 준비를 합니다. 이 두 모델을 사용한 필터링은 fine-tuning할 모델인 Qwen2.5-32B-Instruct에도 사용하므로 우리 설정에 최적화될 수 있지만, 모델 기반 필터링의 아이디어는 다른 설정에도 일반화됩니다.

다양성: 다양성을 정량화하기 위해 각 질문을 Claude 3.5 Sonnet을 사용하여 American Mathematical Society의 Mathematics Subject Classification (MSC) 시스템 (예: 기하학, 동적 시스템, 실해석 등)을 기반으로 특정 도메인으로 분류합니다. 이 분류 체계는 수학의 주제에 초점을 맞추지만 생물학, 물리학 및 경제학과 같은 다른 과학도 포함합니다. 24,496개의 질문 풀에서 최종 예제를 선택하기 위해 먼저 한 도메인을 무작위로 선택합니다. 그런 다음 난이도에서 동기 부여된 것처럼 더 긴 reasoning trace를 선호하는 분포에 따라 이 도메인의 한 문제를 샘플링합니다 (자세한 내용은 §B.4 참조). 1,000개의 총 샘플이 있을 때까지 이 과정을 반복합니다.

이 3단계 과정을 통해 50개의 다른 도메인에 걸쳐 있는 dataset이 생성됩니다 (표 5 참조). §5.1에서 세 가지 기준을 함께 사용하는 것이 중요함을 보여줄 것입니다. 품질, 다양성 또는 난이도에만 의존하면 더 나쁜 datasets이 생성되기 때문입니다. 우리 dataset의 예는 §C.2에 있습니다.

Reasoning data curation to create s1K 정리 노트: 핵심 요약

목표

최소한의 자원으로 강력한 reasoning 성능을 달성하는 모델 학습에 필요한 고품질 데이터를 구축

데이터 구축 과정: 2단계

  1. 59K 샘플 초기 수집:
    • 16개 다양한 소스에서 59,029개 질문 수집
    • 핵심 원칙: 품질, 난이도, 다양성
    • 기존 dataset 활용 (NuminaMATH, AIME, OlympicArena, OmniMath, AGIEval) + 2개 자체 dataset 제작 (s1-prob, s1-teasers)
    • Google Gemini Flash Thinking API 활용하여 각 질문에 대한 reasoning trace 및 해설 생성
    • 평가 질문에 대한 오염 제거 및 중복 제거
  2. 1K 샘플 최종 선택:
    • 3가지 기준에 따른 필터링: 품질, 난이도, 다양성
    • 품질: API 오류 및 형식 문제 있는 샘플 제거 + 고품질 dataset 우선 선택
    • 난이도: Qwen2.5-7B-Instruct, Qwen2.5-32B-Instruct 모델로 정답 여부 판단 + reasoning trace 길이 활용하여 난이도 측정 → 정답 맞춘 문제는 쉬운 문제로 판단하여 제거
    • 다양성: Claude 3.5 Sonnet 활용, Mathematics Subject Classification (MSC) 시스템 기반으로 질문을 도메인 분류 → 각 도메인에서 reasoning trace가 긴 문제 위주로 샘플링하여 최종 1K 샘플 선정

핵심

  • 단순함: 대규모 데이터셋 대신 1,000개의 고품질 샘플에 집중
  • 3가지 핵심 기준: 품질, 난이도, 다양성을 종합적으로 고려한 데이터 선별 방식
  • 모델 기반 필터링: 모델 성능과 reasoning trace 길이를 활용하여 난이도 높은 문제 선별
  • 도메인 분류: MSC 시스템 기반으로 질문을 분류하여 다양한 reasoning task를 포함하는 데이터셋 구축

 

 

3. Test-time scaling

더보기


3.1. Method

우리는 test-time scaling 방법을 1) Sequential (나중 계산이 이전 계산에 의존하는 경우, 예: 긴 reasoning trace)과 2) Parallel (계산이 독립적으로 실행되는 경우, 예: 다수결 투표)로 분류합니다 (Snell et al., 2024; Brown et al., 2024). 우리는 직관적으로 나중 계산이 중간 결과물을 기반으로 더 깊은 reasoning과 반복적인 개선을 가능하게 하므로 sequential scaling이 더 잘 확장될 것이라고 믿기 때문에 sequential scaling에 초점을 맞춥니다. 우리는 새로운 sequential scaling 방법과 이를 벤치마킹하는 방법을 제안합니다.

Budget forcing: 우리는 test time에 최대 및/또는 최소 thinking token 수를 강제하는 간단한 decoding-time intervention을 제안합니다. 특히, end-of-thinking token delimiter와 "Final Answer:"를 추가하여 최대 토큰 수를 적용하여 thinking 단계를 조기에 종료하고 모델이 현재 최상의 답변을 제공하도록 합니다. 최소값을 적용하기 위해 end-of-thinking token delimiter 생성을 억제하고 선택적으로 문자열 "Wait"를 모델의 현재 reasoning trace에 추가하여 모델이 현재 생성된 내용을 반추하도록 장려합니다. 그림 3은 이 간단한 접근 방식이 어떻게 모델을 더 나은 답변에 도달하도록 이끌 수 있는지에 대한 예시를 포함합니다.

Baselines: 우리는 다음을 사용하여 budget forcing을 벤치마킹합니다. (I) 모델에게 prompt에서 얼마나 오래 생성해야 하는지 알려주는 조건부 길이 제어 방법. 우리는 이를 세분화 정도에 따라 (a) Token-conditional control: prompt에서 thinking token의 상한을 지정합니다. (b) Step-conditional control: 각 단계가 약 100개의 토큰인 thinking 단계의 상한을 지정합니다. (c) Class-conditional control: 모델에게 짧은 시간 또는 긴 시간 동안 생각하도록 지시하는 두 개의 일반적인 prompt를 작성합니다 (자세한 내용은 §D.1 참조). (II) 미리 결정된 compute budget에 맞을 때까지 샘플링하는 Rejection sampling. 이 oracle은 길이에 따라 조건화된 응답에 대한 posterior를 포착합니다.

3.2. Metrics

우리는 다양한 방법에서 test-time scaling을 측정하기 위한 평가 지표로 desiderata 집합을 설정합니다. 중요하게도, 우리는 방법이 달성할 수 있는 정확도뿐만 아니라 제어 가능성 및 test-time scaling slope에도 관심을 갖습니다. 고려하는 각 방법에 대해 AIME24와 같은 고정된 벤치마크에서 test-time compute를 다양하게 하여 평가 집합 를 실행합니다. 이는 thinking 토큰으로 측정된 compute를 x축으로, 정확도를 y축으로 하는 piece-wise 선형 함수 를 생성합니다 (그림 1 참조, AIME24의 가장 오른쪽 점은 에 해당합니다). 우리는 세 가지 메트릭을 측정합니다.

 

 

 

여기서 , 는 미리 지정된 최소 및 최대 test-time compute 양을 나타냅니다. 우리의 경우 thinking 토큰입니다. 일반적으로 만 제한합니다. 생성된 토큰은 소비된 test-time compute 양에 해당하므로 이 메트릭은 방법이 해당 test-time compute 사용에 대한 제어 가능성을 어느 정도 허용하는지 측정합니다. 우리는 이를 완벽한 제어를 100%로 하여 백분율로 보고합니다.

 

Scaling은 piece-wise 선형 함수의 평균 기울기입니다. 유용한 방법의 경우 양수여야 하며 클수록 좋습니다.

 

 

Performance는 단순히 벤치마크에서 방법이 달성하는 최대 성능입니다. 단조롭게 증가하는 scaling을 가진 방법은 극한에서 모든 벤치마크에서 100% 성능을 달성합니다. 그러나 우리가 조사한 방법은 결국 평탄해지거나 제어 또는 context window 제한으로 인해 추가 scaling이 실패합니다.

 

 

 

목표

더 나은 성능을 위해 test time에 compute resource를 효율적으로 사용하는 방법 연구

핵심 아이디어

  1. Test-time scaling 방법 분류:
    • Sequential: 나중 계산이 이전 계산에 의존 (e.g., 긴 reasoning trace)
    • Parallel: 계산이 독립적으로 실행 (e.g., majority voting)
    • Sequential scaling에 집중: 직관적으로 더 나은 scaling 가능성 제시 (중간 결과를 바탕으로 더 깊은 reasoning 및 반복적 개선 가능)
  2. Budget forcing 제안:
    • Decoding-time intervention을 통해 thinking token 수 제어
    • 최대 토큰 수 제한: end-of-thinking token delimiter 및 "Final Answer:" 추가하여 thinking 단계 조기 종료
    • 최소 토큰 수 제한: end-of-thinking token delimiter 생성 억제 + "Wait" token 추가하여 추가 탐색 유도
    • 핵심: 간단한 방법으로 모델의 thinking process 제어 가능
  3. Baseline 설정:
    • 조건부 길이 제어 방법: prompt를 통해 생성 길이 제어
      • Token-conditional control: 토큰 수 상한 지정
      • Step-conditional control: thinking 단계 수 상한 지정
      • Class-conditional control: 짧은/긴 thinking 시간 지시
    • Rejection sampling: 미리 정해진 compute budget에 맞을 때까지 샘플링 (oracle 역할)
  4. Test-time scaling 평가 지표 (desiderata) 제시:
    • Control: test-time compute 사용에 대한 제어 가능성 (식 1)
    • Scaling: piece-wise 선형 함수의 평균 기울기 (식 2) - 클수록 좋음
    • Performance: 벤치마크에서 달성하는 최대 성능 (식 3)

핵심

  • Budget forcing: 간단하면서도 효과적인 test-time scaling 방법
  • Sequential scaling 강조: 깊이 있는 reasoning에 유리
  • 명확한 평가 지표 제시: Control, Scaling, Performance 3가지 지표를 통해 다양한 test-time scaling 방법 비교 분석