自 Copilot 问世以来，AI 代码补全工具正变得越来越普遍。在最近的一篇博客中，谷歌又介绍了他们开发的一种混合代码补全方法，而且进行了规模上万人的内部测试。测试结果显示，该方法可以将开发人员的编码效率提升 6%，而且有趣的是，该模型相当小，参数量只有 0.5B。目前，他们 3% 的新代码都是通过接受 ML 代码补全建议生成的。
日益复杂的代码对软件工程的生产力提出了关键挑战。代码补全是一种基本工具，有助于缓解集成开发环境（IDE）中的这种复杂性。
通常，代码补全建议是借助基于规则的语义引擎（SE）来实现的，这些引擎通常可以访问完整的存储库并理解其语义结构。最近的研究表明，大型语言模型（如 Codex 和 PaLM）可以提供更长更复杂的代码建议，这加速了实用产品（如 Copilot）的出现。然而，由机器学习（ML）支持的代码补全如何影响开发人员的生产力仍是一个没有明确答案的问题。
在最近发布的一篇博客中，谷歌介绍了他们如何将 ML 和 SE 结合起来，开发了一种新的基于 Transformer 的混合语义 ML 代码补全方法，现在可供谷歌内部开发人员使用。
在文中，他们讨论了如何将 ML 和 SE 结合起来：
- 使用 ML 对 SE 单个 token 建议重新排序；
- 使用 ML 应用单行和多行补全并使用 SE 检查正确性；
- 通过 ML 对单个 token 语义建议使用单行和多行延续。
跨越 8 种编程语言，历时三个多月，谷歌将从 10000 多名内部开发人员中得到的的混合语义 ML 代码补全情况与对照组进行了比较，发现当可用单行 ML 补全时，他们的编码迭代时间（构建和测试之间的时间）减少了 6%，上下文切换（即离开 IDE）的时间减少了 7%。这些结果表明，ML 和 SE 的结合可以提高开发效率。谷歌表示，目前，他们 3% 的新代码（以字符为单位）是通过接受 ML 代码补全建议生成的。
用于代码补全的 Transformer
代码补全的一种常见方法是训练 transformer 模型，该模型使用自注意力机制进行语言理解，以实现代码理解和补全预测。谷歌处理代码的方式和语言类似，用子词 token 和 Sentence Piece 词汇表表示，并使用在 TPU 上运行的编码器 - 解码器 transformer 模型来完成补全预测。输入是围绕光标的代码（约 1000-2000 个 token），输出是一组可以用来补全当前一行或多行代码的建议。序列通过解码器上的集束搜索（或树搜索）来生成。
在谷歌的 monorepo 上训练期间，研究者掩蔽了一行代码的其余部分和一些后续行，以模拟正在积极开发的代码。他们在 8 种语言（C++、Java、Python、Go、Typescript、Proto、Kotlin 和 Dart）上训练了一个模型，并观察到在所有的语言上，模型的性能要么提升，要么相同，这消除了对专用模型的需要。此外，他们发现约 0.5B 参数量的模型可以在低延迟和低资源成本的情况下获得较高的预测准确率。该模型极大地受益于 monorepo 的质量。对于多行建议，他们迭代地应用具有学习阈值的单行模型来决定是否开始下一行的补全预测。
编码器 - 解码器的 transformer 模型用于预测代码行的剩余部分。
使用 ML 重新排列单个 token 建议
当用户在 IDE 中键入代码时，后端的 ML 模型和 SE 会以交互方式同时请求代码补全。SE 通常仅预测单个 token。谷歌使用的 ML 模型预测多个 token，直到行尾，但他们只考虑第一个 token 来匹配 SE 的预测。他们确定出同样包含在 SE 建议中的前三个 ML 建议，并将其排名提升（boost）到首位。然后，重新排序的结果在 IDE 中显示为对用户的建议。
实际上，谷歌的 SE 在云端运行，提供开发人员熟悉的语言服务（例如语义补全、诊断等），因此他们将 SE 配置为在与执行 ML 推理的 TPU 相同的位置上运行。该 SE 基于一个内部库，该库提供类似编译器的功能，并且具有低延迟的特点。得益于上述设计，请求是并行完成的，ML 通常可以更快地提供服务（中值约 40 毫秒），它们不会给补全增加任何延迟。谷歌研究者观察到，在实际使用中，代码补全质量有了显著提高。在 28% 的已被接受的建议中，补全结果是明显受益于上述 boost 操作的，其排名由于 boost 的存在而更高，只有 0.4% 的已被接受结果与此规律相反。此外，研究者发现，用户在接受补全建议之前键入的字符减少了 10% 以上。
检查单行 / 多行 ML 补全的语义正确性
在推理时，ML 模型通常不知道输入窗口之外的代码，在训练期间看到的代码可能会错过在动态变化的存储库中补全所需的最近添加的代码。这导致了 ML 支持的代码补全应用的一个常见缺点，即模型可能会建议看起来正确但不能编译的代码。根据内部用户体验研究，随着时间的推移，这个问题可能会导致用户信任的降低，同时降低生产力收益。
谷歌的研究人员使用 SE 在给定的延迟预算内（端到端补全小于 100ms）执行快速语义正确性检查，并使用缓存的抽象语法树实现「完整」的结构理解。典型的语义检查包括指代消解（即该对象是否存在）、方法调用检查（比如确认使用正确数量的参数调用了该方法）和可分配性检查（以确认类型是否符合预期）。
例如，对于编码语言 Go，约 8% 的建议在语义检查之前包含编译错误，但是语义检查的应用过滤掉了 80% 的不可编译建议。在加入该功能的前六周内，单行补全的接受率提高到了原来的 1.9 倍，这可能是由于用户信任度的提高。作为对照，对于没有添加语义检查的语言，研究者只看到接受度增加到了原来的 1.3 倍。
可以访问源代码的语言服务器和 ML 后端并置在云端。它们都对 ML 补全建议执行语义检查。
结果
在 10000 多名谷歌内部开发人员在他们的 IDE 中使用补全功能时，研究人员测量到的用户接受率为 25-34%。他们确定，基于 transformer 的混合语义 ML 代码补全工具补全了超过 3% 的代码，同时将谷歌员工的编码迭代时间减少了 6%（在 90% 的置信水平下）。ML 具有推广到大多数主要语言和工程师群体中的潜力。
基于 10000 多名谷歌内部开发人员得到的单行代码补全接受结果。
基于 5000 多名谷歌内部开发人员得到的多行代码补全接受结果。
在探索 API 时提供更长的补全建议
谷歌在博客中表示，他们还将语义补全与整行补全紧密结合。当出现带有语义单 token 补全的下拉列表时，他们会在内联显示从 ML 模型返回的单行补全结果。后者表示作为下拉焦点的项目的延续。例如，如果用户查看一个 API 的可能方法，则内联完整行补全显示完整方法调用，其中还包含调用的所有参数。
ML 集成的完整行完成继续关注的语义下拉完成。
ML 提出的多行补全建议。
结论和未来的工作
在博客中，谷歌的研究人员演示了如何使用基于规则的语义引擎和大型语言模型的组合来实现更好的代码补全效果，从而显著提高开发人员的生产效率。下一步，他们希望通过在推理时向 ML 模型提供额外信息来进一步利用 SE。一个例子是在 ML 和 SE 之间来回进行长预测，其中 SE 迭代检查正确性，并为 ML 模型提供所有可能的补全。在添加 ML 支持的新功能时，他们希望注意的不仅仅是「智能」结果，还要确保对生产力产生积极影响。
