验证器与过程监督

只有当系统能够识别哪一份解答值得信任时，生成多份看似可行的解答才有意义。这个任务由验证器承担：它接收问题和候选项，再返回证据，供系统接受、拒绝、排序、修订或奖励该候选项。单元测试、答案检查器、习得奖励模型、人工评审和证明内核都可以担任验证器，但它们提供的证据并不相同。

验证器并不是真理预言机。它实现的是特定规格下的一项特定判断。单元测试能证明某次执行产生了预期结果。证明内核能证明某个形式化项从声明的假设推出了指定定理。习得评判器则根据训练数据估计标签。这些事实都不能单独证明被检查对象回答了用户的实际请求。

三个彼此独立的问题

有些属性彼此不同，却被放在同一条尺度上，于是验证器的设计很容易变得混乱。过程奖励模型并不天然强于单元测试，结果奖励模型也不天然弱于证明检查器。这些名称回答的是不同问题。有用的分类不是一条阶梯，而是三个彼此独立的问题：

1. 信号附着在哪里？ 结果反馈附着于终端对象，过程反馈附着于中间步骤或前缀。
2. 判断如何产生？ 判断可以来自显式的可执行规则、习得模型或人工审查。证明内核是一条可执行规则，只是它对形式化陈述具有格外强的语义。单元测试套件同样可执行，但只能覆盖测试编码的案例和性质。
3. 返回什么？ 接口可以返回布尔判定、标量分数、自然语言评析，也可以返回反例、执行轨迹或证明证书等证据。

这三个轴可以自由组合。单元测试套件通常是面向终端对象、基于规则的验证器，返回判定和轨迹。过程奖励模型是面向前缀的习得验证器，返回分数。生成式评判器可以检查完整答案或单个步骤，先给出评析，再由独立的提取器把文本转成判定。因此，验证器描述的是系统角色，而不是某一种模型架构或某个保证等级。

这种区分也解释了为什么数学、代码和形式证明特别适合作为训练领域：它们往往能为一部分正确性要求提供可执行检查。开放式建议和综合分析通常没有这样的条件。差别在于能否写出规格，而不是算法之间存在一套普适排名。

结果监督与过程监督

设生成器针对提示 $x$ 产生候选项 $c=(z_{1:T},y)$，其中 $z_{1:T}$ 是由 $T$ 个明确写出的步骤组成的轨迹，$y$ 是最终答案。结果监督为终端对象添加标签：

$$r_{\text{out}}(x,c)=\operatorname{check}(x,y).$$

对于答案精确匹配的任务，check 可以返回 0 或 1；对于习得的结果奖励模型，它也可以返回实数估计。「结果」规定的是标签落在哪里，而不是标签如何产生。

过程监督则为中间对象添加标签。这里的中间对象可以是在前缀 $z_{1:t-1}$ 的上下文中出现的步骤 $z_t$：

$$r_t = V_{\phi}(x,z_{1:t}), \qquad 1 \le t \le T.$$

这里，$r_t$ 是附着于第 $t$ 个前缀的标签或分数，$V_\phi$ 表示参数为 $\phi$ 的验证器。这种记法隐藏了一个重要的设计选择：步骤标签至少可以针对三种不同性质。

• 局部正确性： 这一步在此前状态下是否推导有效？
• 进展： 这一步是否朝请求的结果前进，而不只是重复一个正确事实？
• 后续价值： 在指定的续写策略和预算下，这个前缀最终得到正确答案的概率有多大？

这三种目标不能互换。正确步骤可能毫无进展。有缺陷的前缀也可能有很高的后续价值，只要续写策略经常能够修复它。因此，对成功续写做蒙特卡洛估计，并不会自动得到局部步骤正确性的标签。训练数据必须说明标签针对什么；只要使用逐步分数，也必须说明聚合规则。取所有步骤的最低分、最后一步的分数，或把各步分数相乘，会对轨迹长度和错误位置产生不同偏好。

