大型语言模型重塑软件工程：行业变革与挑战解析

本文概述了软件工程（SE）大语言模型（LLMs）这一新兴领域。本文还提出了将 LLMs 应用于软件工程师面临的技术问题的研究挑战。LLM 的新兴特性带来了新颖性和创造性，可应用于软件工程活动的方方面面，包括编码、设计、需求、修复、重构、性能改进、文档和分析。然而，这些新兴特性也带来了巨大的技术挑战；我们需要能够可靠地剔除不正确解决方案（如幻觉）的技术。我们的调查揭示了混合技术（传统 SE 加 LLM）在开发和部署可靠、高效和有效的基于 LLM 的 SE 中的关键作用。

我们翻译解读最新论文：大型语言模型软件工程综述，文末有论文链接。

作者：张长旺，图源：旺知识

1. 引言

本文综述了基于大型语言模型（LLMs）的软件工程（SE）的最新发展、进步和实证结果；即大型语言模型（LLMs）在软件工程（SE）应用中的应用。我们利用这篇综述来突出这一快速发展但尚处于萌芽阶段的研究文献中的空白。基于文献中的空白和技术上的机会，我们还确定了软件工程研究社区面临的开放性问题和挑战。尽管对这样一个快速扩张领域的任何综述都不能也不声称是全面的，但我们希望这篇综述能提供这个令人兴奋的软件工程新子学科的早期宇宙的有用且相对完整的快照：基于LLM的软件工程。尽管该领域的科学和技术结构仍在形成中，但我们已经能够识别趋势、未来研究的有生产性的途径，以及需要解决的重要技术挑战。

特别是，我们已经能够辨识出与软件工程中现有趋势和确立的方法和子学科之间的重要联系和共鸣。此外，尽管我们发现有相当的理由感到乐观，但仍存在重要的技术挑战，这些挑战可能会在未来几年内指导研究议程。许多作者已经从科学和轶事的角度强调，幻觉是LLMs的一个普遍问题[1]，并且它为基于LLM的SE带来了特定的问题[2]。与人类智能一样，幻觉意味着LLM可以创建虚构的输出。在软件工程的背景下，这意味着创建的工程工件可能是不正确的，但看起来却很合理；LLMs可能会引入错误。然而，与LLMs的许多其他应用不同，软件工程师通常拥有可自动化的真理（软件执行），可以用来评估大多数软件工程工件。此外，软件工程研究社区已经在生产自动化和半自动化技术方面投入了大量的时间，用于检查人类可能产生的潜在错误结果。这意味着，对于这个学科和研究社区来说，在解决诸如幻觉等问题时，有很多经验和专业知识可以借鉴。显然，自动化测试技术[3]–[5]将在确保正确性方面发挥核心作用，就像它们已经对人类工程工件所做的那样。当生成完全新的功能和系统时，自动化测试数据生成受到缺乏可自动化神谕[6]（一种用于确定给定输入刺激的输出行为是否正确的自动化技术）的限制。鉴于LLMs倾向于产生幻觉，神谕问题将保持高度相关性，解决该问题的方法将变得更加有影响力[7]。然而，一些SE应用涉及现有软件系统的适应、改进和开发，对于这些应用来说，有一个现成的可自动化神谕：原始系统的功能行为。

在本文中，我们称之为“自动化回归神谕”，这是一种已经在遗传改进领域证明有利的方法[8]。自动化回归神谕简单地使用软件系统的最新版本作为参考，以基准化任何后续适应和更改的输出。当然，存在“固化”功能不正确的风险，因为自动化回归神谕无法检测系统应该做什么，只能捕获它目前做什么。因此，自动化回归神谕只能测试功能回归，因此最适合用于要维护现有功能的用例。例如，对于非功能性改进，如性能优化和语义保持重构。提供给LLM的输入将是日益增长的研究的重点，我们可以预期在提示工程和提示优化方面的文献将快速发展[9]。在这次综述中，我们强调了现有工作和开放挑战，关于软件工程几个特定方面的提示工程。LLM的输出不必局限于代码，还可以包括其他软件工程工件，如需求、测试用例、设计图和文档。总的来说，由于LLM的语言特性，它可以生成任何语言定义的软件工程工件。我们通常将软件工程工件视为LLM的主要输出，但这并不是唯一的输出。LLM提供的解释附带主要输出也是任何LLM的重要输出。我们的综述强调了需要更多的研究，不仅要优化提示工程（专注于LLM的输入），还需要优化主要输出附带的解释。LLM本质上是非确定性的：相同的提示在不同的推理执行中会产生不同的答案（除非温度设置为零，这在多次执行中通常被发现不是最优的）[10]。此外，无论温度设置如何，提示的微妙变化可能导致非常不同的输出[10]。除了激发“提示工程”和输出处理，这种非确定性行为还为基于LLM的软件工程的科学评估带来了挑战：

如果每次运行过程的结果都可能变化，我们如何确定提出的技术是否取得了对现有技术的进步？这是一个已经在经验软件工程[11]和基于搜索的软件工程（SBSE）[12]的背景下得到深入研究的问题。特别是，SBSE与基于LLM的软件工程有许多相似之处，它们都需要在嘈杂、非确定性和不完整的结果存在的情况下实现稳健的科学评估[13]、[14]。因此，已经有成熟的软件工程文献，正是基于LLM的科学评估所需要的稳健科学评估技术。

例如，现在通常使用诸如参数和非参数推理统计等经过深入研究的技术，在SBSE学科中提供稳健的科学结论，以应对高度非确定性算法。

为了理解基于LLM的软件工程中的增长趋势，我们对arXiv上特定主题的出版物数量进行了手动分析。表I包含了原始数据1，这些数据是从arXiv元数据转储中手动提取的，该转储通过Kaggle公开提供（https://www.kaggle.com/datasets/Cornell-University/arxiv），访问日期为2023年7月27日。我们首先过滤掉分类代码不以cs前缀开头（即计算机科学）的出版物，得到A列。为了识别与LLM相关的计算机科学论文，我们使用“Large Language Model”、“LLM”和“GPT”这些查询在标题或摘要中过滤出版物到人工智能（cs.AI）、机器学习（cs.LG）、神经和进化计算（cs.NE）、软件工程（cs.SE）和编程语言（cs.PL）子分类中（我们手动排除了GPT等过度使用的缩写，例如作为通用规划工具的GPT），得到L列。最后，我们使用相同的查询在软件工程（cs.SE）和编程语言（cs.PL）中识别基于LLM的软件工程论文。

2. 预备知识

A. 大型语言模型

大型语言模型（LLM）是指在大量数据上训练并能够以类似人类的方式生成文本的人工智能（AI）模型。表III提供了LLM术语的术语表，以使本文自包含。

