Deepseek math V2的价值

关注

原创最新推荐文章于 2026-11-08 12:08:08 发布 803 阅读 AI 写同款· GEO 优化 ›

DeepSeek-V2与V2.5技术对比：数学推理与代码生成能力实测大语言模型的版本迭代是衡量AI公司工程落地能力的关键指标。从原理上看，模型升级通常围绕架构优化（如RoPE位置编码改进、GQA分组查询注意力）、训练数据增强及后训练对齐策略展开；其技术价值体现在推理效率提升、长上下文稳定性增强与领域任务泛化性突破。在实际应用场景中，数学推理与代码生成已成为检验模型逻辑能力与工具调用素养的核心测试场，广泛应用于教育辅助、低代码开发与自动化运维等方向。本文基于DeepSeek官方已发布的V2与V2.5两个真实可验证版本，结合HuggingFace模型卡、arXiv技术报告及本地阅读详情

我之前说过讲一下math V2的论文，今天来还个愿

其实为什么这论文没人重视呢？主要是两个原因：

1- 绝大多数人讨厌数学

2- 之前出过一个prover2，大家也不知道干啥的也和数学有关，然后又来一个

讨厌数学就不说了（甚至有人讨厌香菜），主要说第二个，prove2为什么让人不知道是干啥的？

它其实是lean 生成器，你一定会问什么是lean，现在都是lean4

lean4 是 MS Research 开发的交互式定理证明器，一种函数式编程语言 + 数学验证工具，实在理解不了你就当他是python就完了，但是主要for 数学定理证明

比如：

传统数学：写证明如散文“显然由勾股定理所示，巴拉巴拉...”，人类读懂（小学就这么教的），但电脑无法“验证”每步是否严谨（它不理解）。

Lean 形式化：一切写成代码，电脑逐行编译/验证。证明 = 可执行程序，零歧义、机器查证

传统证明像“手写作文”（主观，比如你高考答最后几道大题的时候），Lean 像“Python 代码 + 测试用例”（运行即验）

Deepseek为什么要玩 Lean呢？

数学家用它形式化数论/几何定理（已形式化 10万+ 定理的 Mathlib 库），所以你有可以证明的dataset了么
AI 数学增强：生成 Lean 代码， Lean 运行验证，证明成功/失败因为有了binary的 feedback，可以完美 RL 奖励闭环。
Prover-V2 专为 Lean 优化 tokenizer，支持 theorem、by、sorry 等语法。现在可以生成也能看懂lean代码了

举个例子：

比如我们要算一个定理，前 n 个奇数的和等于 n^2：

这个对应lean声明（formal state）就是

import Mathlib.Data.Nat.Basicimport Mathlib.Algebra.BigOperators.Basic
open BigOperators
/--The sum of the first `n` odd numbers equals `n^2`:`∑_{k = 0}^{n-1} (2k+1) = n^2`.-/theorem odd_sum_square (n : ℕ) :    ∑ k in Finset.range n, (2 * k + 1) = n ^ 2 := by  -- proof to be filled  admit

然后把这个东西改成prompts发给prover2里的V3（prover2是两个模型组成的一个V3，一个7B的子处理器）

V3接到一个这样的prompts

[System] You are a mathematical reasoning expert and Lean 4 proof designer.Given a math problem and its Lean formal statement, you should:
1. Explain the solution in natural language (chain-of-thought).2. Decompose the proof into clear subgoals.3. Produce a Lean 4 proof skeleton which follows your plan and   contains `sorry` placeholders for subgoals.
[User]Problem (informal):Prove that the sum of the first n odd numbers equals n^2.
Formal statement (Lean 4):theorem odd_sum_square (n : ℕ) :  ∑ k in Finset.range n, (2 * k + 1) = n ^ 2 := by  ?_

处理完了，就成了一个COT的解题的视角+lean的骨架了，紧紧差一些细节的subgoal没去证明

