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