在编程评测中区分信号与噪声

Separating signal from noise in coding evaluations

通过一项详细审计，我们发现 SWE-Bench Pro 中存在广泛的任务问题，估计约 30% 的任务存在缺陷。

Loading…

准确衡量模型能力对于合理的部署和安全决策至关重要，包括 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，通过在更长周期和更真实的编程任务上测试模型，以更好地追踪智能体编程能力。与 SWE-bench Verified 类似，任务通过程序化方式从一组公共和私有仓库的功能变更历史中获取。模型需要实现一个解决方案，通过新功能的测试，同时不破坏现有功能。在包含 731 个任务的公开子集上，前沿模型在八个月内通过率从 23.3% 提升到了 80.3%。

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

初始数据质量流程标记问题以供审查。我们通过更深入的智能体辅助审计和与经验丰富的工程师合作的人工标注活动来验证。

初始自动化过滤器审查提供给模型的指令、模型解决任务的尝试以及用于评分这些尝试的测试，以标记可能存在问题或缺陷的示例。该过滤器标记了 286 个可能存在缺陷的任务。随后，我们通过两种方式对该子集进行了更深入的审查：人工监督的智能体审查（通过调查智能体进行广泛检查并做出最终人工判断），以及与经验丰富的软件开发人员合作的人工标注活动。

人工监督的智能体审查

Human-supervised agent review

每个被标记的问题都通过基于 Codex 的调查智能体进行审计，这些智能体可以访问任务仓库和环境。这有助于它们区分合理的任务模糊性（通常可以通过研究附近代码和仓库约定来解决）与真正的规范不足。智能体可以运行测试、检查仓库中的文件，并调查模型在任务上的尝试及其常见失败模式。在多次独立重复这些更深入的审计后，一位研究人员审查了摘要，做出最终判断，并标记了可能的问题。

人工标注活动

Human annotation campaign

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

审查员根据可见的问题描述、测试用例和真实参考解决方案（称为黄金补丁）形成独立判断，然后将流程分析或记录作为辅助背景。随后，审查员根据具体证据分配标签和严重性评级，并将分歧或低置信度案例升级进行进一步审查。

与调查智能体相比，人工审查员更倾向于将任务标记为有缺陷。两种审查路径在类别上也存在一些分歧，但在任何被标记的任务中，“无缺陷”都不是最常见的人工标签。在智能体流程标记的类别中，审查员的判断在 74% 的情况下存在重叠。

与智能体流程相比，人工审查员也更倾向于为任务选择多个标签，这表明他们认为任务存在多种缺陷，或者不能干净地归入单一类别。这表明智能体加审查员流程产生了保守的标签：它捕捉到了人类识别出的相同广泛故障模式，同时低估了审查员看到额外或重叠问题的情况。最大的差异在于低覆盖率测试，人类将其选为基准中最常见问题的比例为 9.4%，而智能体流程仅为 4.1%。

故障模式

Failure modes

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

这个任务涉及规范化目录条目，并通过 TocEntry.to_markdown() 将其渲染回 Markdown。任务提示规定了字符级别的序列化格式，描述了如何强制执行精确的空格和竖线，并给出了示例，例如 " | Chapter 1 | 1" 和 "** | Chapter 1 | 1"：

None

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

None

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

讨论

Discussion

我们已识别出的问题，加上 SWE-bench Verified 中的类似案例，凸显了严格检查基准的重要性。来自开源仓库的问题和拉取请求最初是为人类协作而创建的，通常通过维护者和贡献者之间漫长的来回沟通。因此，问题描述、合并代码和单元测试并不总能对齐，形成干净、隔离的任务来可靠地评估模型。特别是，拉取请求中包含的测试可能过于严格，因为它们是为了验证特定的更改而编写的，而不是为了定义解决任务的、与实现无关的标准。

与此同时，评测缺陷现在比不久之前更容易检测到。随着模型能力的提升，我们可以利用这些模型以更大的深度和一致性来检查提示、测试、补丁、记录和边缘案例，从而有助于发现以前大规模发现成本高昂或不切实际的基准问题。

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

最终，一个评测应该通过难以被钻空子、易于信任且真正反映模型能力或对齐的基准来提供有意义的信号。由于这些结果影响着 OpenAI 的部署和安全决策，我们追踪的评测必须是有效且信息丰富的。

2026
软件与工程

作者

Author

OpenAI

脚注

Footnotes

我们之前⁠将此类别称为窄测试（narrow tests）。

我们之前将此类别称为宽测试（wide tests）。

继续阅读

Keep reading

研究2026年6月30日

一个近乎自主的AI化学家改进了一个具有挑战性的反应

一个近乎自主的AI化学家改进了药物化学中的一个具有挑战性的反应

研究2026年6月17日

LifeSciBench 1x1

介绍 LifeSciBench

研究2026年6月17日