我正在参加「启航计划」

导语

本文是RLPG（ICML 2023）论文的后续作业，本文经过结合不同的存储库上下文来提高基本的代码模型的补全能力，试验显现，作者经过依据CodeT5-base（220M）的RepoFusion模型完结了与StarCoderBase（15.5B）适当的功能体现。

• 会议：Arxiv 2023
• 链接：arxiv.org/pdf/2306.10…

摘要

大型言语模型在像GitHub Copilot这样的编码助手中取得了很大的成功，可是它们难以了解存储库中的上下文，并因而会发生不精确的代码完结。最近的研讨表明，运用存储库上下文能够很好地处理这个问题。作者提出了一个叫做RepoFusion的结构，以在模型练习中整合相关的存储库上下文。试验表明，运用存储库上下文练习的模型功能显着优于其他较大的代码模型，作者发布了一个包括Java存储库的数据集，并供给了代码和练习好的检查点。

1 简介

现如今大型言语模型（LLMs）在编码助手中变得越来越受欢迎，可是它们往往难以了解代码存储库中的上下文，并因而会发生不精确的代码完结。为了处理这一问题，该论文提出了一个叫做RepoFusion的结构，以在模型练习中整合相关的存储库上下文。试验表明，运用存储库上下文练习的模型功能显着优于其他较大的代码模型。此外，该论文还发布了一个包括Java存储库的数据集，并供给了代码和练习好的检查点。在详细完结方面，论文运用了Fusion-in-Decoder架构来将存储库上下文（Repo Context，RC）组合起来，以生成更精确和上下文感知的代码完结。下图1展现了1个比如，其间补全使命就是依据Surrounding Context来猜测Target Hole。

本文的奉献如下：

• 提出了RepoFusion结构，该结构经过学习组合存储库中相关的上下文提示来协助代码模型进行更好的猜测。
• 经过广泛的试验，RepoFusion（一个220M参数模型）显着优于多个依据下一个令牌猜测方针进行练习的较大模型，例如CodeGen-16B [24]。
• 进行了完全的融化研讨，例如存储库上下文的性质、它们的长度、存储库上下文的数量和其他练习配置。其间一个关键发现是利用存储库内不同来源的信息是RepoFusion有用的关键。
• 创立和发布了Stack-Repo，这是一个包括200个Java存储库的数据集，具有宽松的许可证和近似去重的文件，并添加了三种存储库上下文。资源能够在以下网址找到：huggingface.co/RepoFusion。

2 运用存储库上下文练习

2.1 Fusion-in-decoder (FID)

FiD直接将检索回来的每个document都与question经过encoder分别编码，然后concat在一起输入decoder生成最终的输出。

2.2 存储库上下文

Shrivastava等人（这儿的内容是之前一篇论文的作业www.yuque.com/glamour/xv5… ，主张能够先读一下再来读这篇论文）依据编程言语的语法和语义以及常见编程模式，提出了一组存储库等级的提示提案（Prompt Proposal，PP），利用存储库中跨文件的结构和相关上下文。PP是一个函数，它以方针空白的方位和关联存储库作为输入，并回来称为Prompt Proposal Context（PPC）的字符串作为输出。PPC是经过从特定类别的相关源文件（提示源）中提取特定类型的上下文（提示上下文类型）创立的。之前的作业一共总结了63个提示提案（有关详细信息，请参见Shrivastava等人之前的论文）。本文中，作者依照上下文坐落target hole的相对方位，分为prior PPC（前面方位的）和post PPC（后边方位的）。 存储库等级的PP能够被看作是一个确定性的检索机制，它从存储库中回来相关的代码片段。除了PP，为了了解检索到的存储库上下文的作用，作者还考虑了别的两种机制来检索存储库等级的上下文：(a) BM25：运用依据BM25的相似性将存储库中每个文件的上下文进行评分，(b) RandomNN（也在Shrivastava等人中运用）：从一个随机挑选的存储库块列表中，依据嵌入块与表明空间中嵌入周围上下文的相似性，挑选前k个。

2.3 RepoFusion

RepoFusion的中心思维是练习一个代码模型，使其了解存储库的上下文，然后有助于生成精确的target hole猜测。给定一组检索到的存储库上下文，RepoFusion学习运用FiD方法来组合这些上下文的相关部分。Surrounding Context与每个存储库上下文衔接，然后独立编码（参见图1，底部）。作者将Surrounding Context附加到Repo Context（RC）的结尾。这与原始Fid不同。RepoFusion运用N个长度为l个token的RC（由于PPC有63种，所以需求进行排序决议优先选哪N个来作为RC，下面的战略中评论了这个排序问题）。本文尝试了以下四种战略，依据PPC生成和排序RC（见图2）。

1. Truncated-Ranked (T-Rank)。在这种设定下，每个PPC只切断后得到1个RC；他们的次序按Shrivastava等人之前的作业；
2. Truncated-Random (T-Rand)。与1类似，同样每个PPC只切断后得到1个RC，但次序随机；
3. Not Truncated-Ranked (NT-Rank)。该情况下不丢弃切断数据，而是把他们次序的切割后都作为RC候选，这儿1个PPC或许得到多个RC，次序与1共同；
4. Not Truncated-Prior-Last (NT-Prior-Last)。与NT-Rank相同，只是prior PPC始终按次序放置在结尾。由于解码器依照输入的次序关注存储库上下文的衔接编码表明，因而这种战略有助于我们了解从prior PPC的编码表明持续代码生成的作用，由于它是解码器中最近关注的表明。请注意，依据N的值，或许需求删去某些排名靠前的PPC的部分块，以容纳坐落结尾的prior PPC。

