LLM 评测

基准分数为什么不可复现？UK AISI 与 EvalEval 用共享规范补评测报告的缺口

同一个模型、同一个基准，换一套评测协议或推理预算，分数就可能不一样——这就是评测报告的"不可复现"问题。UK AISI 加入了 EvalEval 的共享基建：用 Every Eval Ever 规范和 Evaluation Cards 公开 5 个基准、6 个前沿模型的验证结果与方法细节。本文完整编译：HLE 随 token 预算变化的曲线、Terminal-Bench 2.0 的跨设置对比，以及参与方式。

一句话结论："同一个模型、同一个基准，分数对不上" 往往不是模型变了，而是评测协议、推理预算、反馈条件不一样。英国 AI 安全研究院（UK AISI）宣布使用 EvalEval 的共享基建公开评测结果：用 Every Eval Ever（EEE）规范和 Evaluation Cards 平台发布 5 个基准、6 个前沿模型的验证结果，以及配套的方法、上下文与配置信息——让"这个分数到底怎么来的"变成可查、可复现、可比较。

本文完整编译自 Hugging Face × EvalEval × UK AISI 联合博客《How UK AISI and EvalEval Are Making Benchmark Results Reproducible》（2026-09-22），并做中文整理。

一、问题：结果到处都是，信息不够复现

随着 AI 部署加速，评测正在成为关于模型与系统性能的关键证据。但现实是：

结果分散在各种格式、平台和渠道里；
很多报告缺少复现所需的信息（采样参数、推理预算、评测协议、上下文设置……）；
而重跑一次评测本身可能贵得离谱——尤其是前沿模型的推理成本。

EvalEval Coalition 的使命就是改善这个生态：通过共享的报告规范 Every Eval Ever（EEE） 和开放平台 Evaluation Cards，把评测结果与"理解这些结果所需要的信息"放进一个共同结构里。

这项合作并非临时起意：AISI 与 EvalEval 的合作始于 NeurIPS 2025 期间的联合工作坊，AISI 的反馈也影响了 EEE 规范的形态。这次是把共享基建真正投入实践。

二、EvalEval 的两件基建

项目	是什么	解决什么问题
Every Eval Ever（EEE）	共享的评测结果规范与仓库	统一"评测结果 + 必要元信息"的记录格式
Evaluation Cards	开放的结果展示与比较平台	把基准元数据、评测运行数据、模型元数据合并成可解释的记录

EEE 的仓库开放在 GitHub（evaleval/every_eval_ever）；Evaluation Cards 则让研究者可以按基准或按模型浏览评测结果，也可以把它当作观察"整个评测报告生态"的窗口。

这两件基建共同回答一个关键问题：为什么两个看起来相似的分数，其实是在"有意义地不同"的条件下产生的。比如同样的基准，一个报告用了 3 次采样取最好成绩，另一个做了 20 次独立运行；一个是零样本，一个给了工具权限——不把这些条件写清楚，分数就没有可比性。

三、AISI 开放了什么

AISI 这次公开的内容相当具体。主实验覆盖 5 个基准：

HealthBench（医疗健康）
FrontierMath（前沿数学）
Humanity's Last Exam（HLE）（跨领域高难综合）
SWE-Bench Pro（软件工程）
Terminal-Bench 2.0（终端/命令行任务）

覆盖 6 个前沿模型：Claude Opus 4、Claude Opus 4.5、Claude Opus 4.6、GPT-5、GPT-5.2、GPT-5.4。此外还包含两组相关网络安全评测——Cyber CTFs 与 The Last Ones（使用不同、部分重叠的模型集合）。

这些数据伴随 AISI 的论文《How Inference Compute Shapes Frontier LLM Evaluation》发布，研究的主题正是：基准表现如何依赖推理时算力（inference-time compute）与评测协议。

四、推理算力与评测协议如何改变分数

这次公开的数据中，最有价值的是可交互的结果卡片。以 Humanity's Last Exam 为例：

