验证器与过程监督

推理系统能进步，是因为它能区分好工作和坏工作。因此中心对象不是链、树，也不是强化学习算法，而是验证器。验证器可以是单元测试、答案检查器、证明内核、学出来的结果奖励模型、过程奖励模型，也可以是会写出自己批注的生成式评判器。每一种验证器回答的问题都不同，而这个问题会决定训练和测试时算力能买到什么。

结果、过程与信用分配的单位

设模型对提示 $x$ 生成轨迹 $z_{1:T}$ 和最终答案 $y$。结果监督在终端对象上定义奖励：

$$r_{\text{out}}(x, z_{1:T}, y) = \mathbf{1}\left[\operatorname{check}(x, y)=1\right].$$

相比之下，过程监督则在前缀上定义奖励：

$$r_{\text{proc}}(x, z_{1:t}) \in \{-1, 0, 1\}, \qquad 1 \le t \le T.$$

其中 $x$ 是提示，$z_{1:T}$ 是推理轨迹，$y$ 是最终答案，而 check 函数就是任务可用的验证器。前者便宜而稀疏。后者昂贵而密集。结果奖励问的是「答案是否通过」。过程奖励问的是「这一步是不是好动作」。Uesato 等人在数学文字题上比较了两者，发现结果反馈能用更少标注达到类似的最终答案错误率，但要减少正确答案里的推理步骤错误，仍需要过程反馈 (Uesato et al. 2022)。Lightman 等人随后在 PRM800K 上训练过程奖励模型（PRM，为方案的每一步打分，而不只看最终答案），并发现过程监督在困难 MATH 问题上强于结果监督 (Lightman et al. 2023)。

这是一笔信用分配上的交易。如果系统只看到一个错误最终答案，它就要倒推是哪一步毁掉了整条路径。过程标签指向更早的位置，可以在分支继续消耗预算前剪掉它。但过程标签本身也是判断，常常由人类标出再由模型学习，于是它又引入代理误差。RLVR（可验证奖励的强化学习，只在答案能被自动核验的问题上训练）之所以有吸引力，是因为验证器避免了学出来的奖励缺口；而过程奖励模型可能把这个缺口带回来。

后来的经验表明，这笔交易的成败主要取决于步骤标签从哪里来。Lightman 等人的步骤标签由人工标出；便宜的替代方案，即从某一步出发做蒙特卡洛 rollout 来估计这一步的质量，给出的标签并不可靠。Qwen 团队复盘构建 PRM 的过程，发现真正起作用的是共识过滤：只保留蒙特卡洛估计与作为评判者的 LLM 一致的步骤，他们的 Qwen2.5-Math-PRM 与 ProcessBench 评测由此而来 (Zhang et al. 2025)。ThinkPRM 则把下文的生成式验证器思路与步骤级评判合并：让 PRM 用自己的验证思维链对每一步做推理，只用约 1% 的过程标签就追平了判别式 PRM (Khalifa et al. 2025)。

验证器阶梯

这条阶梯按语义强度排序，而不是按名气排序。

• 启发式评判器 覆盖开放任务，但保证弱。它们适合粗排和分流，却容易被优化压力利用。
• 结果奖励模型 学习为完成方案排序。Cobbe 等人用训练出的验证器重排许多数学候选，并证明在 GSM8K 上，验证随数据扩展比直接微调更有效 (Cobbe et al. 2021)。
• 可执行检查 包括单元测试、答案等价、解析器和类型检查。它们一旦写好就便宜，但覆盖由规格决定。
• 过程奖励模型 为中间步骤打分。它们让搜索和训练信号更密集，但标签成本高，模型也可能学到标注者习惯 (Lightman et al. 2023)。
• 形式化证明检查器 给出最强的终端语义，因为小内核检查证明。它们覆盖窄，而且要求形式化。

这条阶梯也解释了为什么不同研究方向看起来速度不同。数学、代码和形式化证明天然提供检查器，尽管 第 28 章 讨论的 2025 年 IMO 金牌结果表明，连这条边界也在被拉伸。开放建议、综合写作和政策推理则没有。算法可能相同，奖励来源却不同。

生成式验证器

标量验证器把判断压成一个数。生成式验证器则使用语言模型自己的下一词元机制，对候选进行推理。GenRM 用下一词元预测在验证和解题数据上训练验证器，使验证器可以写出自己的思维链，并通过投票花费测试时算力 (Zhang et al. 2024)。这很要紧，因为有些错误太细，浅层分类器看不出来。会推理的验证器可能抓住它们。

代价是验证本身变成另一个推理问题。第 30 章 里的选择器不再是固定组件；它有自己的延迟、采样预算和失败模式。生成式验证器能提升 best-of-$N$ 选择（采样 $N$ 个答案，保留验证器评分最高的那个），但也可能同意一段貌似合理的错误工作。它的优势取决于：在这个任务上，判断是否真的比生成更容易。

def best_of_n_with_verifier(prompt, n):
    candidates = [generator.sample(prompt) for _ in range(n)]
    judged = []
    for c in candidates:
        critique = verifier.generate(format_judgment_prompt(prompt, c))
        judged.append((extract_score(critique), c, critique))
    return max(judged, key=lambda x: x[0])

批注不只是分数。它也是审计数据。系统后来失败时，运营者可以检查到底是候选错了、验证器错了，还是从批注抽取分数的那一步错了。对运营上重要的任务来说，这条审计轨迹正是结构化验证优于不透明标量的一个理由。

当检查器变成目标

每个验证器也是攻击面。在训练中，策略会学习验证器的边界。在推断中，best-of-$N$ 会选出让验证器分数最高的样本。如果检查器不完整，更多优化压力就会找到它的洞。在 第 19 章 里这叫奖励黑客，在 第 30 章 里这叫选择器过度优化，在代码生成里这叫过拟合单元测试。名字不同，是因为循环不同，但形状是一样的。

没有普适修复。现实答案是分层验证。一个代码答案可能需要单元测试、隐藏测试、静态分析、类型检查，以及针对规格匹配的人类审查。一个数学答案可能需要符号等价、数值代入和步骤级 sanity check。一个智能体轨迹可能需要环境反馈、权限检查和结果评估。正确的验证器是一组验证器，而这组里最弱的那层往往决定了整体的上限。

验证器是本部分各章之间的连接点。搜索靠它剪枝，程序辅助推理借外部运行时来强化它；RLVR 把它用作训练奖励，测试时扩展则依赖它把覆盖率转成准确率。下一章会从作为组件的验证器，走到把它用作奖励的完整训练循环。

延伸阅读