介绍 SWE-bench Verified

# 介绍 SWE-bench Verified 来源：https://openai.com/index/introducing-swe-bench-verified/ 我们发布了 SWE-bench 的人工验证子集，可更可靠地评估 AI 模型解决真实软件问题的能力。 *更新于 2025 年 2 月 24 日* 作为我们[准备框架](https://openai.com/preparedness/)的一部分，OpenAI 开发了一系列指标来追踪、评估和预测模型自主行动的能力。自主完成软件工程任务的能力是我们模型自主性风险类别中中等风险等级的关键组成部分。由于软件工程任务的复杂性、准确评估生成代码的困难，以及模拟真实开发场景的挑战，评估这些能力很困难。因此，我们的准备框架方法还必须包括对评估本身的仔细审查，以降低在重要风险类别中低估或高估性能的可能性。 最受欢迎的软件工程评估套件之一是 [SWE-bench](https://www.swebench.com/)——一个用于评估大型语言模型（LLM）解决来自 GitHub 真实软件问题能力的基准。该基准需要给代理提供代码库和问题描述，并要求它们生成解决问题描述的补丁。编码代理在 SWE-bench 上取得了显著进展，根据 [SWE-bench 排行榜](https://www.swebench.com/)，截至 2024 年 8 月 5 日，排名最高的代理在 SWE-bench 上得分为 20%，在 SWE-bench Lite 上得分为 43%。 我们的测试发现了一些 SWE-bench 任务可能难以解决或无法解决，导致 SWE-bench 系统性地低估了模型的自主软件工程能力。我们与 SWE-bench 的作者合作，在基准的新版本中解决了这些问题，应该能提供更准确的评估。 SWE-bench 测试集中的每个样本都是从 GitHub 上 12 个开源 Python 库之一中的已解决 GitHub issue 创建的。每个样本都有一个相关的 pull request（PR），其中包含解决方案代码和用于验证代码正确性的单元测试。这些单元测试在 PR 中的解决方案代码添加之前失败，之后通过，因此称为 `FAIL_TO_PASS` *测试*。每个样本还有相关的 `PASS_TO_PASS` *测试*，这些测试在 PR 合并前后都通过，用于检查代码库中不相关的现有功能是否被 PR 破坏。 对于 SWE-bench 中的每个样本，代理会获得 GitHub issue 的原始文本（称为*问题陈述*），并可以访问代码库。基于此，代理必须编辑代码库中的文件来解决问题。测试不会显示给代理。 通过运行 `FAIL_TO_PASS` 和 `PASS_TO_PASS` 测试来评估提议的编辑。如果 `FAIL_TO_PASS` 测试通过，则意味着编辑解决了问题。如果 `PASS_TO_PASS` 测试通过，则编辑没有无意中破坏代码库的不相关部分。两组测试都需要通过才能完全解决原始 GitHub issue。 鉴于 SWE-bench 与准备框架的潜在相关性，我们的目标是找到改进基准健壮性和可靠性的方法。我们确定了三个主要改进方向： 1. 用于评估解决方案正确性的单元测试通常过于具体，在某些情况下甚至与问题无关。这可能导致正确的解决方案被拒绝。 2. 许多样本的 issue 描述规范不足，导致对问题是什么以及应如何解决存在歧义。 3. 有时很难为代理可靠地设置 SWE-bench 开发环境，无意中导致单元测试失败，无论解决方案如何。在这种情况下，完全有效的解决方案可能被评为不正确。 以下是演示第一个问题的示例。 SWE-bench 样本 `scikit-learn__scikit-learn-14520` 要求代理解决 [scikit-learn 库中的问题](https://github.com/scikit-learn/scikit-learn/issues/14501)。这个问题陈述报告说函数的 `copy` 参数可以由用户指定，但被库忽略（行为被硬编码在函数中）： 接近这个问题的代理首先必须处理函数行为是有意的还是 bug 的歧义，然后对代码库进行更改以解决问题。根据 SWE-bench 设置，代理提议的任何解决方案都需要通过以下测试，该测试提取自[最初解决问题的 PR](https://github.com/scikit-learn/scikit-learn/pull/14520)： 这个测试明确要求解决方案必须在使用 `copy` 参数时抛出 DeprecationWarning，尽管上面的原始问题陈述中的 issue 文本没有传达这个要求。此外，即使代理意识到应该抛出 DeprecationWarning，测试还要求代理完全匹配废弃消息，而这只是在 PR 中讨论后才确定的，代理无法访问这些讨论。 请注意，代理只获得主 issue 文本中的问题描述，看不到它需要通过的测试。鉴于这种设置，代理几乎不可能在 SWE-bench 中解决这个样本。 为了解决这些问题，我们与专业软件开发人员启动了人工注释活动，以筛选 SWE-bench 测试集的每个样本，确保单元测试范围适当且 issue 描述规范良好。 我们与 SWE-bench 的作者一起发布 SWE-bench Verified：原始测试集的子集，由我们的人工注释员验证为无问题的 500 个样本组成。此版本取代了原始 SWE-bench 和 SWE-bench Lite 测试集。此外，我们发布了所有 SWE-bench 测试样本的人工注释。这些注释可以按难度对数据集进行分割。"简单"子集由 196 个小于 15 分钟的修复任务组成，而"困难"子集由 45 个大于 1 小时的任务组成。 我们还与 SWE-bench 作者合作[开发了 SWE-bench 的新评估工具](https://github.com/princeton-nlp/SWE-bench/tree/main/docs/20240627_docker)，它使用容器化的 Docker 环境使在 SWE-bench 上的评估更容易、更可靠。 在 SWE-bench Verified 上，GPT-4o 解决了 33.2% 的样本，最佳表现的开源脚手架 Agentless 将其之前在 SWE-bench 上的得分 16% 翻倍。 我们与 93 名具有 Python 经验的软件开发人员合作，手动筛选 SWE-bench 样本的质量。我们注释了 SWE-bench 测试集中的 1,699 个随机样本以生成 SWE-bench Verified。以下分析基于 1,699 个样本。 我们注释样本以捕获： - 我们是否认为 issue 描述规范不足，因此在其上测试是不公平的。 - `FAIL_TO_PASS` 单元测试是否会过滤出有效的解决方案。 每个注释标准都有一个标签范围从 [0, 1, 2, 3]，严重程度逐步增加。标签 0 和 1 很轻微；标签 2 和 3 很严重，表示样本在某种方式上不合适，应该被丢弃。我们选择跨越四个序数类别进行注释，而不是严重/非严重的单一二元标签，以捕获更细粒度的细节。 此外，我们通过让注释员估计开发人员在假设样本无问题的情况下决定和实现解决方案所需的时间来评估每个样本的难度。最后，我们提供自由形式的输入选项来标记样本的任何其他重大问题（例如，如果 `FAIL_TO_PASS` 单元测试容易被欺骗，这可能导致无效的解决方案被标记为正确）。 我们的工程团队首先为注释员入职测试手动标记了 50 个样本，并具有高度的置信度。为了参加注释活动，每个潜在注释员都必须通过我们的入职测试。我们在入职期间为每个注释员提供了详细反馈，以更好地培训他们完成任务。注释员不一定是与 SWE-bench 相关的代码库的先前专家，但被给予了时间来熟悉他们工作的每个代码库。 为了确保高质量的数据集，每个样本由 3 个单独的注释员标记。很容易无意中遗漏潜在问题，问题本身可能存在歧义，因此我们通过在 3 个注释员中取最高严重程度标签来保守地集合注释。 我们的完整注释规则可以[在这里](https://cdn.openai.com/introducing-swe-bench-verified/swe-b-annotation-instructions.pdf)找到。 为了构造 SWE-bench Verified，我们从原始测试集中过滤出任何问题陈述或 `FAIL_TO_PASS` 单元测试的集合标签严重程度为 2 或以上的样本。我们还过滤出所有被标记为有其他重大问题的样本。鉴于我们的集合方法，这相当于过滤出三个注释员中任何一个标记问题的样本。这种方法导致删除样本的假阳性率较高，但有助于提高对最终数据集样本质量的信心。 我们尽可能多地包含难度为 1-4 小时和 >4 小时的样本，然后随机抽样其余样本以得到构成 SWE-bench Verified 的 500 个样本。 我们的注释结果如下： 我们发现 38.3% 的样本被标记为问题陈述规范不足，61.1% 被标记为单元测试可能不公平地将有效解决方案标记为不正确。总的来说，我们的注释过程导致 68.3% 的 SWE-bench 样本因规范不足、不公平的单元测试或其他问题而被过滤。如前所述，这种过滤过程可能过于谨慎，但允许我们对未过滤样本的可行性有高度的信心。 我们下面展示了几个样本及其注释的示例，精心挑选以说明样本质量的多样性： 下面的图表比较了原始 SWE-bench 数据集和我们新的 SWE-bench Verified 数据集的难度分布。我们基于 1,699 个样本的随机子集估计 SWE-bench 的难度分布。请注意，虽然这些结果提供了实现解决方案所需工作量的估计（请参阅我们的注释说明以了解确切措辞），但它们假设软件工程师能够解决问题。在实践中，我们预期典型软件工程师的基线解决率会低于 100%。 我们观察到原始 SWE-bench 数据集中大多数（77.8%）样本估计对经验丰富的软件工程师来说需要少于一小时的时间完成。SWE-bench Lite 和我们新的 SWE-bench Verified 数据集都进一步倾向于此，留下少于 10% 的 issue 估计需要超过一小时。然而，这种转变的基础机制是重要不同的：SWE-bench Lite 对原始数据集进行了二次采样以使基准更容易，而 SWE-bench Verified 试图从数据集中删除不可行的样本。我们在下一节进一步探讨这个效果。 ##### 难度标签分布 难度类别 | 样本百分比 使用我们新的 SWE-bench Verified 数据集，我们使用在原始 SWE-bench 排行榜上表现良好的多个开源脚手架来测试 GPT-4o 的性能。 我们发现 GPT-4o 在最佳表现脚手架上在 SWE-bench Verified 上的性能达到 33.2%，比其在原始 SWE-bench 上 16% 的得分提高了一倍多。总的来说，这验证了我们最初的怀疑，即原始 SWE-bench 数据集低估了代理能力。请注意，从 SWE-bench Lite 到 SWE-bench Verified 的跳跃不如此显著，因为 SWE-bench Lite 已经以使其比完整数据集更容易的方式进行了过滤，尽管该过程不会完全捕获与我们的过滤过程相同的问题。 ##### 开源脚手架在 SWE-bench 子集上的性能 在 SWE-bench Verified 上评估时性能的增加可能部分由向更容易的样本移动分布来解释（如前面的分析所示）。然而，我们的目标不是夸大基准分数，而是确保基准忠实地代表模型在任何给定难度等级的能力。 我们通过绘制按难度分层的性能来调查这一点。如果我们的新数据集仅仅将难度分布转移为包含更多简单样本，则每个类别内的分层性能不会改变，这从原始 SWE-bench 到 SWE-bench Lite 似乎是这样。相反，当移动到 SWE-bench Verified 时，我们观察到性能在*单个*难度类别*内*增加，这与从所有类别中删除不可能的样本（而不是删除困难的样本）的预期效果一致。这个效果在最容易的两个难度桶中最明显，我们在那里有最多的样本。 ##### 所有脚手架的平均性能按难度分层 难度桶 | 已解决百分比 我们使用 SWE-bench 作为我们准备框架中模型自主性风险类别的中等风险等级的多个评估之一。通过评估来追踪灾难性风险等级取决于确保我们能够信任评估结果并清楚地了解分数的含义。 我们的经验表明我们应该： **深入了解我们的基准。** 虽然 SWE-bench 的设计经过了深思熟虑，但由于本博文中提到的问题，它低估了模型能力。随着我们的系统越来越接近 AGI，我们需要在越来越具有挑战性的任务上评估它们。这也提升了精选和验证基准所需的专业知识和关注的水平，以确保它们足够具有挑战性和强大（[CriticGPT](https://openai.com/index/finding-gpt4s-mistakes-with-gpt-4/) 探索 AI 如何协助注释管道的方式就是这样的工作案例）。 **考虑生态系统中的进展。** 社区主导的代理脚手架进展突出了在评估风险时考虑模型的潜在外部增强的必要性。查看 [SWE-bench 排行榜](https://www.swebench.com/)上给定模型表现最差和表现最佳的脚手架之间的差异，我们可以看到，例如，GPT-4 在 SWE-bench Lite 上的性能使用早期的基于 RAG 的脚手架时在 2.7% 之间变化，使用 CodeR 时在 28.3% 之间变化。因此，准备框架要求评估持续运行并根据需要频繁运行，以识别任何非平凡的能力变化；这包括训练前、期间，甚至训练后，其中模型可以通过与外部系统的集成而得到增强。