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

本文由 新智元 撰写/授权提供，转载请注明原出处。

文章来源于：新智元

作者：新智元编辑部

Stack Overflow，已经被 ChatGPT 创飞了！

因为码农大量涌向 ChatGPT、Github Copilot，Stack Overflow 今天不得已宣布裁员 100 多人，几乎占员工人数的 1/3。

所以，ChatGPT 这类 AI 编码工具，真的要颠覆整个行业了？

不过最近，普林斯顿和芝大的一项研究发现，LLM 想要替代码农，其实没那么容易。

论文地址：https://arxiv.org/abs/2310.06770

在 2294 个 GitHub 真实问题面前，GPT-4 解决随机 GitHub 问题的通过率，竟然是 0%！

而即使是最佳模型 Claude 2，也只能解决其中的 1.96% 而已。

码农会因为 ChatGPT 而失业吗？答案是——目前绝对不会。

要么适应，要么灭亡

作为全世界每个开发者最爱的代码辅助网站，Stack Overflow 在此前的形势还一片大好，在去年掀起了一场招聘狂潮，整个公司的员工人数都翻了一番，达到了 540 人。

然而，自从去年 11 月 OpenAI 发布了 ChatGPT 后，一切都变了。

AI 聊天机器人提供的帮助，比 5 年前的论坛帖子更加具体。通过 LLM，开发者可以即时更正确切的代码、优化建议，以及每行代码正在执行操作的说明。

虽说 LLM 提供的答案也并不是 100% 可靠，但代码具有独特的能力，只需在 IDE 集成开发环境中进行测试，即可立即验证代码了，这一切都使写代码成为了 ChatGPT 的理想用例。

因此，Stack Overflow 的流量大大减少，ChatGPT、GPT-4 驱动的 Github Copilot 等 AI 编程工具，都成为了码农的新去处。

今天，CEO Prashanth Chandrasekar 宣布，Stack Overflow 裁员一百多人，占员工总数的 28%。

CEO 对于裁员的解释是，宏观经济压力下，Stack Overflow 在努力走上盈利之路，不断推出产品创新。

过河拆桥？

ChatGPT 给 Stack Overflow 造成冲击这件事，最大讽刺之处在于，大语言模型的强大能力，很大程度上就是来自像 Stack Overflow 这样的抓取网站。

大语言模型吸空了这些数据，却不回馈任何东西，如果所有数据源都被迫赶出了这一业务，那时会发生什么？

现在，不少科技公司面前已经存在着迫在眉睫的问题：如果程序员减少，人造数据就会减少。

如果没有最新的数据，怎么训练新的 AI 模型呢？

想用我们的数据？拿钱来

Stack Overflow 当然不能坐以待毙，它选择了两种方式自救——

一是开发自己的 AI 编码工具 OverflowAI，二是直接和 OpenAI 这样的科技公司寻求合作，因为这些公司会使用 Stack Overflow 的数据构建 AI 模型。

据悉，OpenAI 正在为 ChatGPT 开发网络爬虫控制，这样 Stack Overflow 这样的网站的数据就不会被爬取。

CEO 表示，Stack Overflow 已经表明了立场：谁想用我们的数据来训练 LLM，谁就来付费。

CEO 认为，像 Stack Overflow 这样的网站对于大语言模型的发展至关重要，为了进步，它们需要在新知识上进行训练。

Stack Overflow首席执行官Prashanth Chandraseka

所以，大语言模型真能取代码农吗？

普林斯顿和芝大团队发现，没那么容易！

在最新论文中，研究人员提出了一种全新框架 SWE-bench，以评估大模型在解决 2294 个 GitHub 真实问题中的能力。

结果发现，像 GPT-4、Claude 2 这样领先的大模型，解决实际问题的能力，都不过5%。

再具体点，GPT-4 可以解决随机 GitHub 问题的通过率竟是 0%，而最佳模型 Claude 2，也只能解决其中的 1.96%。

更值得一提的是，在使用 BM-25 检索每个问题的相关代码文件时，Claude 2 编写的补丁中只有 23% 是有效的（可以用于 repo），只有 ~1% 真正解决了问题。

此外，不同的模型，在解决 12 个流行的 Python 库问题的性能，也有所差异。

GPT-4 大模型取得这样的结果，真是让人大跌眼镜，毕竟许多人都早已将其视为「编程利器」。

但要看清，AI 真正的实力，不要被刷榜评分而陷入担忧。

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

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

那么，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 任务：编辑代码库，解决问题

研究者会给大模型关于问题的文本描述，以及完整的代码库。

大模型的任务，就是对代码库进行编辑，来解决问题。

在实践中，研究者将修改表示为补丁文件，它会指定要修改代码库中的哪些行以解决问题。

