Generator–Verifier：生成的模型与检查的模型

为什么要把生成的模型和检查的模型分开

本文是 Generator–Verifier 系列的第 1 篇，梳理将生成器与验证器分开使用这一思路的源头和研究脉络。生成器（Generator）是生成答案的模型。验证器（Verifier）是为答案打分或判定其是否正确的模型或程序。

出发点是这样一个观察：LLM 在多步推理中很容易因一次失误而全盘出错。推出 GSM8K 的验证器研究（paper）指出，自回归模型（根据前面的 token 逐个生成下一个 token 的模型）在生成过程中没有纠正自身错误的机制，因此一旦解题过程走偏，就很难挽回。同一研究还根据一个趋势指出，仅靠生成方式在难题上提升性能需要过多的参数，因此应寻找扩展性更好的方法。

由此产生的核心思路是“生成–验证差距”。与从头解一道数学题相比，批改别人写好的答卷通常更容易。同一研究（paper）也说明，验证通常是比生成更简单的任务。此外，还有可以从多个候选中选择一个的“选项”优势。打个比方，生成器是写出多份答卷的考生，验证器是从中挑出最可靠答卷的阅卷人。即使考生水平不变，只要阅卷人足够好，最终提交的答案质量也会提高。

这种差距在实际中能被利用到什么程度，阅卷人出错时会发生什么，是贯穿整个系列的问题。

脉络①：Best-of-N 与结果验证器（ORM）

最简单的用法是 Best-of-N。针对同一道题，从生成器中采样 N 个解答，再选出验证器打分最高的那一个。GSM8K 验证器研究（paper）公开了 8.5K 道小学水平的数学应用题，并训练了一个验证器来判断模型生成的解答是否正确。测试时，先采样固定数量的候选，再提交验证器排在第一的解答。

结果可以归纳为两点。第一，与只做微调的基线相比，使用验证器带来的性能提升，大致相当于把模型规模扩大约 30 倍。第二，数据越多，验证器方法的扩展效果就好得多。该研究还报告，dropout（训练中随机关闭部分连接的技术）在微调和验证中都有很强的正则化效果。

像这样只看最终答案是否正确、并据此给整个解答打分的验证器，称为结果奖励模型（ORM，Outcome-supervised Reward Model）。按照 Let's Verify Step by Step（paper）的归纳，ORM 只用 CoT（Chain-of-Thought，逐步解答）的最终结果来训练。它的优点是标签容易获得：如果题目有确定的正确答案，只需比对最终答案即可，不需要人工也能构造训练数据。

弱点也出自同一处。Let's Verify Step by Step（paper）指出，仅以结果为监督的模型经常通过错误的推理得出正确答案。ORM 无法区分“答案正确的解答”和“推理也正确的解答”。

脉络②：过程奖励（PRM）与自动步骤标签

过程奖励模型（PRM，Process-supervised Reward Model）会分别判断解答中的每一步是否正确。Let's Verify Step by Step（paper）列举了 PRM 的三个优点：它能准确指出错误出现在哪里，因此反馈更精细；人更容易解读；它直接奖励人认可的推理过程。

该研究用基于 GPT-4 的模型比较了 ORM 和 PRM，在较难的 MATH 数据集上，PRM 明显优于 ORM。最好的 PRM 在 MATH 测试集的一个代表性子集上解出了 78.2% 的题目。评估方式同样从验证器的角度出发：固定生成器，衡量奖励模型在 Best-of-N 中挑出正确解答的能力。该研究公开了包含 80 万个人工逐步标签的 PRM800K，并通过 Active Learning（主动学习：挑出模型拿不准的样本去获取标签的方法）将过程监督的数据效率提高了 2.6 倍。

问题在于成本。最终答案可以自动评分，但逐步判定没有简单的自动化方法，因此该研究依赖人工标注员。Math-Shepherd（paper）针对这一瓶颈，用无需人工标注、自动生成的逐步监督数据来训练 PRM。这样得到的 PRM 用在两个地方：一是对多个输出重新排序的验证器，二是逐步 PPO（一种强化学习算法）的奖励。

根据 Math-Shepherd（paper）的报告，Mistral-7B 经过逐步 PPO 后，GSM8K 准确率从 77.9% 提高到 84.1%，MATH 从 28.6% 提高到 33.0%。再加上 Math-Shepherd 验证，分别达到 89.1% 和 43.5%。这一脉络的要点是：同一个 PRM 既能作为训练信号，也能作为推理时挑选答案的工具。

