在刚刚结束的ICSE (IEEE/ACM International Conference on Software Engineering) 2023和已经发布接受论文列表的ISSTA (ACM SIGSOFT International Symposium on Software Testing and Analysis) 2023的会议论文集中，涌现了许多LLM与软件工程结合的工作，包括使用LLM辅助软件测试和缺陷修复，以及使用软件工程方法对LLM进行实证分析、精调LLM以及LLM生成程序的自动修复等。

1. 背景

1. LLM

LLM是Large Pre-Trained Language Models的缩写，指的是大型预训练语言模型。这些模型首先会在大量的文本数据上进行无监督训练，然后在特定任务上进行微调，以实现对该任务的优化。在自然语言处理领域，LLM已经被广泛应用于机器翻译、文本摘要、分类等任务上，而本文则探讨了将LLM应用于自动程序修复、自动Debug的可行性。通过实验验证，在一些重要的自动程序修复任务中，LLM的表现已经超越了传统的和基于学习的技术。同时，本文还提出了一些进一步改进LLM在自动程序修复和Debug方面表现的方法和方向。

1. CLM

CLM指的是代码语言模型，是一种对程序代码进行预训练的模型。它可以用于自动化程序修复等领域，能够通过对代码进行分析和预测来生成代码修复方案，从而提高代码质量。论文2通过对十种代码语言模型进行评估和比较，发现CLM具有较强的修复能力，通过微调可以进一步提高其能力。同时，文章呼吁对CLM进行公平、全面的评估，避免数据泄漏和提高模型性能的效率。

2. 架构

语言模型可以根据其体系结构分为三组：仅编码器模型、仅解码器模型和编码器-解码器模型。大多数现有的CLMs采用Transformer体系结构构建，因为它具有最佳的学习能力和可扩展性。 仅编码器模型，例如CodeBERT和Graph-CodeBERT，仅具有双向Transformer编码器和一个注意机制，以学习输入代码序列的矢量化嵌入。它们最适合需要没有生成的下游任务，例如代码表示和代码克隆检测。 仅解码器模型，例如CodeGen、InCoder和Codex，仅具有自回归的Transformer解码器，以学习生成代码序列。它们最适合于下游任务，例如开放式结束代码生成，即根据输入提示生成代码。 编码器-解码器模型具有编码器和解码器，例如GPT-Coder、LEAM和Pointer-Generator-Pointer。它们可以应用于各种下游任务，如代码完成、摘要和生成。

值得注意的是，无论其架构如何，大多数模型都可以使用特定于任务的数据进行微调以提高其性能。

2. LLM for SE

LLM可以应用于软件工程的多个领域，如代码自动修复、代码补全、文档生成、变量/类型预测、测试生成等。其中，代码自动修复是LLM在软件工程中的一个重要应用领域。使用LLM进行自动修复可以避免传统和基于学习的自动修复技术在补丁变体和复杂性方面的局限性。具体应用方式包括直接应用LLM生成补丁、对修复后的代码进行排序和正确性检查等。除此之外，LLM还可以应用于模糊测试、测试生成和变异测试等领域。在这些领域中，LLM的应用方式可以是生成符合语法和语义要求的程序，也可以是直接补全或自动生成相关代码、实现相关任务。

1. APR

APR是指Automated Program Repair，即自动程序修复。它旨在通过自动生成潜在的修补程序来帮助开发人员自动修复软件中的错误。目前，传统的和基于学习的APR技术在修补多样性和复杂性方面存在局限性，因此研究者提出使用大型预训练语言模型（LLM）来避免这些限制。论文1评估了9种最新的LLM模型在3种编程语言（Java、Python和C）的5个不同修复数据集上使用3种不同的APR实验设置的能力，并显示应用LLMs进行APR可以优于所有现有的APR技术，并可以进一步通过增加样本大小和结合修复模板信息来改进。

2. Debugging

Debugging是指在软件开发过程中，通过排除程序错误来使程序运行正常。这通常涉及到在代码中识别、定位、分析和修复错误。调试过程可以通过使用不同的技术进行，例如断点调试、日志记录和跟踪程序执行流程等。

1. Scientific Debugging

科学调试的过程包括通过实验产生有关漏洞根本原因的假设，并测试这些假设。

2. LLM for Testing and Maintanence

1. [ISSTA] Large Language Models are Zero-Shot Fuzzers: Fuzzing Deep-Learning Libraries via Large Language Models

