自 Copilot 問(wèn)世以來(lái)，AI 代碼補(bǔ)全工具正變得越來(lái)越普遍。在最近的一篇博客中，谷歌又介紹了他們開(kāi)發(fā)的一種混合代碼補(bǔ)全方法，而且進(jìn)行了規(guī)模上萬(wàn)人的內(nèi)部測(cè)試。測(cè)試結(jié)果顯示，該方法可以將開(kāi)發(fā)人員的編碼效率提升 6%，而且有趣的是，該模型相當(dāng)小，參數(shù)量只有 0.5B。目前，他們 3% 的新代碼都是通過(guò)接受 ML 代碼補(bǔ)全建議生成的。

轉(zhuǎn)自《機(jī)器之心專欄》

日益復(fù)雜的代碼對(duì)軟件工程的生產(chǎn)力提出了關(guān)鍵挑戰(zhàn)。代碼補(bǔ)全是一種基本工具，有助于緩解集成開(kāi)發(fā)環(huán)境（IDE）中的這種復(fù)雜性。
通常，代碼補(bǔ)全建議是借助基于規(guī)則的語(yǔ)義引擎（SE）來(lái)實(shí)現(xiàn)的，這些引擎通?？梢栽L問(wèn)完整的存儲(chǔ)庫(kù)并理解其語(yǔ)義結(jié)構(gòu)。最近的研究表明，大型語(yǔ)言模型（如 Codex 和 PaLM）可以提供更長(zhǎng)更復(fù)雜的代碼建議，這加速了實(shí)用產(chǎn)品（如 Copilot）的出現(xiàn)。然而，由機(jī)器學(xué)習(xí)（ML）支持的代碼補(bǔ)全如何影響開(kāi)發(fā)人員的生產(chǎn)力仍是一個(gè)沒(méi)有明確答案的問(wèn)題。
在最近發(fā)布的一篇博客中，谷歌介紹了他們?nèi)绾螌?ML 和 SE 結(jié)合起來(lái)，開(kāi)發(fā)了一種新的基于 Transformer 的混合語(yǔ)義 ML 代碼補(bǔ)全方法，現(xiàn)在可供谷歌內(nèi)部開(kāi)發(fā)人員使用。
在文中，他們討論了如何將 ML 和 SE 結(jié)合起來(lái)：

• 使用 ML 對(duì) SE 單個(gè) token 建議重新排序；
• 使用 ML 應(yīng)用單行和多行補(bǔ)全并使用 SE 檢查正確性；
• 通過(guò) ML 對(duì)單個(gè) token 語(yǔ)義建議使用單行和多行延續(xù)。

跨越 8 種編程語(yǔ)言，歷時(shí)三個(gè)多月，谷歌將從 10000 多名內(nèi)部開(kāi)發(fā)人員中得到的的混合語(yǔ)義 ML 代碼補(bǔ)全情況與對(duì)照組進(jìn)行了比較，發(fā)現(xiàn)當(dāng)可用單行 ML 補(bǔ)全時(shí)，他們的編碼迭代時(shí)間（構(gòu)建和測(cè)試之間的時(shí)間）減少了 6%，上下文切換（即離開(kāi) IDE）的時(shí)間減少了 7%。這些結(jié)果表明，ML 和 SE 的結(jié)合可以提高開(kāi)發(fā)效率。谷歌表示，目前，他們 3% 的新代碼（以字符為單位）是通過(guò)接受 ML 代碼補(bǔ)全建議生成的。
用于代碼補(bǔ)全的 Transformer
代碼補(bǔ)全的一種常見(jiàn)方法是訓(xùn)練 transformer 模型，該模型使用自注意力機(jī)制進(jìn)行語(yǔ)言理解，以實(shí)現(xiàn)代碼理解和補(bǔ)全預(yù)測(cè)。谷歌處理代碼的方式和語(yǔ)言類似，用子詞 token 和 Sentence Piece 詞匯表表示，并使用在 TPU 上運(yùn)行的編碼器 - **** transformer 模型來(lái)完成補(bǔ)全預(yù)測(cè)。輸入是圍繞光標(biāo)的代碼（約 1000-2000 個(gè) token），輸出是一組可以用來(lái)補(bǔ)全當(dāng)前一行或多行代碼的建議。序列通過(guò)****上的集束搜索（或樹(shù)搜索）來(lái)生成。
在谷歌的 monorepo 上訓(xùn)練期間，研究者掩蔽了一行代碼的其余部分和一些后續(xù)行，以模擬正在積極開(kāi)發(fā)的代碼。他們?cè)?8 種語(yǔ)言（C++、Java、Python、Go、Typescript、Proto、Kotlin 和 Dart）上訓(xùn)練了一個(gè)模型，并觀察到在所有的語(yǔ)言上，模型的性能要么提升，要么相同，這消除了對(duì)專用模型的需要。此外，他們發(fā)現(xiàn)約 0.5B 參數(shù)量的模型可以在低延遲和低資源成本的情況下獲得較高的預(yù)測(cè)準(zhǔn)確率。該模型極大地受益于 monorepo 的質(zhì)量。對(duì)于多行建議，他們迭代地應(yīng)用具有學(xué)習(xí)閾值的單行模型來(lái)決定是否開(kāi)始下一行的補(bǔ)全預(yù)測(cè)。

