OpenAI 对 SWE-bench Pro 编程评估缺陷的分析

OpenAI 已撤回其对 SWE-bench Pro 基准测试的推荐，结论是该数据集中的任务约有 30% 是损坏的。这一发现是在对该基准测试的 731 个任务的公开拆分集进行严格审计后得出的，结果显示许多评估通过惩罚功能正确的解决方案或奖励不完整的解决方案，从而提供了错误的模型能力信号。

编程基准测试的失效模式

OpenAI 识别出了四类导致编程评估失效的主要缺陷类别。这些问题通常源于基准测试是通过程序从真实的 GitHub issues 和 pull requests 中获取的，而这些内容最初是为人类协作而非孤立的机器测试而设计的。

• 过于严格的测试： 测试强制执行了提示词中未指定的特定实现细节，导致功能正确的提交失败。
• 描述不足的提示词： 提示词省略了隐藏测试所强制执行的要求，但这些要求无法从提供的上下文中合理推断出来。
• 低覆盖率测试： 测试未能充分检查请求的功能，导致不完整或错误的修复方案通过测试。
• 误导性提示词： 指令引导模型走向错误的行为，或直接与测试的要求相矛盾。

审计方法论：智能体与人类

为了识别这些缺陷，OpenAI 采用了双轨质量保证流水线。这种方法突显了 AI agents 日益增长的效用，即执行以前因成本过高而无法手动执行的可扩展数据质量检查。

自动化智能体审查

初步筛选标记了 286 个潜在损坏的任务。随后，这些任务由基于 Codex 的调查智能体进行审计，这些智能体可以访问任务仓库和环境。这些智能体可以运行测试、检查文件并调查常见的失效模式，以区分合理的模糊性与真正的描述不足。

人类标注活动

与此同时，五名经验丰富的软件工程师审查了被标记的任务。审查人员根据问题陈述、测试用例和“gold patch”（标准参考解决方案）形成了独立判断。

对比结果

虽然智能体流水线与人类审查人员在 74% 的案例中重叠，但人类审查人员更有可能将任务识别为损坏的。具体而言，人类将低覆盖率测试识别为基准测试中最常见的问题，占 9.4%，而智能体流水线仅识别出 4.1%。这表明，智能体主导的审查是保守的，并可能低估了重叠问题的数量。

行业观点与反论点

围绕这些发现的社区讨论揭示了对“干净”基准测试的需求与软件工程现实之间的紧张关系。

现实世界的噪声作为一种特性

一些批评者认为，描述不足的提示词和矛盾的指令并不是基准测试中的“bug”，而是对专业环境的准确反映。正如一位评论者所言：

从根本上说，他们难道不是在得出结论，即分配给软件开发人员（无论是人类还是其他形式）的任务往往是不完整的、自相矛盾的，甚至更糟吗？这就是他们的工具必须应对的世界。

“Benchmaxxing” 问题

其他观察者指出，“奖励黑客行为”（reward hacking）和“benchmaxxing”——即实验室通过修改超时设置或硬件配置来人为地提高分数——的普遍存在，是 AI 评估中一个更广泛的系统性问题。由于许多基准测试是“一次性”的，且未能测试实际开发人员工作流中特有的长迭代周期，这一问题变得更加复杂。

结论：对精选基准测试的需求

OpenAI 认为，源自有机开源数据的基准测试本质上容易受到噪声的影响。为了确保部署和安全决策是基于有效数据的，OpenAI 主张开发专门为模型评估而创建的新基准测试，由经验丰富的软件开发人员专门设计，而不是依赖于程序化采集的数据。