Deng, Y., Xia, C. S., Peng, H., Yang, C., & Zhang, L. (2022). Fuzzing Deep-Learning Libraries via Large Language Models. arXiv preprint arXiv:2212.14834.

1. 本文的主要工作

这篇论文介绍了一种名为TitanFuzz的新方法，利用大语言模型（LLMs）来对深度学习库进行fuzzing。传统的fuzzing技术往往难以生成同时满足语言的语法和深度学习API输入/形状约束的张量计算的输入。TitanFuzz利用LLMs，这是在数十亿个代码片段上训练的模型，可以生成包括调用深度学习API调用的人类代码片段。TitanFuzz使用生成和填充LLMs来生成和变异有效且多样化的输入程序以进行fuzzing。实验结果显示，与最先进的fuzzer相比，TitanFuzz在TensorFlow/PyTorch上实现了更高的代码覆盖率，并检测出了65个bug，其中41个以前未知。 TitanFuzz通过使用LLMs并完全自动化fuzzing过程来解决了传统API级别和模型级别fuzzing技术生成多样化API序列和无法生成任意代码的局限性。论文认为，LLMs可以用于在传统方法具有挑战性的领域进行fuzzing，例如深度学习系统，并希望推动这一方向的进一步工作。

2. 传统Fuzzing方法和遇到的问题

传统的fuzzing方法包括基于API级别和基于模型级别的fuzzing技术。其中，API级别的fuzzers主要关注于单个DL库API的fuzzing，通过简单的变异规则来尝试创建许多不同的输入。而模型级别的fuzzing技术可以潜在地测试API序列，但突变规则通常只有少量层次的API可用。

传统fuzzing技术存在如下问题：

1. 难以生成既符合语法/语义规则又满足张量计算的深度学习API输入和形状限制的输入；
2. 它仅集中于各个DL库API的fuzzing，无法生成具有多个关联DL API的API序列；
3. API级和模型级fuzzing技术存在一些限制，比如难以生成多样的API序列。

3. TitanFuzz

TitanFuzz工作流程

对于任意目标API，

1. TitanFuzz首先使用生成式LLM（Codex）生成一系列高质量的模糊测试种子程序。这是通过向模型提供一个分步提示来生成直接使用目标API的代码片段。对于生成的种子，TitanFuzz进一步应用进化模糊算法来迭代生成新的代码片段。在每次迭代中，TitanFuzz首先从种子库中选择一个具有高适应度得分的种子程序。TitanFuzz使用不同的突变操作符系统地将选定种子的部分替换为蒙版标记，以生成蒙版输入。通过多臂老虎机算法选择突变操作符，目的是尽量生成有效且独特的突变。
2. TitanFuzz利用LLM（InCoder）的填充能力来执行代码填充，生成替换蒙版标记的新代码。对于每个生成的突变体，TitanFuzz首先过滤掉所有执行失败的情况，并使用适应度函数为每个突变体评分。然后将所有生成的突变体放入种子库中，并在未来的突变轮次中优先选择得分较高的种子，从而为模糊测试生成更多样化的高质量代码片段。最后，使用不同的后端（CPU和GPU）执行所有生成的程序，通过差分测试oracle来识别潜在的漏洞。

Codex生成例子

2. [ICSE] CodaMOSA- Escaping Coverage Plateaus in Test Generation with Pre-trained Large Language Models

Lemieux, C., Inala, J. P., Lahiri, S. K., & Sen, S. (2023). Codamosa: Escaping coverage plateaus in test generation with pre-trained large language models. In 45th International Conference on Software Engineering, ser . ICSE.

1. 本文的主要工作

本文主要探讨了如何利用大型语言模型（LLMs）来帮助基于搜索的软件测试（search-based software testing, SBST）。SBST通过变异测试用例并选择生成对被测试程序覆盖率更高的测试用例来生成高覆盖率的测试用例，但经常会遇到覆盖率瓶颈，即测试用例的变异不会进一步提高覆盖率。本文提出了CODAMOSA算法，该算法使用LLMs为SBST提供覆盖率低的函数的测试用例，以在SBST的覆盖率提高停滞时改善覆盖率。CODAMOSA将这些测试用例集成到SBST的测试用例表示中，并变异以提高覆盖率。

CodaMOSA生成测试用例的例子