结果标签通常更便宜，因为一个标签就能覆盖完整候选项，但它很难指出每一步对成败的贡献。最终答案失败，并不会指出最早出错的步骤。过程标签提供了更早的干预位置，可供训练或搜索使用；可是每增加一个标签，就多一次可能昂贵、不一致或错误的判断。

相关证据都局限于具体任务。Uesato 等人在 GSM8K 上发现，只看最终答案错误率时，纯结果监督用更少的标注就能取得相近效果；若还要求答案正确的解答少犯推理错误，则需要过程反馈，或一个训练到能够模拟过程反馈的奖励模型 (Uesato et al. 2022)。Lightman 等人在 MATH 测试集的一个代表性子集上报告，在固定生成器的 best-of-$N$ 设置中，他们用过程监督训练的奖励模型比结果监督模型更善于选出正确解答。他们还发布了 PRM800K，其中包含约 80 万个人工步骤标签，用来训练其最佳模型 (Lightman et al. 2024)。这些结果证明过程监督在上述实验条件下有价值，却不能证明每一个过程标签都优于每一次终端检查，也不能证明步骤分数一定要作为在线强化学习奖励。

标签构造本身仍是一项核心问题。Zhang 等人的实验发现，用蒙特卡洛步骤标签训练的过程模型，其泛化能力不如用大语言模型评判或人工标注训练的模型。他们的共识过滤器只保留蒙特卡洛估计与大语言模型判断一致的样本，并指出，仅看 best-of-$N$ 的答案准确率可能掩盖步骤验证能力不足的问题 (Zhang et al. 2025)。ProcessBench 把步骤级任务直接写进评测：在 3,400 份人工标注的解答中，验证器必须找出最早出现错误的步骤，或判断整份解答全部正确。作者发现，现有过程奖励模型往往无法从 GSM8K 和 MATH 泛化到更难的竞赛题 (Zheng et al. 2025)。

候选选择需要明确约定

推断时，验证器经常负责给样本排序。先从生成器 $q_\theta$ 中抽取 $N$ 个候选项，再为每个候选项计算验证器分数：

$$c_i \sim q_\theta(c\mid x), \qquad s_i = V_\phi(x,c_i), \qquad \hat c = \arg\max_{1\le i\le N} s_i.$$

这里，$c_i$ 是第 $i$ 个采样候选项，$s_i$ 是验证器为它给出的分数，$\hat c$ 是得分最高的候选项。再令 $u(x,c)$ 表示理想的独立评估会赋予候选项的任务效用，那么样本集内的选择遗憾为：

$$\operatorname{Regret}(x) = \max_{1\le i\le N} u(x,c_i)-u(x,\hat c).$$

换句话说，选择遗憾等于样本池里效用最高的候选项与验证器实际选中项之间的效用差。遗憾为零，表示验证器从当前样本池中选到了效用最高的候选项，并不表示样本池里有完美答案。

生成器决定有哪些候选项可供选择，验证器决定返回哪一个。因此，best-of-$N$ 只有在样本集中既包含好候选项、验证器又能正确排序时才会成功。选择器最大化的是验证器分数，而不是任务效用。如果 $V_\phi$ 忽略了 $u$ 在意的某种性质，增大 $N$ 只会给选择器更多机会找到利用这个缺口的候选项。

Cobbe 等人在 GSM8K 上展示了这项约定有利的一面：大量采样再由训练好的验证器选择，可以提高准确率；而且随着训练数据增加，验证方案比他们的微调基线扩展得更好 (Cobbe et al. 2021)。这是针对特定生成器、验证器、数据集和采样过程的实验结果，并不意味着验证器固定而不完美时，样本越多一定越好。在同一项研究中，选择后的准确率在约 400 个候选项时达到峰值，之后反而下降。作者把这种下降归因于少见却能骗过验证器的对抗性解答 (Cobbe et al. 2021)。

下面的示例具体展示这种失效方式。代理分数能正确排列前三个候选项。加入一份表述精致但答案错误的候选项后，样本池中的最高真实效用并没有提高，这份错误答案却因代理分数最高而被选中。数字只是示意，并非实测结果。

