DeepSeek-V4.1 Data Recipe 和特点

From DeepSeek-V4.1-Flash:

Instead, our efforts are concentrated almost entirely on what the model is trained on rather than how it is optimized: we invest in large- scale, automated pipelines for data synthesis and environment construction.

Pretraining Data Recipe

Text Data

理念变化：从单条样本质量，到关注不同语料之间的交互和独特的信息增益。几个亮点：

1. 设计一条跨模型参数量 x 训练数据量的 scaling ladder；

   • 推测做法是用一系列小模型跑不同的（N 参数，D 数据量）组合，在统一评测上做性能，拟合出随规模变化的趋势，从而在正式大模型开跑之前推出最优的数据配比；
   • 这个事情是加速迭代的关键，但是要看拟合的好不好；

2. 过滤掉“低信息增益”内容

   • 举了两个例子，分别是 1) 弱模型输出 2) 低质机翻文本，这类内容叫做“隐式重复”，把已有信息换个说法，对模型的信息增益很有限
   • 推测做法是看 perlexity + 语义级别去重，困惑度的做法可以用 FastText 来坐在分类和 confidence，去除掉定义不明确的内容(也可以用 Fast-DetectGPT)，语义级别去重可以看 LLM 的大规模文本去重技术

3. 探索 Model-in-the-loop 模式

   • 关于这点，Report 里没有详细讲，我猜测是关于 text rewrite 部分，通过引入 model 不断提升 rewrite 质量或者 QA 数据的质量；

4. 引入更细粒度的领域专家来构建更细粒度的质量评估

Multi-Modal Data

多模态数据主要有三类：Image-Text Pair、Image-Text Interleave、Domain Specific Data，背景是 DS 发现自己的爬虫过度偏向 Text 内容，所以重新从 CommonCrawl 里爬取来补充多模态覆盖；

• Image-Text Pair: 从网页抽图和 alt text，用图文相关性阈值过滤，按图像语义去重

  • 图文相关性可以用 CLIP/DataComp 实现(映射到同一个 emb 空间)，也有其他的玩法，比如 SIEVE 让模型描述 Image 然后用 caption 做语义对比，BLIP；图像语义过滤和 text 的语义过滤没有区别；

• Image-Text Interleave: 主要来自网页和 PDF，因为多模态的处理 CPU/磁盘开销较大，把构建流水线变成多阶段：启发式+统计过滤 -> 去重 -> 质量模型筛选 -> 组装 interleave data -> 二次过滤去重 -> SmolVLM 做严格质量打分；

Post-Training Data Recipe

数据合成方法论

数据合成的最大难点就是“找到好的 Task”，这个能力基本上构成了每家基模公司自己在特定领域的护城河，比如智谱的 Coding、Kimi 的知识类任务等。

Deepseek 通过训两个模型的方式来解决这个问题：

• Task Constructor：目标是让构造的 Task 不太难也不太容易；
• Task Solver: 目标是判断 Task 难度；

类似这篇 paper 的思想，Absolute Zero: Reinforced Self-play Reasoning with Zero Data，让同一个模型承担出题和解题角色，用执行环境验证代码任务，并通过多次求解估计成功率。

• 全部成功 / 全部失败不给 reward
• 成功任务率，成功率低，reward 越高

General Agent

1. 鼓励员工把最新模型接入日常工作流，回传交互数据和反馈
2. 根据回传数据里观察到的接口，构造一大批 mocked tools，复刻真实工具/系统的输入格式，输出结构、API、行为约束等，覆盖常见 SaaS、企业应用和专门的业务后端
3. 大规模收集内部员工提交基于负面反馈和失败案例，生成单轮、多轮 Agent 的环境，实现失败的系统性投放，以及针对模型弱点的定向 RL

这里我觉得有一个很好的 insight: 如果从日常对话来看，大部分数据/问题，其实都是“垃圾数据”，比如模糊指令、简单的知识问答等等，所以如果能从日常员工的工作过程里找数据，本身就已经是符合真实场景的高质量数据了。

这里可以参考 Anthropic 当年的记录：

《Summer 2025 Sabotage Risk Report》明确说明：
- 员工日常使用 Claude.ai 和 Claude Code。
- 通过产品内点踩按钮和内部反馈 Slack 频道报告异常行为。
- 另有覆盖多数内部 Claude Code 使用的自动离线监测，并人工审计少量记录。

另外基于 trajectory 轨迹数据还原环境，可以参考之前阿里的 Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments: 不追求环境的大而全，还原 trajectory 的必要条件，并在此基础之上做合成，会更加符合客户使用的真实场景。

Coding Agent

两个数据来源：

1. 从员工伙伴的 Coding Agent 会话中，筛选出高复杂度或模型表现差的任务，并按轨迹去重。
2. 满足 star 数阈值的公开 Github 仓库

环境构建由专门的 Agent 协作完成：

• 一个 Agent 判断项目能否在容器里 build 并跑通，能否自动验证。能的话，选择某个 commit 作为起点，设计若干足够复杂的实现方向，产出评测点和构建报告，并按需从外部拉取外部资源。
• 另一个 Agent 在容器里配置依赖、设置初始工作目录、准备测试代码和任务描述，进行自测，并清除会泄露答案的痕迹，再打包成新的镜像层。
• 多个不同 Agent 尝试解题，再由独立的质检 Agent 审查环境和解题轨迹，检查环境问题、事实错误、评测点与描述不匹配、Hack 风险。
• 如果不过关，就交给修复 Agent 去修问题，调整过易过难的评测点，重新进验证。

OPD

全词表做 OPD，用 40+ 个 Teacher 模型，因为不同领域最佳 teacher 可能来自不同开发阶段，甚至架构和 student 都不同，基础设施支持近乎无限数量，异构的 teacher 之间要实现低成本切换（在推理 infra 上做了一些优化，比如把 Teacher 推理的 hidden states 做缓存，重新排布样本等等）。

这里相比 V4 有比较大的优化：

一次 OPD 流程

Student 自己生成解题轨迹
           ↓
Teacher 读取这条轨迹，在相同前缀上给出预测分布
           ↓
Student 与 Teacher 的全词表分布计算 reverse KL
           ↓
反向传播，更新 Student