[DeepSeek-V3]
(1) Natural-language chain-of-thought (high-level plan):
We prove by induction on n.
Base case: n = 0. The sum over an empty range is 0, and 0^2 = 0.
Inductive step: assume that for some n we have  ∑_{k < n} (2k + 1) = n^2.Then  ∑_{k < n+1} (2k + 1)= (∑_{k < n} (2k + 1)) + (2n + 1)= n^2 + (2n + 1)= (n + 1)^2.Thus, by induction, the equality holds for all n.
(2) Subgoal decomposition (informal):
Subgoal 1 (base case):  Show: ∑_{k < 0} (2k+1) = 0^2.
Subgoal 2 (range decomposition):  For all n,  ∑_{k < n+1} (2k+1) = (∑_{k < n} (2k+1)) + (2n+1).
Subgoal 3 (inductive hypothesis usage):  Assume IH: ∑_{k < n} (2k+1) = n^2.  Show: ∑_{k < n+1} (2k+1) = (n+1)^2.
Subgoal 4 (algebraic identity):  Show: n^2 + (2n+1) = (n+1)^2.
(3) Lean 4 proof skeleton with `sorry`:
import Mathlib.Data.Nat.Basicimport Mathlib.Algebra.BigOperators.Basic
open BigOperators
theorem odd_sum_square (n : ℕ) :    ∑ k in Finset.range n, (2 * k + 1) = n ^ 2 := by  -- induction on n  induction' n with n ih  · -- Subgoal 1: base case n = 0    -- ∑_{k < 0} (2k+1) = 0^2    -- (use simp to evaluate the empty sum)    sorry  · -- Subgoal 2 + 3 + 4: inductive step    -- We rewrite the sum over `range n.succ`.    have h_decompose :        ∑ k in Finset.range n.succ, (2 * k + 1)          = (∑ k in Finset.range n, (2 * k + 1)) + (2 * n + 1) := by      -- Subgoal 2: range decomposition      sorry
    -- Use the induction hypothesis to replace the partial sum by n^2.    have h_using_IH :        (∑ k in Finset.range n, (2 * k + 1)) + (2 * n + 1)          = n ^ 2 + (2 * n + 1) := by      -- Subgoal 3: apply IH      sorry
    -- Now prove the algebraic identity n^2 + (2n+1) = (n+1)^2.    have h_algebra :        n ^ 2 + (2 * n + 1) = (Nat.succ n) ^ 2 := by      -- Subgoal 4: algebraic manipulation      sorry
    -- Combine the equalities to close the goal.    -- target: ∑_{k < n.succ} (2k+1) = (n.succ)^2    -- by transitivity using h_decompose, h_using_IH, h_algebra    sorry

下面open Bigoperators的就是lean4的基本骨架了，然后每一个-- 是一个subgoal，sorry留着当占位符，交给7b的小模型去证明了

举一个子目标的例子：

[System] You are a Lean 4 theorem prover. Your task is to fill in the proofof the given lemma, without changing its statement.
[User]Context:
import Mathlib.Data.Nat.Basicimport Mathlib.Algebra.BigOperators.Basic
open BigOperators
-- `odd_sum_square` is being proved by induction on `n`.-- In the inductive step, we have the following subgoal:
theorem range_decompose_subgoal (n : ℕ) :    ∑ k in Finset.range n.succ, (2 * k + 1) =      (∑ k in Finset.range n, (2 * k + 1)) + (2 * n + 1) := by  ?_
Please fill in the proof in Lean 4.

7B的就把这个给解了，解完之后的被带入到原来的V3的结果了，sorry被替换成这个结果

[Prover-7B]
theorem range_decompose_subgoal (n : ℕ) :    ∑ k in Finset.range n.succ, (2 * k + 1) =      (∑ k in Finset.range n, (2 * k + 1)) + (2 * n + 1) := by  -- Use the standard lemma `Finset.range_succ`.  -- It tells us:  --   range (n.succ) = range n ∪ {n},  -- and the sum over `range (n.succ)` splits accordingly.  simpa [Finset.range_succ, Nat.succ_eq_add_one] using    Finset.sum_range_succ (fun k => (2 * k + 1 : ℕ)) n

