导语
- 会议:ICLR 2023在投
- 链接:arxiv.org/abs/2204.05…
1 简介
最近,大型的言语模型在代码生成等相关范畴取得了令人形象深刻的发展。但是,这些left-to-right的自回归式模型不太直接适用于许多普遍存在的代码修改使命,例如修复过错、添加注释或重命名变量。为了解决这个问题,本文提出InCoder模型,该模型经过学习运用一个sential token随机替换一段代码并将它们移动到序列的结尾来填充(这便是本文最中心的立异点,该灵感来源于CM3: A causal masked multimodal model of the Internet.),如图1所示。
在模型推理阶段,可以恣意运用sential token来mask掉一段文本来让模型猜测。一起,该模型也可以在没有sential token的状况下进行简略的生成,所以InCoder将程序组成(经过从左到右生成)和修改(经过填充)使命完结了一致。
本文评价了一系列zero-shot的代码填充使命的功能,如类型猜测、变量重命名、注释生成和完结缺失的代码行。试验发现:运用双向上下文的zero-shot填充在很大程度上优于基于仅从左到右模型的办法,并且在一些使命上取得了与在使命上经过微调的最先进模型适当的功能。 InCoder在现有的从左到右的程序组成使命上也取得了出色的体现,尽管它的练习方针更一般,但它与在相似规模下练习的现有代码言语模型相匹配。
模型在 sites.google.com/view/incode… 上发布。
2 经过Causal Masking的填充和组成
用于代码生成的神经模型要么利用了从左到右(因果)的自回归言语建模方针,要么像BERT那样,运用了掩蔽言语建模方针。这两种办法各有优缺点。因果模型只对所生成的符号左边的上下文设置条件,从而防止填充,但它们可以自回归地生成整个文档。另一方面,遮罩言语模型可以一起运用左右上下文来填充屏蔽区域,但是,它们的练习方针通常仅限于生成文档的15%左右。在本文中,咱们采用了最近提出的因果遮罩方针(causal masking objective),该方针旨在结合因果言语模型和掩蔽言语模型的长处。
2.1 练习
在练习时,首先在每个文档中采样一系列连续token来进行掩码(图1,左上)。为此,需要确定两个数字:
- span的数目;
- 每个span的长度(即隐瞒的token个数)。
关于span的数目,本文从泊松散布中选取span的数量,设置均值为1,并截断值为256,因而通常存在少数的span(约50%的状况为1个span),但散布具有长尾(最多256个span)。
关于span的长度,本文从文档的长度中进行一致采样,假如有span堆叠,则重新采样。
一旦span被采样,每个spankspan_k将被一个特别的sential token <Mask:k><Mask:k>取代。然后将span中的token序列移动到文档的结尾(图1,右上),前置掩码sential token <Mask:k><Mask:k>和一个特别的掩码完毕token <EOS>< EOS >。换句话说,当一个mask token第一次以从左到右的次序出现时,它符号了span被移除的方位;当它第二次出现时,它标志着移动的span文本的开端。然后,咱们最大化概率:
假如对多个span进行采样,则每个span将相似地按次序追加到文档的结尾。与规范的从左到右生成言语建模一样,咱们计算序列自回归的概率,并在除<Mask:k><Mask:k>;之外的一切符号上运用交叉熵损失来练习模型,以便模型在推理过程中不会生成这些token。
2.2 推理
在揣度过程中,模型可以用规范的办法从左到右生成(经过从模型中进行自回归抽样,不运用任何特别符号),也可以在现有文档的恣意方位刺进代码,办法是刺进 <Mask:k><Mask:k> 符号在所需的方位,并在文档的结尾持续生成。为了简便起见,假定咱们只想在单个方位刺进文本,咱们经过从散布中自回归抽样符号,生成一个span来刺进该方位的左右上下文序列
直到<EOS>< EOS >生成或完成使命相关的中止条件。一种更加通用的标明形式是多个mask,那么整个猜测序列将标明为:[A;<Mask:0>;C;<Mask:1>;E;<Mask:2>;<Mask:0>;B;<EOM>;<Mask:1>;D;<EOM>][A; <Mask:0>; C; <Mask:1>; E; <Mask:2>; <Mask:0>; B; < EOM >; <Mask:1>; D; < EOM >],其间区域B和D是需要被填充的。
这里有一个脚注,即在实践中,作者从散布P(⋅∣[Left;<Mask:0>;Right;<Mask:1>;<Mask:0>]P(⋅∣[Left; <Mask:0>; Right; <Mask:1>; <Mask:0>] 中刺进一个<Mask:1><Mask:1>token。假如不刺进<Mask:1><Mask:1>,则会给模型一个隐式的大小提示,即<Mask:0><Mask:0>token应该打开以填充2048令牌上下文窗口的其余部分。相反,刺进一个<Mask:1><Mask:1>token向模型标明在正确的上下文之后省略了文档的一部分。作者发现,运用这一点大大进步了模型猜测。
当应用于代码时,这答应咱们以零方针的办法履行从双向上下文中受益的使命,如图1底部所示,作者展现了四种状况下如何进行推理:
- Type Inference
- Variable Name Prediction
- Docstring Generation
- Multi-Region Infilling
3 练习数据
咱们在一个语料库上练习咱们的模型:
- 具有答应的、非copyleft的、开源答应的公共代码和
- StackOverflow问题、答案和注释。
数据量统计如下:
3.1 代码
代码源
代码数据首要来自于GitHub/GitLab,大约67万个公共非fork存储库,首要包括Python、JavaScript或Jupyter Notebook文件,并具有MIT、Apache 2.0、BSD-2或BSD-3条款答应。
去重
最近的研讨标明,练习中的重复数据删除可以进步模型功能,并降低记忆练习数据的危险。作者也进行了去重操作。
排除练习数据
为了防止数据泄露,作者删除了CodeSearchNet的验证和测验集中包括的一切存储库,因为这些存储库用于为CodeXGLUE中的几个使命构建验证和测验集。
过滤
过滤掉一些过长或过短的文件。
3.2 StackOverflow
语料库的第二个组件由来自StackOverflow的问题、答案和评论组成。The Pile数据集(参阅:/post/718390… )也包括这些问题和答案,但不包括注释。定性地说,作者发现注释,以及InCoder模型具有的填充才能,使其具有一些在言语指导下进行交互式代码修改的才能(如下图11)。
3.3 Metadata
作者还保留了一些文件或许StackOverflow的元数据,例如文件名、拓宽名、来源、StackOverflow的主题、标签等信息。为了答应该元数据在履行模型的从左到右提示时是可选的,作者以50%的概率将每个特点刺进其文档的最初(答应模型学习元数据调理);不然,将其刺进到文档的结尾(答应元数据猜测)。
3.4 Tokenization
为了添加模型所依靠的上下文数量、模型可以生成的文档长度以及练习和推理的功率,作者练习了BPE Tokenizer,答应token跨越空格(不包括换行符)进行扩展,这样常见的代码习惯用法(例如,import numpy as np)在词汇表中标明为单个token。这极大地进步了符号器的功率——相关于GPT-2的字节级BPE符号器和词汇表,将编码练习语料库所需的token总数减少了45%。
4 练习
本文提出的首要模型是InCoder-6.7B,在248张V100上练习了24天。一起,也练习了一个1.3B版别的小模型。
5 填充试验
作者的首要评价试验是不同的编程使命的zero-shot试验。 为了评价InCoder在生成填充时如何从双向上下文中获益,作者比较了三种不同的揣度办法:第2节中描绘的因果掩蔽揣度过程,规范的从左到右生成办法(left-to-right single),以及从左到右生成和重排序办法(left-to-right reranking)。
Left-to-right single
该Baseline底子不运用被mask方位右侧的上下文。它经过对左边上下文进行条件处理,并从模型P(⋅∣left)P(⋅∣left)中自回归采样token,直到达到特定于使命的中止条件(例如,关于注释生成,产生注释完毕分隔符;关于多行填充,将生成指定的行数)。
Left-to-right reranking
该Baseline仅运用左边上下文来给出填充空白的候选语句,但一起运用左边和右侧上下文在这些候选语句中进行挑选。
具体来说,首先为mask区域生成K=10种可能的补全,跨度为1。然后,经过将每个提名人代入空白并对完结的文档进行评分来评价每个提名人。咱们运用完结文档的总日志概率logP([Left;Spank;Right])log P([Left; Span_k; Righ_t]),或许运用完好文档的均匀对数概率。
5.1 Infilling Lines of Code (HumanEval)
作者从HumanEval数据集为完好的代码行创立一个填充试验的基准,从HumanEval数据集构建了两个不同的填充使命,用于单行和多行:
- 单行填充:即隐瞒掉N行内容的某一行,让模型猜测该行内容,共进行N次试验;
- 多行填充:即隐瞒掉若干行内容,让模型猜测多行内容,共进行N(N+1)/2次试验(即CN+12C_{N+1}^2).
猜测成果如下表所示:
一起,作者还比较了被mask掉的部分的右侧的上下文的多少关于试验成果的影响,成果如下图所示:
InCoder办法比L-R baseline有更大的改善,因为右侧有更多的上下文可用(即,当空白区域出现在函数的前期时)。
5.2 Docstring generation (CodeXGLUE)
接下来,作者展现了在CodeXGLUE(参阅:)上的Docstring Generation使命的体现,InCoder模型在Zero-shot的条件下取得了和CodeBERT(参阅:)相似的功能体现。
5.3 Code Cloze (CodeXGLUE)
在完形填空使命上的首要成果如下表所示。运用带有单个符号(包括min/max)作为屏蔽区域的模型比仅运用左边上下文履行得更好,但不如从左到右对整个序列进行评分。屏蔽一个更大的区域(CM填充区域),其履行与对整个序列进行评分适当。填充区域长度和符号化可以影响功能。
5.4 Return Type Prediction
5.5 Variable Name Prediction
6 模型比照
6.1 Comparison to Left-to-Right Generative Models on Code Synthesis
一切模型都是Decoder-only模型,其在HumanEval和MBPP上的试验成果如下表:
可以看到,InCoder模型在HumanEval指标上完成了与CodeGen-Multi大致适当的功能,CodeGen-Multi也是一个用大致相同数量的Python代码练习的∼6B参数模型。
作者还进行了融化试验,比较从本文的练习语料库以及HumanEval和MBPP基准测验中取得的验证集的Python部分的模型功能。试验成果如下表所示:
7 Qualitative Examples
一些试验示例成果如下图:
8 相关作业
略
9 总结
本文证明了在练习生成式代码模型时运用因果掩蔽方针(causal masking objective)可以在许多具有挑战性和有用的代码填充和修改使命中完成强壮的Zero-shot功能。该模型的额定填充才能好像并没有损害其进行规范的从左到右生成的才能:融化试验标明,InCoder模型在规范的从左到右言语到代码组成基准上具有与相似资源模型适当的功能。
展望未来,作者希望经过更多的参数、数据和练习过程,使得模型功能持续进步。此外,微调将使InCoder可以更好地适应自然言语指令和人类目的的其他迹象。最终,本文为未来经过模型微调进行监督填充和修改以及履行迭代解码的作业奠定了根底,其间模型可用于改善自己的输出。