3. [ICSE] Fill in the Blank Context-aware Automated Text Input Generation for Mobile GUI Testing

Liu, Z., Chen, C., Wang, J., Che, X., Huang, Y., Hu, J., & Wang, Q. (2022). Fill in the Blank: Context-aware Automated Text Input Generation for Mobile GUI Testing. arXiv preprint arXiv:2212.047

1. 本文主要工作

本文的主要工作是提出了一种名为QTypist的方法来解决移动GUI测试中的文本输入问题。该方法使用预训练的大语言模型（LLM）智能地生成具有语义相关性的文本输入。同样，该方法开发了基于提示的数据构造和调整方法来提高LLM在移动测试场景中的性能。作者在Google Play上对106个应用进行了测试，得出QTypist的通过率为87％，比最佳基线高93％。将QTypist与三个常用的自动化GUI测试工具集成后，QTypist能够涵盖更多的应用行为和UI页面。

2. GUI自动测试的瓶颈

本文的motivation是为了解决移动GUI测试中的文本输入问题，确保移动应用程序的质量。移动自动化GUI测试工具在生成适当的文本输入以跳转到下一页方面面临困难，因为有效的输入需要多样性和与特定的输入字段的语义相关性。

3. QTypist

QTypist的工作流程

1. 基于Context的Prompt生成

   1. 

   2. Context提取：主要从页面中提取以下信息

      1. Input widget：需要输入文本的控件的信息，包括控件的提示词、Resource ID、已经显示的文本。
      2. Local context：从当前界面提取输入控件相关的其它控件信息，如父节点控件、相同水平线其它控件等，提取它们的文本和Resource ID。
      3. Global context：当前activity名称、app名称、当前界面输入控件的数量等。

2. Prompt生成

   1. 
   2.   如上表所示，prompt的构建主要使用提取出来的信息造句。

4. [ICSE] Large Language Models are Few-shot Testers- Exploring LLM-based General Bug Reproduction

Kang, S., Yoon, J., & Yoo, S. (2022). Large Language Models are Few-shot Testers: Exploring LLM-based General Bug Reproduction. arXiv preprint arXiv:2209.11515.

1. 本文的主要工作

本文的主要工作是提出了LLM-induced Bug ReprOduction（LIBRO）的框架从Bug报告中生成测试用例的方法。该研究强调了自动化调试技术中揭示Bug的测试用例的重要性，并建议从Bug报告生成测试用例是一种被低估但有影响力的自动编写测试的方式。作者建议利用LLMs生成测试用例，并处理结果以确保可靠性。他们对两个数据集进行了广泛的实证分析，LIBRO在Defects4J基准测试中为33.5％的缺陷生成了至少一个Bug复现测试。最终，本文证明，LIBRO有潜力通过自动从Bug报告中生成测试用例显著提高开发人员的效率，从而使更广泛的自动化调试技术可用。

2. LIBRO

可以通过一个例子来理解LIBRO的工作流程：

1. Bug Report

2. Prompt生成

3. LLM生成的测试用例

4. 测试用例插入

5. [ICSE] On the Applicability of Language Models to Block-Based Programs

Griebl, E., Fein, B., Obermüller, F., Fraser, G., & Just, R. (2023). On the Applicability of Language Models to Block-Based Programs. arXiv preprint arXiv:2302.03927.

Block-based program（以Scratch为例）

1. 本文的主要工作

本文的主要工作是探讨自然语言处理技术在流行的基于块的编程语言Scratch中的应用。该研究调查了n-gram模型和transformer在Scratch程序中的应用，重点评估它们在代码完成和错误检测方面的适用性。作者解释说，虽然源代码可能表现出使其适合自然语言处理技术的规律性，但是文字编程语言强加的句法开销在基于块的语言中大部分被消除，这使建模变得更加复杂。评估表明，块减少了可预测性，但是由于Scratch中仍存在一些语法和重复性的元素，因此即使与基于文本的编程语言有所不同，也足以使用n-gram和transformer模型进行编程任务。该研究的结果可作为开发基于块的语言的改进工具和分析的基础，这对于编程教育和最终用户编程都非常重要。

6. [ICSE] Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models

Ahmed, T., Ghosh, S., Bansal, C., Zimmermann, T., Zhang, X., & Rajmohan, S. (2023). Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models. arXiv preprint arXiv:2301.03797.

1. 本文的主要工作

