LLMs are Few-Shot Summarizers: Multi-Intent Comment Generation via In-Contex Learning论文阅读

摘要：

代码注释生成旨在为代码片段生成自然语言描述，以便促进开发人员的程序理解活动。尽管已经研究了很长时间，但现有方法的一个瓶颈是，给定一个代码片段，它们只能生成一个注释，而开发人员通常需要从不同的角度了解信息，比如这个代码片段的功能是什么，如何使用它。为了解决这个限制，本研究从实证角度调查了利用大型语言模型（LLMs）生成可以满足开发人员多样化意图的注释的可行性。我们的直觉基于以下事实：（1）在LLMs的预训练过程中，代码及其成对注释被用来建立自然语言和编程语言之间的语义连接，以及（2）在实际项目中收集用于预训练的注释通常包含不同的开发人员意图。因此，我们假设在预训练之后，LLMs已经可以从不同的角度理解代码。事实上，对两个大规模数据集的实验证明了我们洞察力的合理性：通过采用上下文学习范式并向LLM提供充分的提示（例如，提供十个或更多示例），LLM可以显著优于最先进的监督学习方法，在生成具有多重意图的注释方面。结果还表明，构建提示的定制策略和重新排名结果的后处理策略都可以提升LLM的性能，这为未来利用LLMs实现注释生成的研究方向提供了启示。

Introduction

代码注释生成（又称代码总结）旨在自动生成源代码的简洁流畅的自然语言描述。这被认为是促进程序理解的关键方式，因为开发人员通常会忘记或没有时间编写这样的注释，因此具有提升软件开发和维护活动的潜力。多年来，许多研究致力于推进这一领域的最新技术。例如，早期阶段使用信息检索技术，重点是从代码中提取一些重要的标记，随后一些最新的作品应用了先进的深度学习技术，如神经机器翻译（NMT）模型。

尽管在这一领域取得了巨大的进展，但一个关键问题降低了现有代码注释生成方法的实用性，即它们只能生成描述给定代码片段的一个方面的注释（因此是一对一的映射）。然而，在实践中，开发人员经常以不同的意图编写注释，从不同的角度总结代码（例如，代码的主要功能是什么，我们如何使用它）。例如，Zhai等人[75]手动检查了来自真实项目的注释，并确定了注释中隐藏的六类意图（如表1所示）。Mu等人[47]统计了GitHub上星级最高的Java项目，并发现大约67%的方法的注释中包含多个意图。以上观察结果表明，开发人员真正需要的是一对多的映射（即，从不同角度生成多个注释来总结给定代码），这在本文中称为多意图注释生成任务。

为了解决上述任务，Mu等人提出了一种名为DOME的方法，其中使用注意力机制来针对不同意图集中在代码的不同部分。然而，DOME是基于监督学习的，由于用于训练的数据量有限，这限制了其有效性。为了解决数据短缺问题，我们建议借用大型语言模型（LLMs）的武器，LLMs是在自我监督方式下预先训练的大规模数据语料库，并在此过程中捕获了大量的领域知识。将LLMs应用于多意图注释生成任务的动机有两个因素。首先，专为代码领域设计的LLMs通常使用代码及其相关的成对注释进行预训练，以建立编程语言和自然语言之间的语义连接。例如，常用的预训练任务，遮蔽语言建模，旨在特意对齐编程语言和自然语言表示。其次，现有研究表明，用于LLMs的训练语料库的代码注释通常包含多个意图。因此，在预训练期间，LLMs被训练以从各种角度理解代码，从而潜在地允许它们捕获不同的代码语义。因此，通过充分利用预训练LLMs的能力，我们可以在多意图注释生成任务上取得良好的性能。

最近，上下文学习已被证明是利用LLMs中隐藏的领域知识的有效方法，因为模型的输入格式可以与预训练过程中的格式保持一致。受到这些研究的启发，我们的目标是探究使用上下文学习解决多意图注释生成任务的可行性。通常情况下，上下文学习需要向模型提供一个提示，其中包括描述任务详细信息的自然语言指令，（可选地）展示任务如何完成的少数示例，并要求解决的查询。因此，一个后续的问题是，通过上下文学习，我们如何从LLMs获得更好的结果（例如，通过设计可以引导LLMs朝向期望输出的提示）。为了提供关于上述问题的经验证据，我们在本研究中调查以下几个方面：（a）LLMs是否支持使用上下文学习范式完成多意图注释生成任务？（b）我们是否可以通过设计定制的演示选择策略来提高LLMs的性能？（c）我们是否可以通过设计定制的后处理策略来提高LLMs的性能？