如何评价 LLM 给出的方案好不好？

研究者会使用 unix 的补丁程序，将生成的补丁应用于代码库，然后执行与任务实例相关的单元和系统测试。

如果补丁应用成功，并且通过所有这些测试，就可以认为 LLM 建议的方案成功地解决了问题。

基准的度量指标，是已解析任务实例的百分比。

构建 SWE-bench 的独特数据集

传统的 NLP 基准，通常只涉及短的输入和输出序列，并考虑一些专门为基准创建的“人为”问题。

相比之下，为了构建 SWE-bench，研究者为数据集注入了独特的属性。

比如，采用的是真实的软件工程任务。

由于 SWE-bench 中的每个任务实例都包含一个庞大而复杂的代码库和相关问题的描述，解决 SWE-bench，就需要经验丰富的软件工程师拥有的复杂技能和知识，但在传统的代码生成基准中，这些通常不被评估。

而且，收集过程可以轻松地应用于 GitHub 上的任何 Python 存储库，几乎不需要人工干预。

因此，研究者就可以通过不断提供新的任务实例来扩展 SWE-bench，并就训练日期后创建的问题对语言模型进行评估，这就确保了训练语料库中，并没有包含解决方案。

此外，研究者还保证了基准中不同的长输入、稳健评估、跨上下文代码编辑、解决方案的广泛范围等。

微调 SWE-Llama

接下来，就是到了评估开放模型与专有模型在 SWE-bench 框架的效果了。

可是研究者发现，现成的 CodeLlama 微调模型，无法遵循详细的指令生成整个资源库范围内的代码编辑，通常会输出占位符响应或不相关的代码。

为了评估这些模型的能力，研究人员对 70 亿参数的 CodeLlama-Python 模型和 130 亿参数的 CodeLlama-Python 模型进行了监督微调（SFT）。

由此产生的模型是专门的仓库编辑器，可在消费级硬件上运行，并解决 GitHub 问题。

大模型都败北

接下来，研究者对 GPT-3.5、GPT-4、Cluade 2 以及微调的模型进行了评估。

结果发现，所有模型都失败了——除了发现最简单的问题外，它们都无法解决所有问题。

比如，Claude 2 和 GPT-4 分别只能解决 4.8% 和 1.7% 的任务。

在使用 BM25 检索器后，Claude 2 的性能进一步下降到 1.96%。

不同资源库的难度不同。

如果按资源库对性能进行细分，就会发现所有模型在不同资源库中都表现出相似的趋势。

尽管如此，每个模型所解决的问题并不一定广泛重叠。比如，在 oracle 设置中，Claude 2 和 SWE-Llama 13b 的性能相当，每个模型分别解决了 110 个和 91 个实例。

难度与上下文长度相关。

模型可以在长代码序列上进行预训练，但通常要求一次生成单个函数，并提供有限的上下文来确定问题的框架。

如图所示，可以看到随着上下文总长度的增加，Claude 2 的性能大幅下降，这种情况在其他模型中也可以观察到。

即使增加 BM25 的最大上下文大小，会提高相对于甲骨文文件的召回率，但性能仍然会下降，因为模型根本无法在茫茫词库中定位有问题的代码。

难度与问题解决日期无关。

在表 7 中，展示了在「oracle」检索设置下，针对 2023 年之前或之后创建的 PR，按日期划分的模型结果。

对于大多数模型来说，除 GPT-4 外，在这一日期之前或之后的性能差别不大。

另外，研究还发现微调模型对上下文分布变化很敏感，生成补丁比生成整个文件更容易。而且大模型倾向于生成更短、更简单的编辑。

有网友对「通才模型」的未来有所憧憬和希望。

没错，这也是我的经验之谈。通才模型还不够好，没有足够宽的上下文长度，除了相对较短的代码片段外，无法自行编码。

但我认为这只是时间问题。我可以预见，在不久的将来，接受过特定训练的通才 LLM 将成为非常专业的模型。

虽然大模型无法替代程序员，但可以加速他们的工作流。过去需要 10 人的团队，现在可能只需要 4 个人。这样就能腾出资源，用于公司筹备的其他目标。

与其为了省钱而解雇员工，不如让开发人员惊人的速度完成伟大的事业！

参考资料：

https://www.reddit.com/r/MachineLearning/comments/1795iiz/can_ai_replace_developers_princeton_and/

https://twitter.com/_carlosejimenez/status/1711714120175681552

https://www.swebench.com/

https://futurism.com/the-byte/stack-overflow-layoffs-ai

https://arstechnica.com/gadgets/2023/10/after-chatgpt-disruption-stack-overflow-lays-off-28-percent-of-staff/?comments=1&comments-page=1

扫码关注公众号

获取更多技术资讯