🤖 AI

Towards Evaluation Engineering: An Empirical Study of ML Evaluation Harnesses in the Wild

本文对 57 个机器学习评估框架进行了实证研究，指出规范阶段是操作挑战的主要来源，按根本原因对 16,560 个问题进行了分类，揭示未实现的功能、文档缺失和输入验证不足占问题总数的 60% 以上，并为将评估工程确立为一门独立的软件工程学科奠定了基础。

原作者： Zhimin Zhao, Zehao Wang, Abdul Ali Bangash, Bram Adams, Ahmed E. Hassan

发布于 2026-05-26

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Zhimin Zhao, Zehao Wang, Abdul Ali Bangash, Bram Adams, Ahmed E. Hassan

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象你是一位厨师，试图评判一道新食谱。你拥有食材（数据）、食谱卡片（模型）以及一套定义何为“好菜”的规则（指标）。但在你能品尝食物之前，你需要一个厨房来烹饪，一个计时器来追踪烹饪过程，以及一张记分卡来记录结果。

在人工智能（AI）的世界里，这个“厨房”被称为评估工具链（Evaluation Harness）。它是实际运行测试、加载数据、计算分数并告知你 AI 模型表现是否良好的软件工具。

这篇论文就像是对 57 个不同的"AI 厨房”进行的一次大规模检查，以观察它们如何运作、在何处崩溃，以及人们为何对它们感到沮丧。研究人员将这一新领域称为**“评估工程”**。

以下是他们研究发现的分解，使用了简单的类比：

1. 五阶段厨房工作流

研究人员发现，每个 AI 评估厨房都要经历五个特定阶段，就像一条生产线：

配置（设置厨房）： 准备好炉灶、锅具和食材。这包括安装软件和登录账户。
规范（编写食谱）： 决定具体要烹饪什么以及使用哪些食材。这是你加载 AI 模型和测试数据的地方。
执行（烹饪食物）： 实际运行 AI 模型以生成答案。
评估（品尝与打分）： 将答案与正确答案进行比对并计算分数。
报告（呈上菜单）： 以图表或报告的形式展示最终结果。

大惊喜： 大多数这些厨房在“烹饪”（执行）方面表现出色，但在“呈上”（报告）方面却糟糕透顶。很少有厨房配备自动警报，能在今天的食物味道不如昨天时提醒你。

2. 问题出在哪里（根本原因）

该团队查看了用户提交的超过 16,000 条投诉（称为“问题”）。他们发现，问题通常不是因为数学错误，也不是因为代码以戏剧性的方式崩溃。相反，问题大多是官僚主义和缺失组件造成的。

这就像试图组装一套乐高积木，但说明书缺失了，或者盒子上写着“包含一块红色积木”，但你只得到了一块蓝色的。

厨房失败的三大原因是：

功能缺失（24%）： 工具承诺了某项功能（例如处理特定类型的数据），但开发人员从未真正构建该部分。这就像一辆有方向盘但没有发动机的汽车。
糟糕的说明（20%）： 工具可以运行，但手册缺失、过时或令人困惑。用户无法弄清楚如何使用它。
缺乏安全检查（17%）： 工具不检查食材是否新鲜。如果你喂给它错误的数据，它不会停止；它只是烹饪垃圾并给你一个垃圾分数。

3. 不同类型的厨房

研究人员将这 57 个厨房分为四种“原型”（类型），每种类型都有其特定的头痛问题：

标准化测试厨房（40%）： 这些是大型、著名的厨房，使用标准化考试（如 AI 的 SAT）来测试多种模型。
- 它们最大的头痛： 依赖项断裂。 它们依赖外部食材（数据集），这些食材会毫无预警地发生变化或消失。如果供应商改变了包装，整个厨房就会停止工作。
专用工具（21%）： 这些是微小的工具，只做一件事且做得完美（例如检查机器人是否能行走）。
- 它们最大的头痛： 糟糕的说明。 因为它们太简单了，开发人员忘记了编写清晰的设置说明。
定制探针（21%）： 这些测试特定技能（如编程或数学）。
- 它们最大的头痛： 数学错误。 由于它们发明了自己的评分公式，它们经常算错数学，导致静默错误，即分数看起来正确但实际上是错误的。
全服务餐厅（17%）： 这些是高端、一站式平台，包办一切。
- 它们最大的头痛： 合同不匹配。 因为它们连接了如此多的不同部分（如远程判断器和本地模型），这些部分往往无法使用同一种语言交流，导致沟通中断。

