在编程评测中辨别信号与噪声

OpenAI 表示，在对 SWE-Bench Pro 进行细致审计后，他们发现其中广泛存在任务质量问题，并估计约 30% 的任务本身就有缺陷。

准确衡量模型能力，会直接影响部署与安全决策，其中也包括 OpenAI Preparedness Framework 下的相关判断。OpenAI 认为，评测本身的缺陷会制造失真的能力画像，扭曲安全论证，并把研究重点带偏。

OpenAI 表示，他们此前曾调查过 SWE-bench Verified，发现其中的设计问题和污染问题已经严重到这个基准不再能为软件开发能力提供有意义的信号。当时，他们曾鼓励社区转向 SWE-Bench Pro。

SWE-Bench Pro 的设计目标，是在 SWE-bench Verified 的基础上进一步提升，聚焦更长周期、也更贴近真实世界的编程任务。在公开的 731 个任务子集上，前沿模型的通过率据称在 8 个月内从 23.3% 升至 80.3%。

OpenAI 表示，随后他们使用一套数据点分析流程审计了 SWE-Bench Pro。这套流程会审查模型尝试、任务元数据和失败轨迹，以标记可能存在评测缺陷的任务。被标记出的任务随后会经过多轮 investigator agents 审查，并由 5 名经验丰富的软件工程师独立复核；若出现分歧，则升级处理。

OpenAI 报告称，其自动化流程共标记出 200 个任务，占数据集的 27.4%；而人工标注项目最终识别出 249 个问题任务，占比 34.1%。

这些问题主要落在四类：

测试过于严格，强行要求 prompt 中并未说明的实现细节
prompt 信息不充分，隐藏测试却仍在强制执行未写明的要求
测试覆盖率过低，使不完整的修复也能通过
prompt 具有误导性，把模型引向与测试预期相矛盾的行为

OpenAI 认为，这些结果一方面说明，要构建既有难度又公平的基准测试有多困难；另一方面也说明，agents 正在成为可规模化数据质量审查中的实用工具。

方法

OpenAI 表示，他们的目标是确保：任务失败反映的是真实的模型局限，而任务成功反映的是完整且有效的解法。为了评估基准测试的质量，他们构建了一套质量保障流程，用来检查每个数据点是否准确反映模型能力。

第一道自动化过滤器会审查任务说明、模型尝试和评分测试，筛出疑似损坏或存在问题的样例。这一过滤器共标记出 286 个任务，进入下一步复审。

之后，OpenAI 对这批被标记任务并行执行了两条更深入的审查路径：

人工监督的 agent 审查
由资深软件工程师参与的人工标注项目

人工监督的 agent 审查

OpenAI 表示，每个被标记任务都会交给基于 Codex 的 investigator agents 审计，这些 agents 可以访问任务仓库及其运行环境。它们能够运行测试、检查仓库文件，并查看模型尝试及常见失败模式。

在完成多轮彼此独立的审计后，再由研究人员审阅汇总结果，做出最终判断，并标注可能的问题类别。

人工标注项目

OpenAI 表示，与此同时，他们还并行启动了一项人工标注项目，参与者是受过专门训练的资深软件工程师，熟悉该基准测试的目标、问题分类体系以及各种边界情况。每个任务都会由 5 名工程师审查。

这些审查者会先基于可见的问题描述、测试用例和参考解法，独立形成自己的判断；之后才把流程分析结果或运行记录当作辅助上下文使用。随后，他们会给出标签和严重程度评级，并将存在分歧或信心不足的案例升级处理。

OpenAI 表示，相比 investigator agents，人类审查者更倾向于将任务判定为损坏。在被标记的案例中，人工判断与 agent 审查流程的重合率为 74%；但人类更常为同一个任务同时选择多个标签。

两者最大的差异出现在“测试覆盖率低”这一类问题上：人工审查者认为它是最常见的问题，占整个基准测试的 9.4%；而 agent 审查流程给出的比例是 4.1%。

失败模式

OpenAI 重点举出的一个例子是 OpenLibrary-77c16d5。这个任务要求对目录项进行规范化处理，并通过 TocEntry.to_markdown() 将其重新渲染为 Markdown。

任务 prompt 给出了精确的序列化说明，示例如下：

" | Chapter 1 | 1"
"** | Chapter 1 | 1"
" | Just title | "

但隐藏的 test_to_markdown 断言实际上要求输出为：

"  | Chapter 1 | 1"
"**  | Chapter 1 | 1"
"  | Just title | "

OpenAI 表示，仅仅这一个字符的空格差异，就足以让模型即便完全按 prompt 正确实现，也仍然无法通过隐藏测试。

讨论

OpenAI 认为，这些问题以及 SWE-bench Verified 中的类似案例，说明基准测试验证需要更严格的方法。他们指出，开源 issue 和 pull request 原本是为人类协作而创建的，经常伴随着维护者与贡献者之间来回多轮沟通；因此，prompt、合并后的代码与测试并不总能严丝合缝地对应起来，难以自然形成可靠的评测任务。

文中还认为，pull request 附带的测试之所以可能过于严格，是因为它们验证的是某一份特定代码改动，而不是与实现无关、可替代的通用解法。文章同时指出，如今更强的模型也让评测缺陷更容易暴露，因为它们已经能以更大规模检查 prompt、测试、补丁、执行轨迹和边界情况。

OpenAI 表示，希望评测社区能构建新一代基准测试，由经验丰富的软件开发者专门为衡量模型能力而设计。基于这次分析揭示出的问题，他们收回了此前关于采用 SWE-Bench Pro 的建议。

文章最后总结称，编程评测应当产出难以被“刷分”、值得信任、并且真正反映能力与对齐状况的信号，因为这些结果会被用于部署与安全决策。

注释

OpenAI 表示，他们此前曾将 “overly strict tests” 这一类称为 “narrow tests”。
OpenAI 表示，他们此前曾将 “underspecified prompts” 这一类称为 “wide tests”。