LLMs通常基于深度学习技术，如变换器，并且能够生成有用的语言输出。因此，它们被发现能够执行广泛的与语言相关的任务，包括文本生成[16]、回答问题[17]、翻译[18]、摘要[19]和情感分析[20]。Rumelhart等人[21]引入了循环神经网络的概念，为处理序列数据提供了可能性。Hochreiter和Schmidhuber[22]引入的长短期记忆（LSTM）架构显著提高了其在许多应用中的性能。2017年，Vaswani等人[23]引入了变换器架构，该架构通过自注意力机制捕获单词之间的关系。变换器架构对语言建模产生了深远的影响，并引发了LLMs的爆炸性活动。2018年，OpenAI发布了生成预训练变换器（GPT）模型，随后是后续版本（GPT2、GPT-3、GPT-3.5和GPT-4）。随着GPT-3和3.5的出现，许多观察家注意到生成性能有了显著的飞跃，从而特别吸引了对GPT（以及ChatGPT）的兴趣，以及对LLMs的更广泛兴趣。LLMs之所以能够实现这种性能，部分原因是它们训练所用的大型语料库：例如，GPT-3在45TB的文本数据上训练，拥有1750亿个参数。Meta于2023年2月推出了开源的LLaMA，在1.4万亿个token上训练，模型大小从7亿到65亿个参数不等[24]。

B. 大型语言模型的类别

大型语言模型分为三类：1) 仅编码器模型：也称为自编码器，由编码器网络组成，但没有单独的解码器网络。它采用输入序列并将其映射到低维表示。自编码器的目的是学习输入数据的编码。仅编码器LLMs的例子包括Google的BERT、Meta的RoBERTa和Microsoft的DeBERTa[1]。2) 编码器-解码器模型：除了编码器网络外，还有解码器网络，它通过迭代生成基于上下文向量和之前生成的标记的输出序列。它可以用于机器翻译或文本生成等任务。编码器-解码器LLMs的例子包括Google的T5和Meta的BART[1]。3) 仅解码器模型：与前两种类型的LLMs不同，仅解码器LLMs没有用于处理输入数据的编码器组件，只有解码器组件，它直接基于给定的上下文或输入生成输出序列。仅解码器模型通常基于自回归模型等架构，其中输出是逐标记生成的。由解码器生成的每个标记都取决于之前生成的标记和上下文。

流行的仅解码器模型的例子是OpenAI开发的GPT（生成预训练变换器）系列，Meta的LLaMA，Anthropic的Claude和Google的PaLM[1]。

C. 软件工程中的大语言模型

虽然LLMs已广泛应用于涉及自然语言的任务，但它们在涉及编程语言的软件开发任务中的应用最近也受到了显著的关注。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%[25]的开发者代码由Copilot编写。对于Java，这个数字是62%。GitHub的首席执行官Thomas Dohmke表示，Copilot将很快“在不久的将来”编写80%的代码[26]。2022年，DeepMind引入了AlphaCode[27]，在选定的公共GitHub存储库上训练了40B个参数。在Codeforces平台上的模拟评估中，AlphaCode在超过5000名参与者的竞争中平均排名前54%。最新的GPT模型，GPT-4，也执行代码生成。根据GPT-4的技术报告[28]，在由OpenAI提供的开源数据集HumanEval上的零样本pass@1准确率为67%，该数据集包含164个编程问题。在100个LeetCode问题的基准测试中，GPT-4的性能与人类开发者相当[29]。2023年8月24日，Meta发布了开源的Code Llama[30]，这是在编码任务上公开可用的最先进的LLMs。表II列出了基于自然语言描述的代码生成/补全设计的代表性LLMs。

III. 需求工程和设计

需求工程是软件工程中的重要学科。它构成了系统软件工程师构建的技术属性与系统构建目的之间的基本联系。已有成熟的文献和大量的研究社区专注于需求工程问题[31]。此前也有关于人工智能方法支持需求工程的工作，特别是在计算搜索需求工程方面[32]。然而，迄今为止，需求工程学科在新兴的基于LLM的软件工程文献中得到的关注度较少。

A. LLMs在需求工程中的开放问题

与其他软件开发活动不同，我们没有发现太多关于基于LLM的需求工程或基于LLM的设计的工作。实际上，甚至有证据表明，实践工程师不愿依赖LLMs来实现更高层次的设计目标[36]。因此，这是一个扩展研究领域的大好机会。大多数LLM应用集中在代码生成、测试和修复等任务上。这些任务受益于LLM生成代码的能力。尽管如此，由于其自然语言处理能力，LLMs也有潜力支持需求工程活动。

例如，可追溯性是软件工程中一个长期存在的跨领域问题。特别是，确定需求与其他工程工件（如代码和测试）之间的可追溯链接特别具有挑战性，因为需求通常用自然语言编写；这是LLMs的自然适应。

IV. 代码生成和补全

在所有LLM软件工程应用领域中，代码补全是迄今为止被最深入探索的领域。即使在LLMs出现之前，就有建议表明，从现有代码库中学习是成功和智能代码补全的关键[37]：预训练的LLMs实现了这些早期对代码补全的愿景。虽然幻觉被指出是LLMs更普遍的弱点，但代码补全的具体任务通过充当开发人员的推荐系统来绕过幻觉问题。因此，开发人员负责筛选出任何幻觉的LLM输出，然后才将其渗透到代码库中。当然，如果幻觉程度很高，代码补全推荐系统将变得无效。广泛而迅速的采用，以及已经报告的积极结果，为代码补全提供了早期迹象，表明这种情况并未发生。例如，Murali等人[38]报告了在Meta部署基于Incoder LLM[39]的代码补全工具CodeCompose的经验。在15天内，CodeCompose提出了450万个代码补全建议，开发人员的接受率为22%。定性反馈非常积极，92%是积极的。同样，Peng等人[40]报告说，与没有接受任何此类支持的对照组相比，程序员在使用GitHub Copilot时完成一个非平凡任务（用JavaScript实现HTTP服务器）的速度提高了56%。许多软件工程师似乎已经决定，好处大于任何必要的人工筛选工作，已经有报道显示出热情的水平和接受率。一旦基于LLM的代码补全被完全采用，预计程序员将花费更多的时间审查而不是编写代码[41]。

A. 代码生成模型

