一、編程輔助例子

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

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

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

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

圖2 Copilot示例-代碼補全

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

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

二、背后的技術(shù)

1.Codex模型

Copilot工具背后真正的基石是Codex，是一個基于 GPT 的語言模型，在閱讀了Codex原始論文后，筆者發(fā)現(xiàn)它是GPT-3使用代碼文本數(shù)據(jù)進行了Fine-Tuning之后的產(chǎn)物，在模型的結(jié)構(gòu)上Codex沒有做任何創(chuàng)新的地方。

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

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

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

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

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

2.模型推理優(yōu)化

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

圖3 模型加速手段

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

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

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

?開源模型：雖然我們無法直接基于Codex部署私有化模型服務(wù)，但是在Hugging Face的Model Hub社區(qū)上與代碼生成相關(guān)的開源模型仍然有許多可供我們選擇，更讓我們意外的是其中的開源模型CodeGen[4]甚至在HumanEval評測集上擊敗了Codex。

計算資源：只要不使用參數(shù)量最大的CodeGen-16B，服務(wù)器上的T4顯卡就有足夠的顯存來進行推理，另外我們會測試INT-8量化下使用CPU部署服務(wù)的表現(xiàn)如何。

部署方式：在模型的推理服務(wù)器上我們使用了Triton Inference Server[5]，因為可以很好的適配 FasterTransformer[6]，另外也能搭配各種加速手段。

插件化方式：好消息是Github Copilot插件中的高級配置有調(diào)試選項，可以直接配置模型服務(wù)的地址，因此當(dāng)啟用該選項時可以將其設(shè)置為我們自己的模型服務(wù)地址，另外在插件市場同樣有一些類似于Copilot的插件，并且可以配置本地的代碼生成服務(wù)地址。

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

圖4 CodeGen系列模型

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

圖5 模型服務(wù)

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

圖6 配置選項參考

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

圖7 代碼生成效果

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

圖8 Bert代碼片段

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

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

 四、總結(jié)與思考

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

當(dāng)然我們并不會直接放棄這樣一個可以幫你干“臟活累活”的工具，畢竟如果只是作為一個“副駕駛”，時不時對你進行提醒，而不是代替你開車，它還是可以做的非常好的。另外就像開頭所說的，其實是隨著Github Copilot的收費才促成了筆者的這一次實踐，許多社交媒體上的程序員都聲稱他們已經(jīng)離不開Copilot了。而目前來看我們已經(jīng)有了較為完善的私有化部署方式，還有開源模型CodeGen可供使用，作為一個在日常開發(fā)工作中的私有化工具已經(jīng)足夠好了。不過這還不夠，如果可以使用完全開源并且脫敏的代碼數(shù)據(jù)，并按照合適的模型參數(shù)量來定制化的訓(xùn)練我們的模型??......總之，敬請期待吧??。

參考文獻(xiàn)

[1] 代碼生成工具GitHub Copilot：https://copilot.github.com/

[2] 代碼生成模型OpenAI-codex：https://openai.com/blog/openai-codex/

[3] https://gpt3demo.com

[4] 代碼生成模型CodeGen：https://github.com/salesforce/CodeGen.com/

[5] NVIDIA's Triton Inference Server：https://developer.nvidia.com/nvidia-triton-inference-server

[6] NVIDIA's Triton FasterTransformer：https://github.com/NVIDIA/FasterTransformer

[7] Devlin J, Chang M W, Lee K, et al. Bert: Pre-training of deep bidirectional transformers for language understanding[J]. arXiv preprint arXiv:1810.04805, 2018.

[8] FauxPilot - an open-source GitHub Copilot server：https://github.com/moyix/fauxpilot

[9] 盤點開源“Copilot”，do it yourself：https://lowin.li/2022/06/27/pan-dian-kai-yuan-copilot/

本文轉(zhuǎn)載自 ??AI遇見云??，作者： 張宇博