What Does an Evaluation License? A Commit-Bound Census of Claim-Relative Inference in Inspect Evals

TL;DR 该论文对 Inspect Evals 124 个评估单元做 commit-bound 普查，形式化指标主张的可重放性：110 个因缺少历史证据或语义接地而无法确定性推断，审计只返回可确定的稳定子结构。

问题

问题背景

AI 评估生态正从“跑分”走向“可审计声明”，基准测试的结论是否真的由发布工件支撑，成为模型能力比较的核心信任问题。

现有方法局限

当前评估工件通常只打包任务 task、评分器 scorer 和报告指标 metric，但缺少重放声明所需的两类绑定：一是历史证据（如模型版本、运行时配置、数据快照），二是语义 grounding（如评分标准、任务定义、作弊判定）。这导致：

• 即使重新运行代码，也可能得到不同的数值，无法判断差异来自评估器本身、环境漂移还是模型变化。
• 多数 reproduce 工作仅做“重新执行”，不能回答“该指标是否真的许可某个排名/胜负声明”。
• 常见的 robust/not-robust 二分结论掩盖了停止原因（找不到证据 vs. 语义不明确 vs. 计算不稳定），丢失了可操作信息。

为什么这个问题难/重要

评估声明往往依赖不可观察的历史状态与隐式语义，传统方法无法构造严格的 identified set。论文提出 claim-relative identification：冻结基底 D、grounded family F、claim query q，并枚举可恢复的身份集合，这相当于给评估加了一层形式化推理。业界关注点在于：没有这层，任何 benchmark 排行榜都可能被不可复现的“幽灵分数”污染，且无法被第三方审计。

行业类比

类似 CI/CD 中构建产物必须锁定依赖版本与构建命令，否则测试报告中的 PASS 无从追溯；评估报告中的指标同样需要 commit-bound 的可重放性。

核心洞察

• 评价工件许可的是“前向计算”（任务、评分器、指标），而非附加在该指标上的声明。重放一个声明需要同时绑定冻结基底 D、接地家族 F、声明查询 q，而当前多数 eval 只提供可执行代码，缺失历史证据与语义版本，导致 110/124 单元在确定性推断前停止。区别于传统 reproducibility 只要求代码可重跑，本文把评价视为部分识别问题，暴露“有数值、无推断许可”的隐性断裂。
• 审计不输出 robust/not-robust 二值标签，而是返回类型化停止、不稳定见证与稳定子结构，并区分精确值、赢家、完整排序在不同声明分辨率和主/审查家族下的成立情况。这种 claim-relative 输出使评估结果可被定位到“哪个声明在哪个家族下成立”，而非强制全局含义。工程上意味着评估系统必须记录 commit 边界、语义 grounding 与证据 provenance，否则无法支撑跨版本或跨家族比较。

方法

输入与形式化

• 输入：Inspect Evals 仓库在固定 commit 下的 124 个机械合格评估单元，每个单元包含 task、scorer、reported metric。
• 定义 claim-replay 许可证：由冻结的 substrate D、grounded family F、claim query q 以及对应的 identified set 组成。identified set 刻画在现有历史证据与语义约束下可确定的指标值范围。

关键模块

1. 证据流采集：收集三个证据流（历史运行记录、语义定义、评测工件配置），用于判定每个单元能否重放其声称的指标。
2. 类型化停止判定：对每个单元执行机械推断，若缺少必要的历史证据或语义 grounding，则在确定性推断前停止，并记录 typed stop（例如协议停止、缺失材料等层级）。
3. 关闭执行分析：对能够关闭执行的单元，计算 exact values、winners、complete orders 和 pairwise relations；结果按 claim resolution 和 primary vs review family 分层汇总。

输出

• 每个单元获得 terminal disposition：110 个单元在确定性推断前停止，其余单元给出可复现的 identified set 与关系结构。
• 审计报告返回 typed stops、instability witnesses 和 stable substructure，而非强制单一评估者语义或单一 robust/not-robust 标签。

与同类方法的差异：传统敏感性分析或基准基础设施通常假设单一评估器语义并输出二值鲁棒性标签；本方法通过 claim-relative identification 和 commit-bound census，将证据缺失暴露为类型化停止，并保留可恢复的稳定子结构。