为此，我们对两个大规模的Java语言数据集进行了广泛的实验，它们分别是Funcom [36]和TLC [30]。我们选择OpenAI Codex模型作为代表性LLM，因为它在几个代码智能任务上表现出色。我们的研究得出了以下重要发现：

• F1：当LLM没有得到充分的提示（即演示示例数量少于10）时，LLM的潜力可能没有被充分发挥，其有效性与最先进的监督学习方法DOME相比是次优的；相反，当演示示例数量达到十个时，LLM受到了更充分的提示，其性能超过了DOME方法。

• F2：演示选择策略可以帮助LLM更好地理解正在进行的任务，从而在很大程度上增强其有效性：当示例数量为十个时，并且将与目标代码最相似的代码片段用作演示示例时，与随机选择相比，Codex的BLEU值在两个数据集上分别可以提高97%和131%。

• F3：可以基于简单的启发式方法重新排列LLM的输出以进一步提高性能：与上述实验设置相比，如果可以使用语料库代码中与目标代码相似的注释来指导输出的重新排序，那么Codex的BLEU值在两个数据集上分别可以提高9.9%和9.6%。

我们的研究表明，LLMs在多意图注释生成方面具有潜在的应用价值，因为它在这一任务上建立了强大的性能基线，这应该被未来工具设计者在评估中考虑。进一步的含义包括，设计更好的演示选择策略以及重新排序策略都是有前途的研究方向。

2 BACKGROUND AND RELATED WORKS

2.1 Comment Generation

自动代码注释生成旨在用简洁的自然语言描述总结代码，这是促进程序理解的关键任务。许多方法已被提出来构建一组手动定义的复杂规则，基于这些规则，可以根据特定模板生成注释。随着深度学习的最新进展，一系列研究建议将深度神经网络（DNNs）应用于此任务。通过将代码建模为输入，注释作为输出，这种神经注释生成（NCG）方法可以自动学习一个函数，通常是一个DNN模型，例如神经机器翻译模型，该函数可以根据输入生成输出。这样的DNN模型是使用现有的大规模代码-注释成对数据进行学习的。CodeNN是这个方向的早期尝试，它仅使用代码标记序列，然后是各种利用AST结构、API知识、类型信息、全局上下文、强化学习、多任务学习、双学习、预训练语言模型和混合方法的方法。此外，许多作品还专注于基于过时注释生成最新和有信息量的注释（即注释更新）。

然而，上述方法只能生成描述给定代码片段的一个方面的注释，这限制了它们的实用性，因为开发人员通常在注释代码时表达多个意图。换句话说，仅生成描述代码片段特定方面的注释（例如，代码的功能）可能无法满足开发人员关于全面总结代码的要求（例如，如何使用代码）。具体而言，根据先前的研究，开发人员通常在注释代码时有六种意图，即什么、为什么、如何使用、如何完成、属性和其他。在表1中，我们列出了每个类别的详细定义和示例。开发人员通常在注释中表达多个意图的事实对现有的单一意图注释生成技术的实用性构成了威胁。为了应对这一挑战，Mu等人提出了一种开发人员意图驱动的代码注释生成方法DOME，旨在产生与给定意图一致的注释。它通过利用由给定意图引导的注意力机制来专注于代码中最相关的信息。据我们所知，DOME目前是唯一能够根据不同意图类别生成多样化注释的现有技术。

2.2 Large Language Models

基于大规模未标记数据语料库训练的大型语言模型（LLMs）已经被证明在广泛的任务上表现出色，包括自然语言生成、语义解析和代码生成。它们的强大之处在于它们不需要特定任务的训练数据，并且可以在大量野外数据上进行自我监督方式的预训练（即预训练），以捕获足够的领域知识。这一方向的先驱，GPT模型，最早于2018年提出。此后，许多后续研究通过调整模型架构（例如BERT）或增加参数总量（例如GPT-3）不断提高了最先进的性能。

Codex是由OpenAI发布的基于GPT-3架构的LLM（即包含基于Transformer的解码器）。它驱动着GitHub Copilot，这是一个AI辅助编程工具，可以根据自然语言描述生成完整的代码功能。Codex在一个包含来自多种编程语言（包括Python、JavaScript、C/C++、Go、Perl、PHP、Ruby、Swift、TypeScript、SQL和Shell等）的大量代码-注释成对示例的大型代码语料库上进行训练。与GPT-3类似，Codex在预训练过程中采用自回归方式，即给定一系列代码/注释标记，它被训练以预测下一个标记，并且预测的标记递归地作为下一个预测的输入，直到序列结束。在我们的研究中，我们选择Codex作为代表性的LLM，因为它是软件工程领域中的热门LLM，并且已经在文献中被广泛研究。