本文的主要工作是评估使用大型语言模型（LLMs）来为云服务的故障提出根本原因和缓解步骤的效果，并且探讨 fine-tuning 和多任务模型等优化模型使用的方法。文章还在 Microsoft 公司的 40,000 多个事件中进行了大规模评估，证明了 LLMs 有效地为实际的生产故障提供解决方案。此外，作者还进行了人类验证以确保模型提供的根本原因和缓解步骤的正确性和可读性。

数据集的准备：

该部分的内容包括了对数据集进行清洗和处理，包括数据的去重、标准化incident summaries、选择适当的incident types等。在处理后，作者们将数据集分成了不同的训练、测试和验证集，以便评估LLMs的性能。同时，文档也指出了数据集的缺陷，例如某些重要信息在incident summaries中未被记录下来。为了缓解这些问题，作者们建议拓展数据集，避免数据泄露，并尝试保留incident summaries中的更多细节信息。

2. 本文的研究内容

1. 精调后的GPT-3.x模型可以有效找到事故的根因吗？

利用大语言模型可以为云事件推荐根本原因，并对其进行有效的检测。细调提高了LLMs的有效性，GPT-3.x模型优于编码器解码器模型。人工评估也显示了使用人工智能解决云事件的潜力。

2. 精调后的GPT-3.x模型能够推荐合适的事故处理计划吗？

LLMs在推荐云服务故障的减轻措施方面表现很好。通过对微软超过40,000个事件的研究，发现fine-tuning显着提高了LLMs的效果。GPT-3.x模型表现比编码器-解码器模型更好，LLMs可指导on-call工程师确定实际根本原因，但需要人工审核和专家验证。

3. 与零样本学习相比，精调能够多大程度提高GPT-3.x的能力？

在云服务的事故管理过程中，由于大语言模型没有受到事故管理数据的训练，需要进行fine-tuning以提高效果。在评估过程中，44,340个事故中的fine-tuned GPT-3.x模型效果显著优于其他模型且人工评价结果也显示出人工智能用于解决云服务事故的潜力。

4. 多任务学习可以提高GPT-3.x模型在根因定位和事故处理上的性能吗？

对于incident data，fine-tuning可以明显提高LLMs的有效性，而且GPT-3.x模型表现优于encoder-decoder模型。此外，文档还讨论了使用LLMs来管理incident的优化问题，例如fine-tuning的必要性，以及为每个任务构建一个模型是否更有效。

5. 在已知根因的情况下，GPT-3.x能够更好地提供事故处理计划吗？

提供根因后，各个模型的表现基本都有提升

6. 模型对机器检测到的事故生成的报告优于人工检测到的事故吗？

由于机器检测的事故符合某些固定的pattern，模型的表现更好一些。

3. LLM for Repair

1. [ICSE] Automated Program Repair in the Era of Large Pre-trained Language Models

Xia, C. S., Wei, Y., & Zhang, L. (2023). Automated program repair in the era of large pre-trained language models. In Proceedings of the ACM / IEEE 45th International Conference on Software Engineering (ICSE’23) .

1. 本文的主要工作

本文主要探讨了在大型预训练语言模型(LLMs)的时代中，使用LLMs进行自动化程序修复(APR)的应用。与传统和基于学习的APR技术相比，LLMs可以避免在补丁多样性和复杂性方面的局限性。研究评估了9个最新的LLMs，在3个编程语言（Java、Python和C）的5个修复数据集上，使用3种不同的APR实验设置进行了评估。LLMs在生成补丁、速度和编译率方面的能力进行了评估。研究表明，应用LLMs进行APR可以胜过所有现有的APR技术，并且APR具有规模效应，即更大的模型往往会产生更强的结果。本文还表明，在有错误行后添加后缀代码可以生成更多补丁，具有更高的编译率。该研究得出结论，通过增加样本量和纳入修复模板信息，可以进一步提高基于LLMs的APR。总的来说，本文架起了LLMs与重要的软件工程问题APR之间的桥梁，并提供了使用LLMs进行APR的实用指南。

2. 现有APR技术面临的挑战

APR技术面临的挑战是有限的补丁类型和复杂性问题。传统的和基于学习的APR技术在修补程序时都存在这些限制，因为它们需要使用补丁模板或训练数据来生成补丁。这导致了补丁种类和复杂性的限制。而大型预训练语言模型( LLMs)可以帮助避免这些问题。

