S1: Simple Test-time scaling (25.01) 논문 리뷰

S1: Simple Test-time scaling (25.01) 논문 리뷰

 

 

 

 

---

 1. 테스트 타임 스케일링(Test‑time scaling) 개념

• RLHF 방식으로 모델을 강화학습 후, 모델은 자연어 생성 단계에서 답의 정답과 길이가 다시 길어지는 경향이 있음. 이는 모델이 플래닝, 추론, 리플렉션(self-reflection) 기능을 사용하기 때문임.
  • 생성문 길이와 성능 간 높은 상관관계 존재 (생성문이 길어지면서 올바린 문장 생성을 위한 부가적인 기능 발현)
• DeepSeek R1에서도 관련된 내용 있음
  • “아하 순간(aha moment)”은 모델이 스스로 해결 방식을 반성하며 수정하는 순간이고, 이때 출력 문장이 확장된다는 점이 주목됨.
   

 

 

 2. S1 논문의 핵심 의문

• “강화학습 없이도, 단순하게 길고 다양한 chain‑of‑thought(CoT) 형식을 학습시키면 유사한 성능이 나오지 않을까?”
  • 또는 학습 없이도 길고 다양한 요소가 포함된 reasoning 능력이 강화학습이 아니더라도, SFT로도 발현될 수 있지 않을까?

 

 3. 데이터 구축: S1K (1,000개 샘플)

• 원 데이터 풀 59,000개 중 품질, 난이도, 다양성 기준으로 선별
  • 품질: 품질 낮거나 중복되거나 그림 참조 등 불필요한 샘플 제거
  • 난이도: 두 모델 중 하나라도 맞추는 쉬운 문제 삭제
  • 다양성: 다양한 도메인/주제 포함, 긴 CoT 중심으로 가중 샘플링
• 최종 1,000개 샘플(S1K) 확보

 

 

4. Budget Forcing (예측 시간 조절 트릭)

 

 

• 일반적으로 언어 모델은 최대한 빨리 답을 생성하려는 경향이 있으며, 이는 복잡한 문제를 해결하는 데 있어 충분한 사고를 거치지 않고 성급한 결론을 내리는 문제를 초래할 수 있음 
  • 연구팀은 이 문제를 해결하기 위해 두 가지 기법을 적용
    • 첫째, 모델이 일정한 토큰 수 이상을 생성할 때까지 사고 과정을 유지하도록 설정하여, 모델이 충분한 사고를 거친 후 답을 생성하도록 유도
    • 둘째, 모델이 답을 생성하려고 할 때 "Wait"이라는 추가적인 신호를 입력하여, 모델이 지금까지의 출력을 한 번 더 검토할 기회를 제공

 

 

• Budget : 생성한 토큰의 길이. 문제 해결을 위해 사용할 연산량의 규모 
  • Budget Forcing : 모델에게 사전에 정해진 Budget에 맞도록 생성 길이를 강제 
• Sequential : 
  
  • 생성된 토큰의 길이가 짧을 경우 "Wait" 토큰을 삽입하여 추가 생성 진행 
  • Budget을 넘어가는 생성의 경우 "Final Answer:" 을 삽입하여 정답 생성 강요 
    • 길이 비교를 실험을 위해 진행된 방법론 
   

• 학습 방법 
  • 길이 제한을 두고
    • 최대 토큰 수에 도달하면 강제 종료하고 바로 답을 생성하게 만듦.
    • 길이 연장은 모델이 끝내려 할 때 “Wait”을 덧붙여 CoT을 계속 이어가도록 유도.
      • “Wait”을 덧붙 이면 모델이 생각을 검토·수정하면서 정확도를 높이는 효과를 냄.

 

 

• Budget Forcing을 진행하는 경우 모델이 스스로 Self-Reflection을 진행
  • 추가된 Budget을 이용하여 Reasonig 능력 강화 가능함
  • 강화학습 등의 추가 학습 없이도 강화학습 목적 일부 달성 가능 

 

 

 5. 실험 결과