脉络③：生成式验证器与 LLM-as-a-Judge

前面看到的验证器，大多是输入解答、输出一个分数的判别式分类器。Generative Verifiers 研究（paper）认为，这种方式没有利用预训练 LLM 的文本生成能力。因此它提出了生成式验证器 GenRM，把验证本身当作下一个 token 预测来训练。GenRM 以文本形式生成“这个解答对不对”这一问题的答案，并同时学习解答生成和验证。

这样就能直接沿用 LLM 的长处：它能与指令微调自然结合，也能在判定前用 CoT 写出依据。对同一验证多次生成并取多数投票，就能在验证环节也投入测试时计算（在推理阶段额外使用的计算）。Generative Verifiers 研究（paper）报告，GenRM 优于判别式验证器和 DPO 验证器，也优于 LLM-as-a-Judge（不做额外训练、直接让 LLM 打分的方式）。按 Best-of-N 计算，算法任务的准确率从 5% 提高到 45.3%，GSM8K 从 73% 提高到 93.4%。在用简单题训练、用于难题的设置下，MATH 也从 28% 提高到 44.6%。即使只用合成的验证依据来训练，也能发现数学解答中的细微错误。

总的来说，验证器已从“输出一个分数的分类器”扩展为“边说理由边判定的模型”。判定附带解释后，人可以检查验证器的判断，也可以把这些解释作为修改指令返回给生成器。不过，由于判定要以文本形式生成，每次验证的成本也随之上升。这一成本在下一个脉络中会成为重要问题。

脉络④：为什么验证器会成为推理时计算的瓶颈

Large Language Monkeys（paper）把“多次采样”当作提升性能的另一个维度。在多种任务和模型上，覆盖率（coverage，采样结果中至少有一个解出题目的比例）在样本数增加到四位数范围的过程中持续上升，二者往往呈对数线性关系。在编程、形式化证明这类可以自动检查答案的领域，覆盖率直接转化为性能。在 SWE-bench Lite 上，DeepSeek-Coder-V2-Instruct 的解决率在 1 个样本时为 15.9%，250 个样本时升至 56%，超过了当时单样本最好成绩 43%。

但在没有自动验证器的领域，情况就不同了。根据 Large Language Monkeys（paper），从候选中挑选一个的常用方法——多数投票和奖励模型——在样本超过几百个后就停滞了，没能把增加的样本预算充分用起来。即使正确答案就在候选堆里，挑不出来也没有用。样本越多效果越好，挑选能力却跟不上——这就是验证器成为瓶颈的原因。

Snell 等人的测试时计算研究（paper）比较了使用推理时计算的两种方式：一种以逐步的过程验证器为依据进行搜索，另一种让模型一边修改答案一边改变回答分布。哪种更好，很大程度上取决于题目难度。因此，采用按题目合理分配计算的“计算最优”策略后，效率比 Best-of-N 提高了 4 倍以上。在计算量对齐的比较中，对于小模型有一定成功率的题目，小模型有时还能胜过大 14 倍的模型。

把两项研究放在一起看，结论很清楚：推理时计算并不止于多采样。判断该选什么、在哪里多投入计算的验证器，其质量和成本决定了整体性能的上限。如果验证器调用很贵，候选采得越多，验证成本也会一起膨胀。

脉络⑤：用基于规则的验证器训练（RLVR）与当前方向

验证器不只用于推理时挑选答案，也用作训练信号。RLVR（可验证奖励强化学习）是把数学答案比对、单元测试通过这类可以用规则确认的结果作为奖励，对模型进行强化学习的方法。正如 Let's Verify Step by Step（paper）所指出的，对于能自动确认答案的题目，结果监督无需人工即可提供。因此，基于规则的验证器可以廉价地大量产生训练信号。重采样局限研究（paper）也提到了用 rejection sampling（拒绝采样：只保留通过验证器的解答）来筛选推理模型训练数据的做法。前面介绍的 Math-Shepherd（paper）则是用训练出的 PRM 代替规则，作为 PPO 奖励的例子。

对于无法用规则确认的任务，又需要训练出来的验证器。SWE-Critix（paper）的出发点是：编程智能体的任务往往没有给出成功标准的 oracle（正确性判定器）。该研究训练的通用验证器接收任务和执行轨迹（与代码仓库、工具进行数百次交互的执行记录），预测任务是否完成，并用自然语言解释判断理由。研究结合 SFT（监督微调）和强化学习训练了多个 30B 模型。在留出测试集上，分类准确率从基础 Qwen3-30B-A3B 推理模型的 57%，提高到 SFT 后的 66%、强化学习后的 78%。