每个subgoal都被解完，那么自然就出了一个完整的lean证明，交给lean verify去验证就可以了

所以prover-v2再解答数学题的时候是这个套路，大家看懂了吗？

--------------没看懂没关系，反正你们也用不到-------------

下面讲容易理解的math-v2

mathV2 就特别的好理解，但是很天才的设计

比如标准V3也能做数学题，但是做不了证明题，因为大模型对数学题的做法和人脑考虑不一样，所以之前训了prove2，拿lean来做验证

大家经常能看到一个数学题给LLM，它结果正确，但是中间的think步骤都在乱写

为什么这样？

因为你grpo也好，ppo也好，你都确认的是最终答案的值

有人说你的不对，因为R1论文里写的，grpo同样对think的中间过程check，check是check，只是check你输出的范式是不是<think></think>

那么prm是不是个好的思路，但是prm难训啊。

Deepseek math V2的做法是什么？

其实可以总结为抽象PRM

不同于每一步都要验证正确与否的PRM，你针对输出中间结果统一确认个好坏，这个还是可以实现的吧！

所以思路就来了

首先，我要有一个小镇做题家，一个给做题家批卷子的老师，但是这个老师可能本身就不咋滴，所以我还要找个教委的来监督老师的水平。

于是就有了下面这3个模型

1. 证明生成器，做题家(Proof Generator) (πθ)

这是负责实际生成数学证明的语言模型。

• 功能： 根据给定的问题 (X) 生成证明 (Y)。

• 训练目标： 使用训练好的验证器作为奖励模型 (RY) 对其进行强化学习训练，以最大化证明质量。

• 自我验证： 为了增强推理能力，生成器还被激励产生证明 Y 之后，紧接着进行自我分析 (Z)，即自我评估和纠错。这种自我评估的准确性也受到奖励，简单说就是你想高考取得高分，光做选择题和填空是不行的，你得做大题证明题，而且你的证明步骤得写清楚，这部分会有额外的分数。

2. 证明验证器，判卷老师(Proof Verifier) (πϕ)

这是负责评估证明质量的核心组件。

• 功能： 根据高层评估标准 (Iv)，评估证明的完整性和严谨性，并给出分数（1 分、0.5 分或 0 分）。

• 作用： 它作为奖励模型，为证明生成器提供反馈，指导其优化。

• 训练基础： 它最初是在一个经过监督微调的模型 (DeepSeek-V3.2-Exp-SFT) 的基础上，通过强化学习进行训练的。

3. 元验证器，教委的监督人员(Meta-Verifier) (πη)

这是一个专门用于确保验证器本身的分析结果忠实可靠的辅助模型。

• 动机： 作者引入元验证是为了解决验证器可能在评分正确的情况下，“虚构不存在的问题” 以获得满奖励的漏洞。

• 功能： 元验证器被训练来评估验证器输出的分析 (V) 的质量。它会检查验证器指出的问题是否真实存在，以及这些问题是否在逻辑上支持验证器给出的分数。就是你老师写的评语是否靠谱。

• 协同作用： 元验证器提供的质量分数 (Rmeta) 被整合到证明验证器的奖励函数中，从而提高了验证器在识别问题方面的忠实性（faithfulness）

这里其实隐藏了一个逻辑，教委凭什么能给老师的判卷评语打分，他知识能力一定比老师强吗？也就是元验证器一定比验证器厉害吗？

非也，因为他俩做的不是一个任务，老师给学生打分，是非常复杂的，它要确认它确实看懂了学生的对与错，问题到底出在哪？要写出很详实的证明。

但是，对于老师给题打的分数对应的评语，教委的逻辑是很简单的，就像让你做题你做不出来，但是让你给别人的论调里挑错，你又积极，又能找出问题所在，一旦元验证（教委的能力）发现老师这评语都开始乱写了，那么就到了升级老师的时候。

现在3个role都到位了，开始做题