• Qwen2.5‑32B‑Instruct 모델을 S1K로 기반 SFT만 진행 → S1‑32B 모델 완성
• 테스트 타임에서 budget forcing 적용 시 MATH, AIME24 문제에서 o1-preview (OpenAI) 대비 최대 +27% 향상, AIME24 정확도 50→57%로 상승 GitHubarXiv+8arXiv+8arXiv+8
• 단순하지만 효과적인 접근: 수백만 데이터나 복잡한 강화학습 없이도 높은 성능 달성 arXivarXiv

 

 6. 추가 분석

• 각 필터 (quality/difficulty/diversity)가 없는 경우 S1K보다 성능 저하
• 원 데이터 전체 사용 시 S1K 대비 향상 미미
• dataset 선별과 budget forcing이 성능을 이끈 핵심 요인

---

 결론 & 의미

S1 논문의 가장 놀라운 점은 매우 단순한 메커니즘만으로 test‑time scaling 효과를 유도했다는 것입니다.

1. 손수 만든 1,000개 CoT dataset
2. 테스트 타임에 “Wait”으로 유도하는 budget forcing
3. 강화학습 없이 수월하게 o1-preview 수준 이상의 성능 달성

이는 작은 비용으로도 강력한 reasoning 언어 모델을 만들 수 있다는 점에서 실험적이자 실용적으로 큰 의의를 가집니다.

 

 

 

Recap. 핵심 정리 : 이건 꼭 기억하기 ! 

• Test-time scaling
  • Test-time scaling은 모델이 답을 생성할 때(inference/test time) 더 많은 계산 자원을 투입해서 성능을 향상시키는 방법
  • 기존 (Training-time scaling):
    • 모델 크기 키우기 (파라미터 수 증가)
    • 더 많은 데이터로 더 오래 훈련
    • 훈련할 때 컴퓨팅 파워 투입
  • 새로운 방식 (Test-time scaling)
    • 모델 크기는 그대로
    • 답할 때 더 오래 "생각"하게 만들기
    • 추론할 때 컴퓨팅 파워 투입
  • 실제 작동 방식 : S1 논문에서 보면 "Wait" 토큰을 추가해서 모델이 더 오래 생각하게 만드는 방식
  • 질문: "raspberry에 r이 몇 개 있나?" 일반적 답변: - 모델이 빠르게 "2개"라고 잘못 답함 Test-time scaling 적용: - 모델: "2개인 것 같은데..." - 시스템: "Wait" 토큰 추가 - 모델: "잠깐, 다시 세어보자... r-a-s-p-b-e-r-r-y... 3개네!"

 

 

개인적 감상 

 

• 강화학습 없이, 좋은 퀄리티의 적은 데이터로 SFT를 한다는 접근이 기업이 아닌 곳에서도 충분히 성능 좋은 reasoning model을 학습할 수 있도록 하는 방법론인 것 같아 굳 
• 그런데 실제로 서비스 시, 추론 모델의 경우에는 Think가 너무 길어지면 사용자들이 답변 받는 데에 시간이 오래 걸려 사용성이 떨어지는데 Test-time Scaling이라는 접근법이 실제 프로덕션에서 활용될 수 있는지는 잘 모르겠다 -> 이 부분 appendix에서 지적하긴 하네
  • 자원이 없는 한에서는 이게 맞는 건가 ?

 

+) OpenAI Test-Time Compute Control 해석

 

 

Class-conditional control OpenAI exposes test-time compute control to users via a “reasoning_effort” API parameter with three possible settings: low, medium, and high.3 The OpenAI documentation also states that “Reducing reasoning effort can result in faster responses and fewer tokens used on reasoning in a response." suggesting that they are unable to control test-time compute with guarantees. Thus, maybe OpenAI simply adjusts the prompt or system instruction depending on the reasoning effort desired. In Table 14, we show that separate prompts for short and long thinking allow us to control thinking time to some extent: Prompting the model to think for longer leads to longer thinking. However, it does not reliably improve performance and control is not precise. The current adherence to control may suffice when we only have three classes, but it might not scale to finer-grained classes. To compute Control reported in Table 3 for this method, we assume that prompting the model to think for a short time in Table 14 should produce fewer tokens than the default for AIME24, while the long prompt should produce more. As 8033 > 6109 and 9651 > 6109, one out of two follows our expected control thus Control is 50%.

