參數(shù)量僅0.5B，谷歌代碼補全新方法將內(nèi)部生產(chǎn)效率提升6%
自 Copilot 問世以來，AI 代碼補全工具正變得越來越普遍。在最近的一篇博客中，谷歌又介紹了他們開發(fā)的一種混合代碼補全方法，而且進行了規(guī)模上萬人的內(nèi)部測試。測試結(jié)果顯示，該方法可以將開發(fā)人員的編碼效率提升 6%，而且有趣的是，該模型相當小，參數(shù)量只有 0.5B。目前，他們 3% 的新代碼都是通過接受 ML 代碼補全建議生成的。
日益復雜的代碼對軟件工程的生產(chǎn)力提出了關(guān)鍵挑戰(zhàn)。代碼補全是一種基本工具，有助于緩解集成開發(fā)環(huán)境（IDE）中的這種復雜性。
通常，代碼補全建議是借助基于規(guī)則的語義引擎（SE）來實現(xiàn)的，這些引擎通?？梢栽L問完整的存儲庫并理解其語義結(jié)構(gòu)。最近的研究表明，大型語言模型（如 Codex 和 PaLM）可以提供更長更復雜的代碼建議，這加速了實用產(chǎn)品（如 Copilot）的出現(xiàn)。然而，由機器學習（ML）支持的代碼補全如何影響開發(fā)人員的生產(chǎn)力仍是一個沒有明確答案的問題。
在最近發(fā)布的一篇博客中，谷歌介紹了他們?nèi)绾螌?ML 和 SE 結(jié)合起來，開發(fā)了一種新的基于 Transformer 的混合語義 ML 代碼補全方法，現(xiàn)在可供谷歌內(nèi)部開發(fā)人員使用。
在文中，他們討論了如何將 ML 和 SE 結(jié)合起來：
- 使用 ML 對 SE 單個 token 建議重新排序；
- 使用 ML 應用單行和多行補全并使用 SE 檢查正確性；
- 通過 ML 對單個 token 語義建議使用單行和多行延續(xù)。
跨越 8 種編程語言，歷時三個多月，谷歌將從 10000 多名內(nèi)部開發(fā)人員中得到的的混合語義 ML 代碼補全情況與對照組進行了比較，發(fā)現(xiàn)當可用單行 ML 補全時，他們的編碼迭代時間（構(gòu)建和測試之間的時間）減少了 6%，上下文切換（即離開 IDE）的時間減少了 7%。這些結(jié)果表明，ML 和 SE 的結(jié)合可以提高開發(fā)效率。谷歌表示，目前，他們 3% 的新代碼（以字符為單位）是通過接受 ML 代碼補全建議生成的。
用于代碼補全的 Transformer
代碼補全的一種常見方法是訓練 transformer 模型，該模型使用自注意力機制進行語言理解，以實現(xiàn)代碼理解和補全預測。谷歌處理代碼的方式和語言類似，用子詞 token 和 Sentence Piece 詞匯表表示，并使用在 TPU 上運行的編碼器 - 解碼器 transformer 模型來完成補全預測。輸入是圍繞光標的代碼（約 1000-2000 個 token），輸出是一組可以用來補全當前一行或多行代碼的建議。序列通過解碼器上的集束搜索（或樹搜索）來生成。
在谷歌的 monorepo 上訓練期間，研究者掩蔽了一行代碼的其余部分和一些后續(xù)行，以模擬正在積極開發(fā)的代碼。他們在 8 種語言（C++、Java、Python、Go、Typescript、Proto、Kotlin 和 Dart）上訓練了一個模型，并觀察到在所有的語言上，模型的性能要么提升，要么相同，這消除了對專用模型的需要。此外，他們發(fā)現(xiàn)約 0.5B 參數(shù)量的模型可以在低延遲和低資源成本的情況下獲得較高的預測準確率。該模型極大地受益于 monorepo 的質(zhì)量。對于多行建議，他們迭代地應用具有學習閾值的單行模型來決定是否開始下一行的補全預測。
編碼器 - 解碼器的 transformer 模型用于預測代碼行的剩余部分。
使用 ML 重新排列單個 token 建議
當用戶在 IDE 中鍵入代碼時，后端的 ML 模型和 SE 會以交互方式同時請求代碼補全。SE 通常僅預測單個 token。谷歌使用的 ML 模型預測多個 token，直到行尾，但他們只考慮第一個 token 來匹配 SE 的預測。他們確定出同樣包含在 SE 建議中的前三個 ML 建議，并將其排名提升（boost）到首位。然后，重新排序的結(jié)果在 IDE 中顯示為對用戶的建議。
實際上，谷歌的 SE 在云端運行，提供開發(fā)人員熟悉的語言服務（例如語義補全、診斷等），因此他們將 SE 配置為在與執(zhí)行 ML 推理的 TPU 相同的位置上運行。該 SE 基于一個內(nèi)部庫，該庫提供類似編譯器的功能，并且具有低延遲的特點。得益于上述設(shè)計，請求是并行完成的，ML 通?？梢愿斓靥峁┓眨ㄖ兄导s 40 毫秒），它們不會給補全增加任何延遲。谷歌研究者觀察到，在實際使用中，代碼補全質(zhì)量有了顯著提高。在 28% 的已被接受的建議中，補全結(jié)果是明顯受益于上述 boost 操作的，其排名由于 boost 的存在而更高，只有 0.4% 的已被接受結(jié)果與此規(guī)律相反。此外，研究者發(fā)現(xiàn)，用戶在接受補全建議之前鍵入的字符減少了 10% 以上。
檢查單行 / 多行 ML 補全的語義正確性
在推理時，ML 模型通常不知道輸入窗口之外的代碼，在訓練期間看到的代碼可能會錯過在動態(tài)變化的存儲庫中補全所需的最近添加的代碼。這導致了 ML 支持的代碼補全應用的一個常見缺點，即模型可能會建議看起來正確但不能編譯的代碼。根據(jù)內(nèi)部用戶體驗研究，隨著時間的推移，這個問題可能會導致用戶信任的降低，同時降低生產(chǎn)力收益。
谷歌的研究人員使用 SE 在給定的延遲預算內(nèi)（端到端補全小于 100ms）執(zhí)行快速語義正確性檢查，并使用緩存的抽象語法樹實現(xiàn)「完整」的結(jié)構(gòu)理解。典型的語義檢查包括指代消解（即該對象是否存在）、方法調(diào)用檢查（比如確認使用正確數(shù)量的參數(shù)調(diào)用了該方法）和可分配性檢查（以確認類型是否符合預期）。
例如，對于編碼語言 Go，約 8% 的建議在語義檢查之前包含編譯錯誤，但是語義檢查的應用過濾掉了 80% 的不可編譯建議。在加入該功能的前六周內(nèi)，單行補全的接受率提高到了原來的 1.9 倍，這可能是由于用戶信任度的提高。作為對照，對于沒有添加語義檢查的語言，研究者只看到接受度增加到了原來的 1.3 倍。
可以訪問源代碼的語言服務器和 ML 后端并置在云端。它們都對 ML 補全建議執(zhí)行語義檢查。
結(jié)果
在 10000 多名谷歌內(nèi)部開發(fā)人員在他們的 IDE 中使用補全功能時，研究人員測量到的用戶接受率為 25-34%。他們確定，基于 transformer 的混合語義 ML 代碼補全工具補全了超過 3% 的代碼，同時將谷歌員工的編碼迭代時間減少了 6%（在 90% 的置信水平下）。ML 具有推廣到大多數(shù)主要語言和工程師群體中的潛力。
基于 10000 多名谷歌內(nèi)部開發(fā)人員得到的單行代碼補全接受結(jié)果。
基于 5000 多名谷歌內(nèi)部開發(fā)人員得到的多行代碼補全接受結(jié)果。
在探索 API 時提供更長的補全建議
谷歌在博客中表示，他們還將語義補全與整行補全緊密結(jié)合。當出現(xiàn)帶有語義單 token 補全的下拉列表時，他們會在內(nèi)聯(lián)顯示從 ML 模型返回的單行補全結(jié)果。后者表示作為下拉焦點的項目的延續(xù)。例如，如果用戶查看一個 API 的可能方法，則內(nèi)聯(lián)完整行補全顯示完整方法調(diào)用，其中還包含調(diào)用的所有參數(shù)。
?
ML 集成的完整行完成繼續(xù)關(guān)注的語義下拉完成。
ML 提出的多行補全建議。
結(jié)論和未來的工作
在博客中，谷歌的研究人員演示了如何使用基于規(guī)則的語義引擎和大型語言模型的組合來實現(xiàn)更好的代碼補全效果，從而顯著提高開發(fā)人員的生產(chǎn)效率。下一步，他們希望通過在推理時向 ML 模型提供額外信息來進一步利用 SE。一個例子是在 ML 和 SE 之間來回進行長預測，其中 SE 迭代檢查正確性，并為 ML 模型提供所有可能的補全。在添加 ML 支持的新功能時，他們希望注意的不僅僅是「智能」結(jié)果，還要確保對生產(chǎn)力產(chǎn)生積極影響。
