当 AI 模型跑分挤成一团：排行榜正在失去解释力

发表于
一项覆盖 60 个语言模型基准的研究发现，接近一半的基准已经出现饱和。当头部模型的分差小于评测误差，开发者该如何重新判断模型能力？

每次新模型发布，最先出现的通常不是使用体验，而是一张更长的排行榜。

模型 A 比模型 B 高 0.8 分，模型 C 又在某个榜单上反超 1.2 分。我们很自然地把这些小数点后的变化理解成能力进步，再用它们判断哪个模型更适合写代码、做研究或运行 Agent。

但如果这把尺子的最小刻度已经大于模型之间的差距呢？

最近一篇被 ICML 2026 接收的论文 When AI Benchmarks Plateau 分析了 60 个语言模型基准。研究者发现，接近一半的基准已经出现较高程度的“饱和”：头部模型的成绩挤在很窄的区间里，分差甚至可能小于评测本身的不确定性。

我的判断是：模型可能还在进步，但很多排行榜已经越来越难解释这种进步。 公开跑分仍然有价值，只是它更适合当作筛选信号，而不是模型选型的最终答案。

基准饱和不是“大家都考了满分”

“饱和”很容易被理解为题目已经被模型做完，所有模型都接近 100 分。论文给出的定义更严格：当头部模型无法被可靠地区分，同时它们又接近这个基准可以观察到的上限时，基准才算饱和。

这就像用一把最小刻度为一厘米的尺子测量两块只差一毫米的零件。读数可能一个是 10 厘米，另一个是 10.1 厘米，但这点差异究竟来自零件，还是来自测量误差，尺子已经回答不了。

研究者还区分了另一个容易混淆的状态：停滞（stagnation）。如果头部模型暂时无法区分，但成绩离任务上限仍然很远，可能不是任务已被解决，而是现有模型、数据或评测方法暂时卡住了。

两者对模型选型的影响却很相似：排行榜上的细小领先不再足以支持一个明确结论。

接近一半的基准已经很难区分头部模型

这项研究收集了推理、编程、知识、多语言、事实性和 Agent 等方向的 60 个基准，并用一个考虑评测不确定性的饱和指数进行分析。

论文列出的几个案例很能说明问题：

基准 头部成绩区间 饱和指数 研究者的判断
MATH-500 98.2–99.2 0.92 分差落在估计的不确定性内，区分能力很弱
LiveBench 约 1.09 分的跨度 0.99 成绩仍在约 79% 的水平，更像停滞而非任务完成
LiveCodeBench 约 3.9 分的跨度 0.77 仍有差异，但已经出现明显的成绩压缩
Humanity’s Last Exam 约 11.4 分的跨度 0.22 头部模型仍能被较好地区分

这里最值得注意的不是某个具体指数，而是 LiveBench 的例子。它会持续更新题目，设计目标之一就是降低数据污染，但头部模型仍然可能挤成一团。

也就是说，“题目没有泄漏”和“这套题仍能区分模型”是两个不同问题。 私有或动态测试集可以降低模型见过答案的概率，却不能自动保证评测拥有足够的分辨率。

三个听起来正确的办法，并没有延长多少寿命

研究团队进一步检查了 14 类可能影响饱和的属性。按照他们的研究说明，下面三种常见做法在控制基准年龄后，都没有表现出与饱和程度的强关联：

  • 把测试集保持为私有；
  • 用开放式生成代替选择题；
  • 使用更多语言进行评测。

这不代表这些设计没有价值。私有数据仍能减少针对测试集训练，开放式任务也能观察更丰富的行为，多语言评测更是覆盖真实用户的必要条件。它们解决的只是其他问题，不能单独阻止排行榜失去区分度。

论文中更稳定的信号是基准年龄和测试集规模：基准越老，越容易饱和；规模更大、经过专家设计的数据，通常更能保留区分能力。研究团队因此建议使用更大且更多样的数据、动态更新、对抗式收集、带不确定性的报告，并为基准的修订或退役设置明确条件。

这其实把 Benchmark 从一份“永久试卷”变成了一项需要维护的基础设施。模型在变、训练数据在变、用户任务也在变，评测不可能发布一次就永远有效。

