一、編程輔助例子

GitHub Copilot[1]基于OpenAI的Codex[2]模型（GPT-3[3]的后代）實現，可以在代碼編寫的時候實時地提供代碼補全建議和注釋，并且在多個編輯器的插件市場都可以下載使用。

不管是從Copilot官網上的例子，還是在互聯網上搜索關于Copilot的使用案例，你都可以發現它比一般的代碼補全工具更為先進和靈活，它不僅能補全代碼，更能創造代碼，通過理解使用者簡單的自然語言指令，它能夠按照這些指令直接構建代碼片段，并且正確率超過4成。

      圖1 Copilot示例-注釋生成代碼

另外在代碼補全功能上Copilot每次可以提供多個建議，你可以從多個候選項中選擇合適的代碼片段進行補全。

圖2 Copilot示例-代碼補全

拋開上面這些較為“先進”的功能，Copilot是否能在日常工作中真正地幫助程序員提升工作效率呢？從筆者使用的經驗上來說，Copilot最大的作用在于可以幫我們解決掉大量重復的、枯燥乏味的代碼編寫工作，而且越是這樣重復的代碼Copilot補全預測的越精確，這樣一來你大部分的精力和時間只需要花在最核心最富有創造力的部分上，而那些臟活累活就由“AI”幫你完成，程序員的工作效率和身心健康都能得到極大地提升。下面是一些Copilot在實際業務場景中使用時較為出彩的例子：

• 程序日志記錄：比如在Java或者Golang中使用日志組件打印一些調試信息或者記錄一些變量信息，每次使用時都需要寫一長串代碼，而使用了Copilot后你剛打出logging，后面的代碼就自動補全了，你需要的變量信息、日志的級別、格式化字符串都已經生成完畢。
• 條件判斷&循環體：判斷某個數值變量是否在一個范圍中或者各種條件判斷，比如Python中寫了個for循環前面又有個數組沒用過，就立馬幫你補全上for item in items。
• 模板代碼：例如 React 中，每次用 useState 都要寫一行模板性的初始化代碼。如果第一個變量名是 someVariable，第二個一定是 setSomeVariable。這種根本不需要過腦子的東西，最適合 Copilot 補全了。

二、背后的技術 

1.Codex模型

Copilot工具背后真正的基石是Codex，是一個基于 GPT 的語言模型，在閱讀了Codex原始論文后，筆者發現它是GPT-3使用代碼文本數據進行了Fine-Tuning之后的產物，在模型的結構上Codex沒有做任何創新的地方（對于GPT模型結構可參照歷史文章：?數據不夠用怎么辦？| 基于GPT2-prompts違規文本生成實踐）。

這里是比較有意思的地方，因為GPT系列模型的賣點就是從來不做微調，而且GPT3跟 GPT本質上差別也不大，所以Codex創新不在于模型的本身，而是在于實際的應用上面，這時候去使用微調這樣的方法無疑性價比更高，也是合理的。

另外的創新點在于他提出了一個HumanEval的數據集來衡量模型的好壞，在這個數據集上Codex能夠解決28.8%的問題，相比之下如果直接使用GPT-3則解決不了任何問題。另外如果允許sampling的話（模型跑100遍，得到100個不一樣的結果，只要其中一個正確就算解決問題）能提升到70.2%的成功率。總而言之Codex沒有做特別大的改動，它提出了一個問題，然后把GPT-3在大量代碼組成的數據集上微調了一下并嘗試解決這個問題，最后使用了一個全新的評測數據集來評判代碼生成質量的好壞。

論文中的重點主要聚焦于他整體的評估框架，因為通過語言模型來生成復雜代碼這個問題相對來說還比較新穎，在GPT-3剛問世的的時候OpenAI也給大家做過展示，GPT-3可以生成一些簡單的代碼片段，但是如果用來生成較為復雜的代碼時效果很差，畢竟 GPT-3的訓練數據中沒有包含特別多的代碼，因此一個Code Fine-Tuning數據集就呼之欲出了，根據論文介紹，Codex在2020年5月從Github 的 54,000,000 個公開代碼倉上收集了數據，在經過過濾后，最終的數據集大小為159GB。

那么在評測數據集上采用哪種指標來判斷模型的好壞呢？我們知道文本生成任務的輸出為一個文本序列，比如說機器翻譯經常用的一個評估方法叫做 BLEU score，BLUE這個分數計算的是生成的序列和正確答案序列在一些子序列上的相似度，是一個模糊的匹配過程，因此在代碼生成上面BLUE分數會存在一個大問題——就算你在子片段上跟真實的代碼非常相近，但是很有可能你生成的代碼甚至連編譯都無法通過。最終Codex使用的是一個pass@k 的分數，其含義表示生成 k 個不同的結果，其中只要有一個結果能夠通過所有測試用例的話那么就認為正確。