3. 应用LLM到APR的实验

LLM通过避免传统的和基于学习的APR技术在补丁变化和复杂性方面的局限性来解决APR技术的缺点。研究人员建议使用LLM来克服这些限制，并在5个不同的修复数据集中对9个最新的LLM进行评估，跨越3种编程语言（Java，Python和C）使用3种不同的APR实验设置。该研究表明，将LLM应用于APR可以优于所有现有的APR技术，并且APR的规模效应存在，其中更大的模型倾向于提供更强的结果。该研究还表明，缺陷行后缀代码对于生成更多具有更高编译率的补丁是重要的。总之，该研究将LLM与重要的软件工程问题APR联系起来，并为使用LLM进行APR提供了实用指南。

本研究评估了9个最新的大型预训练语言模型（LLMs），使用三种编程语言（Java、Python和C）在5个不同的修复数据集上以三种不同的自动程序修复（APR）实验设置进行评估。LLMs的能力是通过它们生成补丁的能力、速度和编译率来评估的。研究表明，直接应用最先进的LLMs可以在所有数据集上显著优于所有现有的APR技术。该研究将LLMs与最先进的APR工具进行比较，并表明所研究的LLMs中的Codex可以修复比现有最佳APR技术多32个错误。在所研究的LLMs中，更大的模型往往能够实现更好的性能。本文还表明，在错误行后缀代码对于生成更多补丁具有更高的编译率是很重要的。这项研究得出结论，通过增加样本量和整合修复模板信息，可以进一步改善基于LLM的自动程序修复能力。总的来说，这篇论文为使用LLMs进行自动程序修复提供了实用的指导方针，并展示了使用LLMs解决重要的软件工程问题的潜力。

使用大型模型进行自动程序修复（APR）时，修复效果和时间成本之间存在权衡。模型大小越大，生成补丁的效果越好，但是推理所需的时间也越长，导致补丁生成速度较慢。研究表明，随着LLM的大小增加，补丁生成速度急剧放缓。例如，在完整函数生成上，GPT-NeoX生成补丁需要的时间比GPT-Neo 125M长71倍。补丁生成的时间成本也取决于修复设置，完整函数生成所需的时间明显比生成单行或代码块更长。因此，虽然LLMs具有进行错误定位和修复的能力，但对于实际软件系统来说，首先使用传统的错误定位技术定位精确的错误位置，然后利用LLMs进行更有针对性的补丁生成仍然更具成本效益。

4. 如何进一步提高LLM的修复能力

1. 软件的熵：通过LLMs的熵计算可以潜在地帮助区分正确的补丁和可信的补丁。该研究发现，LLMs认为能够正确修复基础错误的正确补丁比其他补丁更自然。此外，正确的补丁通常比可信的补丁更不熵。这表明LLMs的熵度量可以用于补丁正确性检查，从而使正确的补丁与可信的补丁区分开来。这一发现对解决现有补丁正确性检查解决方案面临的数据集过度拟合问题具有影响。通过LLMs的熵计算还可以帮助在更紧迫的时间限制下优先验证较低熵的补丁，从而实现更快速的正确补丁验证。

软件的熵：

软件熵是一种观念，即如果不采取足够的措施来保持与产品设计和已建立的设计原则的一致性，软件在改变时最终会腐烂。常见用法只与经典热力学和统计物理中定义的熵有间接关系。

en.wikipedia.org/wiki/Softwa…

2. 领域特定知识：通过在原始有缺陷的项目上微调/启示 LLM，将项目特定知识纳入其中，以及使用额外的模板来减少 LLM 生成的代码量，并更快地到达正确的修补程度时，将修复特定知识纳入其中。
3. 与传统APR技术结合：LLMs不仅在直接用于程序修复时有效，还可以将它们与更多的领域特定技术（例如简单的修复模板）相结合，以进一步提高它们的性能。
4. 测试：可以利用测试用例结果的反馈，通过使用基于对话的 LLM 等新类型的 LLM，来更正模型的错误并生成更正确的修补程序。
5. 选择最优采样温度对于良好的补丁生成至关重要。
6. 缩放效应是存在的：当增加模型的大小时，正确和可信的补丁数量也会增加。
7. 成功利用代码中错误行之后的代码对于修复错误非常重要。

2. [ICSE] Impact of Code Language Models on Automated Program Repair

