LLM-as-a-Verifier：把“会做题”变成“会挑对答案”的新扩展轴

一个反直觉的起点是：很多智能体任务并不是因为模型完全不会做而失败，而是因为模型做了很多次之后，系统不知道哪一次是真的对。研究者在 Terminal-Bench V2 上给出了一个很有冲击力的观察：如果把排行榜中多条轨迹汇在一起，并让一个“神谕验证器”总能挑出正确轨迹，Oracle Pass@K 可以达到 98.9%。换句话说，生成侧已经把大量正确答案“撒”出来了，瓶颈转移到了选择侧。今天的核心问题不是单纯让模型再想一次，而是让系统判断：这条长长的工具调用、代码修改、终端输出或机器人视频，到底是不是把任务推进到了正确终点。

为了理解这项工作，先把几个术语放在前面。所谓 verifier（验证器），不是普通意义上的“评委”给一个印象分，而是要确认候选解是否满足任务、是否有隐藏错误、是否真的完成。trajectory（轨迹） 指智能体从初始任务开始的一串状态和动作：读文件、运行命令、改代码、看报错、再修复，都是轨迹的一部分。LLM-as-a-Judge 通常让模型输出 1 到 5 或 1 到 10 的离散分数；而研究者提出的 LLM-as-a-Verifier 不只看模型最后吐出的那个整数，而是读取评分 token 的概率分布，对这些分数取期望，得到连续的、细粒度的质量信号。再往上看，研究者把“验证”本身当成继预训练扩展、后训练扩展、测试时计算扩展之后的另一条 scaling axis：如果生成能力可以靠更多数据、更多训练、更多采样变强，那么验证能力也可以靠更细分数、更多重复评估、更好标准拆解变强。

一、排除法：问题不只是“再生成更多答案”

传统测试时扩展的直觉是 Best-of-N：同一个任务采样 N 个解，再挑最好的。这个套路在数学、代码和工具调用任务中都很自然，因为单次生成的失败率高，多试几次总有机会撞中正确路径。但它有一个被低估的前提：必须有一个足够可靠的选择器。没有选择器，Pass@N 只是理论上限；有一个粗糙选择器，额外生成反而可能把系统带到看起来更自信但实际错误的轨迹。

可以先排除几个常见方案。第一，直接用离散 LLM judge。它的成本低，提示也简单，但最大问题是“塌缩”：模型内部其实对 4.6 分、4.9 分、5.2 分有不同信念，最后却只能输出同一个整数 5。复杂轨迹之间的差异经常被四舍五入抹平，于是比较时产生大量平局。研究者在 Terminal-Bench 的例子里看到，标准 judge 在某些复杂 SQL 优化任务上 100 次评估中有 88 次打成平手。第二，训练专门 reward model。它在特定领域可能有效，但要依赖标注数据，跨代码、机器人、医疗三类任务时泛化会很吃力。第三，只做更多重复投票。重复评估确实能降低方差，但如果每次拿到的仍是粗糙整数，系统主要是在用平均数勉强打破平局，信息密度有限。

研究者的切入点因此很清楚：生成侧已经提供了候选空间，验证侧需要从“给一个离散 verdict”升级为“输出连续、可扩展、可聚合的证据”。这也是他们把 judge 和 verifier 区分开的原因。judge 像比赛评委，一眼给分；verifier 更像工程验收员，要核对规格、输出、错误日志和隐藏失败模式。

二、技术类比：从“只看最高票”到“看整张票型分布”

这项方法最关键的技术动作非常简单，但影响很大：不要只拿 argmax 分数，而要拿评分 token 的完整概率分布做期望。假设评分 token 是一个有序集合，比如 1 到 20。普通 judge 会看哪个 token 概率最高，然后输出那个分数。LLM-as-a-Verifier 则计算每个分数的概率乘以对应数值，再求和。形式上，轨迹奖励是对评分粒度 G、重复次数 K、评价标准 C 三个维度求平均后的期望分数。这样，一个“5 分概率 51%、4 分概率 49%”的候选和一个“5 分概率 95%、4 分概率 5%”的候选不再被视为完全相同。

可以用体检作类比。离散 judge 像医生最后只写“健康/不健康”；连续 verifier 像保留血压、血糖、心率等具体指标。两个病人都被写成“健康”，并不代表风险一样。再用考试作类比。只看最终等级 A/B/C，会丢掉 89 分和 80 分之间的差别；读取 token 分布取期望，相当于把模型犹豫程度也纳入评价。最后用工程验收作类比。一个代码智能体可能看似“任务完成”，但它是否在真实数据库上验证、是否误删中间证据、是否只在修改过的副本上测试，这些都不是一个粗整数容易表达的细节。连续分数让这些微弱但关键的怀疑有地方落脚。

研究者把这个想法扩展成三条验证 scaling 维度。