自动化代码生成有着悠久的历史，其起源可以追溯到早期的自动程序合成愿景[42]，这些愿景一直在发展并产生了令人印象深刻的结果[43]。从Hindle等人关于软件自然性的开创性工作[44]中，我们知道程序员编写的代码（以及语言强制执行的代码编写风格）使得代码具有高度的可预测性。此外，Barr等人[45]发现，大型Java项目存储库的43%提交可以从现有代码中重建。他们将此称为“整形外科假设”，因为自动化修复通过寻找现有代码来修补其他地方的问题的方式进行[46]。他们的实证研究为这种搜寻方法提供了有效性的证据，同时也强调了软件的重复性和可预测性。在更大的存储库（sourceforge）中，Gabel和Su[47]发现，程序员必须编写超过六行代码才能创建一个新的代码片段。这些关于代码自然性、可重用性和可预测性的研究发现，LLMs能够利用相同的可预测可重用来为代码生成提供有效的建议，这并不令人惊讶。这些观察结果支撑了生成和测试方法在修复和遗传改进中的增长[8]，[46]。生成和测试方法提供了更大的代码转换自由度（与更传统的正确构造方法[48]相比），因为生成的代码可能不保留严格、数学定义的（并且不总是适当或有用的）正确性解释。这种探索“语义近邻”更广阔空间的自由度允许遗传改进找到戏剧性的优化（见第VI-C节）。遗传改进方法、命名法和评估方法也提供了一个科学框架，用于理解和评估基于LLM的代码生成。这两种技术都采用了程序转换和代码生成的“生成和测试”方法，可能使遗传改进的现有工作直接适用于基于LLM的代码生成。2021年，Chen等人[49]引入了CodeX，这是一个在公开可用的GitHub代码上微调的GPT语言模型，并评估了其编写Python代码的能力。他们发布了一个新的评估集“HumanEval”，用于衡量从docstrings合成程序的功能正确性，并发现CodeX在解决这些问题时的性能超过了GPT-3和GPT-J。从那时起，关于基于LLM的代码生成的研究激增，HumanEval数据集已在许多后续研究中使用。2022年，Li等人[27]引入了AlphaCode，这是一个用于代码生成的系统，它为竞争性编程问题创建了新的解决方案。他们发现，有三个关键组成部分对于实现可靠性能至关重要：

1. 用于训练和评估的广泛编程数据集。
2. 大型且高效的基于变换器的架构。
3. 大规模模型采样以探索搜索空间，然后基于行为进行过滤。

在Codeforces平台上对编程竞赛的模拟评估中，AlphaCode平均在超过5000名参与者的竞争中排名前54%。还有几篇论文引入了基于大型数据集且训练数据过滤很少的代码合成LLMs[50]–[53]。然而，在2023年，Gunasekar等人[54]报告说，通过仅使用教科书质量的代码语料库训练，参数数量较低的LLMs可以达到与大得多的模型相当的性能。

B. 提高代码生成的提示工程

提示工程被广泛用作一种方法来改善代码生成。例如，Li等人[57]报告了在CodeX、CodeGeeX、CodeGen和Incoder上的多个基准测试（MBPP用于Python，MBJP用于Java，MBJSP用于JavaScript）中，pass@1提高了大约50%到80%。Döderlein等人[58]报告了通过提示工程改进的Copilot和CodeX成功率从大约1/4提高到3/4，在HumanEval和LeetCode上。He和Vechev[59]使用提示工程来提高LLM生成代码的安全性，报告称安全性从59%（考虑的案例）提高到92%。White等人[60]为包括代码生成在内的各种软件工程任务提供了提示工程设计模式目录。Denny等人[61]认为提示工程是一个有用的学习活动，可以促进软件工程学生的计算思维。其他作者考虑了如何将提示工程分解为与LLM的迭代和多阶段对话，使其更接近于思维链推理。例如，Li等人[62]、[63]报告了使用两阶段基于草图的方法SkCoder，在ChatGPT上提高了18%的Pass@1，其中LLM首先创建一个草图，然后随后实现这些草图。Jiang等人[64]和Zhang等人[65]也试图通过提示LLM反映和自我编辑来部署思维链风格的推理。现有的软件工程分析技术也可以为微调和提示工程提供额外信息。例如，Ahmed等人[66]展示了如何使用简单的静态分析在提示中提高使用少样本学习代码生成的性能。Shin等人[67]比较了GPT-4的提示工程和微调，证明微调比提示工程更有效。

C. LLMs和其他技术的混合

在我们的文献综述中，我们发现一些最有希望的结果可以通过混合实现；将LLMs与其他现有的软件工程技术相结合。本节调查了用于代码生成的混合LLMs的工作。几位作者开发了将LLMs与计划和搜索相结合的混合体。例如，Zhang等人[68]、[69]报告了与基线相比大约11%到27%的改进，而Zhang等人[70]将代码生成与API搜索技术混合。

混合方法还使用现有的软件工程和/或AI技术从LLM的前n个输出中选择最佳候选项。例如，Chen等人[71]使用测试生成来选择候选项，并报告了在五个预训练的LLMs上改进了大约20%；Inala等人[72]使用基于神经网络的排名器来预测代码正确性和潜在故障。Jain等人[73]提出了Jigsaw，它基于程序分析和合成技术后处理生成的代码。Dong等人[74]将LLMs视为代理，让多个LLMs在解决代码生成任务时协作和互动地扮演不同角色。他们报告了大约30%-47%的改进。

D. 基于LLM的代码生成的科学评估

迫切需要更彻底的科学评估。许多作者已经以轶事形式报告了LLMs未能生成正确、安全和可靠代码的案例。Poldrack等人[75]也强调了大量人工验证的必要性。本节调查了关于基于LLM的代码生成在正确性、鲁棒性、可解释性、确定性和安全性方面的实证评估的文献。

1. 正确性评估：GPT-4技术报告[28]评估了GPT-4在HumanEval数据集上的代码生成的正确性，报告了67%的零样本准确率，这是对（早期ChatGPT）由Yetistiren等人[76]报告的结果的适度改进。Borji[77]对ChatGPT代码生成失败进行了严格、分类和系统的分析。他们的工作中展示了包括推理、事实错误、数学、编码和偏见在内的十一种失败类别，并进行了讨论。图4显示了根据Papers With Code平台的HumanEval数据集上的pass@1（即，顶级代码候选项的测试通过率）的代码生成正确性排行榜。每个方法背后的LLM模型都显示在括号中。在撰写本文时，最佳的代码生成模型Reflexion[78]可以为超过90%的生成任务生成正确的代码。然而，这些数字和不同语言模型的相对排名在这样一个快速发展的领域本质上是会变化的。例如，原始GPT-4报告[28]中给出的HumanEval上的正确代码的数字只有67%，所以更新后的数字80%（在撰写本文时，也就是五个月之后）从PapersWithCode网站检索到，可能代表了自那以后GPT-4的演变。尽管文献中关于代码生成和补全的成果很有希望，Din等人[79]报告说，当上下文包含错误时，代码补全的性能在HumanEval上下降了超过50%。
2. 鲁棒性评估： LLM代码生成的鲁棒性是指相似的提示引发语义和句法上相似的代码生成的程度。Treude[80]引入了GPTCOMPARE，这是一个原型工具，用于直观地突出LLM代码输出之间的相似之处和差异。Yan等人[81]引入了COCO，用于测试基于LLM的代码生成系统的鲁棒性和一致性。
3. 可解释性评估： LLM相对于以前的机器学习技术的一个显著优势在于，代码生成工件伴随着解释。这样的解释有潜力通过提供额外的信心和更快的理解来增加采用率。需要更多的工作来评估和优化伴随生成代码和其他软件工程工件的解释。MacNeil等人[82]在他们的交互式Web开发电子书上的初步评估表明，大多数学生认为LLM生成的代码解释是有帮助的。Noever和Williams[83]也展示了解释在帮助人类工程师方面的潜力，特别是在代码混淆或缺乏足够现有文档的情况下。通过这种方式，产生洞察和解释的能力可能不仅仅局限于证明LLM本身生成的代码的正确性，而且可能成为教育和文档的宝贵来源（见第XI节）。Sun等人[84]专注于用户对生成式AI在三个软件工程用例中的可解释性需求：基于自然语言描述的代码生成（使用Copilot）、不同编程语言之间的翻译（使用Transcoder）和代码自动完成（使用Copilot）。他们的调查以9个研讨会的形式进行，共有43名软件工程师参与，并确定了在生成式AI（GenAI）代码生成背景下的11个可解释性需求类别。它还提出了4种生成式AI的功能类型：AI文档、模型不确定性、注意力分布和社交透明度（即，使管理AI使用的社会组织因素可见）。

