用例和补全流水线
ASAP有3个组成部分：一个LLM，一个可用示例池(标记的输入-输出对，例如，带注释的代码)，以及一个用于从代码中获取事实的静态分析工具。一个配置文件会指定这些组件。
一旦配置完成后，开发人员对函数体Cin(如左图所示)调用ASAP ，并需要一个输出(例如，代码摘要)。 ASAP使用Cin对其样本池进行BM25检索以得到样本候选集e c 1 ec_1ec1，e c 2 ec_2ec2 ……其中，每个e c i ec_ieci 是<i n p u t i input_iinputi ， o u t p u t i output_ioutputi >形式的一对; 在本文的情景下，i n p u t i input_iinputi是函数定义，o u t p u t i output_ioutputi 是函数头注释。BM25选择与给定的 C i n C_{in}Cin 最匹配的i n p u t i input_iinputi 。
ASAP然后对输入 C i n C_{in}Cin 和几个范例输入i n p u t i input_iinputi s应用程序分析，生成分析结果𝑎𝑝𝑖𝑛和几个𝑎𝑝𝑖 s。
我们将每个样本𝑒构建为一个三元组：
其中，每个三元组都为LLM说明了输入源代码input 通过分析结果𝑎𝑝到输出output 之间的关系。
最终的提示为：
ASAP然后用该提示符查询LLM，并返回补全(例如，自然语言摘要)。
默认情况下，ASAP被配置了分析来提取存储库信息、标记标识符、构建DFGs
默认情况下，ASAP被配置了分析来提取存储库信息、标记标识符、构建DFGs。这些分析是独立的，它们的输出分别在提示符中标记。
例如，图2显示了在ASAP构建的提示符中DFG分析的输出。这几个few-shot示例被扩展并插入到提示符中：代码、存储库信息、标记标识符、DFG和所需的(Gold)摘要都包含在每个few-shot中。目标示例仅包含分析结果，并提示LLM生成所需的输出。
在之前使用“chain of thought” 或“step by step”推理的工作中，没有给模型这样的信息，我们只是用一些指令帮助它组织对样本的推理。在这里，我们不是让模型自己进行推理，而是使用一个简单的程序分析工具向外部提供它，因为我们可以从非常有效的分析工具中获得非常精确的信息。每个小样本示例都包含源代码、派生信息和结论(摘要)，从而为模型提供示例性的“思想链”，以便在生成所需的目标摘要时隐式使用。
下图展示了应用于每个样本的方法的整体流程。
三、实验数据集、指标和设置
Dataset
实验使用广泛使用的CodeSearchNet数据集。
CodeSearchNet是通过提取函数前缀文档的第一段来构建的，但受到一些限制(例如:长度)。它是一个仔细去重复的多项目数据集，允许(要求更高的)跨项目测试。
去重复是关键:与去重复数据集相比，机器学习模型中的代码重复可能会欺骗性地大大提高性能指标。
它是CodeXGLUE基准的一部分，该基准包括10个软件工程任务的14个数据集。
许多模型已经在这个数据集上进行了评估。CodeSearchNet包含来自六种不同编程语言(即Java, Python, JavaScript, Ruby, Go, PHP)的数千个示例。
然而，本文没有使用整个测试数据集，使用我们的模型API端点，这将是非常昂贵和缓慢的；相反，我们选择了从每种语言中均匀随机抽取1000个样本。
由于原始数据集是跨项目的，并且我们对其进行了统一采样，因此我们的子样本包含跨项目数据。
此外，对同一项目的数据集进行了子集设置:按创建日期对同一项目数据进行排序，确保只有时间较早的样本被使用。
这是现实的，因为只有较旧的、已经存在的数据可供使用。
Metrics指标
BLEU
BLEU是用于代码摘要生成和提交日志生成的最广泛使用的基于相似性的度量。BLEU计算在生成的候选译文和一个或多个参考译文中出现的𝑛-grams(通常用于𝑛∈[1…4])的比例；这些分数的几何平均值是BLEU，通常归一化为0-100的范围。在句子级粒度上，BLEU倾向于在很少(或没有)较长𝑛-grams的时候过度惩罚，因此，“句子BLEU”被批评与人类判断的相关性很差。
使用各种平滑技术来降低句子BLEU对稀疏𝑛-gram匹配的敏感性，并使其更符合人类质量评估。
本文报告了 两个变体的数据：BLEU-CN，它使用一种拉普拉斯平滑，BLEU-DC，它使用较新的平滑方法。其他提出的指标，如BERTScore、BLEURT、NUBIA，在计算上很昂贵，没有被广泛使用，因此不容易与之前的基准测试工作进行比较。
考虑到所有这些选项，代码摘要生成指标以及独立的提交日志生成指标一直存在争议。在本文中，遵循先前的工作，主要使用BLEU-CN，这便于将本文方法的结果与以前的工作进行比较。
CodeXGLUE基准
CodeXGLUE基准推荐BLEU-CN，并且大多数较新的模型使用该度量。
然而，本文并没有忽视其他措施。除了BLEU-CN和BLEU-DC，还汇报了另外两种测量方法ROUGE-L和METEOR的结果。
在所有的情况下，ASAP都实现了显著的整体改进：观察到除了Go以外的所有编程语言的收益都大于2.0 BLEU(表3)。
文章认为收益大于2.0 BLEU很重要，原因有两个：
首先Roy等人提供了基于人类主题研究的论点，即对于代码摘要生成(我们的中心任务)，获得2.0或更高的BLEU更有可能符合人类对改进的感知。
其次，认为即使是较小的收益也很重要(特别是如果可重复且具有统计意义)，因为这些任务的增量进展积累起来，会产生强大的实际影响，正如数十年来在自然语言翻译方面的工作所证明的那样。
Experimental Setup & Evaluation Criteria实验设置和评价标准
本文的主要模型是OpenAI的code-davici-002。本文使用测试版，通过它的web服务API。
为了平衡计算约束，如速率限制和对性能稳健估计的期望，本文选择每个实验处理使用1000个样本(每种语言一个处理，每个few-shot选择方法，使用ASAP，没使用ASAP等等)。
本文的实验在大多数情况下产生了统计上显著的、可解释的结果。每个1000个样本的测试仍然需要5到8个小时，(假设)随着OpenAI的负载因素而变化。根据OpenAI的建议，我们包括了尝试之间的等待时间。
为了从模型中得到明确的答案，文章发现有必要将所有实验的温度设置为0。
该模型的设计允许大约4Ktokens的窗口。这限制了少量样本的数量。在实验中，作者使用了3 shots。
然而，在每个实验中，多达2%的随机选择的样本，作者没有得到很好的结果，要么是提示符不适合模型的窗口，要么是模型神秘地生成了一个空字符串。
由于3个样本的构造太长，作者自动减少了shot数目。当发出空摘要时，通过增加shot次数来重新解决这个问题。这个简单、可重复、开销适中的过程可以合并到自动生成工具中。
本文评估了在不同的设置和使用不同的度量标准下，对代码摘要生成使用ASAP-enhanced提示符的好处。在对六种语言的研究中，发现了整体表现提高的证据。
然而，对于其他详细的分析，因为OpenAI API的速率限制，主要关注Java和Python。
实验结果
Encoder-decoders & Few-shot Learning
首先是在CodeSearchNet上使用基于IR的few-shot learning的基线结果。
先前的工作报告表明，对于程序修复和代码生成等任务，IR方法可以找到更好的少量提示样本。在表2中，我们观察到代码摘要生成也是如此。
我们注意到，仅仅使用BM25作为少量样本选择机制，Java和Python的BLEU-4得分分别提高了3.00(15.10%)和1.12(5.42%)。
由于BM25已经在之前的文章(尽管用于其他任务)中使用过，因此我们认为本文中基于BM25的代码总结的少量学习只是一个基线(而不是贡献本身)。
Prompt Enhanced Few-shot Learning提示增强的少样本学习
现在重点研究ASAP提示增强的效果。
表3显示了组合所有六种编程语言的所有提示组件后实现的组件方面的改进和总体改进。BLEU的改善范围从1.84(8.12%)到4.58(16.27%)。
在大多数情况下，我们看到超过2.0 BLEU的改进，这是Roy等人注意到的人类感知所需的阈值。
我们还注意到所有三个组件(即，Repository Information、标识符、 DFG数据流图)帮助模型在所有六种语言中获得更好的性能，因为我们将这些组件单独与BM25组合在一起。
然而，对于Ruby来说，最好的组合只包括Repo。信息。在大多数情况下，Repository Information相对于其他组件很有帮助。
为了确定改进的显著性，使用了威尔科克森符号秩检验，发现在所有情况下，本文的最终提示与普通BM25few-shot学习相比，即使在调整了错误发现风险之后，也具有统计学显著性。
Same Project Code Summarization相同的项目代码总结
由于预先存在的特定于项目的人工事实的价值，Few-shot学习对软件工程具有特殊的重要性。
这种本地上下文包括特定于项目的名称(用于标识符、API等)，以及特定于每个项目的编码模式。
这些现象与项目领域的概念、算法和数据密切相关。有经验的开发人员利用先前的项目特定知识，更好更快地理解代码。
当然，这些细节也可以为机器学习模型提供有用的提示。但是，特定于项目的数据可能是有限的，例如在项目的开始阶段。
在few-shot设置下，即使是有限的特定项目数据，LLM利用这些数据的能力也是非常有用的。
为了了解本文提出的快速增强想法是否有助于特定于项目的代码摘要生成，在Ahmed和Devanbu的数据集上评估了ASAP方法。
由于速率限制，将四个Java和Python项目中的每个项目的测试样本数量减少到100个。由于每个项目测试的样本太少，作者将所有样本组合起来执行统计测试。
在处理同一个项目时，必须小心分割数据，以避免从未来的样本(期望的输出可能已经存在)泄漏到过去的样本。
因此，作者根据该数据集中的创建日期对样本进行排序。
在生成数据集之后，作者应用ASAP方法来评估相同项目设置下的性能，还将结果与交叉项目设置下的性能进行了比较，在交叉项目设置中，作者从完整的交叉项目训练集中检索样本。
表4显示了基于项目的代码摘要生成结果。可以看到，对于4个项目，跨项目的few-shot学习产生了最好的表现，而对于其他4个项目，相同项目的few-shot学习是最有效的。
我们注意到Ahmed & Devanbu没有使用IR来选择few-shot样本，并且在同一个项目的few-shot学习中始终获得了更好的结果。IR确实在Java和Python的大样本中找到了相关的例子，故得到了很好的结果。
作者分析了来自8个项目的16对平均BLEU，同时考虑了跨项目和同一项目的情况。在14例(87.5%)情景下，ASAP快速增强的few-shot学习优于普通BM25检索的few-shot学习。
这表明，在各个项目中，ASAP提示增强是有帮助的。ASAP统计上提高了跨项目和同一项目设置中的性能。
ASAP是模型无关的吗？
到目前为止，实验的结果与code-davinci-002模型有关。
故作者还将语义提示增强应用于另外两个模型，text-davinci-003和gpt-3.5-turbo(聊天模型)，实验结果见表6。在Java、Python和PHP的500个样本上，ASAP快速增强的few-shot学习方法将gpt-3.5-turbo模型的性能提高了1.68%至9.13%，将test- davincii -003模型的性能提高了13.08%至18.69%。
Gpt-3.5-turbo在代码摘要生成时的性能比code- davincii -002和text-davincii-003更差。Turbo版本是冗长的，并且生成的注释在风格上不同于开发人员编写的注释，也不同于提示符中的几个示例。更加精细的提示词工程可能会改进turbo模型，使其产生更自然、更简短的注释；这是留给未来的工作。
Text-davinci-003模型显示了最大的性能提升(尽管仍然被code-davinci-002超越)。注意，text-davinci-003是一个补全模型，类似于code-davinci-002。本文的研究结果表明，与聊天模型相比，ASAP对补全模型更有效。作者还进行了威尔科克森符号秩检验，结果的统计显著性(除了java下的gpt-3.5-turbo)表明，ASAP将不仅仅适用于code-davinci-002模型。
ASAP for Completion
- 实验主要关注few-shot下的代码摘要生成
- 作者探讨了zero-shot下ASAP在
代码补全任务上的适用性 - 评估了包含行补全任务的语义事实的价值，模型根据前一行生成下一行
- 统一随机地从CodeSearchNet数据集中收集了9292个Java和6550个Python样本来进行评估
- 为每个样本随机选择一行，并让模型在给定所有前面的行的情况下生成这行
- 在应用ASAP时，在前面的行之前附加了存储库信息和其他语义事实(即标记的标识符，DFG)
- 在生成带标签的标识符和DFG时，作者
只使用了前一行的部分信息，以避免信息从后面的行泄漏到目标行。
与CodeXGLUE基准一致，作者使用两个指标，精确匹配(EM)和编辑相似性(ES)，来衡量模型的性能。
具体来说，作者对EM进行了McNemar测试，并进行了威尔科克森符号秩检验，以评估模型的性能，类似于对代码摘要生成所做的测试。
表5展示实验结果，可以观察到EM的总体增益为5.79%，ES的总体增益为5.11%，突出了合并语义事实的有效性。对于Python，发现只有ES的改进具有统计学意义，而EM没有。
Performance on Other Metrics
除了BLEU-CN，作者还使用其他3个指标来衡量性能：BLEU-DC, ROUGE-L和METEOR。
在表10中，结果显示了ASAP在所有三个指标上的平均收益。作者进行了威尔科克森符号秩检验，发现BLEU-DC和ROUGE-L对所有语言的性能都有显著改善。
然而，在6种语言中的4种语言中没有观察到METEOR的显著差异，尽管在所有6种比较中，采用了ASAP的样本平均值确实有所改善。
值得注意的是，每种语言作者只用了1000个语言样本(由于成本)，所以看到一些没有观察到显著性的情况并不意外。
为了评估ASAP的整体影响，作者将所有语言的数据集合并，并对code- davincic -002模型(6000个样本)进行相同的测试。然后，得到了所有三个指标的统计显著性(p值< 0.01)，这表明ASAP确实有价值。
Ablation Study
消融研究的主要目的是衡量模型的每个方面对最终观察性能的贡献。在实验中，作者删除了增强提示的每个语义成分并观察性能。
可以发现Repo.组件对Java和Python语言下的模型性能贡献最大(表7)。但是，标记的标识符和DFG也很有帮助。当在提示符中组合所有三个组件时，可以获得最佳结果。
两个示例说明
在手动检查结果时，观察到在几个示例中，ASAP增强提示能够恢复对摘要至关重要的新信息。表8显示了两个使用ASAP提示的示例结果。
在第一个示例中，基线模型未能生成术语“element-wise”。但是，本文提出的提示增强版本可以捕捉到这一重要的概念，与基线得分39.0相比，ASAP的BLEU-4得分为74.0。
类似地，在第二个示例中，基线模型没有将函数识别为standalone process，导致BLEU得分较低，为10.0。
然而，本文提出的方法确实将函数确定为一个standalone process，故得到更高的BLEU得分，为33.0。
五、讨论
Does the Model Memorize the Path?
在ASAP的三个要素中，作者发现存储信息对模型的性能影响最大。也许Code-Davinci-002模型在预训练期间就记住了数据中的特定文件路径，当我们提供函数的路径时，也许模型只是回忆其记忆的信息?
为了进一步研究这一怀疑，作者更改了路径表示：接受存储库名称和路径，在“/”处分割tokens，并采用tokens列表的形式呈现给模型。这种方法背后的主要思想是分散原始表示，并向模型呈现预训练期间未遇到的东西。如果模型不是字面上的记忆，它的性能应该不会受到影响。
作者观察到两个版本之间的差异非常小。对于Java，获得了0.24 BLEU，但对于Python，使用标记化的路径导致损失了0.04。这表明模型不太可能记住函数路径。
Is the Identifier Tag Necessary?
在本文中，作者为标识符分配角色，并在提示符中将它们标记为函数名、参数、标识符等。但是这种显式标记真的有助于性能吗?
为了研究这一点疑惑，作者比较了当提供一个普通的、“无标记”的标识符列表时模型的性能。文章观察到，与简单的无标记标识符列表相比，带标记的标识符为Java和Python带来了更好的性能。对于Java和Python，带标记的标识符方法的性能指标BLEU分别增加了0.41和1.22，这表明显式语义信息确实有助于提高模型性能。
What’s Better: More Shots or ASAP?
尽管LLM有数十亿个参数，但它的提示大小有限。例如，code-davinci-002和gpt-3.5-turbo支持仅允许4k标记的提示长度。ASAP增强确实消耗了一些可用的提示长度预算！因此，提出了两种设计选择：1)在提示符中使用更少的ASAP增强样本，或 2)使用更多的无增强的few-shot样本。
为了研究这个问题，作者还尝试在Java和Python语言下的code- davincii -002模型中使用4和5个shots(而不是3个)。然而，表9显示，使用BM25进行更多shots并不一定会带来更好的性能。在较高的采样率下，有可能引入不相关的样本，这可能会损害而不是帮助模型。
只有在Java中，与基线模型相比，观察到4次和5次shot的性能更好。然而，本文提出的技术只有3shot仍然优于使用5shot的BM25。值得注意的是，模型的上下文窗口每天都在增加，即将推出的GPT-4模型将允许我们拥有多达32K个tokens。因此，在不久的将来，长度限制可能不是一个问题。
然而，本文的研究表明，自动语义增强仍然是一种利用可用提示长度预算的有益方法；此外，构建更多信号丰富、信息丰富的提示，无论长度如何都是有益的。
六、威胁与限制
- 使用大型语言模型时的一个主要问题是：在训练期间测试数据可能
暴露。
遗憾的是，由于无法访问训练数据集，因此无法直接检查这一点。
模型在随机shot时的较低表现表明，记忆可能不是主要因素。当向模型纳入相关信息时，模型的性能随着信息的数量和质量而提高。如果模型已经记住了摘要，即使没有相关范例和语义增强带来的好处，它也可以获得更高的分数。 - 样本量分析：作者通过计算发现所需的样本量总是低于在上述实验中使用的样本量，即1000。
- 最后：对LLM进行微调以使用ASAP可能会提升我们的增强提示方法，但训练成本很高。将把微调部分留给未来的研究。
七、总结
- 在本文中，作者探讨了自动语义增强提示（ASAP）的方法，即提出使用通过语义分析自动派生的标记事实，增强LLM提示中的few-shot样本。
该方法基于一种 直觉，即开发人员经常浏览代码，在代码理解过程中隐式地提取这些事实，从而写出一个好的摘要。 - 虽然可以想象LLM可以自己隐式地推断出这些事实，但推测，在提示中以格式化的方式将这些事实添加到示例和目标中，将有助于LLM在寻求构建摘要时组织其“思维链”。
作者采用了一个具有挑战性的，去重的，精心策划的CodeSearchNet数据集，在两个任务（代码摘要生成和代码补全）上评估了这个想法。研究结果表明， ASAP通常是有用的，它有助于超越最先进的技术。