第一是 score granularity（评分粒度）。评分 token 从少到多，模型并不会突然获得新的环境信息，但它获得了更细的投影空间，可以把内部信念映射得更精确。在 Terminal-Bench V2 的 pairwise verification 上，粒度从 G=1 到 G=20，准确率从 73.1% 提升到 77.5%；信噪比也从 0.775 升到 0.799。这个提升看似不大，却说明“分数空间更细”本身能减少正确轨迹和错误轨迹之间的重叠。

第二是 repeated evaluation（重复评估）。单次验证会受提示措辞、位置偏置、偶然注意点影响。重复 K 次再平均，本质是 Monte Carlo 降方差。实验中 K 从 1 增加到 16，准确率从 74.7% 到 77.4%左右。更有意思的是，连续 verifier 在 K=1 时已经能匹配 heavily ensembled 的离散 judge；这说明细粒度分布不是重复投票的替代品，而是更高质量的单次测量。

第三是 criteria decomposition（标准拆解）。长轨迹任务里的“正确”太复合，模型容易抓住最显眼但未必最重要的因素。研究者把代码智能体轨迹拆成 Specification、Output、Errors 三类标准：是否满足任务要求，最终输出格式是否正确，日志和工具输出中是否有失败信号。任何单一标准准确率约 75.2% 到 76.4%，三者集成达到 78.3%。这类似把“这辆车好不好”拆成刹车、动力、油耗和安全，而不是让一个总印象支配结论。

三、从分数到选择：PPT 如何节省验证成本

如果有 N 个候选轨迹，最直接的办法是两两比较，做全循环赛。但全比较是 O(N²)，候选一多，验证成本会迅速超过生成成本。研究者提出 Probabilistic Pivot Tournament（PPT，概率枢轴锦标赛），核心是用少量枢轴候选集中比较，把成本降到近似 O(Nk)，其中 k 远小于 N。

流程分三步。第一步是 ring pass：把 N 个候选随机排成一个环，只比较相邻对。这个设计有个细节好处：每个候选刚好在 A 位置出现一次、在 B 位置出现一次，能抵消模型对位置的系统偏好。第二步是 pivot selection：根据环上比较得到的平均偏好，挑出 top-k 候选作为枢轴。第三步是 pivot rounds：非枢轴只和枢轴比较，枢轴之间也互相比，然后把 Bradley–Terry 模型得到的偏好概率聚合成 normalized win mass，选最高者。

这里重要的不是算法多复杂，而是研究者承认验证本身也是昂贵资源。一个真正可用的 verifier 不能只在小 N 情况下漂亮，必须能在候选池扩大时把计算花在最可能正确、也最难区分的候选上。附录中 N=20 的 Terminal-Bench 设置显示，PPT 随枢轴数量增加稳定提升；k=9 时准确率 67.13%，接近全循环赛 67.42%，但比较次数明显更少。

四、实验结果：验证器不是只会评文字答案

研究者最有说服力的部分，是把同一个框架放到代码、机器人、医疗三个差异很大的域里。它不是为某个 benchmark 微调的奖励模型，而是作为 plug-and-play 的轨迹奖励模型，在生成 N 个候选后负责选择。

在 Terminal-Bench V2 中，任务要求智能体在 shell 环境里完成长链路操作：文件处理、命令执行、报错恢复、最终状态达成。GPT-5.5 + Capy 的 Pass@1 是 83.1%，候选池 Oracle Pass@5 是 92.1%，LLM-as-a-Verifier 选出的结果达到 86.5%，超过当时列出的强基线。这个结果说明，验证器确实能回收一部分 oracle headroom，但也没有接近 oracle，上限和现实之间仍有明显差距。

在 SWE-Bench Verified 中，候选来自 Claude Opus 4.5、Gemini 3 Flash、MiniMax M2.5 三个模型，任务是修真实 GitHub issue 并通过隐藏测试。平均 Pass@1 为 76.1%，Oracle Pass@3 是 84.4%，验证器达到 78.2%。这里的意义在于，它能从异构模型家族的候选中挑较强补丁，而不是只适配某个单一生成器。

在 RoboRewardBench 中，输入不再是文本轨迹，而是机器人操作视频。验证器基于 Qwen 3.6 35B VLM，对同一指令下两段 rollout 判断哪个更接近目标。结果达到 87.4% preference accuracy，高于离散 LLM-as-a-Judge 的 70.8%，也高于 RoboReward-8B、Robometer-4B、TOPReward 等专门机器人奖励模型。这个跨模态结果很关键：研究者的方法依赖的不是文本任务特化技巧，而是“从评分 token 分布中提取连续信念”的通用结构。

在 MedAgentBench 中，任务涉及模拟电子病历环境下的信息检索、指南查询和多步工具使用。Claude Opus 4.8 的 Pass@1 是 70.2%，验证器提升到 73.3%。医疗域的提升不只是数字好看，因为这里构造完美规则检查器很贵，验证错误也可能有安全含义。研究者没有声称可直接临床使用，但展示了通用验证框架在高风险多步任务中的潜在价值。

