如何从编程评估中分离信号与噪声

准确衡量我们模型的能力对于合理的部署和安全决策至关重要，包括OpenAI《准备框架》下的决策。随着每个模型的发布，我们会报告各种外部和内部基准测试的结果，以追踪模型进展。当评估存在影响结果的缺陷时，它们可能会对能力产生错误理解，错误地呈现安全案例并影响研究优先级。

最近，我们调查了最广泛使用的编程基准测试之一SWE-bench Verified，发现其存在根本性的设计缺陷和数据污染问题，并且该评估不再能提供有关软件开发能力的有意义信号。当时，我们鼓励整个社区转向SWE-bench Pro。

SWE-bench Pro旨在通过测试模型在更长周期和更真实编码任务上的表现，改进SWE-bench Verified，以更好地追踪代理型编码能力。与SWE-bench Verified类似，任务来自一组公共和私有仓库中功能变更历史的程序化提取。模型需要实现一个解决方案，通过新测试以验证功能，同时不破坏现有功能。在731个任务的公共子集上，前沿模型在八个月内通过率从23.3%提升至80.3%。

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

我们发现数据集中有相当一部分存在破坏性问题。我们的数据点分析流水线标记了200个（27.4%）有问题的任务，而人工标注活动发现了249个（34.1%）。问题主要分为四类：

- 过于严格的测试：强制要求提示中未指定的具体实现细节，导致许多功能正确的提交被判无效。
- 提示描述不足：遗漏了隐藏测试强制执行且无法合理推断的要求。
- 覆盖率低的测试：对请求的功能检查不足，使得不完整的修复可以通过。
- 误导性提示：引导模型走向错误行为或与测试要求矛盾。

我们的发现指出了策划困难但公平的基准测试的难度，以及用于可扩展数据质量检查的代理的日益增长的价值。鉴于这些结果，我们估计SWE-bench Pro中约30%的任务有问题，并建议模型开发者仔细检查结果。

方法论

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

一个初始数据质量流水线标记待审查的问题。我们通过更深入的代理辅助审计对标记任务进行验证，并开展由经验丰富的工程师参与的人工标注活动。

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

人工监督的代理审查

每个标记的问题都使用基于Codex的调查员代理进行审计，这些代理可以访问任务仓库和环境。这有助于区分合理的任务歧义（通常可以通过研究附近代码和仓库惯例来解决）与真正的描述不足。代理可以运行测试、检查仓库中的文件，并调查模型在任务上的尝试及其常见失败模式。经过多次独立的深度审计后，研究人员审阅摘要，做出最终判断，并标记可能的问题。

人工标注活动

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

审查员在参考流水线分析或记录作为支持背景之前，从可见的问题陈述、测试用例和真实参考解决方案（称为黄金补丁）形成独立判断。然后，审查员根据具体证据分配标签和严重等级，并将分歧或低置信度的案例升级以进一步调查。

人工审查员比调查员代理更倾向于将任务标记为有问题。两种审查路径在分类上也存在一些分歧，但没有任何标记的任务中“没问题”是人工最常选择的标签。在代理流水线标记的分类中，审查员的判断在74%的案例中重叠。

与代理流水线相比，人工审查员更倾向于为任务选择多个标签，表明他们发现任务有多个问题或无法干净地归入单一类别。这表明代理加审查员流水线产生了保守标签：它捕获了人类识别出的相同广泛失败模式，同时低估了审查员发现额外或重叠问题的案例。最大的差异在于覆盖率低的测试，人类将其选为基准测试中最常见问题的比例为9.4%，而代理流水线为4.1%。

失败模式

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

讨论

我们识别出的问题，加上SWE-bench Verified中的类似案例，凸显了严格检查基准测试的重要性。来自开源仓库的问题和拉取请求最初是为人类协作而创建的，通常通过维护者和贡献者之间的长时间来回沟通。因此，问题描述、合并代码和单元测试并不总是能对齐，形成干净、隔离的任务来可靠地评估模型。特别是，拉取请求中包含的测试可能过于严格，因为它们是为验证特定变更而编写的，而不是为定义与实现无关的解决任务标准。与此同时，现在比不久之前更容易检测到评估缺陷。随着模型能力的提高，我们可以利用这些模型更深入、更一致地检查提示、测试、补丁、轨迹和边缘情况，帮助发现以前成本高昂或难以大规模发现的基准测试问题。

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

最终，一个评估应通过难以玩弄、易于信任、真正反映模型能力或对齐的基准测试提供有意义的信号。由于这些结果影响OpenAI的部署和安全决策，我们追踪的评估需要有效且信息丰富。