Jiang, N., Liu, K., Lutellier, T., & Tan, L. (2023). Impact of Code Language Models on Automated Program Repair. In Proceedings of the ACM / IEEE 45th International Conference on Software Engineering (ICSE’23) .

1. 本文的主要工作

1. 创建了一个新的APR基准测试，名为HumanEval-Java，以进行LLM的修复能力评估；
2. 研究了10个代码语言模型（CLMs）和4种最新的基于深度学习（DL）的APR技术，在4个APR基准测试中进行比较，结果表明即使没有进行微调，CLMs也具有具有竞争力的修复能力，修复的漏洞比最好的DL-based APR技术多72％；
3. 首次对10个CLMs进行APR训练数据的微调实验，结果显示微调可以将CLMs的能力提高31％-1267％，使其修复的漏洞比现有的DL-based APR技术多46％-164％；
4. 研究了有缺陷的代码行的影响，揭示了CLMs不能很好地利用它们来修复漏洞，而经过微调的CLMs则可能过于依赖有缺陷的代码行

2. HumanEval-Java Benchmark

github.com/chao-peng/c…

评估CLMs在APR任务中修复能力的挑战在于，这些CLMs的训练数据可能包含APR基准测试中的错误或修复，因为这些CLMs使用公共代码库，例如某个日期之前的所有GitHub存储库。这会在评估过程中存在数据泄露的风险，因为CLMs可能已经在训练期间看到APR基准测试中的错误或修复。为了解决这个挑战，本文的作者创建了一个新的评估基准测试，名为HumanEval-Java，在训练期间没有被任何评估的CLMs看到。

手动创建的评估基准 HumanEval-Java 解决了在评估 CLM 修复能力时数据泄露问题，通过确保在预训练期间未曾被现有的 CLM 看到。该基准包含164个（单个块）Java漏洞，从简单到复杂漏洞各种不同，并从手动创建的HumanEval数据集转换而来，该数据集是为了解决 CLM 可能已经看到可在网上获取的测试数据集这一威胁而手动创建的。由于 HumanEval-Java 没有包含在 CLM 的预训练数据中，并且主要包含小程序，因此它被认为是比较 CLM 与基于 DL 的 APR 技术的最公平的基准。通过使用这个新的基准，作者确保了评估的公平性，并避免了预训练中基准泄漏的潜在威胁。

3. 实验

1. CLM选取

2. CLM for APR的微调

为了微调代码语言模型（CLMs），除了修复后的代码外，还会提供含有问题的代码作为提示。这样CLMs就可以学习在给定有问题的代码的情况下生成修复后的代码。为了保证微调后的CLMs之间的比较公平，相同的提示被用于所有的CLMs。CLMs被微调用来直接输出已经修复的代码行，与基于深度学习（DL）的自动程序修复（APR）技术的输出相同。微调使用先前工作中共享的APR数据集，该数据集由来自开源GitHub Java项目的提交收集而来。每个单独的修复都被视为一个单独的实例。训练数据集包含129300个实例，验证数据集包含14366个实例，用于微调超参数（例如训练时期的数量）。不同的CLMs使用相同的设置进行微调。使用学习率为1e−5的Adam优化器来更新模型权重。由于在验证数据集上很快收敛，CLMs仅微调了一个APR数据集的训练时期。为了最小化不同模型的差异以进行一致、公平的比较，微调不同模型时设定了固定的随机种子。

3. CLM与传统DL-based修复工具的对比结果

最佳 CLM 能比最佳 DL-based APR 技术多修复 72% 的错误，且无需微调。

4. 将buggy line作为promt的一部分不一定可以提高修复的准确率

5. Fine tuning

总体而言，所有的CLM在微调后修复更多的错误，改善了31%至1267%。因此，与四个基准上的基于DL的APR技术相比，微调后的CLMs始终表现更好。最佳模型InCoder-6B修复的错误数量比最佳基于DL的APR技术多100个（164%）。至于微调的影响，CodeT5模型获得了最大的提升（889%至1,267%），PLBART模型获得了最小的提升（31%）。尽管多任务预训练使得CodeT5模型在微调之前生成的代码质量较差，但它们确实从预训练中学习了通用的编程语言知识，这有助于CodeT5模型从微调中学习到更好的修复能力。对于PLBART模型，一个令人惊讶的结果是，在HumanEval-Java基准测试中，PLBART-large模型在微调后修复的错误数量反而减少了4个，我们在第V-B节中尝试解释此结果。