Mohammadkhani等人[85]使用注意力机制研究了CodeBERT和GraphCodeBERT在包括代码文档生成、代码改进和代码翻译等任务上的表现。

4) 确定性评估： LLMs是非确定性的。Ouyang等人[10]对ChatGPT在代码生成中的非确定性进行了实证研究，发现超过60%的任务在不同请求中产生了零个相等的测试输出。然而，他们对LLM基础代码生成文献的研究显示，只有21.1%的这些论文在其实验中考虑了非确定性威胁。

5) 安全性评估： Hajipour等人[86]提出了一种少样本提示方法来检测安全漏洞，报告说他们的方法自动在几个模型中发现了数千个安全漏洞。Khoury等人[87]发现，ChatGPT生成的代码通常甚至没有达到最低标准的安全编码。Risse和Bööme[88]报告的结果显示，由于模型过度拟合到不相关的训练集特征，漏洞检测的准确性可能被高估了。此外，Yetistiren等人[76]对Copilot、CodeWhisperer和ChatGPT的性能进行了全面评估，涵盖了不同方面，包括代码有效性、代码正确性、代码安全性、代码可靠性，并且他们的结果表明性能存在很大的差异，激发了进一步研究和调查的需要。例如，他们发现由ChatGPT、Copilot和CodeWhisperer生成的程序分别有65%、46%和31%是正确的。

6) 基准测试： 与其他科学评估一样，软件工程评估依赖于公开可用和具有代表性的基准测试套件。已经出现了一些这样的基准测试，可以支持基于LLM的应用程序的软件工程评估。Papers-With-Code平台[5]提供了15个用于评估代码生成的基准测试的摘要。

评估通常依赖于编程课程中的小型编程问题[89]、合成生成的问题集[90]以及Leetcode等在线评判平台[29]、[65]、[91]。尽管结果自然会因LLM在训练集上的表现而有所不同，但这些评估的总体结论表明成功率在20%到80%之间。然而，现有的代码生成基准测试倾向于依赖测试套件来自动判断代码的正确性，这可能是不充分的，导致错误的判断[92]。这突出了需要更多的工作来开发专门针对基于LLM的代码生成评估的评估基准。Liu等人[93]指出了这个问题，展示了现有的测试套件如何可能导致高度的误判结论（这也是在线评判平台的一个严重问题[92]）。为了缓解这个问题，他们提出了EvalPlus——一个代码合成基准测试框架，它自动生成测试输入并严格评估LLM生成代码的功能正确性。他们对14个流行的LLMs（包括GPT-4和ChatGPT）的评估表明，使用为HumanEval新生成的测试，pass@k的评估下降了高达15%，平均考虑了所考虑的问题。Jimenez等人[94]引入了SWE-bench，旨在评估LLMs在现实软件工程环境中的代码生成问题。SWE-bench包含2,294个软件工程问题，来自真实的GitHub问题。结果表明，Claude 2和GPT-4分别只解决了4.8%和1.7%的编码任务。

E. 代码生成和补全中的开放问题

对LLM生成的代码进行评估仍然是基于LLM的代码生成和补全的一个关键问题：尽管已经有许多工作开始将现有的软件测试知识应用到这个问题上，但我们期望更紧密地将自动化测试技术与代码生成和补全技术结合起来。幸运的是，有大量的现有工作集中在自动化测试数据生成上[3]–[5]，这些工作将在确保由LLM生成的工程工件的正确性方面发挥重要作用。本文中讨论的挑战的一个反复出现的主题是，代码执行提供了过滤幻觉响应所需的“真实情况”。它还可以作为交互式推理/行动（“ReAct”）对话[95]的指导，无论是在LLM之外还是之内。自动化测试数据生成允许软件工程师针对运行时真实情况中最相关的区域进行探索。这种基于测试的目标定位可以帮助过滤、微调和优化提示，从而最小化由幻觉引发的问题。LLM在自动化构建有效和高效的软件测试套件的过程中也有很大的潜力。另一个重要的问题是，如何有效地微调预训练的LLMs，以便它们在特定的编程语言、代码库或领域中表现更好：这是特别重要的，因为从头开始训练一个LLM需要大量的计算资源。

例如，转移学习被提出作为在特定编程语言的训练示例数量不足时提高代码补全性能的一种方法[96]。目前的研究重点放在LLMs生成的代码上。然而，LLMs生成的解释可能至少和代码一样重要。可以想象许多场景，工程师宁愿接受一个（可能）次优的软件工程工件，如果它附带了一个有说服力的解释，而不是一个性能更好的解决方案，但解释不够有说服力。毕竟，工程师经常对人类设计的工程工件做出相同的判断，那么对于由机器生成的工件，我们为什么期望会有所不同呢？与专注于优化LLM输入的提示工程一样，解释工程也可能成为一个独立的研究领域。

V. 软件测试

软件测试是一个确立已久的研究学科，其起源可以追溯到20世纪40年代图灵的开创性工作[97]。这项研究的大部分重点一直放在自动化生成测试套件上，这些测试套件能够在计算成本低的情况下实现高故障揭示潜力[3]–[5]。这为我们提供了不仅能筛选出不正确的LLM生成的代码，而且可以作为一个成熟的基线，用来比较新颖的基于LLM的和混合的测试套件生成技术。已经有足够多的工作支持对基于LLM的软件测试进行专门的综述：Wang等人[98]提出了一份主要关于测试的论文综述，但也包括了调试和修复。他们报告了52篇论文（其中33篇自2022年以来发表），其中大约三分之一关注基于测试的LLM微调，其余的依赖于提示工程。

A. 使用LLMs生成新测试

在这一部分中，我们回顾了LLMs在测试数据生成方面的现有工作，然后突出了这个新兴领域发展中的开放问题和挑战。生成的测试可能无法执行，因为LLM无法保证生成可编译的代码。Nie等人[99]报告说，使用TeCo生成的测试中有29%是可执行的，而Yuan等人[100]发现，大约四分之一由ChatGPT生成的测试是可执行的，通过适当的提示工程，这一比例上升到三分之一。在那些确实编译的测试中，一些作者报告了它们实现的代码覆盖率。例如，Bareiß等人[101]报告说，与使用Randoop[102]实现的10%相比，使用CodeX的覆盖率提高到了14%。Hashtroudi等人[103]报告说，通过微调CodeT5，他们生成的测试的行覆盖率提高了50%。Siddiq等人[104]报告说，在HumanEval数据集上使用CodeX实现了80%的覆盖率，但也发现研究的LLMs在EvoSuite SF110数据集上无法实现超过2%的覆盖率。