2.3 In-Context Learning

以前，要在下游任务中应用预训练模型，用户需要以监督方式（即微调）在下游任务的标记数据上进一步对其进行训练。与从头开始训练模型相比，这种范式可以利用预训练模型学到的知识，从而实现更好的性能。然而，这种范式主要有两个限制。首先，用于预训练和微调的数据格式不同，这使得模型在微调过程中学到的知识无法充分利用。其次，微调过程可能非常耗时和资源密集，特别是对于通常包含数十亿参数的大型语言模型而言。

为了解决上述限制，最近提出了上下文学习，并迅速成为研究热点。这种范式表示，几个训练示例和/或需要回答的开发人员查询一起发送到一个大型语言模型中，以产生对查询的响应，而无需进行任何参数更新。基本上，在上下文学习范式中，需要为代码智能任务提供提示，例如代码总结。通过使用提示，大型语言模型被证明在不需要特定任务数据的情况下，对模型未经显式训练的不同任务具有有效性。

总的来说，上下文学习的基本原理是，由于大型语言模型已经在大规模语料库上进行了训练，它们必须已经吸收了大量的领域知识，并因此预计在没有微调的情况下能够很好地推广到未见过的任务。我们的研究有着类似的动机。具体来说，考虑到（1）大型语言模型，例如Codex，是在一个包含大量来自真实世界的代码-注释成对数据的大规模语料库上进行训练的，以及（2）真实世界的注释通常包含不同类别的开发人员意图，我们假设大型语言模型能够从不同角度理解代码，因此有能力在给定代码片段的情况下生成具有多样化意图的注释。通过使用上下文学习，LLMs的这些潜力可以得到利用。

我们的研究目标是探究使用上下文学习范式的大型语言模型在多意图注释生成上的有效性。为此，我们提出回答以下研究问题。

• 问题1：Codex在使用零次、一次和少次学习进行多意图注释生成的有效性如何？作为第一个研究问题，我们旨在探究使用上下文学习解决多意图注释生成问题的可行性。具体而言，我们不使用任何定制设计，仅随机选择代码演示。我们的目标是探究与最先进的DOME方法相比，原始的上下文学习有多有效。结果还可以反映出演示数量（即零次、一次和少次）对有效性的影响程度。
• 问题2：能否通过基于检索的演示选择方法提高有效性？一些最近的研究表明，提示中演示的质量可以显著影响上下文学习的有效性。受到这些研究的启发，我们提出调查定制的演示选择方法是否能够帮助提高模型的性能。具体而言，为了回答这个问题，我们设计了两种基于检索的方法，选择与开发人员查询中指定的代码相似的代码示例，并评估它们的有效性。
• 问题3：能否通过重新排序策略提高有效性？ 大型语言模型经历了一个抽样过程来获得输出。也就是说，开发人员可以从模型获得相同输入的不同结果。在这个问题中，我们进一步研究了通过后处理方式提升模型性能的可行性：首先获得一些结果，然后通过预定义的启发式方法对其重新排序。回答这样一个问题可以为在实践中应用该方法提供指导：它可以使我们清楚地了解通过抽样多个输出能够获得更加合格的结果的程度。

3 STUDY DESIGN

3.1 Research Questions

• 问题1：Codex在使用零次、一次和少次学习进行多意图注释生成的有效性如何？作为第一个研究问题，我们旨在探究使用上下文学习解决多意图注释生成问题的可行性。具体而言，我们不使用任何定制设计，仅随机选择代码演示。我们的目标是探究与最先进的DOME方法相比，原始的上下文学习有多有效。结果还可以反映出演示数量（即零次、一次和少次）对有效性的影响程度。
• 问题2：使用基于检索的演示选择方法能否提高有效性？一些最近的研究表明，提示中演示的质量可以显著影响上下文学习的有效性。受到这些研究的启发，我们提出调查定制的演示选择方法是否能够帮助提高模型的性能。具体而言，为了回答这个问题，我们设计了两种基于检索的方法，选择与开发人员查询中指定的代码相似的代码示例，并评估它们的有效性。
• 问题3：能否通过重新排序策略提高有效性？大型语言模型经历了一个抽样过程来获得输出。也就是说，开发人员可以从模型获得相同输入的不同结果。在这个问题中，我们进一步研究了通过后处理方式提升模型性能的可行性：首先获得一些结果，然后通过预定义的启发式方法对其重新排序。回答这样一个问题可以为在实践中应用该方法提供指导：它可以使我们清楚地了解通过抽样多个输出能够获得更加合格的结果的程度。

