AI编码工具未能代替码农：大模型的局限性揭秘

随着ChatGPT和Github Copilot等AI编码工具的兴起，Stack Overflow近日因流量减少宣布裁员近三分之一。这引发了一个争议的问题：ChatGPT这类AI编码工具，真的要颠覆整个行业了吗？然而，普林斯顿和芝加哥大学的最新研究LLM目前没那么容易代替码农。

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

据报告，GPT-4在面对选取的GitHub问题时的成功率为0%，而表现最佳的模型Claude 2的成功率也仅为1.96%。

那么，我们真的需要为编程工作的未来担忧吗？目前看来，程序员的职位并未受到真正的威胁。

Stack Overflow应对AI编程工具挑战

受到ChatGPT及其GPT-4驱动的Github Copilot等AI编程工具的冲击，曾是开发者首选的代码辅助网站Stack Overflow近期流量明显减少。尽管去年该公司员工人数翻倍至540人，但自去年11月OpenAI发布ChatGPT以来，开发者逐渐转向使用AI工具以获取更实时、准确的代码建议。今天，Stack Overflow的CEO Prashanth Chandrasekar宣布，由于宏观经济压力和转型盈利需求，公司裁员超过100人，占总员工数的28%。

随着ChatGPT等大语言模型的兴起，Stack Overflow和类似的代码辅助网站受到冲击。尽管这些模型大部分依赖于从这些网站获取的数据，却未有所回馈。这带来了一个紧迫问题：如果数据源耗尽，如何为新AI模型供应训练数据？

面对AI的挑战，Stack Overflow采取了两大策略：

自主研发：推出自家AI编码工具。

与科技巨头合作：与OpenAI等公司合作，因其构建AI模型时需用到Stack Overflow数据。为防止未授权数据爬取，OpenAI正在研发网络爬虫控制。Stack Overflow CEO明确，想用其数据训练模型的都需付费，强调知识库网站在AI模型进化中的不可或缺角色。

大语言模型真能取代码农?

普林斯顿和芝加哥大学的团队使用SWE-bench框架，对大语言模型在解决2294个GitHub问题的能力进行评估。结果显示，即使是GPT-4和Claude 2这样的领先模型，成功率都不超过5%。具体来说，GPT-4的成功率为0%，而Claude 2为1.96%。

参考网址：https://www.swebench.com/#

研究显示，使用BM-25检索技术时，Claude 2生成的代码补丁中，仅23%能应用到代码仓库，且仅1%真正解决问题。此外，对于12个主流Python库，模型表现存在差异。这一发现对于那些将GPT-4视为“编程神器”的人来说，无疑是一个巨大的打击。这也提醒了人们，不能单纯依赖高分榜单来判断AI的实际能力。

研究为“程序员是否会因AI失业”争议提供了新证据。有评论指出：“新的评估数据集SWE-bench比之前的HumEval更有说服力，大模型不到4%的成功率，难道说明它们距离真正自主还远？”而SWE-bench的评估准确性是否经得起推敲，又将成为业界新焦点。

SWE-bench重塑编码模型的评测标准

在最近的研究中发现，许多当前用于评估大型编码模型能力的基准测试已经不再适用，因为它们往往无法真实地反映模型的实际表现。以HumanEval为例，其中的挑战性问题过于简单，导致大模型只需短短几行代码便可解决。但实际的软件工程过程并不那么简单，它需在海量代码中寻错或理解复杂函数关系。

基于此，普林斯顿和芝大的研究团队提出了一个新的基准测试——SWE-bench。其独特之处在于直接与GitHub上的实际问题以及相关的合并请求解决方案连接，从而提供实际Python代码任务。模型的主要任务是为提交到GitHub仓库的问题找到答案，这通常涉及到错误报告或功能请求。

此外，SWE-bench要求模型为每个问题生成一个修复补丁，并详细描述其对现有代码库所做的修改。接着，利用仓库内置的测试框架SWE-bench来验证这些更改的代码库。

SWE-bench：精细筛选确保任务实例的高质量

