OpenAI 审计 SWE-Bench Pro 发现约 30% 的评测任务存在缺陷

通过一次详细审计，我们发现 SWE-Bench Pro 中普遍存在任务问题，并估计约 30% 的任务是有缺陷的。

准确衡量我们模型的能力，对于合理的部署和安全决策至关重要，包括依据 OpenAI 的 Preparedness Framework⁠ 所做的决策。每次发布模型时，我们都会报告一系列外部和内部基准测试的结果，以追踪模型的进展。当评估存在影响结果的缺陷时，它们可能会让人对能力产生错误理解，从而误述安全论证并影响研究优先级。

我们 最近调查了 最广泛使用的编码基准之一 SWE-bench Verified 如何存在根本性的设计和污染问题，并发现该评估已不再能提供关于软件开发能力的有意义信号。当时，我们鼓励更广泛的社区转向 SWE-Bench Pro。

SWE-Bench Pro⁠ 旨在改进 SWE-bench Verified，通过在更长的时间跨度和更真实的编码任务上测试模型，以更好地追踪智能体编码能力。与 SWE-bench Verified 一样，任务是以程序化方式从一组公开和私有代码仓库的功能变更历史中提取的。模型需要实现一个解决方案，使其通过针对某项功能的新测试，同时不破坏现有功能。在 731 项任务的公开拆分集上，前沿模型在八个月内从 23.3% 的通过率提升至 80.3%。

此后，我们对 SWE-Bench Pro 进行了类似的审计，使用数据点分析流水线审查了该数据集。该流水线审查了模型在任务上的尝试、任务元数据和失败轨迹，以标记出可能的评估缺陷。随后，每个被标记的任务都经过多轮调查智能体的评估，并由五位经验丰富的软件工程师独立审查，存在分歧的情况则升级进行进一步调查。

这些问题主要分为四类：

• 过于严格的测试¹强制要求提示词中未指定的具体实现细节，导致许多功能上正确的提交被判定为无效。
• 描述不充分的提示词²遗漏了隐藏测试所要求且无法合理推断的需求。
• 覆盖率不足的测试对所请求功能的检查不充分，因此不完整的修复也能通过。
• 误导性的提示词将模型引向错误的行为，或与测试所要求的内容相矛盾。

我们的发现表明，构建既困难又公平的基准测试十分不易，同时也凸显了智能体在大规模数据质量检查方面日益增长的实用价值。基于这些结果，我们估计约 30% 的 SWE-bench Pro 任务存在缺陷，并建议模型开发者仔细审查相关结果。

方法论

我们的目标是确保任务失败反映的是模型真实的能力局限，而任务成功则反映的是对提示词要求的完整且有效的解决方案。为了检查评估中所用数据的质量，我们构建了一条质量保证流水线，用以评估每个数据点是否准确反映了模型能力。

一条初步的自动化过滤器会审查提供给模型的指令、模型为解决任务所做的尝试，以及用于对这些尝试进行评分的测试，从而标记出可能存在缺陷或有问题的样本。该过滤器标记出了 286 个可能存在问题（broken）的任务。随后，我们以两种方式对这一子集进行了更深入的审查：一种是由人工监督的智能体审查，通过调查智能体进行大量检查并最终由人工做出判断；另一种是与经验丰富的软件开发者合作开展的人工标注工作。

人工监督的智能体审查

每个被标记的问题都会由基于 Codex 的调查智能体进行审计，这些智能体被授予访问任务仓库和环境的权限。这有助于它们区分合理的任务歧义——通常可以通过研究附近的代码和仓库惯例来解决——与真正的描述不充分。该智能体可以运行测试、检查仓库中的文件，并调查模型的尝试及其在该任务上的常见失败模式。在这些更深入审计经过多次独立重复后，一名研究员审查了摘要，做出最终判断，并为可能存在的问题打上标签。

人工标注活动