3.2 The Prompt Template for Multi-Intent Comment Generation

正式地，一个提示被定义为 𝑃 = {𝑥_{test} + CD + NL}，其中 NL 是一个自然语言模板，CD = {(𝑥𝑖, 𝑦𝑖)}𝑛 𝑖=1 是由输入代码序列 (𝑥𝑖) 和期望输出序列 (𝑦𝑖) 组成的代码演示集合，而 𝑥test 则是待推断的开发者查询。具体来说，如果 𝑖 = 0，这意味着没有代码演示，那么设置被称为零次学习；如果 𝑖 = 1，这意味着只有一个代码演示，那么设置被称为一次学习；而少次学习意味着有一定数量的代码演示。此外，还有一个约束条件，即 size§ ≤ context-window，这意味着提示应该适合于语言模型的上下文窗口限制内。

图1展示了用于多意图注释生成任务的提示模板。输入提示包含两个部分：代码演示 CD 和查询 𝑥test 。自然语言指令由以特殊标记“#”开头的行表示。在提示的第一行中，我们首先告诉模型正在处理的具体编程语言（例如，Java），然后指定了所需的注释意图，如红色突出显示的定义所示。具体来说，对于“what”意图，我们添加提示“描述方法的功能”；对于“why”意图，我们添加提示“解释方法提供的原因或方法的设计原理”；对于“how-to-use”意图，我们添加提示“描述使用方法的用法或期望的设置”；对于“how-it-is-done”意图，我们添加提示“描述方法的实现细节”；对于“property”意图，我们添加提示“断言方法的属性，包括方法的前置条件或后置条件”。在本示例中，所示的提示旨在生成满足“what”意图的注释。然后，第一行后面跟着一些代码演示，这些演示可以帮助LLM理解所期望的行为，每个演示都包含一个代码片段和一个符合所需意图类别的注释。每个代码演示之间用分隔符“###”分隔。最后，模型被要求输出查询代码的所需注释，显示在图的底部。

3.3 Demonstration Retrieval

请注意，RQ1中使用的代码演示是从一个语料库中随机选择的。而在RQ2中，我们旨在调查定制的演示选择是否可以增强有效性。因此，我们设计了两种策略，从语料库中检索出与所需类别的注释意图相符的相似代码演示示例。其理论基础是，与目标相似的少数演示可能有助于模型更好地理解所需的行为 [45, 48, 60]。 这种范式的整个过程如图2所示：给定一个代码片段和所需的注释意图类别，我们选择与目标相似的代码示例，并使用检索到的代码以及它们的注释构建一个提示，其模板如图1所示。该提示用于查询模型并获取结果。接下来，我们详细介绍这两种检索策略。

• 基于标记的策略：识别相似代码最常用的策略是关注与代码标记的重叠[23, 33, 76]。受这些研究的启发，我们的第一个检索策略也基于标记级别的信息，即根据代码与目标代码的标记相似性对代码库中的代码片段进行排名。具体而言，我们首先通过删除编程语言中定义的关键字（即我们研究中的Java）来预处理目标代码片段和检索到的代码库中的代码片段。背后的直觉是，这些经常使用的标记可能会对相似性计算产生副作用，因为大量的代码片段可能包含它们，受最近一项研究的启发[17]。然后，我们进一步将标识符拆分为子标记，以充分利用标识符名称中隐藏的语义信息[53]。具体而言，这一过程是通过使用Java语言的驼峰命名和下划线命名约定来实现的。最后，我们将所有子标记转换为小写。至于候选代码片段与目标代码之间的基于标记的相似性（𝑠𝑡𝑜𝑘𝑒𝑛），我们利用Jaccard系数[50]进行计算，其定义如下：𝑠token =| tokens target ∩ tokens candidate | / | tokens target ∪ tokens candidate |
  其中𝑡𝑜𝑘𝑒𝑛𝑠𝑡𝑎𝑟𝑔𝑒𝑡表示目标代码的子标记列表，𝑡𝑜𝑘𝑒𝑛𝑠𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑒表示候选代码的子标记列表。𝑠𝑡𝑜𝑘𝑒𝑛的值范围从0到1。较大的𝑠𝑡𝑜𝑘𝑒𝑛值表示目标代码与检索到的候选代码之间的相似性较高。