曲线展示的是在给定 token 数内累计解出的任务占比（每条任务取"最早一次成功"）；
当模型每次尝试后能获得来自 oracle 的正确性反馈时，随着 token 使用增加，模型能继续解出更多任务。

换句话说："HLE 得分"不是一个固定常数——它随你给模型多少推理预算、以及评测过程中是否提供反馈而移动。第二张结果卡片则把 AISI 的 Terminal-Bench 2.0 结果与其他报告的同一批模型放在一起，提示不同评测设置下的可比性问题。

这带来两个直接结论：

看到分数先问条件：推理预算、采样次数、是否给反馈、工具与上下文配置，都会改变结果；
"可复现"要落到 transcript 级别：AISI 特别强调，轨迹级（transcript-level）透明度不仅关系复现，也关系分析与诊断——只有看到具体执行轨迹，才能解释"为什么这次成了、那次没成"。

五、AISI 的评测工程：更省、更稳、更标准

公开结果背后，AISI 有一套自己的评测方法学工作，本次公告里点到三项：

OptStop：让评测更高效（论文 arXiv:2608.14425）——在保证统计意义的提前下，尽早停止不必要的推理；
HiBayES：用分层贝叶斯建模让 LLM 评测在统计上更严谨（论文 arXiv:2505.05602），更好地处理题目难度、模型方差等层级结构；
标准化工作：覆盖 transcript 分析与能力激发（capability elicitation）等领域——也就是"怎么把模型真实能力问出来"这件事本身的规范。

三者组合起来，回答的正是评测领域最实际的三个问题：怎么测得省、怎么测得准、怎么报告得清楚。

六、为什么这件事值得开发者关注

对不同的角色，这次合作有不同含义：

做模型选型的工程团队：以后再看到"某模型在某基准拿到 X 分"，可以到 Evaluation Cards 上核查它的评测条件，避免用不可比的数字做决策；
做评测/Agent 平台的人：EEE 给了"评测结果该怎么记录"的参考结构，尤其适合需要长期追踪自有模型/Agent 表现的团队；如果你的评测跑在 MCP/工具环境里，"记录哪些是轨迹、哪些是终态证据"会越来越重要；
做研究与政策分析的人：AISI 的公开数据提供了已验证的参考点，可以研究"设置选择如何影响报告的分数"这类元科学问题。

EvalEval 官方给三类角色的参与入口也很清楚：

角色	可以做什么
模型开发者	通过 Evaluation Cards 提交已验证的评测结果
评测开发者	用 EEE 规范（GitHub 仓库）报告基准与运行数据
评测 / 治理 / 政策研究者	浏览 Evaluation Cards，或研究整个评测报告生态

七、结语

这次合作的实质，是给"评测"这件事补上工程纪律：把结果、条件、轨迹放进统一结构，让分数可以被理解，而不是被误读。对任何准备长期追踪模型表现的团队来说，一个务实的起点是：从下一份内部评测报告开始，就把"协议 + 预算 + 采样 + 轨迹"一起记录下来——这比事后争论"分数为什么对不上"要便宜得多。

参考来源

Hugging Face × EvalEval × UK AISI：《How UK AISI and EvalEval Are Making Benchmark Results Reproducible》（2026-09-22）https://huggingface.co/blog/evaleval-aisi
EvalEval Coalition：https://evalevalai.com/
UK AI Security Institute：https://www.aisi.gov.uk/
论文《How Inference Compute Shapes Frontier LLM Evaluation》：https://arxiv.org/abs/2606.17930
Evaluation Cards 平台：https://evalcards.evalevalai.com/
Every Eval Ever 规范仓库：https://github.com/evaleval/every_eval_ever
OptStop 论文：https://arxiv.org/abs/2608.14425
HiBayES 博客与论文：https://www.aisi.gov.uk/blog/hibayes-improving-llm-evaluation-with-hierarchical-bayesian-modelling