做题家做了一道题---> 老师不光看你做对没有，还要看你的中间过程，然后从答案的正确性，和中间过程的正确性两个维度给你做题家打分----> 答案一般是有唯一的，但是中间过程未必是唯一的，怎么能证明老师公平公正的给做题家打分，教委（元验证器）就来检查老师的评语来了。

那么要实现这样一个做题到打分流程，怎么训练呢？

详细过程：

1. 证明验证器 (πϕ) 的训练和增强

作为老师（PRM，虽然是all process的rm），证明验证器 (πϕ) 是整个系统的核心，因为它定义了奖励函数和证明质量标准。

初步训练

1）. 基础模型： 验证器是基于 DeepSeek-V3.2-Exp-SFT 版本训练的，该版本经过监督微调（SFT）处理，拥有与数学和代码相关的推理数据基础。

2）. 数据构建： 研究人员首先从 AoPS 竞赛中抓取了 17,503 个主要需要证明的数学奥赛问题 (Dp)。

3）. 生成和标注： 光有Dp这点东西不够用啊，随后，使用DeepSeek-V3.2-Exp-Thinking （这个模型我好像没见过他们发啊）生成了候选证明，并提示该模型进行多轮迭代优化以提高全面性和严谨性。然后就当上人拉肩扛了，没办法冷启动是这样的，找一堆数学专家根据预定义的高级评估标准 (Iv) 对这些证明进行评分（1 分、0.5 分、0 分），从而构建了初始的 RL 数据集 Dv。

4）. RL 目标： 验证器通过强化学习进行训练，目标是生成证明分析并给出分数。奖励函数包括有格式奖励 (Rformat): 确保输出包含识别出的问题总结和分数，另外分数奖励 (Rscore): 基于预测分数 (s′) 与专家标注分数 (s) 的接近程度 (1−∣s′−s∣) 来奖励模型。

搞定了老师以后，引入教委的监督元验证器 (πη) 提高忠实性

元验证器 (πη) 登场：初步训练存在一个关键漏洞：当老师证明存在缺陷 (si<1) 时，验证器可以通过预测正确的低分数来获得满奖励，但同时虚构出不存在的问题（hallucinating non-existent issues），多少有点奖励黑客（可能叫奖励乞丐更合适），从而损害了它的可信度。为了解决一问题，引入了元验证器 (πη)。它是一个独立的、经过 RL 训练的模型，用于评估验证器分析本身的质量，而不是评估原始证明的质量。

元验证训练： 专家根据元验证标准 (Imv) 对初始验证器产生的分析 (Vi) 进行评分 (msi∈{0,0.5,1})，生成 Dmv 数据集。元验证器通过 RL 训练，其目标是评估验证器指出的问题是否确实存在以及这些问题是否逻辑上支持验证器给出的分数。

增强验证器： 最终（在某个训练的checkpoint里，论文没说这块），元验证器提供的质量分数 (Rmeta) 被整合到证明验证器的奖励函数中：RV=Rformat⋅Rscore⋅Rmeta。这提升了验证器识别问题时的忠实性。经过增强，验证器在验证集上的平均分析质量分数从 0.85 提高到 0.96。

所以也可以理解，元验证器在训练初是存在的，在训练中它的元验证能力就被验证器给吸纳了（老师和教委合体了）

2. 做题家证明生成器 (πθ) 的训练和自我验证

初步训练

• 初始化： 在每个训练迭代中，证明生成器都是从验证器的检查点初始化的。比较讽刺的是，第一代学生做题家，其实是个老师。。。

• RL 目标： 生成器使用训练好的验证器 (πϕ) 作为奖励模型。生成器的 RL 目标是最大化验证器对所生成证明 (Yi) 给出的分数 (RY)。

增强推理能力的自我验证

对于 IMO 和 CMO 等挑战性问题，单次尝试很难生成完美的证明。为了让生成器具备迭代改进的能力，它被赋予了自我验证的能力。

1）. 自我分析要求： 训练时，生成器被要求在生成证明 (Y) 之后，立即生成一个遵循验证器相同格式和标准 (Iv) 的自我分析 (Z)。