• 基于语义：最近在克隆检测领域的研究还表明，除了词法级别的代码标记相似性之外，理解代码语义对于找到相似代码也很重要。因此，我们的第二个策略依赖于代码语义来检索相似的代码片段。具体来说，我们利用了预训练的句子转换器模型，该模型已被最近的一项研究证明能够准确捕获代码片段的语义信息，将代码片段编码为包含相应语义信息的向量。利用余弦相似度来检索相似的候选代码片段，这些候选代码片段在向量空间中与目标代码片段的向量接近。

3.4 Reranking Strategy

为了重新排列生成的注释，我们的直觉是相似的代码片段通常具有相似的注释，这在文献中是一个常识。因此，我们的策略是根据它们与检索语料库中与目标代码相似的代码片段的注释的相似性对生成的注释进行重新排列。具体来说，我们使用与目标代码最相似的代码片段的注释作为参考，并从两个角度计算注释的相似性，即基于标记的和基于语义的。对于基于标记的策略，我们关注标记级别的信息，因为注释中的标记通常是具有明确语义的自然语言词语。对于基于语义的策略，我们再次利用预训练的句子转换器模型，将整个注释嵌入到语义向量中，并计算余弦相似度。

3.5 Datasets

在本研究中，我们使用前一项研究[47]发布的多意图注释生成数据集作为我们的评估数据集。具体而言，我们使用两个Java编程语言的数据集，即Funcom [36]和TLC [30]数据集，它们都是代码注释生成任务中最常用的数据集。Funcom包含了来自29K个Java项目的2.1M个代码-注释对，这些数据由Lopes等人[1]收集，并由LeClair等人[36]进一步清理。TLC包含了87,136个代码注释对，这些数据是从2015年到2016年创建的9K多个Java项目中收集的，每个项目至少有20个星。这两个数据集中每个注释的意图类别都是由Mu等人[47]标记的：他们首先邀请了五名领域专家手动标记了8K个代码片段的意图，然后在标记数据上对CodeBERT模型[19]进行了微调，该模型作为分类器。结果显示，微调后的模型可以达到约90%的F1分数，这是一个相对较高的值。最后，作者应用微调后的模型来预测数据集中每个注释的意图类别，并将预测结果用作地面实况标签。由于手动标记如此大规模的数据集是不可行的，我们在本研究中重复使用了他们提供的结果。此外，数据集的训练/验证/测试分区是固定的，这两个数据集的统计数据如表2所示。请注意，在表中，我们没有显示这两个数据集的验证集的统计数据。这是因为我们的方法不需要训练模型。相反，我们只从训练集中检索代码示例（按照Mu等人[47]的方法），并根据测试集评估有效性。因此，验证集在本研究中未被使用。根据现有研究[12, 47]，我们还在评估中排除了其他意图类别的注释，因为这些注释被认为是未指定或模糊的。

3.6 Evaluation Metrics

为了评估Codex模型在代码摘要中的性能，我们利用了常见的度量标准，包括BLEU [51]、ROUGE-L [42]和METEOR [6]。BLEU（双语评估辅助工具）[51]是代码注释生成研究中常用的评估指标，它使用成分n-gram精度分数来衡量一个句子与一组参考句子之间的相似度。ROUGE代表了用于概要评估的召回导向研究[42]。它计算了几个重叠单元的数量，如n-gram、词对和序列。ROUGE有几个不同的变体，我们考虑最流行的一个ROUGE-L [7, 41, 47]，它基于最长公共子序列（LCS）进行计算。METEOR [6]是另一个广泛使用的指标，用于评估生成的代码摘要的质量[29, 47, 65]。METEOR通过将生成的摘要与参考摘要进行对齐，并根据单一匹配计算相似性得分来评估生成的摘要。

3.7 Experiment Settings

在我们的实验中，除了零样本和一样本的设置外，我们选择在少样本设置中使用五个和十个代码示例。由于输入长度受到上下文窗口限制，我们不能使用太多的代码示例。因此，我们决定最多提供十个示例给模型。用于比较的基准是DOME [47]，因为迄今为止它是唯一一个可以解决多意图注释生成任务的方法。为了运行我们的实验，我们使用了最新的Codex模型code-davinci-002。我们将温度设置为默认值0.5，以便从Codex获取明确定义的答案。我们在一台Hygon C86 7385 32核CPU 2.50GHz的机器上运行了所有实验，该机器配备了2TB的RAM。运行的操作系统平台是Ubuntu 18.04。