B. 测试充分性评估

测试有效性通常以“充分性标准”[121]、[122]来衡量。由于测试无法穷尽所有可能性，充分性标准为测试套件的有效性提供了一种最低界限。变异测试是评估软件测试套件充分性的广泛研究技术[123]、[124]，其中故意注入合成故障（称为“变异体”），以评估测试充分性。变异测试已被证明比其他基于结构覆盖的标准（如语句和分支覆盖[125]）提供更严格的充分性标准。变异测试面临的一个具有挑战性的开放问题是如何生成忠实于现实世界故障重要类别的变异体。Khanfir等人[126]使用CodeBert生成类似开发者的变异体，并发现他们的方法比PiTest具有更好的故障揭示能力。Garg等人[127]应用CodeBERT生成忠实于漏洞的变异体。他们的评估发现，17%的变异体未能通过89%相应的漏洞所失败的测试。Brownlee[128]使用GPT-3.5为遗传改进生成变异体，并观察到随机抽样的基于LLM的编辑比标准GI编辑更经常编译并通过单元测试。

C. 测试最小化

测试最小化通过移除多余的测试用例来提高软件测试的效率。Pan等人[129]应用CodeBERT、GraphCodeBERT和UniXcoder提取测试代码的嵌入来进行测试最小化。他们的方法实现了0.84的故障检测率，并且运行速度比基线快得多（平均26.73分钟）。

D. 测试输出预测

Liu等人[130]提出了CodeExecutor，这是一个预训练的Transformer模型，用于预测程序的整个执行轨迹。目的是模仿现实世界中任意程序执行行为。他们的评估将CodeExecutor与CodeX进行了比较，并表明CodeExecutor在执行轨迹预测方面显著优于CodeX（例如，在Tutorial数据集上，输出准确率分别为76%和13%）。

E. 测试不稳定

如果一个测试在某些情况下可以通过，在其他情况下会失败，而没有明显的（测试人员可控制的）执行环境变化，那么这个测试就是不稳定的。测试不稳定性是阻碍工业测试有效性的最紧迫和影响最大的问题之一[131]。LLM已被用于以高准确率（报告了73%的F1分数[132]、[133]和97%的准确率[134]）预测不稳定性。

F. LLMs在软件测试中的开放问题

在基于LLM的软件测试数据生成中存在许多开放问题，其中大多数完全在现有软件测试技术的掌握之中。因此，我们可以预期未来几年将出现基于LLM的软件测试生成的爆炸式增长。本节概述了这一研究议程的一些方向。

1. 提示工程：一个好的软件测试有许多方面可以通过适当的提示工程来获得优势。例如，我们需要了解如何设计提示，以
2. 预测和减少生成的测试不稳定性；
3. 揭示可能的故障，例如通过在历史故障数据上进行训练；
4. 优化模拟和集成测试之间的平衡；
5. 制作现实的数据构建器、模拟对象、参数和输入；
6. 预测最有可能引发覆盖角落案例的测试；
7. 根据生产中普遍的行为定制测试生成。
8. 增强现有测试：基于LLM的测试生成工作一直集中在自动化生成新的测试套件上。然而，鉴于现有的测试生成技术的多样性，仍然存在一个重要（且相对较少研究）的开放问题，即基于现有测试套件的增强和再生[135]、[136]。测试增强和再生可以利用少样本学习，和/或可以在现有的测试数据和历史故障上进行微调，以生成增强的测试套件。需要更多的工作，以LLMs生成额外的测试断言，捕获角落案例、历史故障和可能的程序员错误，利用现有的训练数据。LLMs和现有自动化测试生成技术之间的混合也是一个富有成效的主题[105]。
9. 测试正确性：传统的软件测试生成受到Oracle问题[6]的困扰，即它们受到缺乏自动化Oracle的限制，该Oracle确定测试结果是否正确。AI生成的测试有两个案例：
1. 生成的测试在当前版本上通过：我们可能假设功能已正确测试，并且生成的测试因此充当回归测试，可以检查未来的变化。
2. 生成的测试在当前版本上失败：我们需要知道是断言错误还是生成的测试发现了错误。这两种情况如果没有自我调节就可能产生严重后果。一个通过的测试用例可能只是反映了偶然的正确性[137]、[138]。更糟糕的是，代码实际上可能是错误的（而测试同样错误，但捕获了错误行为）。在这种情况下，生成的测试将倾向于抑制故障补救，在未来的修复中失败。这个问题也影响到了基于LLM的生成测试用例，如果这些测试幻想出了Oracle属性，将这些错误的Oracle断言烘焙进生成的测试中，可能会更加有害。另一方面，当一个生成的测试用例失败时，这可能表明存在一个错误。这个错误揭示将表示LLM基础测试的“胜利”。然而，如果假阳性与真阳性的比例很高，那么成本（例如，人工评估）可能会使这项技术变得不切实际，即使它确实揭示了真正的阳性错误[131]。需要更多的工作来开发自动评估、增强和过滤LLM基础测试执行原始结果的技术，然后再向开发人员呈现“测试信号”。LLM幻觉和测试正确性之间的交互是一个重要的话题。由于基于LLM的代码生成通常由最有可能的内容驱动，而不是最正确的内容，幻觉对任何关于正确性的问题都构成了威胁。然而，有趣的是，Feldt等人[139]报告了一个幻觉有助于软件测试的案例，因为它可能揭示了实际程序语义和程序员对语义的感知之间的差异。他们建议使用一种对话测试代理的形式（即，任何生成的测试都通过对话被程序员过滤），以利用这种能力而不对整体测试正确性构成威胁。

VI. 维护、演化和部署

软件维护和演化是研究了数十年的重要课题。它们涉及我们寻求理解的现有代码库，我们从中提取业务逻辑，并寻求重构、修复和改进。维护问题，如这些，都存在于语言丰富的问题领域中。因此，不足为奇的是，这个领域找到了许多基于LLM的技术应用，正如我们在本节中回顾的。

A. 调试

Kang等人[140]研究了GPT-3.5的故障定位能力，并发现LLM通常能够在第一次尝试时识别出有缺陷的方法。Wu等人[141]对GPT-3.5和GPT-4在故障定位准确性、稳定性和可解释性方面的能力进行了全面研究。结果表明，GPT-4在故障定位准确性方面比现有技术高出47%，但随着代码上下文的增长，性能急剧下降。Feng和Chen[142]提出了AdbGPT，通过与ChatGPT的提示工程一起，从错误报告中重现Android错误。在88个错误报告的数据集中，AdbGPT能够成功重现81%，超过了基线和消融。Joshi等人[143]专注于多语言调试，并提出了RING，它提出了一种基于提示的策略，将修复概念化为定位、转换和候选排名。为了解决故障定位和程序修复中的数据泄露威胁，Wu等人[144]引入了ConDefects，其中包含1,254个Java错误和1,625个Python错误，这些错误是在2021年10月至2023年9月之间产生的。研究人员可以根据它们的创建时期选择代码样本，从而允许他们根据它们的训练数据截止日期评估不同LLM的有效性。此外，还有关于使用LLMs预测错误严重性的工作[145]。