2）. 联合奖励结构： 奖励函数结合了对证明本身的评分 (RY) 和对自我分析的元验证分数 (RZ)。

◦ RY=s（验证器给出的证明分数）

◦ RZ=Rscore(s′,s)⋅Rmeta(Z)（s′ 是生成器预测的自我分数，s 是验证器给的实际分数，Rmeta(Z) 是验证器对自我分析忠实度的评估）。

3）. 激励机制： 这种结构激励模型做到以下几点：

◦ 忠实地承认错误，而不是虚假地宣称正确。

◦ 通过生成正确的证明并准确地认识到其严谨性来获得最高奖励。

◦ 生成器获得高奖励的有效策略是：在最终确定输出之前，识别并解决自身证明中尽可能多的问题。

3. 验证与生成之间的协同循环

验证器和生成器（也带着元验证能力的）通过一个良性循环持续互相提升，这个循环中的关键是自动化标签流程，它使得系统能够在没有人工干预的情况下扩展数据。

1. 协同效应： 验证器提高了生成器的能力，而更强大的生成器则产生了新的、更具挑战性的证明，这些证明挑战了验证器当前的极限，即生成器与验证器之间的差距，说白了验证器整不好就看不太明白生成器再说啥了

。

2. 自动化标签流程： 但是也不能因为看不懂就再来一次人拉肩扛吧？为了持续改进验证器以适应这些新的、难以验证的证明，deepseek开发了一个自动化标签流程，该流程取代了人工标注。

◦ 步骤 1： 对每个新的证明，生成 n 个独立的验证分析，为啥要这么干呢？

最大化错误发现： 通过多次采样，即使证明的缺陷非常细微或隐蔽，其中至少一个分析报告识别出该缺陷的可能性也会大大增加。

为元验证提供依据：只有那些在多次分析中报告问题的证明，才会被送入下一步的元验证评估。这确保了只有最有可能包含缺陷的证明，才会进行更深入、更高质量的审查。

确定最低分数： 最终的标签分配流程是检查那些分配最低分数的分析。如果多个独立的分析都报告了相同或相似的问题（即低分），那么这个证据就更可靠，随后元验证会确认其有效

◦ 步骤 2： 对于报告问题的分析（分数 0 或 0.5），生成 m 个元验证评估来验证发现的问题是否有效。

◦ 步骤 3： 与此同时，如果大多数元验证评估确认了问题，则该分析被认为是有效的。

◦ 步骤 4： 那么，如果所有验证尝试中都没有发现合理的问题，则证明被标记为 1 分；否则，证明被标记为有效分析中给出的最低分数。

1分的（也可能早期会把0.5分一起）这些证明因为元验证被标识为验证你的证明是可信的，因为验证你的证明是可信的，所以你的证明过程是可信的，那么，做题家也就是生成器的证明逻辑本身就可以成为一条dataset被加入到下一轮train的datasets里面，这个就是自动标签的逻辑。

这种全自动化流程在最后两次训练迭代中完全取代了人工标注，实现了在验证计算规模扩大下，持续为验证器创建新的训练数据，从而进一步改进验证器，因为生成器是验证器的儿子，所以生成器也越来越厉害，生成器生成的数据被自动标签流成给送到验证器去了，验证器又强了，强了以后又是下一个迭代的更厉害的生成器了，循环往复。

这个比prover的影响大的原因，prover是特定领域机器对机器的对话（lean），本质上面太窄，但是基于自然语言验证的数学就不一样了，如果你能拿这个方法，做数学题能拿到IMO的金牌，那你玩代码一样可以用相同的方法拿到live bench的理论满分，因为现在的vibe coding的一大问题是，思考范式比较差，只追求最初的逻辑勉强被满足，然后瞎写好多乱发散的次优代码，整体质量比较差，如果你的中间步骤都能特别的容易被证明，被元证明，那理论上你就能写出和高级程序员一样清晰又简洁的代码（不memory等需要解决的长尾效应的前提下）