大模型无法替代码农！普林斯顿芝大惊人发现：GPT-4解决GitHub编程问题成功率为0( 二 ) _大模型

文章插图
GPT-4大模型取得这样的结果，真是让人大跌眼镜，毕竟许多人都早已将其视为「编程利器」。
但要看清， AI真正的实力，不要被刷榜评分而陷入担忧。

文章插图
有网友表示，这是对「码农是否因编程而失业」问题的最好的解答。

文章插图
终于有人为代码模型制作了一个真正的eval数据集，HumEval只是LLM的leetcode面试。我们都知道，这对人类工程师来说是个错误的衡量标准。不到4%听起来是对的，因为大模型离完全自主还很远。

文章插图
那么，SWE-bench评估大模型能力的结果，事实真是如此吗？
SWE-bench：专为编码模型设计
在这项研究中，作者发现，当前许多评测大模型编码能力的基准已经趋于饱和，无法评测出大模型真正的实力。
比如， HumanEval中，挑战问题太过简单，LLM只需要几行代码就能解决独立的问题。
然而，现实中软件工程并非如此简单。

文章插图
修复一个bug可能需要浏览庞大的资源库，理解不同文件中函数之间的关系，又或者在错综复杂的代码中发现一个小错误。
受此启发，普林斯顿、芝大研究人员介绍了SWE-bench 。
SWE-bench通过连接GitHub问题和解决相关测试的合并请求解决方案，从真实Python代码库中获取任务实例。
如图所示，模型的任务（通常是错误报告或功能请求）是解决提交到GitHub仓库的问题。
每项任务都需要生成一个补丁，并描述要应用到现有代码库中的更改。
然后使用仓库的测试框架SWE-bench，评估修改后的代码库。

文章插图
为了找到高质量的大规模任务实例，研究者通过了三个阶段的筛?。?

文章插图
第一阶段：仓库选择和数据搜索。
首先从GitHub上12个流行的开源Python代码库中收集拉取请求（PR），总共产生了约90,000个PR 。
研究人员将重点放在流行的仓库上，因为这些仓库往往维护得更好，有明确的贡献者指南，并且有更好的测试覆盖率。每个PR都有一个相关的代码库，即PR合并前的仓库状态。
第二阶段：基于属性的筛选。
创建候选任务的方法是，选择符合以下条件的合并PR：（1）解决了GitHub问题；（2）修改了仓库的测试文件，这表明用户很可能贡献了测试来检查问题是否已解决。
第三阶段：基于执行的过滤。
对于每个候选任务，都会应用PR的测试内容，并记录应用PR其他内容前后的相关测试结果。
研究者会过滤掉没有至少一项测试的任务实例，这些测试的状态从失败变为通过（以下简称「失败到通过测试」）。此外，还会过滤掉导致安装或运行错误的实例。
通过这些阶段的筛选，原始的90,000个PR被筛选为2,294个任务实例，这些任务实例构成了SWE-bench 。
如下图3所示，显示了这些任务实例在不同资源库中的最终分类，表是SWE-bench任务实例的主要特征。
研究者强调，这些代码库都很大，包含数千个文件，而且参考拉取请求通常会同时对多个文件进行修改。
与现有的LM编程基准相比，SWE-bench具有多项优势。
其中包括，利用用户提交的问题和解决方案的真实设置、来自12个资源库的独特代码问题为特色的多样化输入、基于执行的强大评估框架，以及利用新实例不断更新基准的能力，且只需极少的人工干预。
LLM任务：编辑代码库，解决问题
研究者会给大模型关于问题的文本描述，以及完整的代码库。
大模型的任务，就是对代码库进行编辑，来解决问题。
在实践中，研究者将修改表示为补丁文件，它会指定要修改代码库中的哪些行以解决问题。