自 2024 年 8 月我们首次发布 SWE-bench Verified 以来，业界一直广泛使用这一基准来衡量模型在自主软件工程任务上的进展。发布之后，SWE-bench Verified 为能力提升提供了清晰有力的信号，并逐渐成为前沿模型发布中的标准评估指标。同时，对这些能力的演进进行跟踪和预测也是 OpenAI “准备框架”的重要组成部分。在最初创建 Verified 基准测试时，我们试图解决原始评估中导致 SWE-bench 数据集⁠（在新窗口中打开）中某些任务无法完成的问题。

在最初的几次跃升之后，SWE-bench Verified 上的性能提升已经放缓，过去 6 个月内准确率仅从 74.9% 提升⁠（在新窗口中打开）到 80.9%。这就引发了一个问题：那些尚未被攻克的难题，究竟是因为模型能力不足，还是数据集本身存在问题？

在一项新的分析中，我们发现 Verified 数据集存在两个主要问题，表明该基准已不再适合衡量在当今性能水平下前沿模型在自主软件工程方面的能力进展：

还有证据表明，在训练阶段接触过原题的模型，更有可能在基准测试中取得更好的表现，因为它们从训练中获取了额外信息，而这正是完成那些信息不完整的测试所必需的。

这意味着，SWE-bench Verified 的分数提升已无法反映模型在真实软件开发能力方面取得有意义的进步，反而越来越像是在比拼哪些模型在训练时“刷过”的题更多。正是基于这个原因，我们已停止报告该基准测试的分数，也建议其他模型开发者跟进。

目前，我们正在打造全新、无污染的评估体系，以更准确地衡量模型的编程能力。我们相信，这也是整个研究界值得共同努力的方向。在新方法问世前，OpenAI 建议采用 SWE-bench Pro 的评估数据。

最初的 SWE-bench⁠（在新窗口中打开） 评估于 2023 年发布。其题目均来自 12 个开源 Python 代码仓库中已修复的 GitHub 问题，每个问题对应一个相关的拉取请求（PR）。为了评判模型生成的代码修改是否正确，每个题目均附带两套测试用例：

模型看不到这些测试用例，只能依据原始的 Issue 描述和修复前的代码库状态来生成补丁。只有在其生成的代码改动应用后，所有测试都能通过，才算真正解决了问题。

我们发现这套评估机制存在诸多问题，可能导致模型的实际能力被低估。

为解决这些问题，我们在 2024 年推出了 SWE-bench Verified。我们邀请资深软件工程师对 1699 个 SWE-bench 题目逐一审查，剔除存在上述弊端的题目。每个题目均由三位专家独立评审，最终精选出 500 个题目，构成了 SWE-bench Verified 数据集。

尽管 SWE-bench Verified 相比初版已有大幅改进，但仍然存在问题。我们选取了 OpenAI o3 在 64 次独立运行中屡攻不克的 138 个题目进行复盘。每个案例均由至少六位经验丰富的软件工程师独立审查。如果有专家标记了某个问题，则会由另一团队进行复核。

结果表明，这 138 个题目中有 59.4% 存在测试设计或问题描述上的实质性缺陷，有些题目即便让人类或最强模型来做，也几乎无法解答。

第一种失败模式的典型例子是 pylint-dev__pylint-4551⁠（在新窗口中打开）。该问题的 PR 中引入了一个名为 get_annotation 的新函数。这个函数名并未出现在问题描述中，但测试用例却直接对其进行了导入。尽管某些模型可能会凭直觉创建这样一个函数，但要正确解答该问题，并不一定要实现一个具有这个特定名称的函数。因此，许多有效解答因导入错误而未能通过测试。

SWE-bench Verified 及其代码仓库（包括代码库和发布说明）均为开源，并得到广泛使用和讨论，因此模型开发者几乎无法避免数据污染。

