软件工程的大语言模型：综述

23年10月来自公司Meta Platforms（三个不同办公室）和两所大学：韩国KAIST和英国伦敦King’s College的论文“Large Language Models for Software Engineering: Survey and Open Problems“。

本文对软件工程（SE）的大语言模型（LLM）这一新兴领域进行综述。它还提出LLM应用于软件工程师面临的技术研究挑战。LLM的涌现特性为软件工程的应用程序带来了新颖性和创造性，包括编码、设计、需求、修复、重构、性能改进、文档和分析。然而，这些非常相似的涌现特性也带来了重大的技术挑战；如何排除错误，比如幻觉，需要能够这样的技术。该综述揭示了混合技术（传统SE加LLM）在开发和部署可靠、高效、有效、基于LLM的SE中不得不发挥的关键作用。

如图是论文结构：

虽然LLM已被广泛应用于涉及自然语言的任务，但在编程语言的软件开发应用最近也受到了显著的关注。

2021年，OpenAI引入了CodeX，这是GPT-3的一个经过微调的后代。CodeX由GitHub的Copilot使用，为Visual Studio Code、Visual Studio、Neovim和JetBrains的用户提供代码补全功能。新版本的Copilot，GitHub Copilot X2，是基于GPT-4的。2023年2月，GitHub报告称，平均46%的开发者代码是由Copilot编写的[24]。仅就Java而言，这一数字为62%。GitHub首席执行官Thomas Dohmke表示，Copilot将在2023年6月“迟早”编写80%的代码[25]。

2022年，DeepMind推出了AlphaCode[26]，在选定的公共GitHub存储库上使用40B参数进行训练。在有5000多名参与者的模拟评估比赛中，它的平均排名前54%。

最新的GPT模型GPT-4也执行代码生成。根据GPT-4的技术报告[27]，在HumanEval上GPT-4的零样本pass@1 准确率为67%，其中HumanEval是一个来自OpenAI的开源数据集，由164个编程问题组成。在100个LeetCode问题的基准测试中，GPT-4的性能与人类开发人员相当[28]。2023年8月24日，Meta发布了开源的Code Llama[29]，这是一种用于编码任务公开LLM的最先进技术。如下表是大语言模型对代码生成和补全的代表方法：

需求工程是软件工程中的一门重要学科。它形成了系统软件构建的技术属性与构建系统的目的之间的基本联系。

在LLM的所有软件工程应用领域中，代码补全是迄今为止探索最彻底的领域。甚至在LLM出现之前，就有人认为，从现有的代码库中学习是成功补全代码的关键[36]：经过预训练的LLM实现了这些早期的代码补全愿望。虽然幻觉已经被指出是LLM的弱点，但更普遍地，代码补全的特定任务，可以充当开发人员的推荐系统来避开幻觉问题。因此，开发人员有责任在LLM幻觉流入代码库之前清除它。

当然，高度的幻觉会使代码补全推荐系统失效。广泛而快速的采用代码补全，从效果看，这个后果还没有发生。例如，Murali[37]报告在Meta部署CodeCompose的经验，CodeCompose是一种基于Incoder LLM[38]的代码补全工具。在15天的时间里，CodeCompose提出了450万条代码补全建议，开发者的接受率为22%。这个定性反馈是高度正向的，92%是积极的。同样，Peng[39]报告称，与没有得到任何支持的控制组相比，与GitHub Copilot配对的程序员可以56%更快地完成一项非琐碎的任务（用JavaScript实现HTTP服务器）。

许多软件工程师似乎已经决定，收益超过了任何必要的人工滤波努力，已经有报道称采用率和热情程度很高。一旦完全采用基于LLM的代码补全，程序员将花费更多的时间来审查而不是编写代码[40]。

软件测试是一门公认的研究学科，其起源可以追溯到20世纪40年代末图灵的开创性工作[92]。这项研究的大部分焦点都集中在测试套件的自动生成上，能够以低计算成本实现高故障暴露的潜力[3]-[5]。这不仅提供了能够剔除不正确LLM生成代码的技术，还提供一个成熟的基线，用于比较新的基于LLM的和混合的测试套件生成技术。