与此同时，我们针对被标记的子集开展了一场人工标注活动。我们与经验丰富的软件工程师合作，他们在审查任务之前接受了关于基准目标、问题分类体系和边缘案例的培训。每个任务由五名工程师审查。

审查员根据可见的问题陈述、测试用例以及真实参考答案（称为 gold patch）形成独立判断，然后再将流水线分析或记录作为辅助背景信息使用。随后，审查员基于具体证据分配标签和严重程度评级，并将分歧或低置信度的案例上报以进行进一步审查。

人工审查员比调查智能体更倾向于将任务标记为有问题。两条审查路径之间在类别上也存在一些分歧，但在任何被标记的任务中，“没有问题”都不是最常见的人工标签。在智能体流水线标记的类别中，审查员的判断在 74% 的案例中与之重叠。

与智能体流水线相比，人工审核员也更可能为同一个任务选择多个标签，这表明他们认为任务在多个方面存在问题，或者无法干净地归入单一类别。这说明智能体加审核员的流水线产生了偏保守的标注：它捕捉到了人类识别出的相同宽泛故障模式，但低估了审核员看到额外或重叠问题的情况。差异最大的是低覆盖率测试，人类将其选为最常见问题的比例为基准的 9.4%，而智能体流水线为 4.1%。

故障模式

在若干情况下，任务提示词规定了特定的实现方式，但隐藏测试用例期望的是不同的行为。

该任务涉及规范化目录条目，并通过 TocEntry.to_markdown() 将其重新渲染为 Markdown。任务提示词规定了精确到字符级间距的序列化方式，描述了如何强制实施精确间距和竖线，并给出了诸如 " | Chapter 1 | 1" 和 "** | Chapter 1 | 1" 之类的示例：

无

1
"[space]| Chapter 1 | 1"
2
"**[space]| Chapter 1 | 1"
3
"[space]| Just title | "

而隐藏的 test_to_markdown 断言则要求 " | Chapter 1 | 1" 和 "** | Chapter 1 | 1"：

无

1
"[space][space]| Chapter 1 | 1"
2
"**[space][space]| Chapter 1 | 1"
3
"[space][space]| Just title | "

隐藏测试中有两个前导空格，但提供给模型的示例只包含一个前导空格。如果模型正确地遵循了给定的提示词，那么这一个字符的差异就会导致隐藏测试用例失败，该任务也会被判定为错误。

讨论

我们发现的这些问题，再加上 SWE-bench Verified 中的类似案例，凸显了严格检查基准测试的重要性。开源仓库中的 issue 和 pull request 最初是为人类协作而创建的，往往经过维护者与贡献者之间漫长的反复沟通。因此，问题描述、合并的代码和单元测试并不总能对齐，形成干净、隔离的任务来可靠地评估模型。尤其是，pull request 中包含的测试可能过于严格，因为它们是用来验证某一具体改动的，而非定义一个与实现无关的解决任务的标准。

与此同时，如今发现评估缺陷比不久之前要容易得多。随着模型能力的提升，我们可以利用这些模型以更高的深度和一致性来检查提示词、测试、补丁、轨迹和边缘案例，帮助揭示那些此前在大规模下发现成本高昂或不切实际的基准测试问题。

我们希望更广泛的评测社区能够开发出由经验丰富的软件开发者专门构建的新基准，用以测试模型能力。这种方式可以维持我们所期望的高标准和真实性，从而衡量模型能力，并允许在整个过程中实现更好的人工监督。鉴于本次分析中发现的问题，我们撤回此前关于采用 SWE-Bench Pro 的建议。

归根结底，评测应当通过难以被钻空子、易于信任且真正反映模型能力或对齐水平的基准，提供有意义的信号。由于这些结果会影响 OpenAI 的部署和安全决策，我们所跟踪的评测必须是有效且有信息量的。

脚注

1. 1

   我们此前⁠将这一类别称为窄测试。

2. 2

   我们此前将这一类别称为宽测试。