DeepSeek-Math 数理逻辑解码

🔙 返回 14.1-DeepSeek 家族总览

本文是对 DeepSeek-Math 技术报告(arXiv:2402.03300)中数学推理机制与强化学习算法的深度解读，聚焦「为什么 GRPO 有效」以及「数学数据工程的底层逻辑」。

1. 数学预训练的数据工程: 从互联网「淘金」

1.1 为什么 Common Crawl 比 arXiv 更重要?

DeepSeek-Math 的一个反直觉发现是:arXiv 论文对数学推理能力的提升效果非常有限。

论文表 1 中的对比显示，MathPile(85%+ 来自 arXiv)在几乎所有数学基准上都低于「无数学训练」基线。这个发现挑战了当时的主流假设——许多数学相关研究(如 Llemma、Minerva)大量使用 arXiv 论文作为数学预训练数据。

为什么 arXiv 效果差?

符号密度 vs 推理密度: arXiv 论文包含大量数学符号和公式，但这些符号往往处于「定义和定理陈述」层面，而非「逐步推理」层面。模型从 arXiv 学到的是「如何写数学符号」，而非「如何解数学题」。
语言风格差异: arXiv 论文使用高度形式化的学术语言，与竞赛题、应用题的表述风格差异巨大。预训练在 arXiv 上的模型在面对 GSM8K(小学应用题)或 MATH(竞赛题)时，面临严重的分布偏移。
缺乏交互性: 好的数学训练数据应该包含「问题 → 尝试 → 错误 → 修正 → 解答」的完整链条。arXiv 论文是 polished 的最终结果，没有展示推理过程中的试错和修正。

相比之下，Common Crawl 中的数学网页(如 StackExchange、math forums、教育网站)包含了:

多样化的数学问题表述(从应用题到竞赛题)
逐步解答过程(常包含多种解法的讨论)
多语言内容(中英文数学教育的差异在数据中得到体现)
更贴近真实使用场景的问题

数据与实验节点: DeepSeek-Math Corpus 120B token 的来源全部是网页(Common Crawl)，没有任何 arXiv。这个决策在当时是有争议的——同期 Llemma 使用 OpenWebMath + AlgebraicStack + arXiv(比例 4:1:2)，Minerva 使用数学网页 + 数学论文。DeepSeek-Math 的实验结果(arXiv 无益甚至有害)为这个纯网页策略提供了坚实的实证支持。这也说明，数据质量的核心指标不是「看起来有多专业」，而是「是否包含模型需要学习的推理模式」。

1.2 四迭代 fastText 分类器的工程细节

DeepSeek-Math 的数据收集流水线是一个精妙的「自举」(bootstrapping)过程:

迭代	正例来源	新增域名识别方法	收集数据量	累计数据量
第 1 轮	OpenWebMath(50 万)	fastText 分类器初版	~40B token( top 排名)	~40B
第 2 轮	第 1 轮正例 + 新域名标注页	域名收集率 >10% 的标注	新增	~60B
第 3 轮	第 2 轮扩展种子	同上	新增	~100B
第 4 轮	第 3 轮扩展种子	同上	少量新增	120B

停止准则:第四轮中近 98% 的数据已在第三轮收集。这说明分类器在第三轮后已接近收敛，继续迭代的边际收益极低。

工程落地视角: 这个迭代策略有几个值得学习的工程细节。第一，「域名级分析」而非「页面级分析」是关键洞察——如果 mathoverflow.net 有 50% 的页面被分类为正例，那么该域名下未被收集的页面也很可能是正例，即使分类器对它们的置信度不高。第二，人工标注 URL 而非页面——这大大减少了标注工作量，一个 URL 模式(如 /questions/)可以覆盖数百万个页面。第三，fastText 的配置(256 维向量、3-gram、3 轮训练)是一个轻量但有效的选择——在 100 万样本(50 万正 + 50 万负)上训练只需几分钟，却能达到足够的分类精度。

1.3 多语言数学数据的隐性价值

