同一个模型，换套评测脚本就差 80 分：AI Benchmark 到底测到了什么？

一个模型在排行榜上得了 86 分。换了一套停止符和答案提取规则，还是同一个模型、同一批题，分数却可能发生巨大变化。我们究竟是在测模型，还是在测评测脚本？

过去我们习惯把 Benchmark 分数当成模型的属性：模型 A 82 分，模型 B 76 分，于是 A 更强。

但分数并不是从模型里直接读出来的。题目先被模板包装，再经过聊天格式和推理参数送入模型；模型输出还要被截断、解析、评分，最后才能聚合成一个数字。任一环节改变，都可能让结果变化。

2026 年 9 月的论文 Benchmark Scores Are Pipeline-Dependent 对这件事做了一次端到端审计。它最值得测试人员关注的结论不是“所有排行榜都不可信”，而是：

Benchmark 分数是整条测量流水线的输出，不是模型脱离测试条件后的固有能力。

一、80 分差距是怎么产生的？

研究团队审计了 8 个网络安全 Benchmark，覆盖 23 类任务、48,662 个问题和 10 个商业、开源及安全专用模型。他们把一套评测拆成五个阶段：

阶段	关键问题	常见风险
数据	题目和标准答案可靠吗？	能力覆盖窄、标签错误、答案表示不一致
Prompt	模型实际收到了什么？	模板冲突、格式 token 泄漏、聊天模板不兼容
推理	输出怎样生成？	token 预算不足、停止符误触发、解码配置漂移
提取与评分	怎样从回答变成得分？	正则漏匹配、别名未接受、无效答案分母变化
聚合	单题结果怎样变成总分？	宏微平均混用、任务权重和指标方向不一致

论文识别出 15 类系统性失效模式。最醒目的案例来自一个网络安全基准：它把换行符设为停止序列。某个模型会先输出推理前言，换行在真正答案出现前就终止了生成，因此留下空结果。

作者调整停止条件、提供足够的 token 预算，并在提取答案前正确移除推理段后，报告该模型的分数恢复了 85.9 个百分点。

这个数字很有冲击力，也最容易被误写。它不是“所有 AI Benchmark 都可能误差 85.9 分”，更不是模型能力突然提高了 85.9 分。它是一个特定模型与特定评测管线不兼容的极端案例，说明流水线错误足以吞掉模型本来能够给出的答案。

测试人员真正应该追问的是：排行榜中的失败，有多少是模型答错，又有多少是模型根本没有获得公平作答和被正确计分的机会？

二、从数据集到总分，每一层都可能改变结论

1. 数据正确，不代表测量目标明确

一个安全 Benchmark 可以同时包含漏洞知识、威胁情报抽取、攻击技术映射和风险缓解建议。题目数量很多，不等于覆盖面足够；多个任务也可能反复测量同一种宽泛能力。

论文对 23 个任务、10 个模型的分数矩阵做分析，发现第一主成分解释了 95.25% 的变化。作者据此认为，很多任务大体反映了相近的综合表现。不过，这只是对这组任务和模型的统计描述，不能推广成“95% 的 AI Benchmark 都在测同一件事”。

评测设计时应先写出能力地图：我们要测的是安全知识、代码定位、风险判断，还是工具执行？每类能力有哪些代表性题目？如果没有这张地图，增加题量可能只是在重复已有证据。

2. Prompt 是测试夹具，不是无关包装

同一道选择题可以要求“只输出字母”，也可以要求“先解释再给答案”。模型对两种格式的遵循程度不同，提取器也可能只支持其中一种。

系统提示、few-shot 示例、角色设定和聊天模板都属于评测条件。它们不是越统一越好：不同模型可能需要各自官方模板；但如果每个模型使用不同提示，又必须说明比较的是“模型加推荐配置”，而不是裸模型。

3. 推理配置会制造假失败

最大生成长度太短，长推理模型可能在答案前被截断；停止序列与模型输出习惯冲突，可能生成空结果；温度、采样和后端默认值变化，也会改变重复运行的稳定性。

