LLM Benchmark里的分数到底是怎么打的

> 本文编译自外网

现在常用评估AI 模型 和 agent能力的方法，是看 benchmark 分数。如果两个模型差 5 个点，大家往往就会说分高的模型吊打分低的模型。我们也是专门做benchmark的机构，一次机缘巧合，把自家的 benchmark 拆开看了一遍，发现一个反直觉的事实：即使完全一样的，同一个模型的traj，只换打分的评委模型，分数能从 62.5% 波动到 83.7%。21 个点，大多数榜单上相邻两名之间的差距都没这么大。那我们到底如何分辨一个模型的真实能力？

benchmark 其实是由两个东西组成的：很多模型需要执行的任务，还有一个给你打分的评委。所有人都把评委给定的分数当做评判标准，但它决定了每个模型到底是什么能力。评委有没有足够的抗波动能力，还有能不能真正探寻出评测模型的真实能力是评委需要做到的，你也不希望一个刷榜的模型。你给它分数打到最高。所以这篇讲讲我们怎么把评委这个黑箱拆开，看看评委到底在做什么。

分数里有多少是真的

让分数波动的有两个来源。来自 web 和模型本身：做爬虫任务，因为你的IP脏了之后。网站把你封了。这种波动只能测，消不掉。但是评委波动是同一份跑完的traj评两次，分数波动极高，这个能解决。

首先看 agent 自己的波动。大家可以理解成一个agent跑一个任务多次，跑出来的结果肯定不完全一致。这样跑完的任务我们给它打分，可以得到平均分，最高分，中位分数等这些统计信息。我们拿 GPT-5.5 在同一套 harness、同一份配置下跑了 5 次，每次都是同样的 106 个任务。每次能做对的有 89 个左右，但从来不是同样那 89 个。

其中的任务，会有64 个任务每次agent都能通过，2 个从来不过，中间 40 个处于随机状态：可能是一次误读、一次按钮点错、agent莫名其妙早放弃了。但是跑一次，分数 85%分；然后跑五次取并集，106 个里 104 个评测任务至少也能通过次。单次跑分测的不是模型能不能做到，是它多常做到。或者是模型的中位能力如何。

评委模型的噪音比模型还大

然后我们把 agent 冻住。取出 104 条跑完的轨迹，全都带人工标签，只换一件事：评分用哪个模型。

45% 的 benchmark 结果取决于你问了哪个评委。最松的报 83.7%，最严的报 62.5%。如果评委晃动分数的幅度比模型还大，你根本说不清一次改动到底有没有用。

把评委做成一个 agent

我们第一版评委很朴素：单次 LLM 调用，整个轨迹进去，判决出来。但这套方法在使用一套 harness 的时候还行，harness 一多就崩了。各家轨迹长得完全不一样，动辄几百步，compaction 还会把你最需要的那一段消除掉。

为什么那一段重要？看个例子。任务是提取月租 2,000 美元以下的房源，第 34 步，agent 把筛选器设成了 20,000。从那往后的每一步都干净、自信，而且全错。

证据就是埋在几百步里的一次看似影响不大的错误。你没法把整个轨迹塞进 prompt，单次调用也只有一次机会找到这根针。所以评委应该升级成 agent：拿到轨迹和工作区，像开着只读权限的 Codex 或 Claude Code 一样自己去翻。它能打开 agent 下载的 CSV，滚回第 34 步，把数字和它来源的页面对上。

这里有个比 prompt 更先决的问题：评委只能验证它看得见的东西。截图很大，页面文本很大，预算一紧就有东西被截断。裁错了地方，一句真话会变得无法验证，而"无法验证"和"瞎编"在评委眼里长得一模一样，它就开始把正确答案判成幻觉。先把数据收集做好，再谈 prompt 工程。

别再问过不过，问做到几成

评委最终得输出点什么，过或不过是最自然的选择，反而也是最不可信的，因为真实任务大多不是二元的。任务描述本身就松，"查一下头部贡献者"，没人能验证哪一个算头部。到底是前10算头部，还是前20算？agent 也经常给你错误的文件格式：你要 JSON，它给了个数据全对的 CSV。

我们测试集里有一个真例子：

Go to spaces and navigate to one of the recommended spaces to view. Check the profile of one of the top contributors in this space and return how many followers they have.

agent 报了有 227 个粉丝，但推荐 space 的页面要登录，它换了一个公开能进的 space。同一份截图、同一个粉丝数，11 个评委 5 个判过、6 个判不过，分歧就一件事：公开能进的 space 算不算数。能不能替换掉登录的那个