已经有足够多的工作在基于LLM软件测试方面：Wang[93]对主要关于测试的论文进行了调查，但也包括调试和修复。他们报告了52篇论文（自2022年以来发表的33篇），其中约三分之一涉及基于测试的LLM微调，而其余论文则依赖于提示工程。

几十年来，软件维护和进化一直是重要的研究课题。它们关注现有的代码库，从中寻求理解和业务逻辑提取，并为此寻求重设计、修复和重构。诸如此类的维护问题都存在于语言丰富的问题域中。

基于LLM的软件工程的大部分工作都集中在代码的生成上，但基于LLM生成文档也有可能。Sun[184]探讨了ChatGPT如何对Python代码进行代码总结。他们用CSN Python，并将ChatGPT与NCS、CodeBERT和CodeT5进行了比较。他们采用了三种广泛使用的指标：BLEU、METEOR和ROUGE-L。令人惊讶的是，结果显示，在BLEU和ROUGE-L方面，ChatGPT的性能明显低于基线模型。Ahmed[65]在GPT-3.5上进行了代码汇总的提示工程，而Geng[185]在两个Java语言数据集Funcom和TLC上进行了实验，使用Codex：生成多个意向的注释。Gent[186]证明，预训练的LLM已经具有足够的上下文，可以从不同的技术角度生成多个不同的代码总结。

软件分析有一个公认的领域：如何从现有的软件中为人类工程师提供洞察力[187]。在线公开的大量软件信息刺激了科学见解的增长，这个靠的是软件库挖掘（MSR）[188]-[189]。虽然MSR倾向于关注此类挖掘的科学研究见解，但软件分析倾向于关注组织的机会，是从分析自己的存储库中获得见解，这也有利于人工智能的可理解性[190]。迄今为止，在这两种情况下，数据的收集、管理和分析大多依赖于劳动密集型的人工分析。由于许多LLM已经吸收了这些软件数据，并且能够提供推理和洞察力，因此期望它们发挥重要作用似乎是很自然的。

在软件工程[193]-[194]的整个发展过程中，在工程师和软件基础设施之间寻找富有成效的接口，一直是一个反复出现的主题，可以追溯到20世纪60年代该学科的创立[195]。Vaithilingam[196]报告了24名参与者在理解、编辑和调试Copilot生成代码时遇到的困难，而Feldt[131]为基于LLM的软件测试智体提出设计架构分层结构。Liang[35]调查了410名执业软件工程师，发现LLM被广泛用于促进低级编程任务，但在更多设计级别的软件工程活动，LLM受到抵制。Feng[197]收集了316K条关于ChatGPT代码生成的推文和3.2K条Reddit帖子，去了解社交媒体对人工智能辅助编码工具的态度。他们发现，恐惧是与ChatGPT代码生成相关的主要情绪，掩盖了快乐和惊喜等其他情绪。Ahmad[198]探索了新手软件架构师与ChatGPT交互的方式。

软件工程研究不仅涉及工程产品（软件本身），还涉及它们的构建过程[199]。先前对软件助手的研究[193]，[200]-[203]，显然与基于LLM的软件工程特别相关，这是一些已经开始考虑的话题。例如，Ross[204]介绍了一种基于LLM的程序员助理，与42名参与者一起评估了其部署，而Tian[205]强调了ChatGPT的注意力广度限制。

对识别学生依赖LLM完成作业情况的困难，教师们表示担忧[206]，而其他作者则认为LLM对教育的长期影响将是有益的[207]。Jalil[208]探讨了ChatGPT在软件测试教育中的机会（以及问题）。Savelka[209]分析了三种模型在回答高等教育编程关于入门和中级课程多项选择题方面的有效性。其他几位[79]、[80]、[210]探讨了CodeX生成编程练习和代码解释的能力。他们的总体发现是，生成的大多数内容都是新的、合理的和有用的。