评测结果究竟能证明什么？一项对 Inspect Evals 的可复现性审计

导语

看到一个基准分数时，人们往往会直接问：哪个模型更强？某个评测器是否可靠？但评测代码真正明确的，通常只是一次前向计算——任务如何构造、评分器如何运行，以及最终报告哪个指标。它并不自动证明支撑这些数字的历史数据、版本状态和语义解释都足够完整。

论文《What Does an Evaluation License?》将这个经常被忽略的环节称为“主张—证据”层，并以固定提交版本对 Inspect Evals 展开了一次系统盘点。核心问题不是重新跑出一个分数，而是判断：给定现有证据，这个分数究竟允许我们说到哪一步。

核心要点

• 评测工件不等于结论授权。 一个任务、评分器和指标可以定义计算流程，却未必绑定了可重放的历史证据，也未必消除了对指标含义的多种解释。
• 把主张形式化。 研究设置了冻结底座 D、具有语义依据的候选族 F，以及待回答的主张查询 q，再用由此得到的“识别集”表示所有仍与证据相容的结果。
• 对 124 个单元逐一给出终止状态。 其中 110 个在确定性推断之前就停止，原因是缺少必要的历史证据，或无法完成足够的语义落地。停止并不等于代码无效，而是说明当前材料不能支持更强的历史性结论。
• 不同问题的稳健性不同。 在能够闭合执行的案例中，精确数值、最佳模型、完整排序和两两关系并不必然拥有相同的识别集。某个比较关系稳定，并不意味着完整排名也稳定。
• 区分主要评测族与复核评测族。 研究还按照 primary 与 review family 分开观察结果，从而避免把不同用途、不同语义要求的评测混成一个“可靠”或“不可靠”的标签。

意义与影响

这项工作把评测可复现性从“脚本能否运行”推进到“结论能否被证据支持”。在模型排行榜、自动评审和历史基准比较中，代码仓库常常比数据快照、版本上下文和判定语义更容易保存；如果后者缺失，重新执行得到的只是一次新的计算，不一定是对原始主张的重放。

对评测作者而言，发布结果时应同时记录固定提交、历史输入、评分规则和语义依据，并明确哪些结论可以复核、哪些只能保留为未识别。对评测使用者而言，看到“模型 A 胜出”时，还应追问这个胜出是精确数值、整体排名，还是仅在某些解释下成立的局部关系。

论文最终主张一种“失败即封闭”的审计方式：遇到证据缺口或语义歧义，就返回类型化的停止原因；若不同合理解释产生不同结果，则提供不稳定性见证；只有在解释范围内保持一致的部分，才作为稳定子结构报告。这样的结果可能不如单一排行榜醒目，却更接近评测真正能够许可的结论。

来源：Hugging Face Daily Papers