이 텍스트는 S1 논문에 있던 OpenAI가 추론 시간에 컴퓨팅 자원을 어떻게 제어하는지에 대한 분석임.

 

📝 핵심 내용 해석

1. OpenAI의 "reasoning_effort" API

• 3단계 설정: low, medium, high
• 공식 설명: "추론 노력을 줄이면 더 빠른 응답과 더 적은 추론 토큰 사용 가능"
• 한계: 보장된 제어가 불가능하다고 인정

2. 실제 구현 추정

"maybe OpenAI simply adjusts the prompt or system instruction"

연구자들은 OpenAI가 단순히 프롬프트나 시스템 지시를 조정하는 방식으로 추론 노력을 제어한다고 추정함.

 

3. 실험 결과 (Table 14)

연구자들이 직접 테스트한 결과:

프롬프트 조정 방식:

• 짧은 추론 프롬프트 → 더 짧은 사고 과정
• 긴 추론 프롬프트 → 더 긴 사고 과정

문제점:

• ❌ 성능 향상이 신뢰할 수 없음
• ❌ 정밀한 제어 불가능
• ❌ 3단계는 괜찮지만 더 세밀한 제어에는 확장성 부족

4. 제어 성공률 계산

실험 데이터:

• 기본값: 6109 토큰
• 짧은 프롬프트 결과: 8033 토큰 (실패 - 더 길어짐)
• 긴 프롬프트 결과: 9651 토큰 (성공 - 더 길어짐)

결과: 2개 중 1개만 예상대로 작동 → 제어 성공률 50%

핵심 시사점

OpenAI의 한계

1. 진정한 test-time compute control이 아님
2. 단순한 프롬프트 엔지니어링 수준
3. 정밀하고 신뢰할 수 있는 제어 불가능

업계 전반의 과제

• 추론 시간 컴퓨팅 자원을 정밀하게 제어하는 것은 여전히 미해결 문제
• 현재 기술로는 "더 오래 생각하면 더 좋은 결과"를 보장할 수 없음
• 3단계 정도의 거친 제어는 가능하지만 세밀한 제어는 어려움

실무적 의미

이는 현재 "reasoning effort" 같은 기능들이 실제로는:

• 🎭 마케팅적 포장에 가까울 수 있음
• ⚙️ 기술적으로는 단순한 프롬프트 조정
• 📊 성능 보장 없는 확률적 효과

진정한 test-time compute scaling은 아직 연구 단계에 있다는 걸 보여주는 대목임.

https://github.com/openai/openai-python/blob/44d6210f101abedeb2dd68507fcffcb329df70ea/src/openai/types/chat/completion_create_params.py#L172

openai-python/src/openai/types/chat/completion_create_params.py at 44d6210f101abedeb2dd68507fcffcb329df70ea · openai/openai-pyt

 

 

 

---

Ref. 

ttps://arxiv.org/abs/2501.19393

s1: Simple test-time scaling

 

https://www.youtube.com/watch?v=D3lWvTwX8YU&t=1246s

https://discuss.pytorch.kr/t/s1-test-time-scaling/6060

s1: 테스트 시점 스케일링(Test-Time Scaling)을 단순하게 구현하는 방법에 대한 연구

https://github.com/simplescaling/s1

GitHub - simplescaling/s1: s1: Simple test-time scaling

 

https://hkust-nlp.notion.site/simplerl-reason

7B Model and 8K Examples: Emerging Reasoning with Reinforcement Learning is Both Effective and Efficient | Notion