DeepSeek-Math Corpus 的一个重要特性是「多语言」，这主要体现在中文数学内容的显著比例上。论文中的对比实验揭示了这一特性的价值:

以英文为中心的语料库(OpenWebMath、Proof-Pile-2)在中文 CMATH 基准上提升有限(Proof-Pile-2 仅 19.9%)，甚至可能损害性能(MathPile 降至 1.2%)。
DeepSeekMath Corpus 在 CMATH 上达到 41.5%，远超所有对比语料库。

这背后的原因不是「中文数学题更难」或「中文数据质量更高」，而是数学教育在不同语言中的差异。中国 K-12 数学教育强调代数变形、方程求解和几何证明，而英美数学教育更侧重应用题和统计思维。多语言数据让模型接触到更多样化的解题策略和数学概念表述，从而提升了跨语言的泛化能力。

2. GRPO: 强化学习的「降本增效」革命

2.1 PPO 的痛点: Critic 模型的双重负担

PPO 是 RLHF 的标准算法，但在大语言模型训练中存在明显的效率问题:

显存翻倍: Critic 模型通常与策略模型等大，导致显存占用翻倍。对于 7B 模型，策略 + Critic + 奖励模型 + 参考模型共需约 4 × 7B = 28B 参数的显存。
训练不稳定: Critic 模型需要与策略模型协同训练。Critic 对价值的估计如果不准确，会导致优势计算偏差，进而引发策略更新的不稳定。
超参数敏感: Critic 的学习率、更新频率、损失权重等超参数需要精细调优，增加了实验成本。

2.2 GRPO 的核心思想: 用组内相对优势替代 Critic

GRPO 的关键洞察是:对于数学问题这类「答案明确」的任务，不需要学习一个复杂的 Critic 模型来估计状态价值。相反，可以从同一问题的多个输出中推断出「相对质量」:

A_i = \frac{r_i - \text{mean}(\{r_j\}_{j=1}^{G})}{\text{std}(\{r_j\}_{j=1}^{G})}

这个公式的直觉是:

如果某个输出的奖励高于组内平均，它应该被鼓励(优势为正)。
如果低于平均，它应该被抑制(优势为负)。
标准化(除以标准差)使得优势值在不同问题上具有可比性，避免了某些问题天然奖励范围大而导致的梯度规模差异。

架构细节节点: GRPO 的组大小 $G$ 是一个关键超参数。太小(如 $G=2$ )时，均值估计不稳定;太大(如 $G=64$ )时，采样成本过高。论文中使用的 $G$ 通常在 4-16 之间。另一个细节是「奖励来源」:GRPO 可以使用规则奖励(如数学问题的答案正确性)或模型奖励(如奖励模型的打分)。在 DeepSeek-Math 中，数学问题使用规则奖励(因为答案可以精确验证)，这使得 GRPO 的优势计算非常干净——没有奖励模型本身的噪声。

2.3 GRPO 与 PPO 的实证对比

论文提供了 GRPO 相比 PPO 的资源节省数据:

维度	PPO	GRPO	节省比例
显存占用	策略 + Critic + 奖励 + 参考	策略 + 奖励 + 参考	~25-30%
训练稳定性	Critic 估计偏差导致波动	组内均值天然平滑	显著提升
超参数数量	Critic LR、更新频率、权重等	组大小、裁剪阈值	减少
实现复杂度	需要维护 Critic 的训练循环	仅需策略模型训练循环	简化

谱系与影响节点: GRPO 在 DeepSeek-Math 中首次提出时，主要用于数学问题的强化学习。但其设计足够通用，后续被 DeepSeek-V2(通用 RL)、DeepSeek-Coder-V2(代码 RL)和 DeepSeek-R1(推理 RL)全面采用。在 DeepSeek-R1 中，GRPO 的组大小扩大到 16-64，奖励信号从单一的「答案正确性」扩展到「格式奖励 + 过程奖励 + 答案奖励」的组合。GRPO 的成功也影响了开源社区——后续许多复现 DeepSeek-R1 的项目(如 Open-R1、TinyZero)都将 GRPO 作为默认的 RL 算法。