因此，报告一个分数至少要绑定模型版本、服务端或本地推理版本、聊天模板、温度、最大输出长度、停止条件和运行时间。只写模型名字，就像性能测试只写“接口耗时 300 毫秒”，却不写硬件、并发和数据量。

4. 提取器可能比模型更容易答错

模型回答“选项 B”，标准答案记录为“B”，语义完全一致；但一个只接受精确字符串的解析器可能判错。反过来，过于宽松的正则又可能从一段矛盾解释中抓到一个碰巧出现的字母，判为正确。

无效输出如何处理同样关键：算作错误、排除出分母，还是重试？三种策略都可能有使用场景，但不能混用后仍比较总分。

5. 聚合决定什么声音被放大

假设任务 A 有 1,000 题，任务 B 有 20 题。按所有题目微平均，A 几乎决定总分；先计算每个任务得分再宏平均，两者权重相等。两种结果回答的是不同问题。

因此，“模型 A 总分更高”还不够。测试报告应同时保留分任务结果、样本数、置信区间或重复运行波动，以及选择该聚合方式的理由。

三、修正流水线后，排行榜为什么会换位？

研究团队构建了一个诊断性评测工具，尽可能统一九类配置，包括 Prompt 格式、解码、token 上限、停止序列、答案提取、评分、分母与聚合规则。

作者报告，标准化之后，10 个模型中有 9 个至少在一个 Benchmark 上移动了三个或更多名次。两个语义相近的任务，也会因为二元评分、部分得分和别名处理方式不同，而给出不一致的模型排序。

这不意味着标准化后的排名就是唯一真相。论文自己明确说明：这套工具用于暴露和纠正评测选择，不是一个放之四海而皆准的评判器。

排名变化至少可能有三种解释：

• 原流水线存在实现错误，修正后更接近原本的测量目标；
• 两套协议都合理，但测量的能力定义不同；
• 所谓“统一”反而破坏了某个模型或任务需要的合法条件。

所以审计不能以“分数变化越小越好”为目标，而要判断每个变化是否更符合事先定义的测试契约。

四、如何验收一套 AI 评测流水线

我建议把 Benchmark 当成需要独立测试的软件产品，而不是下载后直接运行的题库。

第一步：先定义预期，而不是先看排行榜

在运行模型前写清楚：

• 要测量的能力和不测量的能力；
• 可接受回答的范围与格式；
• 哪些情况必须判错，哪些可以部分得分；
• 拒答、超时、空输出和解析失败分别怎样处理；
• 多少差距才足以支持选型或上线决策。

如果先看模型输出，再修改规则让“合理答案”通过，评测会被结果反向塑造。合理的规则修订可以进行，但必须保留版本、原因，并重新计算所有模型，而不是只修某个失败样本。

第二步：给流水线建立一组金丝雀样本

不需要先跑几万题。可以人工设计一小组确定性样本，专门验证管线：

金丝雀样本	预期发现的问题
答案出现在第一行和最后一行	stop sequence 与 token 截断
“B”“选项 B”“答案是 B”	等价答案与提取器兼容性
解释中先否定 A，最后选择 B	正则误抓中间 token
空字符串、拒答、超时	无效结果和分母策略
多个任务规模相差悬殊	宏平均与微平均差异
人工植入一条错误标准答案	标签审查与异常检测

这些样本测试的是测量系统，不用于证明模型能力。

第三步：保存原始输出，评分器可重复运行

原始 Prompt、模型响应、调用参数、退出原因和错误信息都应保留。评分逻辑改变时，优先对同一批输出重新评分，这样才能隔离评分器的影响。

如果改的是 Prompt、推理参数或停止条件，就必须重新生成。此时结果变化同时包含新配置和模型随机性的影响，不能描述成纯粹的评分修正。

第四步：做单变量扰动

每次只改变一个条件，例如最大 token 从 256 调到 1,024，其他设置保持不变；或者只替换答案提取器。比较：

• 总分与分任务分数变化；
• 无效输出率；
• 解析器之间的一致率；
• 模型排名及成对次序；
• 受影响样本和失败原因。

若一次同时换 Prompt、推理后端和评分器，即使结果提高，也不知道是哪一项造成的。

