기존 DeepSeek-R1의 전략은 새로운 턴이 시작되면 이전의 긴 Reasoning Trace를 버리는 방식이었습니다.
하지만 Tool-Calling 시나리오에서 이 방식은 치명적인 비효율을 낳습니다.
토큰 비효율성 (Token Inefficiency)
Agent가 도구를 여러 번 호출해야 하는 복잡한 작업을 수행한다고 가정해 봅시다.
모델이 문제를 분석하고 추론하여 도구 A를 호출합니다.
도구 A의 결과가 돌아옵니다.
(기존 방식) 이전의 추론 내용을 다 버리면 모델은 도구 A의 결과를 해석하고 다음 단계를 결정하기 위해 처음부터 다시 문제를 추론해야 합니다.
User Message 기반의 Context 관리
DeepSeek-V3.2는 이를 해결하기 위해 Context 관리 규칙을 재정의했습니다.
Reasoning Content는 "새로운 사용자 메시지"가 들어올 때만 삭제합니다.
도구의 실행 결과만 추가되는 상황이라면 이전의 Reasoning Trace를 그대로 유지합니다.
이를 통해 모델은 앞선 사고 과정을 기억한 채로 다음 도구를 호출하거나 답변을 생성할 수 있습니다.
모델은 이미 "추론 데이터(Non-agentic)"와 "도구 사용 데이터(Non-reasoning agentic)"를 각각 학습했습니다.
하지만 추론하면서 도구를 쓰는 데이터는 부족합니다.
이를 해결하기 위한 Cold-Start 전략은 Prompt Engineering에 있습니다.
Prompting Strategy
저자들은 모델이 명시적인 지시를 잘 따른다는 점을 이용했습니다.
System Prompt: 모델에게 최종 답변()을 내기 전에 반드시 태그 안에서 추론 과정을 거치도록 지시합니다. 동시에 Function Call에 대한 가이드라인도 포함합니다.
Data Composition:
Reasoning Data: 태그를 사용하여 추론 경로를 라벨링.
Agentic Data: 도구 호출 가이드 포함.
Hybrid (Cold-Start): 위 두 가지를 결합하여 추론 과정 중에 Multiple Tool Calls을 수행하도록 유도하는 프롬프트 사용.
초기에는 이 "도구 사용 중 추론" 패턴이 완벽하지 않더라도 모델이 간헐적으로 성공적인 Trajectory을 만들어내면 이후 Reinforcement Learning(RL)의 훌륭한 시드 데이터가 됩니다.
Cold-Start로 초기 능력을 확보했다면 RL을 통해 이를 강화해야 합니다.
DeepSeek 팀은 이를 위해 4가지 주요 도메인에서 대규모 합성/수집 데이터를 구축했습니다.
Search Agent (검색 에이전트)
Pipeline: DeepSeek-V3.2 기반의 Multi-Agent 파이프라인을 구축했습니다.
Question Construction: 웹 코퍼스에서 정보를 추출해 질문-답변 쌍을 생성.
Answer Generation: 다양한 설정(System Prompt, Checkpoint 등)을 가진 에이전트들이 후보 답변 생성.
Verification: 검색 능력을 가진 검증 에이전트가 후보군을 검증. "Ground-truth는 맞고 나머지 오답들은 확실히 틀린" 케이스만 선별합니다.
Optimization: Reliability, Helpfulness을 동시에 최적화하기 위해 Generative Reward Model을 사용합니다.
Code Agent (코드 에이전트)
GitHub의 Issue와 PR(Pull Request) 데이터를 활용하여 실제 소프트웨어 이슈 해결 능력을 학습합니다.
Build Pipeline: 수백만 개의 Issue-PR 쌍을 마이닝한 후 V3.2 기반의 자동화 에이전트가 패키지 설치, 의존성 해결, 테스트 실행을 수행하여 Reproducible 환경을 구축합니다.
Success Criteria:
F2P (False-to-Positive) > 0: Gold Patch 적용 시 실패하던 테스트가 통과해야 함 (이슈 해결).
P2F (Pass-to-Fail) = 0: 기존에 통과하던 테스트가 실패하면 안 됨 (Regression 없음).
엄격한 기준을 통과한 수만 개의 Python, Java, C++ 등 다국어 환경이 구축되었습니다.
Code Interpreter & General Agent
Code Interpreter: Jupyter Notebook 환경에서 수학, 논리, 데이터 사이언스 문제를 해결합니다.
General Agent: "Hard to solve, easy to verify" 1,827개의 태스크를 합성했습니다.
예: "특정 제약 조건을 만족하는 여행 일정 짜기"
Process: 에이전트가 DB와 Tool을 구축 -> Task 생성 -> Solution 생성 -> Verification Function 생성의 과정을 반복하며 난이도를 조절합니다.
RL Filter: V3.2 모델이 RL을 수행했을 때 Pass@100이 0이 아닌 태스크만 남겨 훈련 데이터로 사용합니다.
DeepSeek-V3.2는 MMLU-Pro, GPQA Diamond, AIME 2025 등 다양한 벤치마크에서 평가되었습니다.
특히 Tool-use 벤치마크에서는 모델을 'Thinking Mode'로 설정하여 평가를 진행했습니다.
Reasoning Performance
Competitors: GPT-5-high와 유사한 수준의 성능을 보였으며 Gemini-3.0-Pro보다는 소폭 낮은 성능을 기록했습니다.
Efficiency: 흥미로운 점은 오픈 소스 모델인 K2-Thinking과 비교했을 때 비슷한 점수를 내면서도 훨씬 적은 Output Token을 사용했다는 점입니다. 이는 추론 과정이 더 효율적으로 압축되었음을 의미합니다.
The Power of RL Budget
저자들은 성능 향상의 주요 원인을 RL Training Budget의 증대로 꼽았습니다.
"최근 몇 달간 RL 학습 예산을 늘릴수록 성능이 일관되게 향상되었으며 이미 RL 비용이 Pre-training 비용의 10%를 넘어섰다."
이는 Post-training 단계 특히 RL이 모델의 잠재력을 끌어올리는 데 얼마나 중요한지를 시사합니다.
Code & Agent Performance
SWE-bench Verified & Terminal Bench 2.0: 오픈 소스 LLM들을 압도하는 성능을 보여주며 실무 코딩 워크플로우에서의 가능성을 입증했습니다.
Tool-Use: Closed-source 모델들과의 격차를 상당히 좁혔습니다. 하지만 DeepSeek-V3.2의 과도한 자기 검증 경향이 발견되었습니다. 모델이 너무 신중하게 스스로를 검증하려다 보니 Trajectory가 길어져 128K Context Window를 초과하는 경우가 빈번히 발생했고 이는 성능 저하로 이어졌습니다.
섹션에서 가장 눈길을 끄는 것은 바로 DeepSeek-V3.2-Speciale입니다.
What is 'Speciale'?
일반적인 DeepSeek-V3.2는 배포 비용과 레이턴시를 고려하여 Length Constraint Reward Model을 통해 답변 길이를 억제하며 학습되었습니다. Speciale 모델은 이 제약을 제거하고 오직 성능 극대화에 초점을 맞춘 모델입니다.
Performance
State-of-the-Art: 여러 벤치마크에서 Gemini-3.0-Pro를 능가했습니다.
Competition: 별도의 타겟 트레이닝 없이도 IOI 2025(정보올림피아드), ICPC World Finals에서 금메달 수준의 성과를 달성했습니다.
Math: IMO 2025와 CMO에서도 금메달 커트라인을 넘겼습니다.
The Trade-off
하지만 Speciale 모델은 일반 V3.2에 비해 토큰 효율성이 매우 떨어집니다. 추론 비용이 매우 비싸기 때문에 실서비스용으로는 적합하지 않지만 Token Efficiency가 향후 연구의 핵심 과제임을 보여줍니다.
Search Agent 시나리오에서는 128K라는 긴 문맥도 부족할 때가 많습니다(테스트 케이스의 20% 이상이 초과). 이를 해결하기 위한 Test-time Compute Scaling 전략이 소개되었습니다.
Strategies
토큰 사용량이 80%를 넘을 때, 어떻게 대처할 것인가?
Summary: 이전 기록 요약 후 재개.
Discard-75%: 앞쪽 75%의 Tool history 삭제.
Discard-all: 이전의 모든 Tool history 삭제 (Reset).
Results
실험 결과, 가장 단순해 보이는 Discard-all 전략이 효율성과 성능(Score 67.6) 면에서 우수한 성과를 보였습니다. 이는 복잡한 요약보다 과감한 문맥 정리가 Agent의 장기적인 문제 해결에 더 유리할 수 있음을 시사합니다. 병렬 스케일링과 유사한 수준의 성능을 훨씬 적은 스텝으로 달성한 결과입니다.
RL is Key: Pre-training 비용의 10% 이상을 RL에 투자함으로써 성능을 비약적으로 끌어올렸습니다.
Speciale Model: 토큰 제약을 푼 모델은 이미 SOTA(Gemini-3.0-Pro)를 넘어섰습니다. 남은 과제는 '효율성'입니다.
Agent Generalization: 합성 데이터를 통한 RL이 다양한 Agent 업무 수행 능력의 핵심입니다.
Practical Challenge: 긴 추론 과정과 Tool Use를 결합할 때 발생하는 Context Overflow 문제는 여전히 해결해야 할 과제이며, Discard-all과 같은 전략적인 Context Management가 필수적입니다.