B. 程序修复

修复缺陷在过去十年中一直是软件工程研究社区非常感兴趣的课题[146]、[147]，并且已经初步部署在工业中[148]。

大部分关于自动化修复的工作都使用了在遗传改进领域广泛采用的生成和测试方法，并且可以方便地应用于基于LLM的技术。因此，LLMs肯定会对自动化软件修复产生积极影响，但仍存在技术挑战，需要控制幻觉问题和管理可扩展性，正如我们在本节中报告的。为了实现可扩展性，所有生成和测试方法都需要解决构建时间问题[149]。基于LLM的修复也不例外；幻觉倾向使得定期执行测试阶段变得更加重要。使用ReAct部署模型[95]可能会帮助找到有效和有效的工程折衷方案。当ReAct应用于修复时，整体方法将在“推理”阶段（生成候选修复）和“行动”阶段（通过测试评估修复，涉及构建问题）之间交替进行。为了解决这个问题，我们可以参照软件修复的成熟文献[46]、[150]，这些文献基于二十余年的搜索基础方法在软件工程中的发展[12]、[151]。这些文献为研究社区提供了丰富的经验和专业知识，使其非常有能力发展基于LLM的生成和测试方法来解决这个问题。最近关于修复的工作开始使用神经AI模型，如Tufano等人[152]的开创性工作。自2022年以来，关于基于LLM的修复的研究文献迅速发展。例如，Xia等人[153]提出了AlphaRepair。它将APR问题重新定义为完形填空（或填充）任务，利用LLMs直接基于潜在错误代码部分的双向上下文填充正确代码。AlphaRepair还首次证明了LLMs可以超越所有先前的APR技术。他们进一步对五个数据集上的九个LLMs进行了实证研究[154]。他们的发现不仅证实了基于LLM的APR（特别是完形填空风格的方法）的优越性，还提供了一些实用的指导方针。Wei等人[155]通过LLM和补全引擎之间的交互综合补丁，并发现该方法比最佳基线多修复了14个和16个错误。程序修复自然适合于提示工程的会话模型。Xia等人[156]提出了会话APR，它以会话方式在补丁生成和验证之间交替进行。他们在十个LLMs上的评估表明，他们的方法在有效性和效率方面都具有优越性。他们进一步提出了ChatRepair[157]，表明会话方法可以修复337个错误中的162个，每个错误只需0.42美元，从而也解决了对计算资源需求的潜在关注。Chen等人[158]引入了SELF-DEBUGGING，它教会LLM通过少样本学习来调试其预测的代码，SELF-DEBUGGING报告了高达12%的基线准确性提升。

C. 性能改进

自计算机编程诞生之初，性能优化的重要性就已被认识到。实际上，性能优化甚至在Ada Lovelace十九世纪关于分析引擎的笔记中就被提及[170]。最初的实际部署优化主要发生在编译器开发中，通过优化编译器的工作[171]。这是当前实用且高效计算的基础，但由于其通用性，必然是一种一刀切的方法；由于其普遍适用性，对于特定的问题领域来说并不最优。因此，也有很多关于特定源到源转换以改进优化的工作，可以追溯到20世纪70年代[172]、[173]。长期以来，这项工作的重点是寻找合适的一组保持意义不变的转换，动机是正确的程序可以转换成自身的一个更有效版本，同时保持其正确性。然而，近年来，程序合成研究转向了不同的方向：受到遗传编程[174]的启发，以及自动程序修复[146]、[175]的早期结果，它考虑了一组更广泛的转换，这种方法被称为“遗传改进”[8]、[176]。更广泛的转换可能会产生错误的代码，但自动化测试可以筛选这些代码，以确保对预期语义的足够忠实。此外，将现有代码视为一种“遗传材料”的自由度，为非功能性属性（如执行时间、内存和功耗）带来了显著的改进（例如，一个非平凡的基因测序系统的加速提高了70倍[177]）。尽管人工智能技术，如进化算法，用于改进性能的潜力已被深入研究，但研究人员才刚刚开始考虑基于LLM的性能改进的潜力。在Madaan等人[178]的工作中，作者使用CODEGEN和CodeX提出功能正确、性能改进的编辑（PIEs），提高了Python和C++（已经使用最大优化编译器选项-O3预优化）的执行时间。类似地，Garg等人[179]提出了DeepDev-PERF，这是一种针对C#应用程序的性能改进建议方法。DeepDev-PERF采用了英语预训练的BART-large模型，并在源代码上进行了进一步预训练。Kang和Yoo[180]提出使用LLMs为遗传改进提出目标特定的变异算子，并在提高效率和减少内存消耗方面提供了演示。Garg等人[181]提出了RAPGen，它为LLMs生成零样本提示以改进性能。提示是通过从一个预先构建的先前性能改进的知识库中检索提示指令来生成的。Chen等人[182]使用GPT模型作为他们源代码优化方法Supersonic的基线，并发现Supersonic提高了26.0%的程序运行时间，而GPT-3.5-Turbo和GPT-4分别只有12.0%和4.0%。

Cummins等人[183]专注于编译器的性能，并展示了LLMs在优化编译器指令方面的效果。他们的结果表明，一个相对较小的（70亿参数）LLM，训练用于生成指令计数和优化编译器LLVM代码，可以在减少编译器指令计数方面产生3%的改进，超过了现有技术。他们在正确性方面的结果也是有希望的，91%可以编译，70%与原始编译器输出在功能上正确。

D. 代码克隆检测与重用

关于管理软件重用以提取价值和避免重复的工作已有大量先前研究[184]，LLMs也被应用于解决这一问题[185]。软件通常包含大量的克隆，这些克隆来自于临时重用，这导致了很多关于自动化克隆检测的工作[186]，这也是经过模糊测试微调的LLMs的应用领域之一[187]。

E. 重构

当我们重构代码时，我们通常期望其行为保持不变。这对于自动化方法（如基于搜索的重构[188]）特别有吸引力，因为这意味着我们可以简单地依赖自动化回归神谕（Automated Regression Oracle）。这种“免费”的自动化神谕优势非常重要，也将适用于基于LLM的重构。Poldrack等人[75]展示了GPT-4对现有代码进行重构可以显著提高根据Halstead[189]和McCabe[190]等长期建立的结构度量标准衡量的代码质量。Noever和Williams[83]强调了AI驱动的代码助手在重构遗留代码和简化高价值存储库的解释或功能方面的重要价值。

