从编码评估中分离信号与噪声
Separating signal from noise in coding evaluations
OpenAI 对 SWE-Bench Pro 进行审计后发现约 30% 的任务存在缺陷。审计通过自动过滤器标记 286 个可能问题任务，随后使用基于 Codex 的 investigator agent 进行多次独立审查，并由五位经验丰富的软件工程师进行人工标注。人工审查员更倾向于将任务标记为有缺陷（249 个，34.1%），而 agent 流程标记了 200 个（27.4%）。主要问题包括提示与隐藏测试用例不一致、低覆盖率测试等。基于此，OpenAI 撤回此前关于采用 SWE-Bench Pro 的建议。
2026年7月8日
通过一项详细审计，我们发现 SWE-Bench Pro 中存在广泛的任务问题，估计约 30% 的任务存在缺陷。
加载中…分享方法论方法论人工监督的 agent 审查人工标注活动目录
准确衡量我们模型的能力，对于做出合理的部署和安全决策至关重要，包括在 OpenAI 的 Preparedness Framework(opens in a new window) 下的决策。每次发布模型时，我们都会报告各种外部和内部基准测试的结果，以跟踪模型进展。当评估存在影响结果的缺陷时，它们可能会对能力产生错误的理解，歪曲安全案例并影响研究优先级。
我们最近调查了最广泛使用的编码基准之一 SWE-bench Verified 如何存在根本性的设计和污染问题，并发现该评估不再能提供关于软件开发能力的有意义信号。当时，我们鼓励更广泛的社区转向 SWE-Bench Pro。
SWE-Bench Pro(opens in a new window) 旨在通过测试模型在更长周期和更现实的编码任务上的表现来改进 SWE-bench Verified，从而更好地跟踪 agent 编码能力。与 SWE-bench Verified 一样，任务是从一组公共和私有仓库的功能变更历史中以编程方式获取的。模型需要实现一个解决方案，该方案能通过新功能的测试，同时不破坏现有功能。在包含 731 个任务的公开子集上，前沿模型在八个月内通过率从 23.3% 提升到了 80.3%。
此后，我们对 SWE-Bench Pro 进行了类似的审计，使用一个数据点分析流程审查了数据集。该流程审查了模型对任务的尝试、任务元数据和失败轨迹，以标记可能的评估缺陷。每个被标记的任务随后通过多次 investigator-agent 传递进行评估，并由五位经验丰富的软件工程师独立审查，分歧之处会升级以进行进一步调查。
我们发现数据集中有相当一部分任务存在明显的缺陷问题。我们的数据点分析流程标记了 200 个（27.4%）有缺陷的任务，而人工标注活动则识别出 249 个（34.1%）。
问题主要分为四类：
我们的发现指出了策划困难但公平的基准的难度，以及 agent 在可扩展数据质量检查中日益增长的实用性。鉴于这些结果，我们估计 SWE-Bench Pro 中约 30% 的任务存在缺陷，并建议模型开发者仔细检查结果。
我们的目标是确保任务失败反映的是模型的真实局限，而任务成功则代表对提示要求的完整且有效的解决方案。为了检查评估中使用的数据质量，我们创建了一个质量保证流程，以评估每个数据点是否准确反映了模型能力。
一个初始的数据质量流程会标记问题以供审查。我们通过对标记任务进行更深入的 agent 辅助审计，以及与经验丰富的工程师合作进行的人工标注活动来验证。
一个初始的自动过滤器会审查给模型的指令、模型解决任务的尝试，以及用于对这些尝试进行评分的测试，以标记可能存在缺陷或有问题的示例。该过滤器标记了 286 个可能存在问题任务。然后，我们通过两种方式对该子集进行了更深入的审查：人工监督的 agent 审查，该审查使用 investigator agent 进行广泛检查并做出最终人工判断；以及与经验丰富的软件开发人员合作进行的人工标注活动。
每个被标记的问题都会使用基于 Codex 的 investigator agent 进行审计，这些 agent 可以访问任务仓库和环境。这有助于他们将合理的任务歧义（通常可以通过研究附近代码和仓库约定来解决）与真正的不明确性区分开来。agent 可以运行测试、检查仓库中的文件，并调查模型对该任务的尝试及其常见失败模式。在多次独立重复这些更深入的审计之后，一位研究人员审查了摘要，做出了最终判断，并标记了可能的问题。
同时，我们对被标记的子集进行了一项人工标注活动。我们与经验丰富的软件工程师合作，他们在审查任务之前接受了关于基准目标、问题分类和边缘案例的培训。每个任务由五位工程师审查。
审查员在将流程分析或记录作为支持背景之前，会根据可见的问题陈述、测试用例和真实参考解决方案（称为 gold patch）形成独立判断。然后，审查员根据具体证据分配标签和严重性评级，并将分歧或低置信度案例升级以进行进一步审查。
与 investigator agent 相比，人工审查员更倾向于将任务标记为有缺陷。两种审查路径在分类上也存在一些分歧，但在被标记的任务中，没有一个是“无缺陷”成为最常见的人工标签。在 agent 流程标记的分类中，审查员的判断在 74% 的情况下是重叠的。
与 agent 流程相比，人工审查员也更倾向于为一个任务选择多个标签，这表明他们认为任务存在多种方式的缺陷，或者不能干净地归入单一类别。这表明 agent 加审查员的流程导致了保守的标记：它捕捉到了与人类识别出的相同广泛失败模式，同时低估了审查员看到额外或重叠问题的情况。最大的差异在于低覆盖率测试，人类将其选为基准中最常见的问题，占比 9.4%，而 agent 流程的占比为 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 中的类似案例，凸显了严格检查基准的重要性。来自开源仓库的问题和拉取请求最初是为人类协作而创建的，通常通过维护者和贡献者之间漫长的来回沟通。因此，问题描述、合并的代码和单元测试并不总能对齐，形成清晰、独立的任务来可靠地评估模型。特别是，拉取请求中包含的测试可能过于严格，因为它们是为了验证特定的更改而编写的，而不是为了定义解决任务的、与实现无关的标准。
与此同时，现在检测评估缺陷比不久之前要容易得多。随着模型能力的提升，我们可以利用这些模型以更深入和更一致的方式检查提示、测试、补丁、轨迹和边缘案例，从而帮助发现以前大规模发现成本高昂或不切实际的基准问题。
我们希望更广泛的评估社区能够开发出由经验丰富的软件开发人员专门为测试模型能力而构建的新基准。这种方法可以保持我们衡量模型能力所需的高标准和现实性，并允许在整个过程中进行更好的人工监督。鉴于本分析中发现的问题，我们撤回之前关于采用 SWE-Bench Pro 的建议。
最终，评估应该通过难以被钻空子、易于信任且真正反映模型能力或对齐的基准来提供有意义的信号。由于这些结果会影响 OpenAI 的部署和安全决策，我们跟踪的评估必须是有效且信息丰富的。
我们之前 将此类别称为窄测试。
我们之前将此类别称为宽测试。
研究2026年6月30日
研究2026年6月17日
研究2026年6月17日