谷歌提出最新的基于规则和机器学习混合的代码补全方法

日益复杂的代码对软件工程的生产率提出了关键挑战。代码补全是一种重要工具，有助于缓解集成开发环境（IDE）中的这种复杂性。通常，代码完成建议使用基于规则的语义引擎（semantic engines，SE）实现，这些引擎通常可以访问完整的存储库并理解其语义结构。最近的研究表明，大型语言模型（例如Codex和PaLM）可以实现更长更复杂的代码建议，因此，出现了有用的产品（例如Copilot）。然而，由机器学习（ML）支持的代码补全如何影响开发人员的生产力，而不仅仅是感知的生产力和可接受的建议，这个问题仍然悬而未决。

今天，我们将介绍如何将ML和SE结合起来，开发一种新的基于Transformer的混合语义ML代码补全，现在可供内部谷歌开发人员使用。我们讨论了如何通过（1）使用ML对SE单标记建议重新排序，（2）使用ML应用单行和多行补全并使用SE检查正确性，或（3）使用单标记语义建议的ML的单行和多行延拓来组合ML和SE。我们将10k以上的Googler的混合语义ML代码完成情况（跨越八种编程语言超过三个月）与对照组进行比较，发现当暴露于单行ML完成时，编码迭代时间（构建和测试之间的时间）减少了6%，上下文切换（即离开IDE）减少了7%。这些结果表明，ML和SE的结合可以提高开发效率。目前，3%的新代码（以字符为单位）是通过接受ML完成建议生成的。

#### 补全transformers

代码补全的一种常见方法是训练transformer模型，该模型使用自注意力机制进行语言理解，以实现代码理解和完成预测。我们处理类似于语言的代码，用子词标记和句子段词汇表表示，并使用TPU上运行的编码器-解码器-转换器模型进行完成预测。输入是围绕光标的代码（约1000-2000个令牌），输出是一组完成当前或多行的建议。序列是通过解码器上的波束搜索（或树探索）生成的。

在谷歌monorepo的训练期间，我们屏蔽了一行的其余部分和一些后续行，以模拟正在积极开发的代码。我们在八种语言（C++、Java、Python、Go、Typescript、Proto、Kotlin和Dart）上训练单个模型，并观察到所有语言的性能都得到了改善或相同，从而消除了对专用模型的需要。此外，我们发现，约0.5B参数的模型大小可以在低延迟和资源成本的情况下很好地权衡高预测精度。该模型极大地受益于单一回购协议的质量，这是由指导方针和审查强制执行的。对于多行建议，我们迭代应用具有学习阈值的单行模型来决定是否开始预测下一行的完成情况。