F. 维护和演化中的开放问题

由于软件维护和演化的许多子领域都涉及现有遗留系统的源代码，我们可以预期LLM的应用将迅速增长。本节概述了这个新兴研究领域的一些现有开放问题。

1. 性能改进中的开放问题：需要更多的工作来开发基于LLM的技术，以自动寻找性能改进。与遗传改进一样，这些不仅仅局限于执行时间，还可以考虑其他非功能性属性，如功耗[191]–[193]和内存占用[194]以及多目标、在非功能性属性集合之间的权衡[195]。我们预计会有更多的工作集中在基于LLM的遗传改进式代码优化技术上，这有可能带来许多戏剧性的进展和突破。
2. 重构中的开放问题：根据定义，重构不会改变语义，因此基于LLM的重构可以依赖于自动化回归神谕。因此，令人惊讶的是，目前还没有更多的关于基于LLM的重构的工作。在这一部分中，我们概述了可能的方向。设计模式在实际软件工程中发挥了关键作用已有三十年的历史[196]。LLMs可能帮助工程师将现有代码重构为使用设计模式，同时提供开发人员友好的解释和文档。每当新技术出现时，重构也变得必要。例如，当API更新或新的API变得可用时。尽管它们可以（有时是自动地[197]）修复，API误用仍然是软件工程错误中一个常见的来源。自动化面向新API的重构过程比其他代码转换要简单，因为存在自动化回归神谕。最后，LLMs的少样本学习能力可能使更定制化的重构成为可能。关于基于LLM的重构的新兴工作集中在根据众所周知的重构模式进行全局重构。然而，程序员通常有特定于项目的重构需求。高达三分之一的软件工程工作量都花在主要重复性、繁琐且可能出错的重构活动上，这些活动实现了这些特定于项目的重构需求。LLMs的少样本学习能力可能自动从具体示例中推广，自动化我们所说的“定制化”重构。需要更多的工作来开发可靠的少样本学习定制化重构技术。
3. 
   

VII. 文档生成

大部分基于LLM的软件工程工作都集中在代码生成上，但基于LLM的文档生成也有相当大的潜力。Sun等人[198]探讨了ChatGPT在Python代码摘要生成方面的表现。他们使用了CSN-Python并与NCS、CodeBERT和CodeT5进行了比较。他们采用了三种广泛使用的指标：BLEU、METEOR和ROUGE-L。令人惊讶的是，结果显示ChatGPT在BLEU和ROUGE-L方面的表现显著低于基线模型。Ahmed等人[66]对GPT-3.5进行了代码摘要的提示工程，而Geng等人[199]使用Codex在两个Java语言数据集Funcom和TLC上进行了实验：生成多意图评论。Gent等人[200]展示了预训练的LLM已经有足够的上下文来从不同的技术角度生成不同的代码摘要。

A. 文档生成和代码摘要中的开放问题

许多现有的代码摘要技术都是基于检索的：给定的代码使用神经表示以向量格式表示，随后用于从语料库中检索最相关的文本摘要。

这种方法有一个明显的限制，因为可以生成的摘要集受到训练语料的限制。LLMs可能实现自动化代码摘要，不受此训练语料的限制，借助它们的自然语言处理能力。虽然这可能导致更丰富和语义上更相关的摘要，我们也注意到现有的评估指标通常是词汇性质的，这限制了我们比较和评估LLM生成的更丰富摘要的能力[198]。基于ReAct方法[95]的最新进展可能为生成的文档提供更大的保证，即使它不能被执行。

VIII. 软件分析和代码库挖掘

软件分析是一个确立已久的领域；如何从现有的软件工件中为人类工程师提供洞见[201]。大量公开可用的软件工件信息促进了通过挖掘软件仓库（MSR）[202]、[203]获得的科学见解的增长。虽然MSR倾向于关注从此类挖掘中获得的科学研究见解，软件分析倾向于关注组织从分析自己的仓库中获得见解的机会，这也可以有益于AI的可理解性[204]。迄今为止，在这两种情况下，大部分数据的收集、管理和分析都依赖于劳动密集型的人工分析。我们没有发现有关使用LLMs支持此活动的工作。然而，由于许多LLMs已经摄取了这些软件工件数据，并且能够提供推理和见解，因此它们似乎很自然地会发挥重要作用。例如，LLMs可以根据它们摄取大量数据（包括以前对研究人员感兴趣的研究问题和假设）的能力，识别出有趣的新的MSR研究问题。它们还可以协助可追溯性，这是软件工程师很难维护的[205]、[206]。

IX. 人机交互

寻找人类工程师和软件基础设施之间的有效接口一直是软件工程发展过程中的一个反复出现的主题[207]、[208]，可以追溯到20世纪60年代该学科的开端[209]。我们发现了大量有趣的研究问题。例如，Vaithilingam等人[210]报告了24名参与者在理解、编辑和调试由Copilot生成的代码时遇到的困难，而Feldt等人[139]为基于LLM的软件测试代理提出了一个设计架构的层次结构。Liang等人[36]调查了410名实践软件工程师，发现LLMs被广泛用于促进低级编程任务，但也存在抵制使用LLMs进行更高级别的软件工程活动的情绪。Feng等人[211]收集了316K条推文和3.2K条Reddit帖子，关于ChatGPT的代码生成，以了解社交媒体对AI辅助编码工具的态度。

X. 软件工程过程

软件工程不仅关注软件产品，还关注构建它们的流程[213]。先前关于软件助手的研究[207]、[214]–[217]与基于LLM的软件工程尤其相关，一些作者已经开始考虑这一主题。例如，Ross等人[218]介绍了一个基于LLM的程序员助手，并在42名参与者中评估了其部署，而Tian等人[219]强调了ChatGPT的注意力持续时间限制。

XI. 软件工程教育

教师们对识别学生依赖LLMs完成作业的案例表示担忧[220]，而其他作者则认为LLMs对教育的长期影响将是有益的[221]。然而，我们目前更关注LLMs对软件工程教育领域具体的影响，当前文献集中在基于LLM的教程支持上。例如，Jalil等人[222]探索了ChatGPT在软件测试教育中的机遇和问题。Savelka等人[223]分析了三种模型回答高等教育初级和中级编程课程多项选择题的有效性。其他几位作者[82]、[83]、[224]探索了CodeX在生成编程练习和代码解释方面的能力。他们的普遍发现是，大多数生成的内容是新颖的、合理的且有用的（见第IV-D3节）。

XII. 跨领域开放研究主题

从基于LLM的软件工程的初步文献中出现了一些模式，本节概述了那些跨越所有软件工程应用的开放研究问题。

A. 构建和调整LLMs以适应SE

大部分先前的工作将LLMs视为原子组件，重点是将它们整合到更广泛的软件工程工作流程中。虽然已有尝试调整行为，但这些尝试往往集中在提示工程上，只有少数微调的例子。一个更具挑战性但可能产生影响的问题在于训练和微调模型，特别是针对软件工程任务。Ding等人[225]使用执行输入和动态执行跟踪训练了一个类似BERT的LLM。他们展示了这种动态信息如何提高模型在下游软件工程预测任务中的准确性（高达25%）：漏洞和克隆检测以及覆盖率预测（完整执行路径和分支覆盖）。

