2026年7月8日

剥离编程评估中的噪音，提取真实信号

通过详细的审计，我们发现 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 进行了类似的审计，审查了该数据集。该流水线审查了模型对任务的尝试、任务元数据以及失败追踪记录，以标记出可能存在的评估缺陷。随后，每一个被标记的任务都会经过调查员智能体 (investigator-agent) 的多轮评估，并由五位经验丰富的软件工程师进行独立审查；遇到分歧时则会上报以作进一步调查。

我们发现该数据集的很大一部分存在使任务失效的问题。我们的数据点分析流水线标记了 200 个 (27.4%) 存在缺陷的任务，而人工标注活动则识别出了 249 个 (34.1%)。

这些问题主要分为四大类：

测试过于严格 (Overly strict tests)¹：强制要求提示词中未指定的具体实现细节，导致许多在功能上正确的提交被判定为无效。
提示词说明不足 (Underspecified prompts)²：遗漏了隐藏测试所强制要求且无法合理推断的各项条件。
测试覆盖率低 (Low-coverage tests)：未能充分检验所要求的功能，导致不完整的修复也能通过测试。
提示词具误导性 (Misleading prompt)：将模型引向错误的行为，或与测试的要求相矛盾。

我们的发现凸显了策划高难度且公平的基准测试充满挑战，同时也展现了智能体在规模化数据质量检查中日益增长的实用性。鉴于这些结果，我们估计约有 30% 的 SWE-bench Pro 任务存在缺陷，并建议模型开发者仔细审视其结果。

研究方法

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

结合自动化筛选与人工审查的质量保证工作流，用于评估任务质量。 — 初步的数据质量分析流水线会标记出问题以供审查。我们通过智能体辅助的深度审计（针对被标记任务）以及由经验丰富的工程师参与的人工标注活动，来对这些问题进行验证。

初步的自动化筛选器会审查下发给模型的指令、模型解决任务的尝试过程，以及用于给这些尝试打分的测试用例，从而标记出可能存在缺陷或问题的样本。该筛选器标记了 286 个可能存在缺陷的任务。随后，我们通过两种方式对该子集进行了更深入的审查：一是人工监督下的智能体审查，即通过调查员智能体进行广泛检查并由人工做出最终判断；二是与经验丰富的软件开发者合作进行的人工标注活动。

人工监督下的智能体审查

每个被标记的问题都会由基于 Codex 的调查员智能体进行审计，这些智能体获得了访问任务代码库与环境的权限。这有助于它们区分合理的任务歧义（通常可以通过研究上下文代码和代码仓库规范来解决）与真正的说明不足。智能体能够运行测试、检查代码仓库中的文件，并调查模型在任务上的尝试过程及其常见的失败模式。在多次独立重复这些深度审计之后，研究人员会审查摘要、做出最终判断，并对可能存在的问题进行标记。

人工标注活动

与此同时，我们针对被标记的子集开展了人工标注活动。我们与经验丰富的软件工程师合作，他们在审查任务前接受了关于基准测试目标、问题分类法及边缘情况 (edge cases) 的培训。每项任务均由五位工程师进行审查。

审查者首先根据可见的问题描述、测试用例以及作为基准的参考解决方案（即 gold patch）形成独立判断，然后再将流水线分析或运行记录作为辅助背景信息。随后，审查者根据具体证据分配标签并评定严重程度，同时将存在分歧或把握不大的案例上报作进一步审查。

相比调查员智能体，人工审查者更有可能将任务标记为存在缺陷。两种审查路径在问题归类上也存在一些分歧，但在所有被标记的任务中，“不存在缺陷 (not broken)”从未成为人类审查者最常给出的标签。在智能体流水线标记的类别中，审查者的判断在 74% 的案例中与之重合。

与智能体流水线相比，人工审查者也更有可能为单个任务选择多个标签，这表明他们发现任务在多个方面存在缺陷，或者无法简单地归入单一类别。这表明智能体结合人工审查的流水线得出的标签相对保守：它捕获了人类识别出的大类失败模式，但少计了审查者发现的带有附加或重叠问题的案例。差异最大的是低覆盖率测试问题，人工审查者认为这是该基准测试最常见的问题（占 9.4%），而智能体流水线的这一比例为 4.1%。

失败模式

在多个案例中，任务提示词规定了特定的实现方式，但隐藏的测试用例却期望得到不同的行为。

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

无

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

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

无

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

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

讨论

我们发现的问题，加上 SWE-bench Verified 中的类似案例，凸显了严格检查基准测试的重要性。开源仓库中的 Issue 和 Pull Request 最初是为人类协作而创建的，通常需要维护者和贡献者之间进行长时间的反复沟通。因此，问题描述、合并代码及单元测试并不总是能完全对应，难以形成整洁、孤立的任务来可靠地评估模型。尤其是 Pull Request 中包含的测试可能会过于严格，因为编写它们是为了验证特定的修改，而非为解决该任务定义一个与具体实现无关的标准。

与此同时，相较于不久前，现在发现评估缺陷要容易得多。随着模型能力的提升，我们可以利用这些模型对提示词、测试、补丁、追踪记录以及边缘情况进行更深入且一致的检查，从而帮助发现以前查找成本过高或难以规模化查找的基准测试问题。

我们希望更广泛的评估社区能够由经验丰富的软件开发者专门针对测试模型能力，开发出全新的基准测试。这种方法能够保持我们衡量模型能力所期望的高门槛与真实性，并能在整个过程中实现更好的人工监督。鉴于本次分析揭示的问题，我们撤回此前关于采用 SWE-Bench Pro 的建议。

归根结底，评估应当通过难以作弊、值得信赖且能真正反映模型能力或对齐程度的基准测试，提供有意义的信号。由于这些结果将为 OpenAI 的部署与安全决策提供参考，我们所追踪的评估必须是有效且具有参考价值的。