我们首先在自己的模型中发现了数据污染的迹象。例如，GPT‑5.2 解出了我们先前认定几乎不可能完成的 31 个任务。在 django__django-14725⁠（在新窗口中打开） 中，测试一个名为 `edit_only` 的新参数，而问题描述从未提及。在解题过程中，GPT‑5.2 的思维链显示，它知晓详细描述代码库变更的发布说明，并正确指出 edit_only 参数是在 Django 4.1 中引入的。

为了更全面地评估数据污染问题的严重程度，我们搭建了一套自动化对抗性测试流程。针对每个 SWE-bench Verified 题目，我们让 GPT‑5 去探测 GPT‑5.2‑Chat、Claude Opus 4.5 和 Gemini 3 Flash Preview 是否存在数据污染。选择这些模型是为了排除推理模型的影响，尽管我们承认这些模型之间很可能仍然存在不容忽视的能力差距。

为了探测污染，提供给 GPT‑5 的信息包括：SWE-bench Verified 任务的 ID、描述、金标准补丁和 PR 测试。在 15 轮交互中，我们允许 GPT‑5 改变系统/开发者指令、用户提示词、助理预填回复，并尝试不同的诱导策略。每轮之后，一个评判模型会标记出现了多少新的任务特定信息，并将每个回复的污染严重程度从"无"到"强"进行标注。GPT‑5 可以根据前几轮的结果调整策略，以迭代的方式恢复任务特定细节。对于每一个“强污染”案例，我们还会用另一个评判模型验证 GPT‑5 没有向目标模型泄露过多信息。最后，我们手动核验了所有“强污染”案例，也就是本文所披露的这些对话记录。

以下是来自不同模型提供商的“强污染”示例。

仅凭任务描述中的一小段文字，GPT‑5.2 就能输出与金标准补丁完全一致的修复补丁，尤其是包括具体的类名、方法名，以及新引入的提前返回条件 `if username is None or password is None`。

Opus 不仅能够准确还原该 PR 引入的 4 行功能性修改及其关联的具体文件名和方法名，还可以逐字引用 diff 中包含的那条内联注释。

在除了任务 ID 之外未获得任何额外信息的情况下，Gemini 3 Flash 就能够一字不差地输出任务描述及金标准补丁的内容。这些细节包括用于用户名验证的新正则表达式，以及更改的具体行号。

通过这次对 SWE-bench Verified 的审查，我们总结出评估设计上的两个更广泛的经验教训。首先，基于公开数据构建的基准测试存在数据污染风险，训练数据的暴露会在不知不觉中抬高分数。如果在构建基准测试时使用了公开爬取的数据，模型开发者就应进行额外的污染测试。公开发布的基准测试，甚至其解决方案，最终都可能被纳入训练数据。因此，无论是在数据集的发布方式上（例如采用密码保护），还是在训练数据过滤上（例如严格遵守 canary 字符串），都需要格外谨慎。

其次，自动化评分很难做到尽善尽美。理想的测试用例，既要能充分验证功能的正确性，又不应绑定无关紧要的实现细节，同时还得防止模型钻空子。这类问题本身就非常复杂且难以解决，识别这些问题也耗费了多次大规模的人工标注工作。

我们已将这些发现反馈并应用到近期的评估工作中。最近几个月，我们已改为报告 SWE-Bench Pro 公开子集的评估结果，并建议其他模型开发者同样采取这种做法。SWE-bench Pro 并非完美，但从实测数据来看，其受到数据污染的影响似乎要小得多。我们的污染检测流程确实发现了一些污染案例，但无论是出现频率还是严重程度，都远不及 SWE-bench Verified，而且没有模型能够完整复现出金标准补丁的全部内容。

我们将持续投入资源打造原创、私有的评测基准测试，并呼吁业界和学术界共同推进这项工作。在 GDPVal⁠ 中，任务由领域专家内部编写，降低了数据暴露风险，解法则由受过专业训练的评审员综合评估。这种做法虽然投入巨大，但在衡量真实能力提升方面已是大势所趋。