3 试验和成果

3.1-3.2 数据集构建与试验细节

作者从The stack V1.1数据会集挑选了200个Java的存储库，其计算目标如下：

其间对于每个target hole，作者挑选其前面两行和后边两行作为Surrounding Context。并挑选了CodeT5-base作为RepoFusion的根底模型，并首要对比了以下Baseline：

1. CodeT5(FT)：挑选CodeT5-base、-large并运用不同的PPC类型和Context长度进行Fine-tune；
2. BigCode Model：挑选SantaCoder、StarCoderBase这两种运用Fill-in-the-middle(FiM)方式练习的模型进行对比；
3. CodeGen：对比了CodeGen-2Bmulti, CodeGen-6B-multi, and CodeGen-16B-multi。

作者发现预练习的CodeT5模型不能很好地完结Java代码。因而，为了取得RepoFusion练习的根底模型，作者运用512的输入上下文长度，在Java存储库上运用Next Token Prediction方针对CodeT5-base进行微调。对于评价目标，作者采取了与之前作业共同的成功率Success Rate（SR）。

3.3 试验成果

试验成果如表2所示，作者首要强调了以下几点发现：

• Model Size和Context Length的添加能够提高Baseline功能。例如，CodeT5-large比CodeT5-base功能更好。选用4096的Context length比2048功能要好；
• RepoFusion是有用的。RepoFusion在相同的有用上下文长度下逾越了其他更大的模型，即便被约束运用较少的存储库上下文也比其它模型体现更好。当供给额外的存储库上下文时，RepoFusion的功能还有进一步提高。与StarCoderBase模型比较，RepoFusion的成功率仅略低。
• Prompt Proposal很重要。图3右侧阐明在运用T-Rank和NT-Rank时，RepoFusion运用Random-NN、BM25和PPC的SR。成果表明，运用PPC的RC作用最好。
• NT-Prior-Last最有用。图3的左边阐明了四种战略在两个不同的设置中的成功率：N = 32，l = 768和N = 63，l = 512。能够看到，有序的RC，尤其是NT-Prior-Last、NT-Rank和T-Rank比随机排序的RC（T-Rand）体现更好。此外，与T版别比较，NT版别的改进表明，供给来自顶部提示主张的完整上下文的价值，而不是显现更多提示主张的切断上下文。
• 更长的上下文更好。图4的左边制作了成功率随存储库上下文长度l改变的改变。成果表明，跟着每个存储库上下文的巨细添加，功能有所改善。但是，在两种情况下（N = 32，N = 63），跟着l的值添加，功能到达饱和点。

• 运用更多的RC作用更好。为了了解多个存储库上下文的作用，作者评价了模型在不同的N值下的体现。从图4的中部能够看出，当l = 512时，RepoFusion的功能跟着N的添加而添加，最高到达N = 63，而当存储库上下文更长，l = 768时，功能添加最高到达N = 32。在此之后，添加N的值不会再带来进一步的改进。
• 多样的PP对RepoFusion有协助。作者研讨了每个RC数量N对应的平均不同PPC的数量的成功率。请注意，PPC的数量小于N，由于一般一个PPC会发生多个RC。从图4的右侧能够看出，运用许多不同的PPC对于取得更好的RepoFusion功能至关重要。
• 对CodeT5运用Next Token Prediction进行Fine-tune很重要。表4展现了运用预练习的CodeT5-base模型初始化与运用微调版别进行初始化进行练习时，RepoFusion的评价成果。能够看到，运用RC进行练习能够提高依据预练习的CodeT5模型的功能（原始CodeT5功能参见表7）。作者发现，在所有情况下，运用微调的模型进行练习都具有显着的优势。

4 相关作业

Shrivastava等人提出了RLPG，一种依据target hole挑选PP的分类器，并利用所选PP和从前上下文来提示Codex。类似地，RepoCoder经过注入LLM的从前猜测以及检索到的上下文和输入提示中的从前上下文，迭代地细化方针空泛的猜测。在这项作业中，本文借鉴了Shrivastava等人有关在推理过程中利用存储库等级信息的见解，将他们的发现扩展到触及不同代码言语模型（LLMs）的各种配置中，考虑到不同的上下文长度和巨细。此外，本文的结构是运用RC进行练习的，并学习有用地利用从存储库获取的多个相关上下文。

5 评论

RepoFusion跟着存储库上下文数量的添加而呈线性扩展，这或许导致推理时间较慢。生成的代码难以了解或调试，或许存在安全隐患。过度依靠这些模型或许会导致用户忽略代码中的过错或过于自信，引入过错。布置RepoFusion需求仔细考虑，并有或许需求运用优化技术以提高推理速度。虽然RepoFusion在单行代码主动完结方面体现出色，但在其他使命中的功能需求进一步研讨。