2.4 统一范式: 理解后训练方法的演进

DeepSeek-Math 提出的统一范式将 RFT、DPO、PPO 和 GRPO 视为同一谱系上的不同变体，其核心差异在于三个维度:

                    数据来源
                   /          \
              离线采样      在线采样
                 |            |
    RFT ────────┤            ├──── PPO (Critic)
    DPO ────────┤            ├──── GRPO (无 Critic)
                 |            |
              规则/模型奖励   规则/模型奖励

这个范式的价值在于:

概念清晰: 不再将 RFT/DPO/PPO/GRPO 视为互不相关的独立方法，而是理解它们为同一框架下的参数选择。
迁移方便: 如果一个方法在某个任务上效果不佳，可以根据范式分析是哪个维度出了问题(数据?奖励?算法?)，然后有针对性地调整。
组合创新: 可以混合不同维度的选择，例如「在线采样 + 规则奖励 + DPO 风格的目标函数」。

3. 从代码模型到数学模型: 能力迁移的底层机制

3.1 为什么代码预训练有助于数学推理?

DeepSeek-Math 的一个核心假设是:从代码模型初始化比从通用模型初始化更好。论文通过实验验证了这一假设，但没有深入解释其机制。这里我们从工程角度分析其底层原因:

结构化思维: 代码编写要求严格的逻辑顺序(变量定义 → 计算 → 条件判断 → 输出)。这种「逐步构造」的思维模式与数学证明中的「逐步推导」高度一致。
符号操作: 代码中的变量赋值、函数调用和表达式求值，与数学中的代数变形、公式代入和数值计算在底层操作上是同构的。
精确性: 代码不允许模糊——一个语法错误或类型不匹配就会导致编译失败。这种对精确性的要求训练了模型「仔细验证每一步」的习惯，这对数学推理至关重要。
工具使用: 代码模型已经学会了「什么时候调用函数、如何传递参数、如何处理返回值」。这种能力直接迁移到「使用 Python 解决数学问题」的场景中。

论文表 4 的数据支持了这一分析:DeepSeek-Coder-Base-v1.5 7B 在 GSM8K(43.2%)和 MATH(19.2%)上已经显著优于通用模型 Mistral 7B(40.3% 和 14.3%)，说明代码预训练已经赋予了模型一定的数学推理基础。

3.2 数学预训练对通用能力的正向迁移

与「代码 → 数学」的迁移同样有趣的是「数学 → 通用」的迁移。DeepSeekMath-Base 7B 相比其前身 DeepSeek-Coder-Base-v1.5:

MMLU: 49.1% → 54.9%(+5.8%)
BBH: 55.2% → 59.5%(+4.3%)
HumanEval: 43.2% → 40.9%(-2.3%)
MBPP: 60.4% → 52.6%(-7.8%)

通用推理能力的提升说明数学预训练增强了模型的「逻辑推导」和「抽象思维」能力，而这些能力是跨领域的。代码能力的轻微下降则提示了「灾难性遗忘」的风险——虽然 20% 代码数据 + 10% 自然语言数据的配比已经有效缓解了遗忘，但代码能力的峰值仍需要更高比例的代码数据来维持。

设计动机节点: 这个权衡直接影响了后续 DeepSeek-Coder-V2 的数据配比决策。DeepSeek-Coder-V2 选择 60% 代码 + 10% 数学 + 30% 自然语言，而非 DeepSeek-Coder 的 87% 代码 + 13% 自然语言——这意味着团队从 DeepSeek-Math 的实验中认识到，数学数据不仅对数学能力有益，对通用推理也有显著增益，因此值得在代码模型的预训练中分配一定比例。

4. 数学推理的评测陷阱与数据污染

4.1 数据污染的不可避免性

DeepSeek-Math 采用了严格的去污染措施(10-gram 过滤 + 精确匹配)，但论文也坦诚地指出:

"尽管我们尽最大努力收集最新的代码问题进行模型测试，但数据污染的可能性无法完全排除。"

数学评测中的数据污染尤其难以防范，因为:

问题表述的变体: 同一数学问题可能有数十种不同的文字表述，n-gram 过滤无法捕捉语义层面的重复。
解答的广泛传播: 数学竞赛题的解答在论坛、博客、教育网站上广泛存在，即使问题本身被过滤，模型也可能从解答中「学到」解题模式。
核心知识的天生重叠: 某些数学问题测试的是基础定理的应用(如勾股定理、二次方程求根公式)，这些知识无论如何都无法从训练数据中完全排除。

4.2 评测设计的改进方向

基于 DeepSeek-Math 的经验，更可靠的数学评测应该:

动态更新题库: 像 LeetCode 竞赛基准那样，持续收集最新题目，确保测试数据不会出现在训练集中。
人工原创题目: 聘请数学家设计全新的、从未公开过的问题。
过程评估而非仅结果评估: 不仅看最终答案是否正确，还评估推理过程的合理性。这可以通过过程奖励模型或人工评判来实现。
跨语言泛化测试: 在训练时未见过的语言上测试数学能力，以检验模型是否真正理解了数学概念而非记忆了特定语言的表述模式。

5. 未解问题与未来方向

5.1 过程奖励的缺失

DeepSeek-Math 使用的是「结果监督」(outcome supervision)——仅在最终答案上给予奖励。这在简单问题上有效，但在复杂多步推理中存在局限:

一个 10 步推理中，如果第 5 步出错，后续 5 步即使完全正确也无法得到正确答案。结果奖励无法区分「前 5 步正确后 5 步出错」和「前 5 步出错后 5 步正确」的输出。
模型无法从「部分正确」的输出中学习——只要最终答案错误，整个输出就被惩罚。

后续 DeepSeek-R1 通过引入「过程奖励模型」(PRM)部分解决了这个问题，但 PRM 的训练成本高且泛化能力有限。如何设计既有效又高效的过程监督机制，仍然是开放问题。

5.2 几何与定理证明的短板

论文明确指出 DeepSeekMath 在几何和定理证明方面的能力相对较弱，特别是在处理与三角形和椭圆相关的问题时。这反映了当前大语言模型的一个普遍局限:

几何需要空间推理: 三角形、圆、椭圆等几何对象的关系需要空间想象能力，而自回归语言模型本质上是一维序列处理器，缺乏对二维/三维空间的天然理解。
定理证明需要反向搜索: 证明一个定理通常需要从结论出发反向寻找前提(「要证 A，只需证 B;要证 B，只需证 C...」)，这种反向搜索与自回归模型的正向生成方向不一致。

未来的改进方向可能包括:

多模态融合:将几何图形作为图像输入，让模型同时处理视觉和文本信息。
符号-神经混合:结合符号推理引擎(如自动定理证明器)和神经网络，让各自发挥所长。
专门的证明搜索算法:在推理时引入树搜索(如 MCTS)来探索多种证明路径。

5.3 从 7B 到更大规模的scaling

DeepSeek-Math 的所有实验都在 7B 规模上进行。一个自然的问题是:如果将同样的数据和方法扩展到 70B 或更大规模，性能会如何变化?

从 Scaling Law 的角度，更大规模的模型在数学推理上应该会有显著提升。但 DeepSeek-Math 的核心发现——「高质量数据 + 高效算法 > 纯参数规模」——提示了一个重要的成本效益考量:与其训练一个 70B 模型，不如将一个 7B 模型训练得更好(更多数据、更好的 RL)。

后续 DeepSeek-V3(236B MoE)和 DeepSeek-R1 的实验表明，当规模足够大时，纯 RL(无需 SFT)就能激发强大的推理能力。这意味着 DeepSeek-Math 的「SFT + RL」两阶段流程在小模型上是必要的，但在超大规模模型上，RL alone 可能就足够了。