candidates = [
    {"name": "direct partial", "true_utility": 0.62, "proxy_score": 0.60},
    {"name": "careful correct", "true_utility": 0.90, "proxy_score": 0.82},
    {"name": "concise correct", "true_utility": 0.95, "proxy_score": 0.87},
    {"name": "polished wrong", "true_utility": 0.20, "proxy_score": 0.98},
]

for n in range(1, len(candidates) + 1):
    pool = candidates[:n]
    selected = max(pool, key=lambda item: item["proxy_score"])
    oracle = max(pool, key=lambda item: item["true_utility"])
    regret = oracle["true_utility"] - selected["true_utility"]
    print(
        f"N={n}: selected={selected['name']!r}; "
        f"selection regret={regret:.2f}"
    )

这里的 $N$ 是候选项数量。当 $N=3$ 时，选择器返回 concise correct，选择遗憾为零。当 $N=4$ 时，它改为返回 polished wrong，遗憾升至 0.75。真实系统不会暴露 true_utility，这正是为什么系统需要独立评估集和隐藏检查。

如何评估验证器

验证器基准必须与验证器在系统中承担的角色一致。如果部署会从大型候选池中选择最高分，那么只在均衡且相互独立的样本上报告准确率还不够。先设评估分布为 $D$，候选项来自部署中的生成器，其任务正确性标签为 $Y\in\{0,1\}$。对于布尔决定 $\hat Y$，需要关注两种错误：

$$\operatorname{FAR}=\Pr_D(\hat Y=1\mid Y=0), \qquad \operatorname{FRR}=\Pr_D(\hat Y=0\mid Y=1).$$

这里，$\Pr_D$ 表示部署分布 $D$ 下的概率，$Y$ 是参考正确性标签，$\hat Y$ 是验证器的决定。

误接收率（false-accept rate，FAR）衡量有多少错误候选项被当作正确结果放行。误拒绝率（false-reject rate，FRR）衡量有多少正确候选项被丢弃。两类错误的代价通常不对称。辅导提示或许可以容忍误拒绝，再生成一次；权限检查却不能轻易容忍误接收。阈值应当反映这种不对称。

对于标量分数，排序和校准是两种不同性质，需要分别评估。排序关注较好的候选项是否通常得到较高分。校准关注某个分数，例如 0.8，是否对应指定分布下的实际事件率。两者互不蕴含。选择前后都应报告这两类指标，因为选择最大分数会改变下游用户面对的分布。

一份有用的验证器评估至少包括：

• 候选项级别的误接收率、误拒绝率、排序质量和校准；
• 每个实际部署的 $N$ 值对应的端到端任务效用和选择遗憾；
• 按难度、长度和领域分层的结果；对于过程验证器，还要同时包括全程正确和含错误的轨迹；
• 来自部署中的生成器、温度、提示、工具和搜索策略的候选项，而不只是旧策略产生的静态语料；
• 部署后收集的对抗性失败和自然发生的失败；
• 在总成本匹配的条件下，比较延迟、词元用量、执行成本和人工评审成本。

分布条件至关重要。训练和搜索都会把候选项推向验证器给高分的区域。只在普通样本上评测的验证器，可能看起来很可靠，却在经过优化的分布尾部失效。每当生成器、搜索预算、检查器、提示、评分准则或分数提取器改变，都要重新评估。

生成式验证器

判别式验证器把候选项直接映射成标签或分数。生成式验证器则先写出用于说明判断的词元，再给出结论。发表于 ICLR 2025 的 GenRM 使用下一词元预测，同时在验证和解题数据上训练验证器。在作者的实验中，验证论证和多数投票让验证器能够用额外的测试时算力改善 best-of-$N$ 选择；实验覆盖多项算法和数学基准 (Zhang et al. 2025)。

ThinkPRM 把同一类思路用于步骤级验证。它为每个步骤生成一条验证链。在报告的实验中，它只使用约 8,000 个过程标签，约为 PRM800K 的 1%，却优于论文比较的判别式过程模型。这些标签从一个推理模型生成的 1,000 条合成验证链中筛选而来 (Khalifa et al. 2026)。这说明在这些基准上，生成可以成为一种数据效率较高的验证器接口；但它不能证明写出的论证会让判断正确，也不能证明这种方法不需要监督。