需要注意的是，RQ1和RQ2的结果都会受到随机性的影响。RQ2受到采样过程的影响，而RQ1受到示例选择的影响。为了解决这个问题，我们重复了每个设置一百次，并在论文中报告了平均值。 因此，RQ1和RQ2的结果可以被视为Codex在特定设置下的预期平均有效性。相比之下，RQ3研究了是否可以通过利用采样结果的多样性来获得更好的结果。为了实现这一点，我们重复了一百次实验，并根据获得的结果应用了我们的重新排名策略。因此，这个RQ的结果可以被视为Codex的最佳可达到有效性。

4 STUDYRESULTS

4.1 RQ1:theEffectivenessofVanillaIn-Context Learning

表3列出了DOME和Codex在多意图注释生成任务上的结果。对于Codex，分别列出了使用0、1、5和10个演示示例的结果。通常情况下，我们观察到随着代码演示数量的增加，上下文学习的有效性会更好。例如，对于“what”意图，当没有使用任何代码演示时，Codex的BLEU值为19.3%，而在使用十个示例时，这个值增加到了34.5%，在Funcom数据集上。这符合我们的预期，因为更多的示例将为模型提供关于正在进行任务的更多指导。与最先进的DOME相比，我们注意到零样本和一样本学习的有效性低于DOME。例如，两个数据集上零样本学习的平均BLEU值分别为21.2%和18.8%，而DOME的对应值分别为31.8%和22.2%。这表明，如果没有足够的代码演示，LLM在多意图注释生成任务上的潜力可能无法充分利用。

发现 1：零样本学习和一样本学习可能无法充分发挥LLM的潜力，其效果与DOME方法相比不尽如人意。**

当代码演示数量增加到五个时，我们观察到Codex的效果与DOME相比具有竞争力：就ROUGE-L和METEOR指标而言，其值高于DOME，而BLEU值略低。一个潜在的原因是BLEU指标过分关注n-gram的重叠。具体而言，它要求严格一致性（即n-gram必须完全相同），这对于尚未经过精调以实现与参考文本完美对齐的模型来说是困难的。相比之下，ROUGE-L和METEOR指标通过专注于最长公共子序列并考虑其他特征（如单词顺序）来放宽了这一要求。然而，当代码演示数量达到十个时，Codex在两个数据集上均始终优于DOME，关于三个指标的平均值分别为Funcom数据集的33.4%/76.1%/24.1%和TLC数据集的27.2%/66.7%/19.2%。这样的表现优于两个数据集上的DOME的状态艺术性能，分别提高了5.0%/79.1%/17.6%和22.5%/81.8%/16.4%。我们还发现不同方法的性能在意图类别之间有所变化：总体上，所有方法在“how-it-is-done”类别上的性能相对较低。这一发现与现有研究的结果一致。

发现-2：当LLM得到充分的提示时，其性能将超过现有的最先进的监督学习方法。例如，当演示数量为十个时，Codex在两个数据集上的平均ROUGE-L值分别为76.1%/66.7%，优于DOME的79.1%/81.8%。

4.2 RQ2:the Effectiveness of Demonstration Selection

不同检索式演示选择策略的结果如表4所示。零次学习设置从此表中排除，因为它不使用任何代码演示。我们观察到，基于标记和语义相似性的演示选择与普通随机选择相比，显著提高了性能。例如，当选择的示例数量为十个时，Codex在Funcom和TLC数据集上的BLEU值分别为33.4%和27.2%；而当示例基于标记（语义）相似性选择时，这些值分别增加到64.5%（65.9%）和60.7%（62.8%），相对改进分别为93%（97%）和123%（131%）。我们还注意到，这种性能改进是普遍的（即，在每个数据集上都可以观察到，无论使用多少个代码示例）。此外，我们注意到，如果提供相似的示例，1次学习的性能甚至比普通的10次学习更好（例如，在Funcom数据集上的BLEU值分别为39.2%和33.4%）。这样的结果表明了上下文学习中演示质量的重要性：如果给定提示与正在进行的任务相似，则可以提高模型的性能。