另一个方向是改进和扩展验证器本身。验证器协同进化研究“Who Verifies the Verifier?”（paper）指出了没有既定验证器的开放式任务所面临的问题：直接使用手写的评分细则，或让 LLM 评判器给与自身相似的模型打分，容易出现奖励黑客和共同的盲区。因此，该研究从失败案例中合成小型、大多为确定性的缺陷检测器，再将其组合成可检查的验证器。验证器的选择依据不是智能体得分，而是与一个由十个条目组成的基准集的一致程度。在 MBPP+ 上，与手工搭建的初始组合相比，留出数据上的一致度提高了 0.21。

不完美验证器的局限与实践模式

验证器出错时，投入再多计算也无济于事。重采样局限研究（paper）分析了假阳性（false positive，验证器放过错误答案的情况）。只要假阳性概率不为零，重新采样也不会降低这一概率，因此无论计算预算多大，准确率都会存在上限。在单元测试覆盖有限的 HumanEval 和 MBPP 上，模型的单样本准确率与假阳性比例强相关。因此研究认为，弱模型无论采样多少次，都达不到足够强的模型的单样本准确率。由于假阳性带来的损失超过收益，最优尝试次数往往少于 10 次。

把验证器用作奖励时，问题会更严重，因为生成器会学会验证器偏好的东西。Prover-Verifier Games 研究（paper）表明，只以答案是否正确为标准来优化 CoT 解答，可能使解答变得难以阅读和核查。因此，该研究交替训练两种生成器：一种是生成能骗过小型验证器的错误解答的“狡猾（sneaky）”生成器，另一种是生成验证器能接受的正确解答的“有帮助（helpful）”生成器。结果，验证器的鲁棒性和解答的可读性都得到了提升。验证器协同进化研究（paper）的发现则更具警示意义：去掉基准集这一保障后，验证器退化成了什么都放行的空评分器，而用这个验证器训练出的技能看起来却同样出色。研究者得出结论：仅凭下游任务得分，无法为自我进化的验证器提供保证。

考虑到这些局限，实践模式可以归纳为四种。第一，采样再挑选（Best-of-N）最简单，但准确率受制于验证器的假阳性，因此不要盲目增加样本数。第二，在搜索中用逐步验证器在中间步骤剪枝，以节省计算。正如测试时计算研究（paper）所示，还要根据题目难度调整计算分配。第三，生成–批评–修正循环把验证器的解释返回给生成器，让它修改答案。这与 Generative Verifiers 研究（paper）中那种判定附带理由的验证器很契合。

第四，在编程智能体中，单元测试是最便捷的基于规则的验证器。但正如重采样局限研究（paper）所示，如果测试覆盖面窄，测试本身就会成为假阳性的通道。对于仅靠测试难以确认的长任务记录，目前正在研究用 SWE-Critix（paper）这类训练出的验证器加以补充。

延伸学习，以及引向第 2 篇的问题

如果是第一次阅读，建议先读 GSM8K 验证器研究（paper），把握 Best-of-N 和验证器的基本框架，再读 Let's Verify Step by Step（paper），了解 ORM 与 PRM 的区别。接下来最好连着读 Large Language Monkeys（paper）和重采样局限研究（paper），这样可以把增加样本带来的可能性与验证器假阳性造成的上限放在一起理解。Generative Verifiers 研究（paper）和测试时计算研究（paper）是之后的进阶材料。

本篇结束时留下的问题是：“什么样的验证器才是好验证器？”从前面这些研究来看，至少需要三种性质。第一是准确性，尤其是不放过错误答案的能力。第二是成本。当候选增加到几百个，或在搜索的每一步都调用验证器时，单次验证的速度会左右整体计算量。第三是分数的校准（calibration）。验证器说“80% 确信”时，实际也要有那么高的正确率，才能决定何时多采样、何时停止、何时转交给人。

第 2 篇将接续这个问题，探讨把以快速、校准良好的判断为目标的决策模型 Jev 用作验证器，能如何提升生成器–验证器结构的性能。出发点是两个问题：像生成式验证器那样附带长篇解释的判定和快速判定，各自应在什么时候使用？要减少假阳性，应如何利用置信度？