前沿代码

2026-06-09 1 阅读 streamer45
提高从正确性到质量的标准 # 今天的编码基准已经确定模型可以编写正确的代码。但随着人工智能生成的代码成为生产的主要途径,正确性现在成为了赌注。我们应该问的问题是:模型真的能写出好的代码吗?我们很高兴推出 FrontierCode,这是一个衡量模型真正满足高质量生产代码库标准的基准。是什么让我们与众不同:维护者真的会合并这个 PR 吗?我们是第一个衡量代码可合并性的基准。我们的标准评估端到端代码质量——正确性、测试质量、范围规则、风格以及对代码库标准的遵守情况。它采用了一套新颖的评分技术,包括单元测试、评分标准和新型验证器。由开源维护者精心制作。 20 多名世界一流的开源开发人员从他们维护的存储库中构建了现实、多样化且具有挑战性的编码任务,每个任务花费了 40 多个小时。他们在存储库中定义了“可合并”的含义。严格的质量控制。评分标准是主观的,因此我们建立了一个广泛的质量控制管道,包括对抗性测试、校准和多阶段审查,其中每项任务都由认知研究人员手动审查。与 SWE-Bench Pro 相比,我们的误报率降低了 81%。我们的基准测试提供了模型编写高质量、可维护代码的能力的最强可用信号。我们发现,即使是当今最有能力的模型也难以满足这一新标准。 20 多名世界一流的开源维护人员,每项任务需要 40 个小时的工作量 由 Cognition 研究人员手动审核 每项任务 与 SWE-Bench Pro 相比,误报率降低 81% 有史以来第一个衡量代码质量的基准和微妙的人类偏好 结果 # 我们呈现了 FrontierCode 的三个嵌套子集,难度不断增加:扩展、主要和钻石。 Diamond 包含 50 个最难的任务,Main 是最难的 100 个任务(包括 Diamond),Extend 是全套 150 个任务。我们报告两个指标:通过率和分数:如果解决方案清除了所有阻止标准,即维护人员在代码审查期间考虑硬停止的标准,则解决方案通过,否则失败。解决方案的分数是评分标准项目的加权总和。未通过阻塞标准的解决方案接收 0。每个模型在每次可用的推理工作中运行 5 次。对于每项工作,我们都会对 5 次试验的指标进行平均,然后报告每个模型在其最佳推理水平下的得分。 FrontierCode Diamond 仍然不饱和:性能最好的模型 Claude Opus 4.8 的得分仅为 13.4%。其他型号的得分明显较低:GPT-5.5 得分为 6.3%,Gemini 3.1 Pro 得分为 4.7%,其他型号的得分甚至更低。然而,GPT 5.5 使用的代币数量始终比 Opus 4.8 少 4 倍,从而实现了更好的成本智能权衡。在 FrontierCode Main 和 Extended 上,Opus 4.8 仍然保持着明显的领先优势,分别为 34.3% 和 51.8%。我们还观察到开源模型与前沿之间存在巨大差距。 Kimi K2.6 是性能最好的开源模型,在 Diamond 上仅取得 3.8%,在 Main 上取得 16%,在 Extended 上取得 37%。本文的其余部分将深入探讨我们构建 FrontierCode 的原因和方式。为什么我们构建 FrontierCode # 第一代编码基准测试,例如 SWE-Bench Verified 和 Pro,是为能力较差的模型设计的。它们在许多现实性和稳健性方面都存在缺陷。从根本上来说,他们只测试功能的正确性,而不测试质量。此外,这些基准很容易出现错误分类错误。 METR 的实验发现,在这些基准测试中得分较高的模型通常会生成人类维护人员无法接受的补丁。我们如何定义错误分类?这些分为两类: 误报:验证者不应奖励错误的解决方案。测试覆盖率可能不完整,导致模型编写出错误的解决方案,但仍被接受。漏报:验证者不应惩罚正确的解决方案。测试可能过于具体,例如检查确切的错误字符串或函数名称,或 unsolvable ,测试不在指令或代码库中的行为。通过对智能体轨迹的分析,我们发现 FrontierCode 产生的错误分类错误比其他领先基准测试减少了 81%。这意味着 FrontierCode 分数是当前可用的最准确的排名。现有的基准在几个方面也缺乏多样性。虽然其他基准测试通过程序化抓取从单个 PR 中产生问题,但 FrontierCode 是由回购维护人员从多 PR 链和自由格式请求中手工选择的。我们还将 SWE-Bench Pro 所代表的语言数量增加了三倍。众所周知,现有基准以过度指定和详细的提示形式提供了太多指导。当今的前沿模型需要的手动操作要少得多。 FrontierCode 期望