研究者为了找到高质量的大规模任务实例，他们通过了以下三个细致的筛选阶段：

1、仓库选择和数据搜集:

首先初步选取了12个流行的开源Python代码库，从中收集约90,000个拉取请求（PR）。

研究人员会优先选择流行的仓库，因为它们往往维护得更好，具有明确的贡献者指南和高测试覆盖率。每个PR都与一个特定的代码库，即PR合并之前的仓库状态。

2、基于属性的筛选:

在创建候选任务的方法是选择满足以下标准的PR：

（1）解决了GitHub上的某个问题。
（2）修改了仓库的测试文件，这暗示了用户可能附带了测试以核实问题的解决情况。

3、基于执行的过滤:

对每个候选任务，执行PR的测试内容，并对比应用PR前后的测试结果。研究者会剔除没有经历“失败到通过测试”的任务实例。此外，还会过滤可能导致安装或运行错误的实例。

经过上述三阶段筛选，从原始的90,000个PR中，成功挑选出2,294个高质量任务实例，组成了SWE-bench。

研究者指出，被选中的代码库都规模庞大，包含数千个文件，并且相关的拉取请求通常涉及多个文件的修改。相较于现有的LM编程基准，SWE-bench展现出多重优势，包括：

• 利用真实的用户提交问题和解决方案。
• 提供来自12个资源库的多样化编码问题。
• 强大的基于执行的评估框架。
• 能够利用新实例持续更新，且只需最少的人工干预。

LLM在代码修复任务中的表现：如何衡量其效果？

研究团队为大模型提供了问题描述和代码库。具体来说，大模型需针对描述修改代码以达到解决问题的目的。在实际操作中，这些代码的修改被形式化为“补丁文件”，它明确指出为解决问题需要更改代码库中的哪些部分。

那么，如何判断LLM的修复方案是否有效？

为此，研究者利用unix的补丁程序工具，将这些生成的补丁应用到代码库中。接着，他们会执行相关的单元测试和系统测试以验证这些修改。只有当补丁成功且所有测试均通过时，方案才被视为有效。作为基准的关键指标，研究者关注的是成功解决任务实例的百分比。

SWE-bench：构建独特的数据集

与传统的NLP基准不同，通常只聚焦于短输入和专为基准设计的“人为”问题，SWE-bench基准测试带来了全新的视角。此基准考虑了真实的软件工程任务，其每个任务均涉及复杂的代码库和相关问题描述。解决这些问题需要的不仅仅是代码生成能力，还需具备资深软件工程师的专业技巧，这是传统基准所忽视的。

令人印象深刻的是，SWE-bench的数据采集流程适用于GitHub上的任何Python存储库，大大减少了人工干预的需要。这意味着研究者可以不断地为SWE-bench添加新任务，确保语言模型在尚未接触过的问题上得到评估。这就保证训练的语料库中没有包含具体解决方案，

研究者将关注在其基准的多样性，包括长输入、稳健的评估机制、跨上下文的代码编辑以及解决方案的广泛覆盖。

CodeLlama模型在SWE-bench中的调优

为了在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%。

（1）不同资源库的效果：

所有模型在不同代码库中呈现相似趋势。但各模型所解决的任务实例不总是相同。如，Claude 2和SWE-Llama 13b在oracle环境下分别解决了110个和91个问题。

（2）上下文长度的影响：

模型在长代码预训练时表现受限，难以处理长上下文。增加BM25上下文大小后，尽管召回率提高，但总体性能下降。

（3）问题创建日期的影响：
以2023年为分界，除GPT-4外，模型在此日期前后的表现无显著差异。

另外研究还发现，微调模型对上下文敏感，更擅长生成补丁而非整个文件。大模型更偏向生成简短、简单的代码。

以上数据图片均参考论文：https://arxiv.org/abs/2310.06770

LLM模型助力，未来工作流加速

尽管目前的通才模型存在上下文长度限制，但其潜力不容小觑。预见到未来，特训的LLM将展现更强的专业性。这并不意味着模型会取代程序员，反而可以加速他们的工作流，从而助力团队更快地实现目标。