模型能当自己的裁判吗LLM-as-a-Verifier自验证实验深度解析Terminal-Bench 2.1拿下88%【免费下载链接】llm-as-a-verifierLLM-as-a-Verifier is a general-purpose framework that provides fine-grained feedback for any agent without requiring additional training. It achieves SOTA performance across coding, robotics, and medical agentic benchmarks.项目地址: https://gitcode.com/gh_mirrors/ll/llm-as-a-verifierLLM-as-a-Verifier是一个无需额外训练的通用 Agent 验证框架为任意智能体提供细粒度反馈fine-grained feedback。在 Terminal-Bench 2.1 自验证实验中同一个模型既当「运动员」又当「裁判」Best-of-5 选择精度拿下88.0%——远超单次运行的 Pass1逼近理论上限。下面带你完整拆解这个实验是如何做到的。1️⃣ 先搞懂它和普通 LLM 评委有什么不同「让大模型给另一段输出打分」LLM-as-a-Judge已经很常见但通常只输出一个离散分数区分度有限。LLM-as-a-Verifier 的关键思路就 3 点细粒度打分用 1–20 分的量表代替「对/错」保留更多区分度取概率期望不只看模型最终输出的那个分数而是对分数 token 的完整 logprob 分布取期望把「模型其实拿不准」这种信号也量化进来重复 分解多次重复验证、把评估标准拆成多条独立打分放大微弱信号得到的细粒度反馈可以直接用于测试时扩展test-time scaling、进度跟踪和强化学习。核心实现位于 llm_verifier/fine_grained_reward.py。2️⃣ 自验证实验设计同一个模型既是运动员又是裁判在 Terminal-Bench 2.1 上实验的设定相当「苛刻」生成用deepseek-v4-flash驱动 mini-swe-agent每个任务生成5 条轨迹裁判仍然用同一个模型deepseek-v4-flash作为验证器挑选其中最好的一条轨迹数据随仓库提供在 data/terminal_bench_2.1_trajs/两个配置各有一个独立复现脚本scripts/run_bo3.py 与 scripts/run_bo5.py。最终结果配置Pass1单次最佳LLM-as-a-VerifierOracle理论上限Best-of-379.4%86.5% ± 1.1%92.1%Best-of-578.7%88.0% ± 0.6%96.6%两个值得注意的发现自验证有效选择结果大幅高于 Pass1说明模型对自己的输出并非盲目乐观而是能客观区分好坏裁判与选手同源也没问题即使验证器就是生成轨迹的那个模型细粒度打分机制依然能逼近 Oracle 上限3️⃣ 揭秘为什么同一模型能评出自己的高下① 细粒度奖励不是一刀切而是逐条标准打分每次对比中验证器会针对多条评估标准如「是否修复了根本原因」「是否确认修复生效」独立打分并对每个分数 token 的 logprob 分布取期望再经重复验证取平均。工程上用一个**字母量表A–T对应 1–20 分**来实现正是为了便于提取 logprob见 llm_verifier/prompts.py 中的提示词模板。② 概率枢轴锦标赛把比较成本从 O(N²) 降到 O(Nk)从 5 条轨迹里挑 1 条如果两两全比需要 C(5,2)10 次对比随候选数增长会爆炸。Probabilistic Pivot TournamentPPT的解法很聪明环形赛Ring pass随机排成一个环只比较相邻配对且每条轨迹在「A/B 槽位」各出现一次天然抵消模型的位置偏好选枢轴按环形赛成绩取前 k 个作为枢轴枢轴赛所有「非枢轴 vs 枢轴」「枢轴 vs 枢轴」的对比集中火力最终按胜率加权选出最优这实现了在 llm_verifier/pivot_tournament.py——pivots参数可在成本与精度之间自由权衡。③ 评估标准只信终端输出不信「自我宣称」这是自验证能否客观的命门。Terminal-Bench 的验证器标准criteria/terminal_bench.md开篇就强调以终端输出为唯一事实依据。不要相信 Agent 的自我评估或成功宣称——Agent 常在终端报错时仍声称成功。标准被拆成三条独立检查Specification Adherence逐条核对任务的具体要求——文件路径、安装位置、输出格式、命名等Output Match找到 Agent 最后运行的验证命令将其实际输出与任务期望的输出逐字符比对Error Signal Detection扫描轨迹尤其是后段步骤中的错误信息、traceback、非零退出码等未解决的失败信号把裁判的注意力从「Agent 说了什么」拉回到「终端实际显示了什么」是模型能公正评判自己输出的关键设计。4️⃣ 附加能力实时进度跟踪及时止损同一套细粒度奖励还能给轨迹的每一步打分。官方用 Terminal-Bench 的pytorch-model-cli任务演示成功轨迹的验证分数随步骤持续爬升失败轨迹则因错误行为始终低位徘徊数据见 data/progress_tracking/pytorch-model-cli/。配合ProgressTracker做在线跟踪时更有价值它只看得见「到目前为止的步骤」无法偷看未来。运行中分数长期低于阈值如 0.05就可以提前终止一条没希望的 rollout或者决定何时重新采样——实现真正的测试时资源调度实现见 llm_verifier/progress.py。5️⃣ 快速上手3 步复现 88%第一步安装pip install llm-verifier第二步配置在.env中填入DEEPSEEK_API_KEY轨迹已随仓库提供评分只需这一个 Key。第三步运行python scripts/run_bo5.py # best-of-5对应 88.0% 结果0.2.0 版本还带来了前缀缓存优化缓存命中率从 5.2% 提升到 78.4%输入成本约降 3.4 倍和 token 用量统计完整说明见 CHANGELOG.md。想迁移到自己的任务官方给出了三步模板add_new_benchmark.md把自己的轨迹放进data/task_name_trajs/参考 criteria/TEMPLATE.md 编写评估标准让编码 Agent 按模板自动生成 runner 并跑通6️⃣ 总结模型可以当自己的裁判吗结论依据✅ 同一模型自验证可行Best-of-5 达 88.0%显著高于 Pass1 的 78.7%✅ 细粒度是核心1–20 分 logprob 期望 重复验证把微弱差异放大✅ 只信证据不轻信以终端输出为标准的裁判设计让自评不偏袒自己✅ 工程友好无需训练、支持多模态、进度跟踪可实时止损✅ 开箱可复现轨迹数据与独立复现脚本随仓库提供模型能当自己的裁判——前提是裁判的「眼睛」足够细细粒度奖励、规则足够硬只信证据的标准、流程足够省枢轴锦标赛。这或许正是 LLM-as-a-Verifier 给 Agent 评估领域带来的最有价值的启示。【免费下载链接】llm-as-a-verifierLLM-as-a-Verifier is a general-purpose framework that provides fine-grained feedback for any agent without requiring additional training. It achieves SOTA performance across coding, robotics, and medical agentic benchmarks.项目地址: https://gitcode.com/gh_mirrors/ll/llm-as-a-verifier创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考