LLM-as-a-Verifier：把验证本身变成可扩展的新轴

论文：LLM-as-a-Verifier: A General-Purpose Verification Framework
作者：Jacky Kwok, Shulu Li, Pranav Atreya 等（Stanford, UC Berkeley, NVIDIA）
链接：arXiv:2607.05391
Overall Performance
图1：LLM-as-a-Verifier 在编码、机器人、医疗三个领域均达到 SOTA

核心洞察：验证是尚未被充分扩展的维度

过去几年，LLM 的进步主要靠三条路：预训练数据/算力扩展、后训练优化（RLHF/RLAIF）、测试时推理扩展（test-time compute）。这篇论文提出了一个被忽视的第四条路——验证扩展（Verification Scaling）。

逻辑很简单：生成能力可以通过采样多条轨迹再选最好的来放大（oracle Pass@K 在 Terminal-Bench V2 上能到 98.9%），但选哪条需要可靠的验证器。传统的 LM Judge 输出离散分数（比如 1-5 分），在复杂任务上大量打平——Terminal-Bench 上 27% 的比较会 tie。训练专门的 Reward Model 虽然更精细，但受限于训练数据，跨域泛化差。

Framework Overview
图2：LLM-as-a-Verifier 框架总览——多模态输入、三种扩展维度、多种下游应用

方法：从离散判断到连续概率

LLM-as-a-Verifier 的核心改动非常直觉：不要只取概率最高的那个 token 作为分数，而是取整个打分 token 分布的期望值。

具体做法：给模型一个提示，要求用字母表示的 1-20 分给两个候选轨迹打分（用字母而非数字是为了提取 logprobs），然后从 <score_A> 和 <score_B> 标签处提取 top-K token 的 logprobs，计算加权期望得到连续分数。

这个连续分数有三个可扩展的维度：

1. 分数粒度（Granularity）

从 G=1（标准 judge）扩展到 G=20。更细的粒度让模型内部信念有更多空间投射，减少了把不同质量的方案映射到同一分数的概率。SNR 从 0.775 提升到 0.799，验证准确率从 73.1% 提到 77.5%。

2. 重复评估（Repetition）

同一方案评 K 次，取均值。本质是蒙特卡洛方差缩减。K=1 到 K=16，准确率从 74.7% 提到 77.5%，且连续分数在 K=1 时就已经追平了 K=16 次的离散 judge。

3. 标准分解（Decomposition）

把"这条轨迹对不对"拆成多个子标准分别评估再聚合。在代码任务上拆成 Specification（是否满足需求）、Output（输出格式）、Errors（有无报错）三项，任一单项准确率 75-76%，三项聚合到 78.3%。

Verification Scaling
图4：验证沿三个维度（粒度、重复、分解）持续提升准确率
Judge vs Verifier
图7：连续验证器 vs 离散 judge——准确率始终更高，tie rate 始终为零

Probabilistic Pivot Tournament：高效的候选排序

要从 N 条轨迹里选最好的，朴素做法是 O(N²) 两两比较。论文提出了 Probabilistic Pivot Tournament（PPT），复杂度降到 O(Nk)，k 远小于 N：

Pivot Tournament
图6：Probabilistic Pivot Tournament——五阶段流水线，从 O(N²) 降到 O(Nk)
  1. Ring Pass：随机排列 N 个候选，依次比较相邻对。每个候选在"A"和"B"位置各出现一次，消除了位置偏差。
  2. Pivot Selection：按 ring pass 得分选 top-k 作为 pivot。
  3. Pivot Tournament：所有非 pivot vs pivot、pivot vs pivot 两两比较，把预算集中在不确定的头部候选上。

实验结果：跨领域 SOTA

在四个基准上，用同一个验证框架、不训练任何东西，直接 SOTA：

基准Pass@1OracleLLM-as-a-Verifier
Terminal-Bench V283.1%92.1%86.5%
SWE-Bench Verified76.1%84.4%78.2%
RoboRewardBench——87.4%
MedAgentBench70.2%75.0%73.3%

机器人领域的成绩尤其亮眼——zero-shot、无需训练，直接超过专门在 ~45k episode 上训练的 RoboReward-8B（81.4%）和 Robometer-4B（78.8%）。

进度追踪：验证分数不只是排名工具

论文发现验证分数与任务进度高度相关（Spearman VOC）：成功的轨迹分数单调上升，失败的轨迹分数停滞。这为监控 agent 运行状态提供了自然接口——作者还做了 Claude Code 和 Codex 的扩展（TurboAgent），可以实时显示验证分数，在 agent 走偏时及时干预。

机器人任务上，VOC 达到 0.966，远超 RoboReward-8B 的 0.877 和 TOPReward 的 0.565。

RL 密集奖励：验证信号还能反哺训练

把验证分数作为 dense reward 直接喂给 RL 算法：

RL Sample Efficiency
图9：验证分数作为 dense reward，离策略 RL 提升 ~1.8× 样本效率，在策略 RL 提升 ~1.1×

工程意义

这篇论文的工程启示很直接：验证和生成一样，是一个可以被系统化扩展的能力。而且这个扩展不需要新数据、新训练，只需要改变"怎么读模型的输出"。
  1. 如果你在用 LLM 做评估/选最优方案，立刻把离散分数换成 logprob 期望。不需要训练，不需要新模型，同一个 API call 就能拿到更精细的信号。
  2. 预算有限时优先扩展粒度，因为 K=1 的连续分数已经等于 K=16 次的离散 judge。
  3. 评估标准要拆分，不要用一个大而全的 prompt 让模型做综合判断。
  4. 验证分数是天然的进度监控信号，可以做 agent 的 health check。
  5. 对于不支持 logprob 的模型（如 GPT-5.5 API），论文给了一个 two-stage workaround：先让闭源模型做推理分析，再把推理过程传给支持 logprob 的模型打分，效果依然优于直接用离散分数。

原文链接：arXiv:2607.05391 ｜ 论文狗-PaperDog