編碼器 - ****的 transformer 模型用于預(yù)測(cè)代碼行的剩余部分。
使用 ML 重新排列單個(gè) token 建議
當(dāng)用戶在 IDE 中鍵入代碼時(shí)，后端的 ML 模型和 SE 會(huì)以交互方式同時(shí)請(qǐng)求代碼補(bǔ)全。SE 通常僅預(yù)測(cè)單個(gè) token。谷歌使用的 ML 模型預(yù)測(cè)多個(gè) token，直到行尾，但他們只考慮第一個(gè) token 來(lái)匹配 SE 的預(yù)測(cè)。他們確定出同樣包含在 SE 建議中的前三個(gè) ML 建議，并將其排名提升（boost）到首位。然后，重新排序的結(jié)果在 IDE 中顯示為對(duì)用戶的建議。
實(shí)際上，谷歌的 SE 在云端運(yùn)行，提供開(kāi)發(fā)人員熟悉的語(yǔ)言服務(wù)（例如語(yǔ)義補(bǔ)全、診斷等），因此他們將 SE 配置為在與執(zhí)行 ML 推理的 TPU 相同的位置上運(yùn)行。該 SE 基于一個(gè)內(nèi)部庫(kù)，該庫(kù)提供類似編譯器的功能，并且具有低延遲的特點(diǎn)。得益于上述設(shè)計(jì)，請(qǐng)求是并行完成的，ML 通?？梢愿斓靥峁┓?wù)（中值約 40 毫秒），它們不會(huì)給補(bǔ)全增加任何延遲。
谷歌研究者觀察到，在實(shí)際使用中，代碼補(bǔ)全質(zhì)量有了顯著提高。在 28% 的已被接受的建議中，補(bǔ)全結(jié)果是明顯受益于上述 boost 操作的，其排名由于 boost 的存在而更高，只有 0.4% 的已被接受結(jié)果與此規(guī)律相反。此外，研究者發(fā)現(xiàn)，用戶在接受補(bǔ)全建議之前鍵入的字符減少了 10% 以上。
檢查單行 / 多行 ML 補(bǔ)全的語(yǔ)義正確性
在推理時(shí)，ML 模型通常不知道輸入窗口之外的代碼，在訓(xùn)練期間看到的代碼可能會(huì)錯(cuò)過(guò)在動(dòng)態(tài)變化的存儲(chǔ)庫(kù)中補(bǔ)全所需的最近添加的代碼。這導(dǎo)致了 ML 支持的代碼補(bǔ)全應(yīng)用的一個(gè)常見(jiàn)缺點(diǎn)，即模型可能會(huì)建議看起來(lái)正確但不能編譯的代碼。根據(jù)內(nèi)部用戶體驗(yàn)研究，隨著時(shí)間的推移，這個(gè)問(wèn)題可能會(huì)導(dǎo)致用戶信任的降低，同時(shí)降低生產(chǎn)力收益。
谷歌的研究人員使用 SE 在給定的延遲預(yù)算內(nèi)（端到端補(bǔ)全小于 100ms）執(zhí)行快速語(yǔ)義正確性檢查，并使用緩存的抽象語(yǔ)法樹(shù)實(shí)現(xiàn)「完整」的結(jié)構(gòu)理解。典型的語(yǔ)義檢查包括指代消解（即該對(duì)象是否存在）、方法調(diào)用檢查（比如確認(rèn)使用正確數(shù)量的參數(shù)調(diào)用了該方法）和可分配性檢查（以確認(rèn)類型是否符合預(yù)期）。
例如，對(duì)于編碼語(yǔ)言 Go，約 8% 的建議在語(yǔ)義檢查之前包含編譯錯(cuò)誤，但是語(yǔ)義檢查的應(yīng)用過(guò)濾掉了 80% 的不可編譯建議。在加入該功能的前六周內(nèi)，單行補(bǔ)全的接受率提高到了原來(lái)的 1.9 倍，這可能是由于用戶信任度的提高。作為對(duì)照，對(duì)于沒(méi)有添加語(yǔ)義檢查的語(yǔ)言，研究者只看到接受度增加到了原來(lái)的 1.3 倍。