<center>![](https://www.datalearner.com/resources/blog_images/482da54a-a5f8-4f22-831a-556e426f370a.jpeg)</center>
<center>*编码器-解码器-变压器模型用于预测代码行的剩余部分*</center>

#### 使用ML对单个令牌建议重新排序

当用户在IDE中键入代码时，会在后端同时从ML模型和SE交互请求代码完成。SE通常仅预测单个令牌。我们使用的ML模型预测多个令牌，直到行尾，但我们只考虑第一个令牌来匹配SE的预测。我们确定了前三个ML建议，它们也包含在SE建议中，并将其排名提升到首位。然后，重新排序的结果在IDE中显示为对用户的建议。

实际上，我们的SE在云中运行，提供开发人员熟悉的语言服务（例如语义完成、诊断等），因此我们将SE配置为在与执行ML推理的TPU相同的位置上运行。SEs基于一个内部库，该库提供了低延迟的类似编译器的功能。由于设计设置，请求是并行完成的，ML通常更快地提供服务（中位数约40毫秒），我们不会给完成增加任何延迟。我们观察到，在实际使用中，质量有了显著提高。对于28%的已接受完井，由于提升，完井排名更高，在0.4%的情况下更差。此外，我们发现用户在接受完成建议之前键入的字符减少了10%。

#### 检查单行/多行ML补全的语义正确性

在推理时，ML模型通常不知道输入窗口之外的代码，在训练期间看到的代码可能会错过在动态变化的存储库中完成所需的最近添加的代码。这导致了ML支持的代码完成的一个常见缺点，即模型可能会建议看起来正确但不编译的代码。根据内部用户体验研究，随着时间的推移，这个问题可能会导致用户信任的侵蚀，同时降低生产力收益。

我们使用SE在给定的延迟预算内（端到端完成小于100ms）执行快速语义正确性检查，并使用缓存的抽象语法树实现“完整”的结构理解。典型的语义检查包括引用解析（即，该对象是否存在）、方法调用检查（例如，确认使用正确数量的参数调用了该方法）和可分配性检查（以确认类型是否符合预期）。

例如，对于编码语言Go，大约8%的建议在语义检查之前包含编译错误。然而，语义检查的应用过滤掉了80%的不可编译建议。在加入该功能的前六周内，单线完工的接受率提高了1.9倍，这可能是由于用户信任度的提高。作为比较，对于没有添加语义检查的语言，我们只看到接受度增加了1.3倍。

<center>![](https://www.datalearner.com/resources/blog_images/88c1ebb3-5780-419c-a532-b06645a24e4e.jpg)</center>
<center>可以访问源代码的语言服务器和ML后端并置在云上。它们都对ML完成建议执行语义检查。</center>

#### 实验结果

有一万多名谷歌内部开发者在他们的IDE中使用完成设置，我们测量到用户接受率为25-34%。我们确定，基于transformer的混合语义ML代码完成超过3%的代码，同时将Googler的编码迭代时间减少了6%（在90%置信水平下）。这种转变的规模对应于观察到的转换特征（例如关键框架）的典型效应，这些特征通常只影响一个子群体，而ML有可能推广到大多数主要语言和工程师。

- ML添加的所有代码的分数2.6%

- 编码迭代持续时间减少6%

- 上下文切换数量减少7%

- 接受率（对于大于750ms的可见建议）25%

- 每个accept的平均字符数21

上面是对于在八种语言的日常开发中使用它的10k以上谷歌内部开发人员，在生产中衡量单行代码完成的关键指标。

- ML添加的所有代码的分数（建议中大于1行）0.6%

- 每次接受的平均字符数73

- 接受率（对于大于750ms的可见建议）34%

上面是5k以上的谷歌内部开发人员在日常开发中跨八种语言使用它，在生产中衡量多行代码完成的关键指标。

#### 在探索API的同时提供长代码补全

我们还将语义补全与整行补全紧密结合在一起。当出现带有语义单令牌完成的下拉列表时，我们内联显示从ML模型返回的单行完成。后者表示作为下拉列表焦点的项目的延续。例如，如果用户查看API的可能方法，则内联完整行完成显示完整方法调用，其中还包含调用的所有参数。

<center>![](https://www.datalearner.com/resources/blog_images/72e19810-e8e4-4b90-9d78-1bb180c56b5c.gif)</center>
<center></center>

ML集成了完整的行补全，继续关注语义下拉补全。

<center>![](https://www.datalearner.com/resources/blog_images/457f6187-d9fb-4433-aae8-43fdd8495801.png)</center>
<center>ML的多行建议</center>

#### 结论和未来工作

我们演示了如何使用基于规则的语义引擎和大型语言模型的组合来显著提高开发人员的生产率，并实现更好的代码完成。下一步，我们希望通过在推理时向ML模型提供额外信息来进一步利用SE。一个例子是在ML和SE之间来回进行长预测，SE迭代检查正确性，并提供ML模型的所有可能延续。在添加ML支持的新功能时，我们希望注意的不仅仅是“智能”结果，还要确保对生产力产生积极影响。

#### 致谢

这项研究是Google Core和Google research Brain团队两年合作的成果。特别感谢Marc Rasi、Yurun Shen、Vlad Pchelin、Charles Sutton、Varun Godbole、Jacob Austin、Danny Tarlow、Benjamin Lee、Satish Chandra、Ksenia Korovina、Stanislav Pyatykh、Cristopher Claeys、Petros Manitis、Evgeny Gryaznov、Pavel Sychev、Chris Gorgolewski、Kristof Molnar、Alberto Elizondo、Ambar Murillo、Dominik Schulz、David Tattersall、Rishabh Singh、Manzil Zaheer、Ted Ying、，Juanjo Carin、Alexander Fromemgen、Maxim Kachurovskiy和Marcus Revaj感谢他们的贡献。

谷歌提出最新的基于规则和机器学习混合的代码补全方法

相关博客

最热博客