实验

实验设计

作者在 pinned commit 上冻结 Inspect Evals 的全部 124 个机械合格单元，对每个单元执行 claim-relative 审计：检查其历史证据流、语义基础是否绑定到报告的 claim。审计区分 primary family 与 review family，并记录每个单元的 terminal disposition。在 Frozen Random Ten 子集上展开完整记录（3 个完整审计 + 7 个停止记录）。

关键发现

• 全部 124 个单元中，110 个 在确定性推理前停止，原因是 required historical evidence 或 semantic grounding 不可用。
• 仅 14 个单元 执行关闭，得到 exact values、winners、complete orders 和 pairwise relations。
• 这些可复现的结构按 claim resolution 和 family 分离，并出现 instability witnesses 与 stable substructure，而非单一 robust/not-robust 标签。

与基线的深度解读

传统评估范式假定评估工件（task, scorer, metric）自动 license 其声明。本审计显示这一推断层通常缺失，与 sensitivity analyses、partial identification 文献一致。工程启示：评估复现不能只靠代码，必须绑定历史证据与语义版本；否则 eval 结果的 claim 无法 replay。建议在评估基础设施中显式建模 claim-replay 层，将评估依赖视为一等公民。

行业影响

落地场景

论文提出的 声明-重放识别集 (claim-replay identified set) 概念可直接应用于模型评估平台与基准测试服务，例如内部模型质量门禁、第三方基准评测、监管审计等。具体 use case：在电商推荐系统中，团队使用多个评估器比较召回模型，但评估结论常因历史数据版本、标注语义漂移而无法复现。该审计方法能识别哪些声明有稳定证据支撑，哪些仅停留在“可执行但不许可”的状态，从而避免错误选型。金融风控场景中，模型性能声明需通过监管审查，该方法可提供类型化停止与稳定子结构证据，辅助合规沟通。

商业价值

• 降本：避免因不可复现的评估结论而重复实验，减少返工与错误部署。
• 增收：向客户提供更可信的模型性能报告，可支撑更高定价或赢得合同。
• 体验提升：内部决策者获得清晰的证据强度分级，而非单一 robust/not-robust 标签，提高决策质量与速度。

论文将评估从“跑分”提升为“可审计的证据链”，对医疗 AI、自动驾驶等强监管领域尤其有价值。

与现有产品/工作流接口

• 可集成进 MLOps pipeline，在模型注册前强制触发 claim-replay 审计步骤，输出 typed stop 与 stable substructure。
• 与 Weights & Biases、MLflow 等实验跟踪工具结合，将 frozen substrate D、grounded family F、claim query q 等元数据记录到 run 中，实现审计可追溯。
• 以 Inspect Evals 自身的 124 个单元审计为模板，企业可构建内部基准的普查流程，定期生成 commit-bound census 报告，作为发布门禁的一部分。

局限

• - 论文承认的局限：作者明确表示“前瞻性效用仍是一个开放测试”，即该审计框架对未来评估设计的预测能力尚未经验证。此外，普查仅针对 Inspect Evals 在固定提交处的 124 个机械合格单元，未覆盖其他基准或同一基准的动态更新。框架中“声明”“家族”等类别定义依赖作者构建的类型体系，可能引入主观性，影响结论的普适性。
• - 可推断的局限：审计以“确定性推理”作为执行闭合标准，导致 110/124 个单元被判定为无法推断，这一标准可能过于严格。实际评估中即使缺少部分历史证据，仍可通过替代数据或部分识别获得有用区间，但本文未探讨这种中间推断层次。此外，所有停止原因被类型化分类，缺少定量敏感性分析，无法指导优先修复哪些缺失项。
• - 与同类工作对比的弱点：与统计学中的部分识别和敏感性分析相比，该框架主要依赖类型化分类而非概率模型，未提供置信区间或不确定性量化。同时，审计过程依赖人工检查和文档解析，没有自动化工具支持，难以扩展到更大规模的评估生态。此外，未与现有基准元分析工作（如 HELM、BIG-bench audit）直接比较，也未实证验证审计结果如何改进下游模型选择。