案例分析。 对于定性分析，我们提供一个案例来展示类似代码如何帮助纠正Codex生成的评论，如图3所示。给定测试代码，其Oracle评论为“Plays previous video in playlist”，Codex在随机选择的情况下生成了一个语义无关的评论“Plays the next song or video”。这个评论是不合适的，因为属性“next”是错误的（Oracle为“previous”），会误导潜在的代码维护者。幸运的是，在使用基于语义的演示选择策略后，Codex生成了一个与Oracle语义相同的评论，即“Plays the previous video in your playlist”。实现的BLEU分数达到了73.1%，这是一个相对较高的性能。通过调查语料库中最语义相似的代码（列在图底部），我们发现Codex成功的一个潜在原因是示例代码表明属性可以来自方法名。具体来说，与语义相似代码的评论是“Play the first item”，“first”是方法名中的一个标记。有了这个例子，Codex生成了正确的属性“previous”，这也可以从方法名中提取出来。

发现-3. 无论是基于标记还是基于语义的演示选择策略都可以极大地提高Codex的有效性。

在比较两种选择策略时，我们发现在所有设置下都没有一种策略能够持续地优于另一种。例如，当使用一次学习时，基于标记的选择的性能平均比基于语义的选择更好；反之亦然，当使用少量学习时（即，示例数为五或十）。此外，即使基于语义的选择在示例数为十时通常表现更好，但在某些情况下，它也可以被基于标记的选择所超越。例如，在“what”意图上，基于标记的选择的BLEU值分别为50.5%和44.8%，超过了基于语义的选择，后者分别为40.4%和40.2%。

发现-4：没有一种演示选择策略能够始终优于其替代方案。其有效性取决于详细的设置（例如，示例数量和意图）。

4.3 RQ3: the Effectiveness of Reranking

由于空间限制，我们在表5中列出了不同重排策略的结果。对于1-shot学习，我们还将不同的重排策略与基于标记的演示选择策略结合起来，因为根据上述部分的结果，该选择策略在1-shot学习上取得了更好的结果。同样，对于10-shot学习，我们将不同的重排策略与基于语义的演示选择策略相结合。

结果显示，两种重排策略都稍微提高了Codex的性能。例如，对于1-shot学习，基于标记的重排策略将Funcom和TLC数据集上的BLEU值从23.1%和21.1%提高到29.1%和26.8%，而基于语义的策略在这两个数据集上进一步实现了30.2%和27.2%。我们还注意到，无论是否使用演示选择，重排都可以提高结果。性能最佳的模型变体，即基于语义的演示选择和基于标记的重排的10-shot学习，在两个数据集上的平均BLEU分数分别为72.4%和68.8%，分别优于现有技术DOME 128%和210%（见表3）。

案例分析。 我们提供另一个案例来展示重排策略如何帮助选择更合格的评论，如图4所示。在这个图中，我们展示了Codex生成的前5个评论。第一个生成的评论在语义上模糊，因为它未能明确解释单词DURABLE_EXPLICIT和DURABLE_IMPLICIT的含义。类似地，第二个生成的评论也可能误导开发人员，因为不清楚Endpoint是什么，而这在源代码中并没有出现。第三和第四个生成的评论表达方式相似，但含义相同，它们都与标准评论在语义上相同。在使用基于标记的相似代码选择之后，一个包含“确定是否…”评论的代码片段被用来帮助重新排列原始结果。由于与参考评论存在大量标记重叠，根据基于标记的重排策略，Codex生成的第四个评论被用作最终结果。与原始的前1个结果相比，BLEU值从23.4%增加到了68.6%。

Finding-5. 基于标记和基于语义的重排策略都可以进一步提升Codex的性能。

在两种重排策略之间的比较中，我们再次观察到没有一种策略能始终胜过另一种。通常情况下，当与演示选择相结合时，基于标记的重排效果更好，而当不采用演示选择时，基于语义的重排效果更好。然而，也存在一些特殊情况。例如，在“what”意图类别中，基于语义的重排与演示选择相结合时表现更好。

Finding-6. 没有一种重排策略能始终胜过其替代方案。

5 DISCUSSION

5.1 Human Evaluation

虽然诸如BLEU、ROUGE-L和METEOR等指标可以评估生成评论与原始评论之间的词汇差异，但它们不足以反映语义差异。因此，为了进一步评估各种方法生成的评论质量，我们进行了人工评估。具体来说，我们招募了六名具有至少五年Java开发经验的参与者。参与者包括三名博士生和三名高级研究人员，他们不是本文的合著者。我们随机选择了100个代码片段（每个意图类别20个）进行此用户研究。对于每个代码片段，我们向参与者展示原始评论和来自四种方法的结果，即DOME、Codex-10-shot、基于语义选择的Codex-10-shot和基于语义选择和基于标记的重新排序的Codex-10-shot，这导致了400个生成的评论作为我们的评估对象。为了确保公平，参与者不知道评论来自何处。每个参与者被要求从三个方面评价所有400条评论：（1）自然度 ，从语法角度反映生成评论的流畅性；（2）充分性，反映生成评论的信息丰富程度；以及 （3）有用性 ，反映生成评论如何帮助开发人员，评分采用5点李克特量表（1表示差，2表示边缘，3表示可接受，4表示良好，5表示优秀）。这样的实验设置遵循现有研究的做法。