需要更多的工作来开发新形式的LLMs，特别是为软件工程量身定制的，利用软件的独特属性，将其与自然语言区分开来。动态信息是当前大多数工作中缺少的一个关键差异化因素。我们期望下一代SE特定的LLMs能够解决这个问题。构建和训练LLMs的一个重要方面是它们的能耗。LLM的能力已与其大小相关联[226]，导致模型大小迅速增长[227]、[228]。训练和发展更大的模型可能直接对环境产生影响[229]。虽然已建议模型性能不仅取决于模型大小，还取决于训练数据量[230]，但为了实现所需性能而需要的正确模型大小问题仍然不清晰。更轻量的模型也可能扩大采用范围，从而提高部署性。最近，如低秩适应（lora）[231]和模型量化[232]等技术已显示出潜力，但它们仍需针对特定应用进行实证评估。

B. 动态自适应提示工程和参数调整的需求

初步的提示工程工作已经展示了其潜力，可以显著改进LLM生成的软件工程工件。然而，正如[58]中已经发现的，结果是高度特定于问题的，因此不切实际的是一种通用方法。此外，很少有论文报告模型参数设置，然而我们知道其中许多，如温度设置，在决定LLM输出的性质方面起着至关重要的作用。作为一个直接的起点，作者必须显著地报告这些参数设置，以支持复制。然而，我们还需要更多的研究在动态自适应提示工程和模型参数调整方面。这个研究议程可能会从现有的参数调整工作中获得灵感，例如用于其他动态自适应任务的模糊测试[233]。动态提示优化也可能利用与SBSE[12]相关的技术，将提示优化重新构想为多目标计算搜索过程。

C. 混合化

LLMs很少在孤立时最有效，但作为整体SE过程的一部分时可能非常有效。需要更多的工作来理解SE工作流程的设计模式，LLM可以安全、高效且有效地存在其中。我们相信现有的与生成和测试方法相关的SE理论和实践，如自动化修复和遗传改进，已经非常适合LLMs。我们期望看到更多的工作将LLM整合到这些现有的软件工程框架中。然而，需要更多的工作来定制和扩展这些框架，以最好地利用LLM基础软件工程提供的机会。

特别是，我们期望看到关于提示工程和LLM响应后处理的静态和动态分析工作的快速发展。我们还期望看到混合软件工程流程，适应持续集成管道以整合LLMs。

D. 利用幻觉

虽然幻觉一直被广泛认为是一个问题，但正如本调查报告的，它在应用到软件工程领域时也可能提供好处。LLM的幻觉很少是完全随机的错误响应。相反，由于它们固有的统计特性，它们更好地被描述为“似是而非的未来”，这可能经常使它们在正确的上下文中有用。幻觉可以被重新用于为软件增强提供潜在有用的建议。例如，当幻觉一个测试用例时，LLM可以被重新用于建议新功能，而一个幻觉的代码摘要可能表明（人类）代码误解的潜力；如果LLM“误解”了代码，人类难道不会也误解它吗？当LLM幻觉一个不存在的API时，它可以被重新用于建议重构以简化或扩展现有API。需要更多的工作来利用这种积极潜力，并利用幻觉促进软件改进。

E. 健壮、可靠和稳定的评估

Hort等人[234]对293篇关于LLMs用于代码生成的论文进行了审查，以确定在多大程度上共享了足够的信息以支持复制。他们发现只有33%的论文共享了源代码，27%的论文共享了训练的工件。他们还从能耗的角度评估了这些论文，评估了独立研究人员评估训练期间能耗的可能性。他们报告说，大约38%（79篇涉及模型训练的出版物中的30篇）共享了足够的信息来估计他们训练期间的能耗。Wang等人[98]对LLM基础测试的调查中也发现了科学评估质量可能存在日益严重问题的其他证据。在他们的调查中，他们过滤了一个初步的LLM基础测试论文池，以删除那些不符合标准评估质量约束的论文。这些约束要求论文包括一个清晰、定义良好、可重复的评估方法，包括一个控制或基线，用来衡量有效性。这个过滤标准去除了最初符合关键词搜索条件的论文中的90%以上。正如这些文献分析所示，显然需要更多的工作来为LLM基础软件工程这一新兴学科建立坚实的科学基础。这样的基础可能借鉴现有的一般经验软件工程基础，更具体地说，借鉴基于AI的软件工程，如SBSE（自然相似性[105]、[235]）。

尽管如此，LLMs具有其独特的属性，如提供解释的能力，这将需要特定领域的理论和实证科学基础。LLMs本质上表现出非确定性行为。研究人员需要仔细设计他们的实验，配置他们的LLMs（例如，评估不同分布采样策略的影响），并在得出关于LLMs的结论时考虑非确定性。SBSE文献提供了支持此类评估所需的推理统计的建议[13]、[14]。我们将看到在未来几年中，软件工程师的语言模型数量和多样性将迅速增长。无论是从业者还是实践软件工程师都将需要可靠、高效和全面的基准测试系统。如TESTPILOT[116]和Papers With Code平台（
https://paperswithcode.com/sota/code-generation-on-humaneval/）等基准测试平台将变得越来越重要。除了通用的科学基础、基准和评估平台外，我们还期望看到开发人员在LLM辅助编程时的行为纵向研究，以便我们能更好地理解程序员-LLM交互，并设计更有效的用例场景。

F. 彻底的测试

幻觉问题已经被广泛研究。它将继续是软件工程界乃至更广泛的计算机科学界非常感兴趣的话题。虽然可能会取得巨大进展，但由于幻觉风险与LLM技术本身一样内在，因此不太可能完全根除。幸运的是，在过去的六十多年里，软件工程师已经开发出了强大的自动化验证和测试技术，帮助减少人为错误的影响。我们期望这些技术也将延续到人工智能错误上。

G. 处理更长的文本输入

LLMs对大型输入提示的性能可能是人工智能界非常感兴趣的话题[236]。在这方面的进步将对软件工程产生强烈影响，因为软件系统的相当大的规模以及当能够更有效地处理更大提示时所开辟的机会。

H. 软件工程中覆盖不足的子领域

正如我们的综述所揭示的，软件工程的一些子领域在文献中明显被代表不足；有些令人惊讶。例如，需求工程和设计（第III节）以及重构（第VI-E节）几乎没有覆盖，然而它们显然是值得考虑的，因为它们在很大程度上依赖于语言形式的分析以及模式的识别和预测。

作者：张长旺，图源：旺知识

参考资料

标题：Large Language Models for Software Engineering: Survey and Open Problems
作者：Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Yoo, Jie M. Zhang
单位：Meta Platforms Inc., KAIST, King’s College London
链接：
https://arxiv.org/abs/2310.03533v4