# OpenAI 审计 SWE-Bench Pro 发现约 30% 的评测任务存在缺陷 - 来源：OpenAI：官网动态（RSS · 排除企业/客户案例） - 发布时间：2026-07-08 21:00 - AIHOT 分数：70 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmrcigf5k01bqihx54i8oph9u - 原文链接：https://openai.com/index/separating-signal-from-noise-coding-evaluations ## 精选理由 OpenAI 自己审计了 SWE-Bench Pro，发现三成任务有缺陷，这个基准给出来的分数可能要打问号，做模型评测和选型的人该认真看看。 ## AI 摘要 OpenAI 对编码评测基准 SWE-Bench Pro 进行详细审计，发现约 30% 的任务存在缺陷。在 731 个任务的公开子集中，前沿模型通过率在八个月内从 23.3% 提升至 80.3%，但数据质量检查显示大量任务存在测试过于严格、提示词描述不足、测试覆盖不全或误导性提示等问题。OpenAI 建议模型开发者仔细审视评测结果，并指出 AI 智能体在规模化数据质量检查中日益增长的实用性。 ## 正文 去伪存真：编程评测中的信号与噪声 | OpenAI 2026年7月8日 研究｜出版物 去伪存真：编程评测中的信号与噪声 通过一次详细的审查，我们发现 SWE-Bench Pro 中存在广泛的任务问题，并估算约 30% 的任务存在缺陷。 准确衡量我们模型的能力，对于做出合理的部署和安全决策至关重要，其中包括 OpenAI 预备框架下的决策。每次发布新模型时，我们都会报告多种外部和内部基准的测试结果，以跟踪模型进展。当评测存在影响结果的缺陷时，它们可能会让人对能力产生错误理解，曲解安全案例，并影响研究优先级。 我们近期调查了最广泛使用的编程基准之一 SWE-bench Verified，发现其存在根本性的设计和污染问题，并且该评测已无法提供有关软件开发能力的有意义信号。当时，我们鼓励整个社区转向 SWE-Bench Pro。 SWE-Bench Pro 的设计目标是对 SWE-bench Verified 进行改进，通过让模型在更长的时间跨度、更真实的编程任务上接受测试，从而更好地追踪智能体编程能力。与 SWE-bench Verified 一样，任务是从一组公开和私有仓库的功能变更历史中通过程序化方式抽取的。模型需要实现一个解决方案，使其通过某个功能的新增测试，同时不破坏现有功能。在包含 731 个任务的公开拆分中，前沿模型在八个月内通过率从 23.3% 提升到了 80.3%。 此后，我们对 SWE-Bench Pro 进行了类似的审查，使用一个数据点分析流水线来审核数据集。该流水线审查了模型对任务的尝试结果、任务元数据以及失败轨迹，以标记可能的评测缺陷。每个被标记的任务随后经过多次调查智能体（investigator-agent）轮次的评估，并由五位经验丰富的软件工程师独立审核，分歧之处会升级进行进一步调查。 按问题类型标记的数据集占比 我们发现数据集中相当一部分任务存在缺陷问题。我们的数据点分析流程标记了200个（27.4%）有缺陷的任务，而人工标注活动则识别出249个（34.1%）。 这些问题主要分为四类： 过严格的测试¹强制要求提示词中未指定的具体实现细节，导致许多功能正确的提交被判定无效。 提示词说明不足²省略了隐藏测试所强制要求且无法合理推断的约束条件。 低覆盖率测试对请求的功能检查不充分，使得不完整的修复也能通过测试。 误导性提示词引导模型走向错误的行为，或与测试要求相矛盾。 我们的研究结果指出了构建困难但公平的基准测试的难度，以及智能体在可扩展的数据质量检查方面日益增长的实用性。基于这些结果，我们估计大约30%的SWE-bench Pro任务是存在缺陷的，并建议模型开发者仔细审视结果。 方法论 我们的目标是确保任务失败反映的是模型的真实局限性，而任务成功则代表对提示词要求的完整且有效的解决方案。为了检查评估所用数据的质量，我们创建了一个质量保证流程，以评估每个数据点是否准确反映了模型能力。 初始数据质量流程会标记出需要进一步审查的问题。我们通过更深入的、智能体辅助的审计对标记任务进行验证，并开展由经验丰富的工程师参与的人工标注活动。 初始自动过滤器会审查提供给模型的指令、模型尝试解决任务的过程，以及用于评判这些尝试的测试，从而标记可能存在问题或缺陷的示例。该过滤器标记了286个可能存在问题的任务。随后，我们对该子集进行了两种方式的深入审查：人工监督的智能体审查（由调查智能体进行广泛检查，并最终由人工判断）以及由经验丰富的软件开发者参与的人工标注活动。 人工监督的智能体审查 每个被标记的问题都会由基于 Codex 的调查型智能体进行审计，这些智能体有权访问任务仓库和环境。这有助于它们区分合理的任务歧义（通常可以通过研究附近代码和仓库约定来解决）与真正的不明确性。智能体可以运行测试、检查仓库中的文件，并调查模型在该任务上的尝试及其常见失败模式。经过多次独立的深度审计后，研究人员会审阅摘要，做出最终判断，并标记出可能存在的问题。 人工标注活动 与此同时，我们对被标记的子集进行了一项人工标注活动。我们与经验丰富的软件工程师合作，他们在审阅任务之前接受了关于基准目标、问题分类和边缘案例的培训。每个任务由五名工程师审阅。 审阅人员在参考流水线分析或转录作为辅助上下文之前，首先根据可见的问题描述、测试用例和真实参考解决方案（即黄金补丁）形成独立判断。然后，审阅人员根据具体证据分配标签和严重等级，并将存在分歧或低置信度的案例上报进行进一步审阅。 人工审阅人员比调查型智能体更倾向于将任务标记为有缺陷。两种审阅路径在分类上也存在一些分歧，但在被标记的任务中，没有一项中“无缺陷”是人工最常见的标签。在智能体流水线标记的类别中，审阅人员的判断在 74% 的情况下是一致的。 与智能体流水线相比，人工审阅人员更倾向于为任务选择多个标签，这表明他们发现任务存在多种缺陷方式，或者不能干净地归入单一类别。这表明智能体加审阅人员的流水线导致了保守的标注：它捕获了人类识别的相同广泛失败模式，同时低估了审阅人员发现额外或重叠问题的情况。最大的差异出现在低覆盖测试上，人类将其选为 9.4% 的基准中最常见的问题，而智能体流水线仅为 4.1%。 失败模式 在某些情况下，任务提示词规定了具体的实现方式，但隐藏测试用例却期望不同的行为。 OpenLibrary-77c16d5 该任务涉及规范化目录条目，并通过 TocEntry.to_markdown() 将其渲染回 Markdown。任务提示词详细说明了字符级别间距的序列化方式，描述了如何强制执行精确的间距和管道符号，并给出了类似“ | Chapter 1 | 1”和“** | Chapter 1 | 1”的示例： 无 1"[空格]| Chapter 1 | 1"2"**[空格]| Chapter 1 | 1"3"[空格]| Just title | " 隐藏的 test_to_markdown 断言反而要求“ | Chapter 1 | 1”和“** | Chapter 1 | 1”： 无 1"[空格][空格]| Chapter 1 | 1"2"**[空格][空格]| Chapter 1 | 1"3"[空格][空格]| Just title | " 隐藏测试中前导空格有两个，但提供给模型的示例中只有一个前导空格。如果模型严格遵循给出的提示，这一个字符的差异就会导致隐藏测试用例失败，该任务也会被判为错误。 讨论 我们已经发现的问题，加上 SWE-bench Verified 中的类似情况，凸显了严格审查基准的重要性。来自开源仓库的问题和拉取请求原本是为了人类协作而创建的，通常需要维护者和贡献者之间进行长时间的来回沟通。因此，问题描述、合并代码和单元测试并不总是能完美对齐，形成用于可靠评估模型的干净、孤立的任务。特别是，拉取请求中包含的测试可能过于严苛，因为它们是为了验证某个特定变更而编写的，而非定义一种与实现无关的任务解决标准。 与此同时，相比不久之前，现在更容易检测到评估缺陷。随着模型能力的提升，我们可以利用这些模型以更深入、更一致的方式检查提示词、测试、补丁、追踪和边界情况，从而帮助发现那些以前规模化排查代价高昂或不可行的基准问题。 我们希望更广泛的评估社区能够开发出由经验丰富的软件开发者专门为测试模型能力而构建的新基准。这种方法可以保持我们衡量模型能力时所期望的高标准与真实性，并允许在整个过程中进行更好的人工监督。鉴于本次分析中暴露出的问题，我们撤回之前关于采用 SWE-Bench Pro 的建议。 归根结底，一项评估应当通过那些难以被取巧、易于被信任、且真正反映模型能力或对齐程度的基准来提供有意义的信号。由于这些结果会影响 OpenAI 的部署与安全决策，我们所追踪的评估需要具备有效性和信息量。 2026 软件与工程 脚注 1 我们此前⁠将这一类别称为窄测试。 2 我们此前将这一类别称为宽测试。