我们的用户研究结果列在表6中。我们观察到，较高的指标值导致参与者给出较高的评分。具体来说，在我们的定量评估中表现最佳的模型变体，即基于语义选择和基于标记的重新排序的10-shot学习，也获得了参与者最高的评分（分别为3.8、4.1和4.3）。我们还注意到，大型语言模型擅长生成流畅的自然语言描述，因为所有模型变体在自然度属性方面的得分均高于4。相比之下，生成评论在有用性属性上的得分都低于4，这表明仍有提升生成评论有用性的空间。

5.2 Implications

大型语言模型是few-shot摘要器。我们的实证调查表明，LLM能够生成具有多种意图的高质量代码注释。结果显示，在两个数据集上，表现最佳的模型变体，即基于语义选择和基于标记的重新排序的Codex-10-shot，远远优于现有技术的DOME方法（例如，在Funcom/TLC数据集上，相对于BLEU指标，比DOME分别提高了128%/210%）。这表明，在实践中，开发人员可以参考LLM来帮助他们自动生成具有不同意图的注释。因此，LLM具有促进程序理解活动的巨大潜力。对于研究人员来说，这也表明在评估新提出的代码摘要方法时，与LLM进行比较是必要的。

关于提示质量的重要性。我们的结果表明，提供给LLM的提示质量可以显著影响生成的结果。具体来说，为LLM提供与目标代码相似的示例可能有助于它们生成更加合格的结果。这需要更多关注示范选择过程。然而，就选择策略而言，我们的结果也表明并没有一种万能的解决方案：基于标记的相似代码选择和基于语义的选择互补。这意味着可以将更多的研究工作投入到设计更好的选择策略中。

更多尝试，更多收获。 由于采样过程，LLM可以针对特定输入生成多个结果。我们的结果（例如，图4中的案例）显示，有时可能不会在第一时间生成与预期相似的注释。因此，在实践中，如果开发人员觉得生成的注释不够好，他们可能会多次查询LLM。对于研究人员来说，如何自动重新排列LLM的结果也值得更深入地探讨，我们通过两个简单的启发式方法的初步尝试取得了令人满意的结果。

5.3 Threats to Validity

内部有效性。 Codex是在开源项目上进行训练的，因此可能存在数据泄漏，即Codex在预训练过程中可能已经看到了测试用例的注释。然而，我们观察到Codex在零-shot设置下表现不佳，这表明模型的输出并不是由于记忆而生成的。这样的威胁也面临着其他大型语言模型研究 [48]，要完全解决这个威胁需要从头开始重新训练模型，考虑到计算资源的限制，目前这是不可行的。
如前所介绍的，我们的结果受到模型采样过程或演示选择造成的随机性的影响。为了减轻这种威胁并将实验的时间成本保持在合理的范围内，我们将每个实验重复一百次。然而，一百次可能无法完全消除随机性，我们将更多的实验留作未来的工作。

外部有效性。 将我们的观察应用于实践的第一个威胁是不清楚开发人员是否能够找到与目标代码类似的代码片段，以构建更好的提示给LLM。然而，我们的结果还表明，在10-shot设置下，即使演示是随机选择的，Codex的性能也超过了最先进的DOME。另一个威胁是我们只关注Java编程语言。这一设置受限于文献中多意图评论数据集的可用性。考虑到这两个数据集都是大规模的，而且Java是评论生成领域中研究最广泛的语言 [28, 36, 47]，这个威胁得到了缓解。

6、Conclusion

我们的实证研究主要探讨了利用LLMs来解决多意图评论生成是否可行，以及如何提高LLMs在这一任务上的效果。我们的结果肯定了第一个观点：通过利用少量样本的上下文学习，Codex的性能超过了最先进的监督学习方法。我们还证明了演示选择和结果重新排序都可以帮助提升Codex的性能。我们的研究为多意图评论生成任务建立了新的基线，并指出了值得进行更深入研究的研究方向。