五、最有前景的转向：分数不只用于选答案，还能估计进度

Big Picture 的反转在这里：LLM-as-a-Verifier 表面上是 Best-of-N 选择器，深一层却是“任务进度传感器”。如果验证器能对轨迹前缀打分，那么分数随时间的变化可以表示智能体是否在真正接近目标。研究者用 Value-Order Correlation（VOC）衡量步骤时间顺序和验证器分数之间的 Spearman 相关。Terminal-Bench 成功轨迹 VOC 为 0.848，失败轨迹为 0.769；机器人数据上，LLM-as-a-Verifier VOC 达到 0.966，高于多个机器人奖励模型。

这对实际智能体非常重要。今天很多代码智能体的问题不是最后失败才可怕，而是它们在失败前已经浪费了大量时间、安装了错误依赖、污染了工作目录，甚至把错误状态提交到了文件系统。一个实时进度分数可以让用户在长任务中看到：智能体是在稳步逼近目标，还是陷入循环、偏航或退化。研究者因此实现了 Claude Code 和 Codex 的扩展 TurboAgent，用代理方式并行生成候选、运行 PPT 选择，并提供网页界面监控验证器输出。

六、作为强化学习 dense reward：缓解稀疏奖励的信用分配

研究者还把验证器分数用作强化学习的 dense reward。稀疏奖励的经典痛点是：只有最终成败信号，中间步骤不知道该奖谁罚谁。机器人控制中，策略可能摸到物体、移动一半、差一步完成，但环境奖励仍是 0；数学推理中，多个回答最终都错，GRPO 的组内相对优势可能塌缩，模型拿不到区分“错得更接近”和“完全乱写”的梯度。

在 LIBERO 机器人任务里，研究者用 VLM 验证器对 rollout 帧序列产生进度曲线，并把环境奖励加上 λ 倍的验证器进度奖励，用于 DSRL-SAC 微调 π0 策略。结果约有 1.8× sample efficiency，最终成功率也从 0.69 提到 0.76。在 MATH 上，他们给 Qwen3-8B 的 GRPO 加入 reasoning reward，样本效率约提升 1.1×。机器人提升更大，数学提升较小但方向一致。这表明 verifier 不只是评测后处理，也可能进入训练循环，成为无需专门标注的 reward shaping 组件。

七、诚实边界：这不是万能裁判

这项工作值得重视，但边界也要清楚。第一，它依赖 scoring-token logits。很多闭源前沿模型 API 不返回 token 级 logprob，因此不能直接使用核心公式。研究者给了两阶段 workaround：先让闭源模型生成 reasoning，再把 reasoning 连同任务和轨迹交给可读 logprob 的开放模型打连续分。这个方法在 Terminal-Bench 上优于离散基线，但它增加复杂度，也把可靠性转移给第二阶段模型。

第二，验证器仍会继承基础模型的偏见和盲区。连续分数能减少平局，不等于保证真值。一个模型如果看不懂某个隐藏测试约束，概率分布再细也只是“细粒度地错”。第三，criteria decomposition 当前仍偏手工。代码任务里的 Specification、Output、Errors 很合理，但医疗、机器人、复杂企业流程中该拆哪些标准，仍需要领域知识。第四，重复评估降低方差但不消除共同偏差；如果所有评估都被同一错误线索误导，K 增大只能让错误更稳定。第五，RL 部分还主要是单任务或有限设置，多轮长时程 RL 中如何按步骤稳定给奖，仍是未来问题。

还有一个更现实的边界：验证成本。Best-of-N 加 verifier 是用推理成本换成功率。对于离线 benchmark 或高价值任务，这笔账可能划算；对于低延迟、大规模在线应用，G、K、C、N、k 都必须自适应调度，而不是固定开满。

八、为什么这篇工作的意义大于一个新榜单分数

这项工作的真正价值，不在于某个 benchmark 上多出 2 到 4 个点，而在于它重新定义了智能体系统中的一个分工：生成模型负责提出可能路径，验证模型负责把可能路径转化为可信选择。过去大家常说“LLM 生成很强但验证很弱”，于是默认验证要靠人工、隐藏测试或专门 reward model。研究者展示了另一种可能：同一个通用大模型，只要不把它的信念粗暴压成一个整数，而是读出评分 token 分布，并沿粒度、重复和标准拆解三个维度扩展，就能成为跨领域的可用验证器。

这也解释了开头的反直觉现象。未来能力提升未必总来自更大的生成模型；有时来自更会利用已有模型的“犹豫”。token 概率分布里的不确定性，过去常被当作解码细节丢掉；在这里，它变成了排序、监控和训练的燃料。LLM-as-a-Verifier 的 Big Picture 是：当智能体进入真实软件仓库、终端环境、机器人世界和医疗流程后，关键竞争力不只是会不会行动，而是能否持续判断自己的行动是否有效。验证不再是评测结束后的裁判哨，而是智能体运行中的导航仪。