6. Fine-tuning数据集大小的影响

CodeT5、CodeGen和InCoder模型在微调1万和5万个APR实例后达到了最佳的修复能力，但微调数据过多会导致它们修复的错误数量减少。最佳微调的PLBART模型仍然无法超越预训练的PLBART模型。

CodeT5和InCoder模型表现出最佳的模型大小效率，因此开发更大的CodeT5和InCoder模型比开发其他模型更有前途。PLBART、CodeT5和InCoder模型都比CodeGen模型具有更好的时间效率和内存效率，因此在资源有限的情况下它们是更好的选择。

4. 关于未来研究的讨论

1. Fine-tuning

使用APR训练数据微调CLMs可以提高它们的修复能力，未来的APR技术可以基于CLMs而不是从零开始进行训练。 将语法和结构信息或测试用例执行信息纳入微调中可能进一步提高CLMs的修复能力。

经过微调的CLMs与现有的基于DL的APR技术存在一个共同缺点，即过度依赖有问题的代码行。这可能是由于模型倾向于支持进行小的更改以修复错误，并且训练集中大多数错误的修复都是小的更改。然而，这使得修复需要对有问题的代码行进行较大修改的错误变得更加困难。可能的解决方案包括在微调APR数据集中平衡不同的错误，或专门为需要进行大幅修改的错误开发单独的模型。

预训练和微调更大的CodeT5和InCoder模型是修复更多错误的有前途的方向。

2. Benchmarks

好的基准测试对于评估和比较CLMs至关重要，未来的基准测试开发应避免预训练中的基准测试泄漏问题。

Benchmark应该包含大的、复杂的缺陷数据集。 评估CLMs的大小、时间和内存效率也应包括在未来的全面评估中。

4. SE for LLM

1. [ISSTA] Towards Efficient Fine-tuning of Pre-trained Code Models: An Experimental Study and Beyond

Shi, E., Wang, Y., Zhang, H., Du, L., Han, S., Zhang, D., & Sun, H. (2023). Towards Efficient Fine-tuning of Pre-trained Code Models: An Experimental Study and Beyond. arXiv preprint arXiv:2304.05216.

1. 本文的主要工作

本文的主要工作是对预训练代码模型和其在下游任务上的微调进行实验研究。作者探索了预训练模型中编码的代码属性，并基于发现提出了一种有效的微调方法，该方法通过层冻结（layer freezing）减少了训练时间和参数。作者在五个下游任务上评估了该方法，并将其与传统微调方法进行了比较，结果显示该方法在保持或提高模型性能的同时降低了计算成本。此外，本文还对预训练代码模型在词汇、语法、语义和结构代码属性方面进行了探测，并提出了一种有效的微调方法。

2. 代码模型的下游任务

如上表，本文主要研究以下五种下游任务：

1. 代码搜索：使用自然语言描述，从代码数据集中检索符合语义的代码片段
2. 克隆检测：检测两个代码片段是否功能一致
3. 代码总结：使用自然语言描述给定代码片段
4. 代码生成：基于自然语言描述生成一个完整的函数
5. 代码补全：基于前置代码片段预测下一行代码

3. Probing

Probing是一种研究使用预训练模型的语言属性的技术，该技术通过提取预训练模型的上下文表示，将其作为固定特征，并将其馈送到线性分类器中，只训练它来预测与语言属性相关的探测任务。这种技术已经被广泛应用于NLP领域，以研究预训练语言模型所捕获的语言属性。在软件工程领域，probing技术用于研究预训练编码模型对源代码的认知。

本文首先研究了大模型在代码理解上的probing能力，对预训练代码模型的词法、句法、语义和结构特性进行了探究。关键结论：

1. 对于预训练的分层表示，源代码的词汇、句法和结构属性主要分别由较低、中间和较高层捕捉，而语义属性几乎贯穿整个模型。同时，在微调过程中，较低和中间层捕捉到的基本代码属性仍得以保留。
2. 在预训练和微调模型之间，对于五个下游任务底部九层的表示是相似的。只有在微调过程中顶部两层的表示发生了很大的变化。

4. Fine-tuning

本文提出了精调方法Telly-K，一种通过层冻结的高效微调方法，可以减少训练时间和参数。该方法在五个下游任务上进行了评估，并与传统的微调方法进行了比较，表明在维持类似或更好性能的同时降低了计算成本。