最后是HumanEval這個評測數據集，數據集中包含164個編程的問題，主要涉及到語言的理解、算法能力、簡單的數學推理以及一些簡單的編程面試問題，數據量不是那么大，其中每個編程問題包括函數頭、docstrings、函數體和幾個單元測試用例，目前該數據集已經開源→https://github.com/openai/human-eval。

 2.模型推理優化

基于預訓練模型實現的工具應用在實際業務場景中有一個不容忽視的問題，那就是模型的推理性能是否能夠滿足需求，而Codex實際上就是GPT模型，在推理過程中需要逐字生成代碼，因此如果需要實時地提供補全建議則對模型的推理性能有很高的要求。

圖3 模型加速手段

上圖中包含了一些常用的模型加速手段，在論文中OpenAI并沒有披露針對模型部署方面的優化，但是在后面我們實際嘗試去私有化部署代碼生成模型時還是應用了多種模型加速方式，期望讓使用感受能夠接近Github Copilot。

3.組裝你自己的AI編程助手

在實際私有化部署我們的“AI輔助”前先看看我們手上有哪些資源：

• 開源模型：雖然我們無法直接基于Codex部署私有化模型服務，但是在Hugging Face的Model Hub社區上與代碼生成相關的開源模型仍然有許多可供我們選擇，更讓我們意外的是其中的開源模型CodeGen[4]甚至在HumanEval評測集上擊敗了Codex。
• 計算資源：只要不使用參數量最大的CodeGen-16B，服務器上的T4顯卡就有足夠的顯存來進行推理，另外我們會測試INT-8量化下使用CPU部署服務的表現如何。
• 部署方式：在模型的推理服務器上我們使用了Triton Inference Server[5]，因為可以很好的適配 FasterTransformer[6]，另外也能搭配各種加速手段。
• 插件化方式：好消息是Github Copilot插件中的高級配置有調試選項，可以直接配置模型服務的地址，因此當啟用該選項時可以將其設置為我們自己的模型服務地址，另外在插件市場同樣有一些類似于Copilot的插件，并且可以配置本地的代碼生成服務地址。

接下來就是部署我們自己的代碼生成服務了，在使用GPU服務器進行部署時我們選擇了CodeGen-2B模型支持多語言模式的版本：

圖4 CodeGen系列模型

然后使用Triton Inference Server以及 FasterTransformer backend來啟動我們的模型服務：

圖5 模型服務

修改Copilot的插件的配置選項：

圖6 配置選項參考

最終讓我們看一下代碼生成的效果，就讓AI解一下斐波那契數列吧：

圖7 代碼生成效果

在使用GPU部署代碼生成模型服務的情況下，從代碼生成的速度上來說并已經完全不亞于于Github Copilot的速度了，通常來說服務器上的GPU計算資源較為寶貴，但是卻有許多空閑的CPU資源，因此我們需要測試CPU部署時代碼的生成速度是否能夠滿足日常需求，首先是我們期望模型生成的代碼片段，這是Bert[7]模型定義中Embedding的一部分，實際測試時我們只鍵入Class名稱，藍色的注釋，然后讓模型來生成接下來的代碼片段：

圖8 Bert代碼片段

我們試用了CodeGen的多個模型，并且記錄在不同情況下他們返回結果的延時：

從結果來看，使用CPU部署后在經過INT8量化技術的加持下，當我們使用參數量最小的代碼生成模型，至少在速度上可以獲得還不錯的體驗。

四、總結與思考

從本次探究Github Copilot背后的技術以及進行簡單的代碼生成實踐來看，基于GPT系列模型在文本生成這個領域上的確有著許多應用落地的可能，然而代碼生成這一技術并不是“無害”的，首先是在模型訓練過程中使用的“開源代碼數據集”中包含許多個人數據，在筆者使用過程中發現，如果涉及到文件路徑的鍵入，經常會出現一些帶用戶名的路徑補全建議，其直接使用他人的開源代碼來作為訓練數據也在社區上引起了廣泛的爭議，甚至有許多開源社區的作者期望制定一個新的開源協議，限制他們的開源庫不被用來作為深度學習的數據。另外經過Copilot生成的代碼質量難以把控，還是會存在“埋坑”的可能性，很有可能在某天當你debug一個問題時卻完全想不起來自己為什么會寫下這一段代碼，直到最后才意識到這是AI幫你生成的。

當然我們并不會直接放棄這樣一個可以幫你干“臟活累活”的工具，畢竟如果只是作為一個“副駕駛”，時不時對你進行提醒，而不是代替你開車，它還是可以做的非常好的。另外就像開頭所說的，其實是隨著Github Copilot的收費才促成了筆者的這一次實踐，許多社交媒體上的程序員都聲稱他們已經離不開Copilot了。而目前來看我們已經有了較為完善的私有化部署方式，還有開源模型CodeGen可供使用，作為一個在日常開發工作中的私有化工具已經足夠好了。

本文轉載自 ??AI遇見云??，作者： 張宇博