4. “沉默杀手”

这篇论文发现的最危险的问题是静默评分错误。

想象一位评委品尝汤并给出五星评级。评委很自信，分数已打印，大家都很开心。但实际上评委忘了加盐，汤的味道糟透了。工具没有崩溃；它只是给出了一个错误的分数。

论文发现，许多工具计算分数不正确（算法错误）或未能检查数据是否合理（验证缺口），而且由于系统中没有内置的“第二意见”，直到很久以后才有人注意到。

5. 这对未来的意义

该论文得出结论，我们需要将这些工具不仅仅视为“脚本”，而是视为严肃的工程产品。

开发人员需要停止假设数学是完美的，并开始构建“安全网”（例如在打印分数之前检查分数是否合理）。
用户需要停止盲目信任分数。仅仅因为工具说“准确率 95%"并不意味着它是真的；你需要复核工作。
研究人员需要发明新的方法来测试这些工具，因为测试软件的传统方法在“测试”本身是一个可能会产生幻觉的 AI 时是行不通的。

简而言之： 我们建造了令人惊叹的机器来测试其他机器，但这些负责测试的机器往往缺少说明、逻辑存在漏洞，并且缺乏在困惑时告知我们的能力。修复这些“厨房”与培养更优秀的“厨师”（AI 模型）同样重要。

技术摘要：迈向评估工程：对现实世界中机器学习评估框架的实证研究

1. 问题陈述

机器学习（ML）评估支撑着人工智能的进步，然而执行这些评估的软件基础设施——即评估框架（evaluation harnesses）——从软件工程（SE）角度受到的关注却十分有限。现有文献侧重于评估什么（指标、基准、能力），而将框架本身视为透明工具，而非具有独特操作工作流、故障模式和设计权衡的工程化软件产品。

这一差距导致对**评估工程（EvalEng）**缺乏理解：评估工程化过程中产生的软件工程问题，包括框架设计、依赖管理、评分正确性以及结果完整性。缺乏这种理解，机器学习评估的可靠性会因基准污染、结果不可复现以及难以在复杂基础设施中检测到的静默评分错误等问题而受损。

2. 方法论

作者对截至 2026 年 1 月 6 日收集的 57 个开源评估框架和 19,638 个 GitHub 问题（包括错误报告、功能请求和使用疑问）进行了大规模实证研究。该研究采用四阶段方法论：

框架收集：研究人员从精选来源（如 Awesome Production ML List）识别出 57 个框架，并通过基于关键词的 GitHub 搜索扩展覆盖范围。纳入标准包括明确的评估/基准测试功能、模型调用以及活跃维护（500+ 星标，过去 12 个月内有活动）。
工作流提取：利用对文档和本地执行的迭代开放式卡片分类和恒定比较法，团队推导出了分层工作流模型。该过程在第 51 个框架处达到理论饱和。
问题挖掘：团队从 57 个框架（跨越 59 个仓库）中检索了 19,638 个问题。
分类：采用混合方法，结合人工标注与大语言模型（LLM）分类。
- 人工标注：由两位作者对 377 个具有统计显著性的问题进行人工标注，以建立工作流阶段和根本原因的分类体系。评分者间信度很高（Cohen's $\kappa > 0.87$ ）。
- LLM 校准：基于 Claude Haiku 4.5 的分类器针对人类共识标签进行校准，并应用于完整语料库，将问题映射到工作流阶段和根本原因类别。

3. 主要贡献

本文通过四项主要贡献为评估工程奠定了实证基础：