这种接口在运维上的优势是可检查。结构化的生成结果可以同时暴露判定、分数、首个疑似错误、支持证据和不确定性。它为运维人员提供一条便于调试的假设，默认不能当作忠实解释。仍然需要独立测试或人工评审，才能判断究竟是评析误解了候选项、分数提取器误读了评析，还是选择器错误使用了分数。

新的接口也带来新的失效方式。评析可能听起来很有说服力却是错的，可能遗漏关键问题、与最终判定矛盾，或在多次采样之间摇摆。评析还可能复制不可信候选项里的指令。必须把每份评析都当作不可信的模型输出，通过严格的结构约定解析，保留原始文本供审计，而且绝不能执行评析中的指令。评估必须包含验证器的采样预算和提取规则，不能只记录基础模型名称。

当检查器成为优化目标

一旦验证器分数开始控制选择或学习，验证的性质就变了。在普通评估中，检查器只是观察候选项；在 best-of-$N$ 或强化学习中，生成器会针对检查器优化。任何系统性盲点都会成为优化目标。

Gao 等人的奖励模型实验展示了强化学习和 best-of-$N$ 都会遇到这种代理问题：在他们的合成设置中，针对习得代理的优化不断增强后，独立金标准模型给出的分数最终反而下降 (Gao et al. 2023)。这项结果并没有给出一条普适的退化曲线，却说明经过优化的验证器不能同时充当唯一的发布评判者。DeepSeek-R1 报告了一项相关的工程选择。作者没有在推理任务中使用基于神经网络的结果与过程奖励模型，因为他们在大规模强化学习中观察到奖励黑客，并认为反复重新训练奖励模型的复杂度太高；这些任务改用基于规则的准确率奖励和格式奖励 (Guo et al. 2025)。

对策不是寻找一个完美检查器，而是把职责分开：

• 用便宜且可见的检查快速反馈，但为独立评估保留隐藏检查。一旦失效暴露出覆盖缺口，就要轮换或扩充隐藏检查。
• 组合覆盖不同性质的检查。代码可能同时需要单元测试、性质测试、静态分析、资源限制，以及对照原始规格的人工评审。
• 发布评估器要独立于被优化的信号。随着优化压力增大，持续衡量代理分数与留出任务效用之间的差距。
• 当留出效用停滞、审计差距扩大，或候选项之间的分数领先幅度不再可靠时，停止增加样本数、搜索深度或强化学习步数。
• 当验证器意见不一、分数差距很小、必要证据缺失，或候选项落在验证范围之外时，系统应当弃答，或转交更强的检查器或人工评审。

只有在各层提供不同证据时，分层才有帮助。五个用同一批标签训练的习得评判器可能共享同一个盲点。十个公开单元测试也可能同时漏掉同一项边界条件。系统需要记录每一层能证明什么，以及仍有哪些性质没有检查。

生产记录

验证器是部署系统的一部分，因此它的来源信息应当和模型记录放在一起。每次运行都要记录生成器、验证器、提示、评分准则和分数提取器的版本，还要记录候选项数量、采样参数、工具和数据版本、阈值、聚合规则，以及验证总预算。

记录所有被考虑过的候选项，而不只是胜出者。保存每一项的验证器判定、分数、结构化评析、执行证据和选择理由。敏感轨迹仍然需要访问控制和保留期限；但没有候选项级别的记录，运维人员就无法重建故障发生在生成、验证、提取还是选择环节。

按相同总成本比较方案。生成式验证器阅读八份长解答，消耗的词元可能比再生成几份候选项还多。过程模型可以通过提前剪枝减少搜索，却要为每一步额外打分。报告质量时，应同时报告生成、验证、执行和人工评审成本。

下一章会沿着这份信号进入训练流程。同一项区分仍然成立：奖励规定的是优化器能够看到什么，而不是用户在意的一切。

延伸阅读