Telly-K在五个下游任务上的表现：

1. 代码搜索

2. 克隆检测和代码总结

3. 代码生成和补全

2. [ICSE] An Empirical Comparison of Pre-Trained Models of Source Code

Niu, C., Li, C., Ng, V., Chen, D., Ge, J., & Luo, B. (2023). An Empirical Comparison of Pre-Trained Models of Source Code. arXiv preprint arXiv:2302.04026.

1. 本文的主要工作

本文的主要工作是对19个预训练代码模型进行系统的比较，并评估它们在13个流行的软件工程任务中的表现。作者使用各种评估指标，包括分类和检索任务的标准评估指标，以及自然语言处理和计算机科学社区开发的产出指标，如困惑度、Levenshtein编辑相似性和BLEU分数。作者提供了关于不同预训练模型在不同软件工程任务上表现的见解，强调现有模型的局限性，并强调需要进一步研究以改善CodePTMs的理解和 advancement。

2. 评测的模型与软件工程任务

上表总结了各个软件工程任务对应的可用于评测的代码模型。术语解释：代码理解（Und）、代码生成（Gen）、代码（C）、自然语言（NL）、预测值（V）。

13个任务分别为：

• 缺陷检测（Defect Detection）：检测代码是否含有缺陷。
• 克隆检测（Clone Detection）：相似代码检测。
• 异常类型(Exception Type)：根据代码片段，判断可能引发哪种异常。
• 代码到代码提取（Code-to-Code Retrieval）：代码片段的提取
• 代码搜索(Code search)：给定自然语言查询，从代码库中检索出相关的代码片段。
• 代码问答(Code question answering)：回答给定自然语言问题所对应的代码解答。
• 代码翻译（Code Translation）：从一个语言翻译到另一个语言
• Bug修复（Bug Fixing）：修复代码中的bug
• 代码补全(Code Completion)：根据输入的代码片段，预测所要生成代码的后续部分。
• 变异生成（Mutant Generation）：变异输入的代码片段
• 断言生成（Assert Generation）：断言语句的生成
• 代码摘要(Code summarization)：根据输入的代码，生成一段简洁的代码摘要。
• 代码生成（Code Generation）：从自然语言描述生成代码片段。

3. 本文的发现

1. 本文通过评测，更新了各个任务的最佳表现模型（SOTA）：

2. 本文详细给出了不同模型的代码理解能力的评分：

代码翻译和断言生成：

缺陷修复、代码补全和变异生成

从自然语言的代码生成

3. [ICSE] Automated Repair of Programs from Large Language Models

Fan, Z., Gao, X., Roychoudhury, A., & Tan, S. H. (2022). Automated Repair of Programs from Large Language Models. arXiv preprint arXiv:2205.10583.

1. 本文的主要工作

本文的主要工作是系统地研究自动化程序修复（APR）技术是否能够修复由大型语言模型（例如Codex）生成的代码的错误解决方案。研究还分析了Codex模型常见的编程错误，例如语法错误和算法相关错误，以及使用程序合成技术解决未定义函数或对函数进行部分化合成功能的潜力。此外，研究还探讨了使用Codex编辑模式作为APR工具的可行性，并建议在引入更灵活的故障定位和将重点转向综合/语义基础方法

1. 大模型生成的代码的Bug类型

大模型生成的代码主要包括语法错误和算法相关错误。语法错误通常是由于生成的代码不完整或调用未定义的变量/函数/类所致，可能需要使用代码补全技术来解决。如果程序使用了未定义的函数，则需要使用程序综合技术来合成函数体以解决编译错误。对于算法相关错误，可能需要使用具有深度理解算法任务描述和程序语义的方法来解决。此外，文章还进一步将大模型自动生成的错误分类，并提供了具体的例子。

2. 使用传统缺陷修复工具修复Codex生成的代码

本文使用TBar和Recoder两种工具来修复Codex生成的有Bug的代码，修复效果如下表：

3. 使用Codex修复Codex生成的代码

本文使用Codex的edit模式，基于如下三种不同的配置来实验Codex的代码修复能力：

1. 只告诉Codex代码中有Bug（Codex-e bug）
2. 告诉Codex去修复哪一行（Codex-e line）
3. 告诉Codex去修复哪一个语句（Codex-e stm）

修复效果：