在编码评估中分离信号与噪声

# 在代码评估中分离信号与噪声 来源：https://openai.com/index/separating-signal-from-noise-coding-evaluations/ 准确衡量我们模型的能力，对于合理的部署和安全决策至关重要，包括基于 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 进行了类似的审计，使用数据点分析流水线审查了数据集。该流水线审查了模型对任务的尝试、任务元数据和失败跟踪信息，以标记可能的评估缺陷。每个被标记的任务随后通过多个调查智能体进行审查，并由五位经验丰富的软件工程师独立评审，分歧则升级进行进一步调查。 我们发现数据集的相当一部分任务存在破坏性问题。我们的数据点分析流水线标记了 200 个（27.4%）有缺陷的任务，而人工标注活动则识别出 249 个（34.1%）。 问题主要分为四类： - **过度严格的测试**[1]：强制执行提示中未指定的具体实现细节，导致许多功能正确的提交被判定无效。 - **提示不明确**[2]：省略了隐藏测试所强制要求且无法合理推断的需求。 - **测试覆盖率低**：未能充分检查所请求的功能，导致不完整的修复方案能够通过测试。 - **误导性提示**：引导模型走向错误的行为，或与测试要求相矛盾。 我们的发现指出了策划具有挑战性但公平的基准测试的难度，以及智能体在可扩展数据质量检查方面日益增长的实用性。基于这些结果，我们估计 SWE-bench Pro 中约 30% 的任务存在缺陷，并建议模型开发者仔细审查结果。 ## 方法论 我们的目标是确保任务失败反映出真实的模型限制，而任务成功则代表对提示要求的完整且有效的解决方案。为了检查评估中使用的数据质量，我们创建了一个质量保证流水线，以评估每个数据点是否准确反映模型能力。 初始数据质量流水线标记出问题以供审查。我们通过更深入的智能体辅助审计（针对标记的任务）和与经验丰富的工程师合作的人工标注活动来进行验证。 初始自动过滤器会审查提供给模型的指令、模型尝试解决问题的过程以及用于评分这些尝试的测试，以标记可能存在问题或缺陷的例子。该过滤器标记了 286 个可能存在问题的任务。然后，我们以两种方式对该子集进行了更深入的审查：人工监督的智能体审查（通过调查智能体进行广泛检查并做出最终人工判断）；以及与经验丰富的软件开发人员合作的人工标注活动。 ## 人工监督的智能体审查 每个被标记的问题都由基于 Codex 的调查智能体进行审计，这些智能体可以访问任务仓库和环境。这有助于他们将合理的任务歧义（通常可以通过研究附近代码和仓库约定来解决）与真正的不明确规范区分开来。智能体可以运行测试、检查仓库中的文件，并调查模型在任务上的尝试及其常见失败模式。在多次独立重复这些更深入的审计后，研究人员会审查摘要，做出最终判断，并标记可能存在的问题。 ## 人工标注活动 与此同时，我们对标记的子集进行了一项人工标注活动。我们与经验丰富的软件工程师合作，他们在审查任务之前接受了关于基准目标、问题分类和边缘情况的培训。每项任务由五位工程师审查。 审查者根据可见的问题描述、测试用例和真实的参考解决方案（称为 gold patch）形成独立判断，然后再使用流水线分析或记录作为辅助背景。然后，审查者根据具体证据分配标签和严重等级，并将分歧或信心不足的情况升级进行进一步审查。 与调查智能体相比，人工审查者更倾向于将任务标记为有缺陷。两种审查路径在类别上也存在一些分歧，但在任何标记的任务中，“无缺陷”都并非最常见的人工标签。在智能体流水线标记的类别中，审查者的判断在 74% 的情况下重叠。 与智能体流水线相比，人工审查者也更倾向于为一项任务选择多个标签，这表明他们发现任务存在多种缺陷，或者不能整齐地归入单一类别。这表明智能体加审查者的流水线导致了保守的标注：它捕捉到了人类识别的相同主要失败模式，但在审查者看到额外或重叠问题的情况下计数不足。最大的差异出现在测试覆盖率低的类别上，人类将其选为最常见的基准问题（占基准的 9.4%），而智能体流水线仅为 4.1%。 ### 失败模式 在几个案例中，任务提示规定了具体的实现，但隐藏的测试案例却期望不同的行为。 ## 讨论 我们已识别出的问题，加上 [SWE-bench Verified](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) 中的类似案例，凸显了严格检查基准的重要性。来自开源仓库的问题和拉取请求最初是为了人类协作而创建的，通常通过维护者和贡献者之间的长时间来回沟通。因此，问题描述、合并代码和单元测试并不总能对齐，形成用于可靠评估模型的清晰、孤立的任务。特别是，拉取请求中包含的测试可能过于严格，因为它们是为了验证特定的变更而编写的，而不是为了定义与实现无关的任务解决标准。 与此同时，评估缺陷现在比不久之前更容易检测。随着模型能力的提升，我们可以利用这些模型以更深入和更一致的方式检查提示、测试、补丁、跟踪信息和边缘情况，从而帮助发现以前规模上成本高或难以实现的基准问题。 我们希望更广泛的评估社区能够开发出由经验丰富的软件开发人员专门为测试模型能力而构建的新基准。这种方法可以保持我们希望衡量模型能力的高标准和现实性，并在整个过程中实现更好的人工监督。鉴于本分析中发现的问题，我们撤回之前采用 SWE-Bench Pro 的建议。 归根结底，评估应该通过难以被操纵、易于信任且真正反映模型能力或对齐性的基准来提供有意义的信号。由于这些结果会影响 OpenAI 的部署和安全决策，我们所追踪的评估需要是有效且信息丰富的。