分离编码评估中的信号与噪声
# 分离编码评估中的信号与噪声
通过详细审计，我们发现 SWE-Bench Pro 存在广泛的任务问题，并估计约 30% 的任务是失败的。
准确测量模型的能力对于合理部署和安全决策非常重要，包括在 OpenAI 的 [准备框架](https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf) 下的决策。在每次模型发布时，我们会报告一系列外部和内部基准测试的结果，以跟踪模型进展。当评估存在缺陷时，可能会导致对能力的错误理解，误导安全案例并影响研究优先级。
我们 [最近调查](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) 了一个广泛使用的编码基准，SWE-bench Verified，发现其存在基本设计和污染问题，且评估已无法提供有关软件开发能力的有意义信号。那时，我们鼓励更广泛的社区转向 SWE-Bench Pro。
[SWE-Bench Pro](https://scale.com/blog/swe-bench-pro) 旨在通过在更长时间范围和更真实的编码任务上测试模型来改进 SWE-bench Verified，以更好地跟踪代理编码能力。与 SWE-bench Verified 一样，任务是从一组公共和私有代码库的功能变更历史中程序化获取的。模型必须实现一个解决方案，使其通过新功能的测试，而不破坏现有功能。在 731 个任务的公共分割中，前沿模型的通过率在八个月内从 23.3% 提高到 80.3%。
随后，我们对 SWE-Bench Pro 进行了类似的审计，使用数据点分析管道审查数据集。该管道审查了模型尝试任务的情况、任务元数据和失败追踪，以标记可能的评估缺陷。每个标记的任务随后通过多个调查员-代理的过程进行评估，并由五位经验丰富的软件工程师独立审查，对异议进行升级以进一步调查。
## 数据集按问题类型标记的比例
| 问题类型 | 比例 |
| ------------------- | ------ |
| 过于严格的测试 | 14.4% |
| 覆盖不足的测试 | 17.8% |
| 误导性提示 | 4.1% |
| 其他问题 | 9.4% |
| 描述不清的提示 | 6.3% |
| 人工监督的代理评审 | 7.5% |
| 人工标注 | 1.9% |
| 总计 | 100% |
我们发现数据集中有相当一部分的问题存在破坏性。我们的数据点分析管道标记了 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"`：
```none
1"[space]| Chapter 1 | 1" 2"**[space]| Chapter 1 | 1" 3"[space]| Just title | "
```
隐藏的 `test_to_markdown` 断言则要求 `" | Chapter 1 | 1"` 和 `"** | Chapter 1 | 1"`：
```none
1"[space][space]| Chapter 1 | 1" 2"**[space][space]| Chapter 1 | 1" 3"[space][space]| Just title | "
```
隐藏测试中有两个前导空格，但模型给出的示例中仅包含一个前导空格。如果模型正确地跟随提示中给出的信息，那么这一字符的差异就会使得隐藏测试用例失败，从而导致该任务被标记为错误。
## 讨论
我们确定的问题，加上在 [SWE-bench Verified](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) 中出现的类似情况，凸显了严格检查基准的重要性。开源代码库中的问题和拉取请求最初是为人类协作而创建的，通常需要维护者和贡献者之间进行长时间的沟通。因此，问题描述、合并代码和单元测试并不总是能齐心协力地形成可靠地评估模型的干净、孤立的任务。尤其是，拉取请求中包含的测试可能过于严格，因为它们是为了验证特定变更而编写的，而不是为了定义解决此任务的实现无关标准。
同时，评估缺陷现在比过去更容易发现。随着模型能力的提升，我们可以利用这些模型深入检视提示、测试、补丁、追踪和边缘情况，从而以更大的深度和一致性帮助发现之前昂贵或不切实际的基准问题。
我们希望更广泛的评估社区发展出新的基准，这些基准是由经验丰富的软件开发者专门用于测试模型能力。这种方法可以保持我们希望测量的模型能力的高标准和现实性，并在整个过程中允许更好的人工监督。鉴于本次分析中揭示的问题，我们撤回了先前采用 SWE-Bench Pro 的建议。
最终，评估应该通过难以操控、易于信任，并真实反映模型能力或对齐情况的基准提供有意义的信号。因为这些结果影响 OpenAI 的部署和安全决策，所跟踪的评估需要有效且信息丰富。
---
原文链接：[点击查看](https://openai.com/index/separating-signal-from-noise-coding-evaluations)
通过详细审计，我们发现 SWE-Bench Pro 存在广泛的任务问题，并估计约 30% 的任务是失败的。
准确测量模型的能力对于合理部署和安全决策非常重要，包括在 OpenAI 的 [准备框架](https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf) 下的决策。在每次模型发布时，我们会报告一系列外部和内部基准测试的结果，以跟踪模型进展。当评估存在缺陷时，可能会导致对能力的错误理解，误导安全案例并影响研究优先级。
我们 [最近调查](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) 了一个广泛使用的编码基准，SWE-bench Verified，发现其存在基本设计和污染问题，且评估已无法提供有关软件开发能力的有意义信号。那时，我们鼓励更广泛的社区转向 SWE-Bench Pro。
[SWE-Bench Pro](https://scale.com/blog/swe-bench-pro) 旨在通过在更长时间范围和更真实的编码任务上测试模型来改进 SWE-bench Verified，以更好地跟踪代理编码能力。与 SWE-bench Verified 一样，任务是从一组公共和私有代码库的功能变更历史中程序化获取的。模型必须实现一个解决方案，使其通过新功能的测试，而不破坏现有功能。在 731 个任务的公共分割中，前沿模型的通过率在八个月内从 23.3% 提高到 80.3%。
随后，我们对 SWE-Bench Pro 进行了类似的审计，使用数据点分析管道审查数据集。该管道审查了模型尝试任务的情况、任务元数据和失败追踪，以标记可能的评估缺陷。每个标记的任务随后通过多个调查员-代理的过程进行评估，并由五位经验丰富的软件工程师独立审查，对异议进行升级以进一步调查。
## 数据集按问题类型标记的比例
| 问题类型 | 比例 |
| ------------------- | ------ |
| 过于严格的测试 | 14.4% |
| 覆盖不足的测试 | 17.8% |
| 误导性提示 | 4.1% |
| 其他问题 | 9.4% |
| 描述不清的提示 | 6.3% |
| 人工监督的代理评审 | 7.5% |
| 人工标注 | 1.9% |
| 总计 | 100% |
我们发现数据集中有相当一部分的问题存在破坏性。我们的数据点分析管道标记了 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"`：
```none
1"[space]| Chapter 1 | 1" 2"**[space]| Chapter 1 | 1" 3"[space]| Just title | "
```
隐藏的 `test_to_markdown` 断言则要求 `" | Chapter 1 | 1"` 和 `"** | Chapter 1 | 1"`：
```none
1"[space][space]| Chapter 1 | 1" 2"**[space][space]| Chapter 1 | 1" 3"[space][space]| Just title | "
```
隐藏测试中有两个前导空格，但模型给出的示例中仅包含一个前导空格。如果模型正确地跟随提示中给出的信息，那么这一字符的差异就会使得隐藏测试用例失败，从而导致该任务被标记为错误。
## 讨论
我们确定的问题，加上在 [SWE-bench Verified](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) 中出现的类似情况，凸显了严格检查基准的重要性。开源代码库中的问题和拉取请求最初是为人类协作而创建的，通常需要维护者和贡献者之间进行长时间的沟通。因此，问题描述、合并代码和单元测试并不总是能齐心协力地形成可靠地评估模型的干净、孤立的任务。尤其是，拉取请求中包含的测试可能过于严格，因为它们是为了验证特定变更而编写的，而不是为了定义解决此任务的实现无关标准。
同时，评估缺陷现在比过去更容易发现。随着模型能力的提升，我们可以利用这些模型深入检视提示、测试、补丁、追踪和边缘情况，从而以更大的深度和一致性帮助发现之前昂贵或不切实际的基准问题。
我们希望更广泛的评估社区发展出新的基准，这些基准是由经验丰富的软件开发者专门用于测试模型能力。这种方法可以保持我们希望测量的模型能力的高标准和现实性，并在整个过程中允许更好的人工监督。鉴于本次分析中揭示的问题，我们撤回了先前采用 SWE-Bench Pro 的建议。
最终，评估应该通过难以操控、易于信任，并真实反映模型能力或对齐情况的基准提供有意义的信号。因为这些结果影响 OpenAI 的部署和安全决策，所跟踪的评估需要有效且信息丰富。
---
原文链接：[点击查看](https://openai.com/index/separating-signal-from-noise-coding-evaluations)
评论
暂无评论。