可以訪問(wèn)源代碼的語(yǔ)言服務(wù)器和 ML 后端并置在云端。它們都對(duì) ML 補(bǔ)全建議執(zhí)行語(yǔ)義檢查。
結(jié)果
在 10000 多名谷歌內(nèi)部開(kāi)發(fā)人員在他們的 IDE 中使用補(bǔ)全功能時(shí)，研究人員測(cè)量到的用戶接受率為 25-34%。他們確定，基于 transformer 的混合語(yǔ)義 ML 代碼補(bǔ)全工具補(bǔ)全了超過(guò) 3% 的代碼，同時(shí)將谷歌員工的編碼迭代時(shí)間減少了 6%（在 90% 的置信水平下）。ML 具有推廣到大多數(shù)主要語(yǔ)言和工程師群體中的潛力。

基于 10000 多名谷歌內(nèi)部開(kāi)發(fā)人員得到的單行代碼補(bǔ)全接受結(jié)果。

基于 5000 多名谷歌內(nèi)部開(kāi)發(fā)人員得到的多行代碼補(bǔ)全接受結(jié)果。
在探索 API 時(shí)提供更長(zhǎng)的補(bǔ)全建議
谷歌在博客中表示，他們還將語(yǔ)義補(bǔ)全與整行補(bǔ)全緊密結(jié)合。當(dāng)出現(xiàn)帶有語(yǔ)義單 token 補(bǔ)全的下拉列表時(shí)，他們會(huì)在內(nèi)聯(lián)顯示從 ML 模型返回的單行補(bǔ)全結(jié)果。后者表示作為下拉焦點(diǎn)的項(xiàng)目的延續(xù)。例如，如果用戶查看一個(gè) API 的可能方法，則內(nèi)聯(lián)完整行補(bǔ)全顯示完整方法調(diào)用，其中還包含調(diào)用的所有參數(shù)。

ML 集成的完整行完成繼續(xù)關(guān)注的語(yǔ)義下拉完成。

ML 提出的多行補(bǔ)全建議。
結(jié)論和未來(lái)的工作
在博客中，谷歌的研究人員演示了如何使用基于規(guī)則的語(yǔ)義引擎和大型語(yǔ)言模型的組合來(lái)實(shí)現(xiàn)更好的代碼補(bǔ)全效果，從而顯著提高開(kāi)發(fā)人員的生產(chǎn)效率。
下一步，他們希望通過(guò)在推理時(shí)向 ML 模型提供額外信息來(lái)進(jìn)一步利用 SE。一個(gè)例子是在 ML 和 SE 之間來(lái)回進(jìn)行長(zhǎng)預(yù)測(cè)，其中 SE 迭代檢查正確性，并為 ML 模型提供所有可能的補(bǔ)全。在添加 ML 支持的新功能時(shí)，他們希望注意的不僅僅是「智能」結(jié)果，還要確保對(duì)生產(chǎn)力產(chǎn)生積極影響。
原文鏈接：https://ai.googleblog.com/2022/07/ml-enhanced-code-completion-improves.html