第五步：在报告中附一张评测流水线卡

至少包含：

项目	必须记录的内容
数据	名称、版本、筛选条件、样本数、标签修订
Prompt	系统提示、题目模板、few-shot、聊天格式
推理	精确模型版本、后端、温度、token 预算、停止条件
提取	解析代码版本、等价答案、无效输出处理
评分	单题规则、部分得分、judge 配置
聚合	权重、分母、宏/微平均、重复次数
证据	原始输出、错误日志、配置文件与代码提交

没有这张卡，别人很难复现你的分数；未来模型或依赖升级后，你自己也无法判断分数变化来自能力还是环境。

五、一个低成本的可复现实验

本文没有独立运行论文的八个 Benchmark。下面是一个可以在普通项目中执行的实验方案，属于工程建议，不是已经完成的实验结果。

准备 30～50 条拥有明确答案的内部测试题，覆盖至少三类能力。选择两个模型，各固定一次原始输出。然后设计三组评分：

• 严格精确匹配；
• 支持事先声明的等价表达；
• 使用规则提取后再评分。

保持输出不变，比较三组评分和无效答案率。这一步只测试提取与评分。

然后选择一个模型，分别使用短 token 预算和足够 token 预算运行；除该变量外保持一致。记录截断率、答案出现位置和最终得分。这一步测试推理配置。

实验开始前定义失败条件：

• 人工金标准抽查发现错误率超过预设门槛，暂停模型比较；
• 两个提取器对同一输出分歧超过门槛，先审计解析规则；
• 无效答案率异常升高，不把它隐藏在总分中；
• 任一配置字段无法追溯，本轮结果不得用于上线决策。

最终交付物不是“哪个模型第一”，而是三份证据：模型在固定协议下的结果、协议扰动造成的变化，以及仍未解释的失败。

六、别把论文结果扩大成普遍定律

这项研究提供了罕见的端到端评测审计，但仍有明确边界。

首先，实证对象是网络安全领域的 8 个 Benchmark。它提出的五阶段模型具有通用启发，但“15 类失效”“85.9 个百分点”和具体排名变化都不能直接外推到医疗、客服、RAG 或编码 Agent。

其次，部分分析依赖重新生成，无法像固定输出重新评分那样完全隔离单个变量。作者也说明，有些扰动只能在条件允许时进行。

再次，统一配置是诊断手段，不是唯一正确配置。对一个模型使用其官方聊天模板，和对所有模型使用同一模板，分别对应不同的比较目标。

最后，论文是一篇预印本。代码和评测工具已经公开，但本文尚未独立复现实验，因此文中的论文数字均应理解为作者报告。

七、测试人员真正需要守住什么

模型评测和普通软件测试有一个共同原则：结论强度不能超过证据强度。

一次运行只能说明某个版本在某套条件下的表现；一个总分不能替代失败分类；排行榜差距不能自动变成生产环境收益；脚本成功退出，也不能证明它正确解析了模型回答。

当团队下次拿出一个漂亮分数，可以先问六个问题：

• 测的具体能力是什么？
• 模型实际收到了什么 Prompt？
• 输出是否被截断或判为无效？
• 答案怎样被提取和计分？
• 总分怎样聚合，失败样本是否仍在分母中？
• 换一项合理配置，结论是否仍然成立？

Benchmark 的价值不是制造一个方便传播的数字，而是提供一套可重复、可解释、能被推翻的测量过程。

真正可靠的模型选型，不是挑排行榜上分数最高的名字，而是确认：这条评测流水线测到的能力，确实是你的产品需要的能力；它给出的差异，也经得起配置变化和失败样本的复查。

---

参考资料

• Benchmark Scores Are Pipeline-Dependent：论文全文（v1）
• 论文摘要与版本记录
• CyberBench Audit：作者公开的审计代码
• SAYF-Eval：作者公开的诊断性评测工具
• 编码 Agent 的交付验收流程
• 别再迷信 LLM 裁判

说明：论文数字来自作者报告，本文未独立复现其完整实验；评测流水线卡、金丝雀样本和低成本实验是基于论文方法提出的工程建议。