OpenAI 停止 SWE-bench Verified 评估，促使业界重新审视 AI 基准可靠性

OpenAI 已宣布决定停止在其前沿 AI 模型评估中报告 SWE-bench Verified 分数。公司表示，鉴于可能存在数据污染和测试用例质量问题，该基准需要重新评估其是否仍适用于当前的评估目的。此举再次强调了一个问题：AI 模型评估体系应当如何随着时间推移被维护、更新和解读。

发生了什么

SWE-bench Verified 的设计目标，是衡量 AI 模型解决来自真实软件仓库问题的能力。该基准向模型提供需要理解、调试并在真实开发环境中实现代码变更的任务。这些任务通常涉及浏览复杂代码库、识别错误并提出能够与现有软件结构集成的解决方案。OpenAI 过去曾将该基准作为其最先进模型进展的重要指标，尤其是在自动化软件工程领域。公司如今决定重新评估其作用。这表明，即便是被广泛使用的基准，随着模型性能和数据环境的变化，其解读方式也可能需要调整。

为什么重要

基准分数往往具有较高权重，常被视为技术进展的指标以及模型能力的概括。然而，分数会因评估设计和数据条件而变化，即便数值相同，其意义也取决于基准本身的可靠性。OpenAI 同时提及可能存在的数据污染和测试用例质量问题，与这一背景相一致。这说明，分数产生的条件与分数本身同样重要。

数据污染是大模型开发中的持续性问题。随着训练语料不断扩大，越来越难以完全排除模型在训练过程中无意接触到基准任务、解决模式或高度相关示例的可能性。如果训练语料包含公开代码仓库，而这些仓库中又包含基准所使用的具体问题或解决方案，就可能出现这种情况。当模型接触过此类数据时，其在基准上的表现可能反映的是记忆或模式识别，而非解决新问题的能力或对未见任务的泛化能力。OpenAI 决定在这一背景下重新评估 SWE-bench Verified，凸显了在大规模 AI 开发中维持训练数据与评估数据分离的持续挑战。

测试用例质量是另一个重要变量。基准的有效性取决于其能否验证模型是否解决了给定问题。如果测试用例不完整、存在歧义，或未覆盖足够范围的边缘情况和失败模式，模型可能看似成功，却并未真正处理底层任务。在软件工程中，细微交互、环境依赖和特定仓库结构十分常见，因此设计稳健的测试套件尤其具有挑战性。OpenAI 对测试用例质量的担忧表明，现有测试可能无法充分捕捉真实软件开发问题的细微差别，从而导致对模型性能的评估不完整。

更广泛的意义在于，AI 评估正日益成为一个维护问题，而不仅仅是静态测量问题。基准通常用于捕捉某一时点的能力快照。然而，随着时间推移，模型不断进步，训练数据持续增长，基准本身也可能逐渐不再代表其原本要衡量的能力。曾经对模型而言具有挑战性的任务，可能变得轻而易举；或者，基准的底层假设可能不再与正在开发的前沿能力相匹配。因此，基准需要持续维护，包括定期更新问题集、重新验证测试用例，以及适应新的模型架构和训练范式。OpenAI 的举动表明，如果不进行周期性审查，依赖静态基准可能会限制对前沿 AI 进展的准确理解。

鉴于 OpenAI 在 AI 研究社区中的影响力，其决定也可能促使其他机构和研究人员重新审视自己对 SWE-bench Verified 及类似基准的依赖。尽管该基准在特定研究场景中，或在评估较不先进的模型时，仍可能具有价值，但其用于评估“前沿”能力的适用性如今正处于审查之中。这可能推动行业对单一指标评估持更高程度的审慎态度，并鼓励在整个 AI 生态中开发更动态、更全面且更透明的评估框架。重点可能从单纯报告高分，转向展示在多样化真实世界挑战中的稳健、可泛化表现。

运营层面的启示

对于开发代码生成系统的团队而言，这意味着不应仅依赖单一基准分数。相反，更稳健的评估策略应将基准结果与多样化的内部和外部验证方法结合起来。这可以包括基于任务的评估，即在真实编码项目上考察模型表现；用于检查稳定性的内部回归测试；以及对真实使用模式的持续监测。这样的多维方法能够更全面地呈现模型能力及其部署准备程度。

治理层面的启示同样存在。建立清晰的评估框架治理机制变得十分重要。组织应制定程序，用于选择基准、记录选择理由，并定期审查其持续相关性。还应建立流程，跟踪训练数据来源并评估其与评估材料的潜在重叠，从而降低污染风险。测试套件的质量和完整性也应接受持续监测和定期重新评估，以帮助确保其仍能代表所需能力。OpenAI 的公告强化了这样一种预期：评估方法应当透明、可验证，并能够适应 AI 创新的快速节奏。

不确定性或限制

需要在 OpenAI 所述语境下理解此次公告。公司已表示，将停止在其前沿模型评估中报告 SWE-bench Verified 分数，并将可能的数据污染和测试用例质量问题作为原因。这并不意味着该基准对所有其他用途或其他组织都失去效力。SWE-bench Verified 仍可能是特定研究目的、不同开发阶段模型评估，或比较代码生成能力某些方面的有用工具。核心信息并不是对该基准整体效用作出最终判断，而是呼吁在使用时谨慎考虑其适用性和可靠性，尤其是在评估最先进 AI 系统时。因此，关键问题并非是否用某个评估指标取代另一个指标，而是需要定期审视评估系统，特别是在它们被用于概括快速变化的模型能力时。

Builder Implications

• 在开发代码生成模型时，不应仅依赖单一基准分数，而应将基准结果与真实使用场景、基于任务的测试以及内部回归检查结合起来。
• 在设计内部评估框架时，应建立跟踪训练数据来源并评估其与评估材料潜在重叠的流程，尤其是在代码导向基准中。
• 应定期审查测试套件的完整性和一致性，因为基准可靠性不仅取决于被测模型，也取决于测试质量。
• 应将评估框架视为需要周期性重新审视的动态系统，而不是无需修订即可长期有效的固定记分板。