金鼎配资 GPT-5编程测评大反转！表面不及格，实际63.1%的任务没交卷

henry 发自凹非寺量子位 | 公众号 QbitAI金鼎配资

Scale AI的新软件工程基准SWE-BENCH PRO，出现反转！

表面上看，“御三家”集体翻车，没一家的解决率超过25%

GPT-5Claude Opus 4.1Gemini 2.5分别以23.3%、22.7%、13.5%的解决率“荣”登前三

但深入数据背后，则暗藏玄机。

前OpenAI研究员Neil Chowdhury表示，如果只看已提交的任务，GPT-5能达到63%的准确率，比Claude Opus 4.1的31%，高了近一倍！

（这怎么不算G又赢！？）

换句话说，GPT-5在擅长的题目上依旧稳健，与老基准SWE-Bench-Verified的74.9%差距不大，而Claude跟其他模型则直接拉垮到底。

那么，究竟是什么基准测试，让这些顶级模型如此狼狈？

SWE-BENCH PRO

先说结论，不是模型变菜了，而是题变难了。

与平均正确率高达70%SWE-Bench-Verified相比，SWE-BENCH PRO严格得可不止一星半点。

一方面金鼎配资，作为OpenAI于2024年8月发布的测试集，SWE-Bench-Verified中的很多代码库已被用作大语言模型的预训练语料，存在着数据污染的风险。

另一方面，SWE-Bench-Verified还包含不少琐碎的问题，例如500个问题中有161个只需一两行修改。

这与工业软件工程中通常涉及的跨多文件、数百行修改的场景差距较大，从而无法真正反映实际开发场景中所面临的挑战。

基于此，SWE-BENCH PRO主打全新题目，以确保模型在训练阶段从未接触过测试内容，从而更真实地考验模型的实际能力。

涵盖1865个商业应用、B2B服务和开发者工具的多元化代码库

具体来说，SWE-BENCH PRO将这些代码库构建为以下三个子集：

公共集：来自采用copy-left许可证的11个公共代码库的731个问题。商业集：来自276个源自初创公司代码库的问题。保留集：来自采用copy-left许可证的12个公共代码库的858个问题。

（注：公共集将在HuggingFace上发布，商业集和保留集保持私有，商业集的测试结果会公开，保留集用于验证模型是否过拟合。每个问题由任务描述、相关测试集和可运行环境构成。）

这些从强Copyleft许可证（GPL）代码库和真实的初创公司获取的商业代码库能够有效地解决SWE-Bench-Verified存在的数据污染问题。

为了确保任务的复杂性，研究团队还排除了像1-10行代码编辑这样琐碎的编辑，保留了需要进行大量多文件修改的问题。

此外，为了防止模型对任何单一代码库产生过拟合，这些代码库都处于活跃状态并覆盖消费者应用、B2B服务和开发者工具平台。

接下来，就让我们看看研究者是如何在这些问题上进行测试的。

human in the loop的测试环节金鼎配资

为了将模型评估的重点放在当模型获得充分细节后，能否实现给定的修复或补丁上。

研究团队在SWE-Bench Verified的基础上，将SWE-BENCH PRO中的每个问题都经过了人工增强，并加入了问题陈述、需求说明以及接口信息。

首先，研究团队提供一个待解决问题的问题陈述并在必要时补充上下文信息。

其次，针对潜在的歧义问题，对于每个问题，列出了一系列需求并指定相应的类和函数。

之后，在环境方面，每个任务都在一个容器化的、用于特定语言的环境中进行评估。

在测试阶段，研究通过fail2pass测试验证问题是否已解决，通过pass2pass测试确保现有功能保持完整。

其中，为了确保测试质量，fail2pass测试会经过人工筛选，去掉与任务不相关或过于宽泛的测试。

对于偶尔失败的测试，则会运行三次，以确保结果稳定。

实验结论

正如我们开头提到的，大语言模型在SWE-BENCH PRO上的解决率仅为中等水平，远低于SWE-Bench Verified中的70% 。

其中，在公共集上，GPT-5和Claude Opus 4.1分别实现了23.3%和22.7%的最高解决率，显著优于小规模模型，Claude Sonnet 4也达到了16.3%的解决率。

不过，像DeepSeek Qwen-3 32B和GPT-4o这样的老模型表现就多少有点不尽人意了，仅为3.4%和3.9%。

在商业集上，即便是最优模型的得分也低于20%。

这表明当前模型在解决真实商业场景中的问题时，能力仍然非常有限。

针对这一苦涩的实验结果，研究人员展开了进一步的分析，结论如下：

首先，编程语言的难度代码库以及模型的种类被视为影响模型表现的关键因素。

Go和Python通常表现较好，一些模型在这些语言上的解决率超过 30%，而JavaScript和TypeScript则波动较大，从0%到超过30%不等。不同代码库的解决率差异也很明显，一些代码库普遍偏低（低于 10%），另一些则超过50%。前沿模型如Claude Opus 4.1和GPT-5在大多数编程语言和代码库中表现稳定，小规模模型则更易出现接近零的解决率。

其次，不同的模型的失败原因往往各不相同。

OPUS 4.1的主要失败模式是语义理解不足，错误解答占35.9%，语法错误占24.2%，表明其技术执行能力较强，但在问题理解和算法正确性方面存在挑战。GPT-5的结果显示在工具使用的有效性上可能存在差异，但错误解答相对较少。SONNET 4的主要失败模式是上下文溢出（35.6%）和显著的无休止文件读取行为（17.0%），表明其在上下文管理和文件导航策略上存在局限。GEMINI 2.5的失败模式则较为均衡，涵盖工具错误（38.8%）、语法错误（30.5%）和错误解答（18.0%），显示其在多个维度上保持了一定能力。QWEN3 32B作为开源模型，表现出最高的工具错误率（42.0%），凸显了集成化工具使用对于高效代理的重要性。

不难看出，GPT-5虽然延续了以往“会就会，不会就不会”的答题策略，但面对高企的未回答率（63.1%），它的表现仍然不够看。

那么，谁会成为第一个突破30%的大模型呢？