统一工作流模型：一个包含五个阶段、九个步骤、三十四种策略的模型，描述了机器学习评估的操作生命周期（资源供给 $\to$ 规范定义 $\to$ 执行 $\to$ 评估 $\to$ 报告）。
实证问题映射：对 57 个框架中 16,560 个与工作流相关的 GitHub 问题进行了分类，识别出操作摩擦发生的位置。
根本原因分类体系：一个包含十个类别的操作挑战分类体系，区分了软件缺陷（如算法错误）和能力缺口（如未实现的功能）。
采用差距识别：一项分析揭示了面向生产的能力存在显著差距，例如不确定性量化和回归告警。

4. 主要结果

研究问题 1：操作工作流

研究识别出一个五阶段工作流：

资源供给（Provisioning）：环境设置和凭据配置。
规范定义（Specification）：定义输入（模型、数据集）和评分裁判。
执行（Execution）：运行被测系统（SUT）。
评估（Assessment）：计算指标并聚合分数。
报告（Reporting）：可视化结果并对回归进行告警。

发现：

离线主导：大多数框架（40.4% 的标准化大语言模型套件，21.1% 的窄域库）仅限于静态、离线工作流。仅有 17.5%（全栈大语言模型平台）涵盖所有五个阶段。
策略缺口：虽然安装（git clone、Python 包）几乎是通用的，但容器化部署却很罕见（21.1%）。仅有 7.0% 的框架支持生产流量采样。
报告缺陷：报告是支持最少的阶段。仅有 22.8% 的框架量化不确定性，仅有 8.8% 提供回归告警。

研究问题 2：操作挑战的根本原因

研究将 16,560 个问题分类为十种根本原因。前三种原因占所有问题的61.7%：

未实现功能缺口（24.3%）：所需功能缺失。
文档缺陷（20.3%）：缺少或过时的说明。
验证缺口（17.2%）：缺少输入/输出验证。

原型特定模式：

标准化大语言模型套件：问题数量庞大；次要根本原因是外部依赖断裂（8.9%），这是由于依赖不断变化的上游数据集所致。
特定任务探针：次要根本原因是算法错误（11.9%），因为领域定制的评分缺乏参考实现。
全栈平台：次要根本原因是接口契约不匹配（10.6%），这是由于复杂的多组件集成所致。
窄域库：文档缺陷（31.8%）是主要根本原因，超过了功能缺口。

研究问题 3：各阶段的根本原因分布

根本原因并非均匀分布；它们集中在特定阶段：

资源供给：以环境不兼容（16.1%）和外部依赖断裂（20.1%）为主导。
规范定义：集中在未实现功能缺口（32.8%）和文档缺陷（27.1%）。
评估：以算法错误（25.9%）和验证缺口（22.5%）为主导。
跨阶段：验证缺口是唯一在所有五个阶段中占比均超过 10% 的根本原因，表明系统性地需要更好的语义验证。

工作流转变：挑战从早期阶段的环境相关问题转变为后期阶段的评分相关问题。

5. 意义与影响

本文认为，评估可靠性是一个独特的软件工程问题，需要超越指标设计的关注。

对于开发者：
- 超越模式验证，转向语义 API 契约，以防止静默失败（例如，类型有效但语义错误）。
- 为评分管道实施独立于预言机（oracle-independent）的验证（例如，变换测试、差异测试），因为框架输出通常缺乏独立的真实基准。
- 根据原型特定的故障模式定制维护（例如，为基准套件固定依赖项，为全栈平台进行契约测试）。
- 发布机器可读的规范文档（类似于模型卡片），声明工作流覆盖范围、依赖项和已知挑战模式。
对于用户：
- 不要在没有独立验证的情况下将框架输出视为真实基准，特别是在偏离设计的基准配置时。
- 认识到大多数框架缺乏不确定性量化，这使得区分真实能力缺口与框架伪影变得困难。
对于研究人员：
- 将评估工程视为一个软件工程研究问题。现有的 MLOps 和测试框架需要进行结构性调整，以应对评估框架的独特约束（例如，提示敏感性、基准漂移、静态与生产流量分布的偏移）。
- 研究如何在基准不稳定的环境中定义回归阈值和统计显著性。

研究结论指出，提高评估可靠性需要对所有阶段的工作流设计采取整体方法，而不是孤立地改进指标或基准。所提供的工作流模型和根本原因分类体系为纵向研究提供了基线，以追踪评估基础设施的成熟度。