排行榜测到的也不一定只是模型

基准饱和只解释了尺子为什么逐渐失去分辨率。到了 Coding Agent 和通用 Agent 场景，还有第二层问题：被测对象本身也变得不再单一。

我在上一篇关于 DeepSeek V4 Flash 正式版 的文章里提到，Agent 成绩往往由模型、后训练、Harness、工具定义、上下文管理和推理预算共同决定。同一个模型换一套执行框架，结果可能发生明显变化。

Stanford CRFM 的 HELM 评测框架 也发现，Prompt 等适配策略会显著影响成绩，甚至改变模型之间的相对趋势。因此，HELM 强调同时做到三件事：覆盖多个场景、使用多个指标，并控制模型的适配方式。

所以，当我们看到一个模型在 Agent 榜单上领先时，至少要继续问三个问题：

  1. 这套基准现在还能可靠地区分头部模型吗？
  2. 不同模型是否使用了相同的工具、Prompt、Token 预算和重试策略？
  3. 榜单指标是否对应我真正需要完成的任务？

如果这些条件没有对齐，多出来的几分可能来自模型，也可能来自 Harness、预算或评测噪声。只看总分，很难知道应该把改进归因到哪里。

开发团队需要一张自己的“小考卷”

公共基准适合观察行业全景，但真正的模型选型应该回到自己的任务分布。这个过程不需要一开始就建设庞大的评测平台，一套小而稳定的内部任务集往往更有用。

我会优先做下面五件事。

1. 从真实失败里收集题目

不要只写“请生成一个登录页面”这类演示任务。保留线上失败、人工返工、工具调用异常和容易误判的边界案例。评测集应该像真实工作，而不是像产品演示。

2. 同时记录成功、稳定性和代价

一个 Agent 偶尔成功一次没有太大意义。至少应该记录：

维度 可以记录的指标
任务结果 完成率、测试通过率、人工验收结果
稳定性 多次运行成功率、结果方差、重试次数
效率 P50/P95 延迟、Token 用量、单次任务成本
工程风险 越权修改、回滚次数、错误恢复能力
人工成本 审查时间、接管次数、返工量

这里的重点不是把指标做得更多，而是避免用一个平均分遮住真正的取舍。更高的任务成功率，如果伴随数倍成本和更大的结果波动，未必就是更适合生产环境的选择。

3. 比较模型时固定执行环境

固定系统提示词、工具版本、上下文、Token 上限、超时和重试次数。否则比较的其实是两套系统，而不只是两个模型。

如果你本来就想比较完整 Agent 系统，也应该明确写成“系统 A 对系统 B”，不要把结果缩写成模型能力。

4. 报告区间，不只报告平均值

同一个任务至少重复运行几次。除了平均成功率，也要看最差表现和波动范围。当两个模型的差异小于运行波动时，更诚实的结论是“暂时无法区分”，而不是强行排出第一名。

5. 给内部评测设置退役条件

如果所有模型都能轻松通过、真实故障不再被覆盖，或者团队已经围绕题目做了大量定向优化，这套评测就应该补题、拆分或退役。

评测集不是越稳定越好。题目可以稳定一段时间，方便回归比较；它衡量的能力和失败模式则必须跟着业务变化。

饱和也可能是一件好事

并不是所有饱和都意味着评测失败。

如果一个基准定义清楚、数据有效，而模型确实已经稳定解决了任务，那么排行榜失去区分度反而代表一种成功。就像基础算术不再适合区分数学家，并不是基础算术没有价值，而是我们不该继续用它决定谁更适合研究新的数学问题。

真正困难的是区分两种情况：模型解决了任务，还是尺子停止测量有意义的差异。论文也承认，这需要更可靠的不确定性估计、任务上限和持续监测，现实中并不总能清楚判断。

因此，结论不该是“跑分都没用”，而是降低它在决策中的权重。公共排行榜负责提供候选名单，内部评测负责回答是否适合，真实运行数据负责决定能否长期留下。

下次看到新模型又领先零点几分时，可以先不急着换模型。先问一句：变长的是能力，还是排行榜的小数位？

下一代评测不应该只是一张更长的榜单，而应该是一套更接近真实工作的验收系统。

资料与口径