这个任务给 0 或 1 都不对，它值 60 分。你也可以争 45 分，这个争论本身就是重点：分数没有消除疑问，而是把疑问放到了看得见的地方。所以我们改要一个数：要求的结果交付了百分之几，正确且有证据支撑。效果立竿见影。同一个评委、同一批轨迹跑四次，只改一个按理不该影响结果的设置。按过或不过读，分数波动 20 个点；按 0 到 100 读，只动 0.5 个点。

二元评委犯错得情况并不比打分评委多，它只是放大。每个边界任务抛一次硬币，每次抛硬币在总分里都算一整个任务。

三个评委取中位数

另一个杠杆是把评委模型的结果多跑几次再聚合起来。这招管用是因为评委模型的波动是随机的：每次评分都是真分数加个误差，误差之间互不相同，凑在一起会抵消掉大部分。n 个独立评委取平均，方差缩到原来的 1/n；三个评委，散布缩到 √3 分之一，五个缩到 √5 分之一。实测会打点折扣，整个 benchmark 的数字最终只动一个点左右。

怎么合比合几个更讲究。第一反应是取平均，但找埋藏的缺陷是个搜索问题：偶尔有一个评委翻到了对的文件，回来打个 10 分，另外两个稳坐 96，这一个离群值就把平均拖下去 30 分。中位数反而是更合理的。

但中位数也会把另一种情况一起扔掉：某个孤立的评委是对的，但它分不清这两种情况。我们试过一种修复情况：三个分数差太远时，把三份审查意见送给第四个模型仲裁。但这其实更是一条死路。因为再怎么缩小，并转移这种状态，打分者也是 LLM，不同次跑的结果给不同答案，等于拿稳定的中位数换了一张不稳定的不知道说什么的统计信息，最终数字比以前波动反而更强。

顺带用大学改卷的情况举例。改一摞考卷是同一个问题，没人希望两个助教给同一份卷子天差地别的分，所以不让他们各自从头判断，发一份评分细则：完整证明 50 分，真正难的那一步值 40 分，哪怕你只做出来十分之一。我们对失败模式做了一样的事：一个任务跨模型跑 20 遍，把每一种失败的情况收集起来，列成清单喂给评委，现在有 5,692 条。case也明显，它只覆盖你见过的失败方法。但是也有agent破解了这个方法，有 agent 干脆不开浏览器、直接逆向了网站的 API完成任务，但清单上没有这一行，评委模型又会不知如何是好。

分数到手，怎么比模型

每个任务有了分数，怎么拿到"A 比 B 强"的结论？三种办法，越往后越好。

定一条阈值，几乎每家榜单都会这么报。但它把分数刚告诉你的信息全扔了：52 和 48 在任何实际意义上是同一次运行。

逐任务配对：让两个模型做同一个任务，每个任务判一个赢家再数。这就是arena。分数上留 左右5 分的阈值给平局，因为两个模型面对的是同一个任务。这比“84 比 78”那种报法有用：两个模型大部分打平，Opus 在具体 14 个任务上领先。

胜场计数会把赢的幅度扔掉，均差又会被评委的判决污染，结论因此甚至可能翻转：Opus 赢 Grok 44 个任务、平均赢 12.3 分，Grok 赢 28 个、平均赢 26.7 分。按均差 Grok 赢，按胜场 Opus 以 56.6 比 43.4 赢。我们肯定相信 Opus 的能力会更好，但单个任务有时差 90 分，我能肯定这几乎总是评委模型在作怪。

模型一多，两两配对就不够用了，上 Elo方法。每个任务算一局，分差超过 5 分算赢，5 分以内算平，因为 5 分大概就是同一个评委在同一任务上的自然晃动。106 个任务、6 个配置，凑出 1,590 场对局。

前四名差距在 56 分以内，分差极小。真正拉开差距的在另一处：Opus 5 低推理档比高推理档低 88 分。把推理档位调高，比换更聪明的模型厂商管用。

评委稳了，分数才是可以对比的分数

agent 噪音的应对是诚实汇报：多跑几次，把 best-of-N 亮出来。评委波动是真的可以抹平的：做到以下几点即可。证据全给，要分数不要判决，独立评三次取中位数。评委的波动稳定下来之后，你才能画出这种图：

Luna xhigh 只比 Opus 5 落后两个任务，成本是十六分之一。这个比较有意义，前提就是评委在两次评测之间没有动。

上个月我们写的那篇 Lovable 的文章，结论是验收标准要骗不了 agent：flag 取回来才算数。这篇把问题又往前推了一级：就算 flag 是真的，但评委模型还在波动。得等裁判做到真正的公平公正之后，排行榜的数字才作数。

我们天天盯着模型之间差几个点，其实榜单里一大块分差是评委模型在波动。

所以给 agent 打分之前，先给评委模型的行为固定住。

-- 完 --

机智流推荐阅读：

1. ‍

2. 

3. 

4.