本文內(nèi)容整理自 QCon 全球軟件開發(fā)大會(huì)上，阿里云通義靈碼產(chǎn)品技術(shù)負(fù)責(zé)人陳鑫發(fā)表演講

大家好，我是通義靈碼的產(chǎn)品技術(shù)負(fù)責(zé)人陳鑫。過(guò)去有八年時(shí)間，我都是在阿里集團(tuán)做研發(fā)效能，即研發(fā)工具相關(guān)的工作。

我們從 2015 年開始做一站式 DevOps 平臺(tái)，然后打造了云效，也就是將 DevOps 平臺(tái)實(shí)現(xiàn)云化。到了 2023 年，我們明顯感覺到大模型時(shí)代來(lái)了以后，軟件工具將面臨著徹底的革新，大模型和軟件工具鏈的結(jié)合，使軟件研發(fā)進(jìn)入下一個(gè)時(shí)代。

那它第一個(gè)落腳點(diǎn)在哪？實(shí)際上就是輔助編程，所以我們就開始打造了通義靈碼這款產(chǎn)品，它是一個(gè)基于代碼大模型的的 AI 輔助工具。今天我借這個(gè)機(jī)會(huì)和大家分享通義靈碼技術(shù)實(shí)現(xiàn)上的一些細(xì)節(jié)以及我們?nèi)绾慰创竽Ｐ驮谲浖邪l(fā)領(lǐng)域的發(fā)展。

我會(huì)分為三個(gè)部分來(lái)分享。第一部分先介紹 AIGC 對(duì)軟件研發(fā)的根本性影響，從宏觀上介紹當(dāng)下的趨勢(shì)；第二部分將介紹 Copilot 模式，第三部分是未來(lái)軟件研發(fā) Agent 產(chǎn)品的進(jìn)展。為什么我會(huì)提到 Copilot Agent，稍后我給大家講解。

01 AIGC 對(duì)軟件研發(fā)的根本性影響

這張圖是我過(guò)去幾年畫的一張圖，我認(rèn)為企業(yè)研發(fā)效能的核心影響因素是這三點(diǎn)。

第一點(diǎn)是人員技能。人員技能決定了企業(yè)研發(fā)效能的一個(gè)非常大的因素，比如說(shuō)谷歌可以招聘到個(gè)人能力強(qiáng)于他人十倍的工程師，一個(gè)人等同于十個(gè)人，那由一群十倍工程師組成的一個(gè)小團(tuán)體，戰(zhàn)斗力就很強(qiáng)，甚至可以實(shí)現(xiàn)全棧，他們的角色分工可能就非常簡(jiǎn)單，工作非常高效，最終的效能也非常大。

但是實(shí)際上我們企業(yè)內(nèi)部，尤其是中國(guó)企業(yè)，沒有幾個(gè)能夠達(dá)到谷歌的水平。這是客觀影響因素，我們認(rèn)為人員技能是效能基石，當(dāng)然也是效能的破局點(diǎn)。

第二點(diǎn)是協(xié)同消耗。在我們不可能要求每個(gè)工程師能力強(qiáng)大的基礎(chǔ)上，每個(gè)人一定是有專業(yè)分工的，比如有些做軟件設(shè)計(jì)，有些做開發(fā)、做測(cè)試、做項(xiàng)目管理。這些人組成的團(tuán)隊(duì)隨著軟件架構(gòu)的復(fù)雜度越來(lái)越大，組織的復(fù)雜度也會(huì)正相關(guān)的變大，這就造成了協(xié)同消耗也會(huì)越來(lái)越大，最終拖慢了整體的研發(fā)效能。

第三點(diǎn)是成本控制。我們發(fā)現(xiàn)做項(xiàng)目的時(shí)候人員不可能總是富裕的，永遠(yuǎn)是缺人手，也不可能有無(wú)限的資金去招到十倍工程師，所以這也是一個(gè)制約因素。

今天在 AIGC 的時(shí)代，這三個(gè)因素已經(jīng)產(chǎn)生了一些根本性變化。

在人員技能上，通過(guò) AI 輔助可以快速將一些初級(jí)工程師的能力提升。這個(gè)其實(shí)在國(guó)外是有一些報(bào)道的，初級(jí)工程師使用了代碼輔助工具的效果是明顯高于高級(jí)工程師的，為什么呢？因?yàn)檫@些工具對(duì)于初級(jí)工作的替代，或者說(shuō)它的輔助效果是非常好的，所以它可以快速補(bǔ)齊初級(jí)工程師的能力短板。

在協(xié)同消耗上，如果今天 AI 能夠變成一個(gè)超級(jí)個(gè)體，實(shí)際上它對(duì)流程協(xié)同消耗的降低是有幫助的。比如一些簡(jiǎn)單的工作就不需要跟人打交道了，AI 直接就可以做，也不需要給每個(gè)人都講一遍需求應(yīng)該怎么測(cè)試，AI 做簡(jiǎn)單測(cè)試就可以了，這樣時(shí)間的效率就提升了。所以可以通過(guò)超級(jí)個(gè)體去有效的降低協(xié)同消耗。

在成本控制上，實(shí)際上 AI 大量的用法就是代替事務(wù)性工作，包括現(xiàn)在用代碼大模型去做代碼輔助，也是希望代替 70% 的日常事務(wù)性勞動(dòng)。

那具體來(lái)看的話，會(huì)有這四個(gè)挑戰(zhàn)以及智能化的機(jī)會(huì)。

第一個(gè)是個(gè)體效率，剛剛也給大家介紹了，大量研發(fā)工程師的重復(fù)工作和簡(jiǎn)單溝通都可以通過(guò) AI 來(lái)完成了，它是一個(gè) Copilot 模式。

另外一個(gè)協(xié)作效率，一些簡(jiǎn)單的工作直接讓 AI 做，可以使協(xié)同消耗降低，這點(diǎn)剛剛我已經(jīng)講述的比較清晰了。

第三個(gè)是研發(fā)體驗(yàn)，過(guò)去 DevOps 工具鏈關(guān)注的是什么？一個(gè)接一個(gè)拼成一個(gè)大的流水線，拼成整個(gè)的工具鏈。其實(shí)每個(gè)工具鏈在不同的企業(yè)里可能有不同的使用習(xí)慣，甚至有不同的賬號(hào)體系、不同的界面、不同的交互、不同的權(quán)限。這種復(fù)雜度給開發(fā)者帶來(lái)了非常大的上下文切換成本和理解成本，這在無(wú)形中讓開發(fā)者其實(shí)很不爽。

但是在 AI 時(shí)代發(fā)生了一些變化，我們可以通過(guò)統(tǒng)一的對(duì)話入口，用自然語(yǔ)言的方式去操作很多工具，甚至在自然語(yǔ)言的窗口里解決很多的問題。

我舉個(gè)例子，比如過(guò)去查一個(gè) SQL 到底有沒有性能問題，我們應(yīng)該怎么辦？可能先在代碼里面把 SQL 語(yǔ)句摳出來(lái)，把它變成一個(gè)可執(zhí)行的語(yǔ)句，再放到一個(gè) DMS 系統(tǒng)里面診斷一下看看它有沒有用索引，有沒有問題，然后再人工判斷一下到底要不要改這個(gè) SQL 去優(yōu)化它，最后再到 IDE 里把它變更掉，這個(gè)流程需要切換多個(gè)系統(tǒng)，要做很多的事情。

那在未來(lái)，如果我們有代碼智能工具的話，就可以圈選一個(gè)代碼，問大模型這個(gè) SQL 有沒有問題，這個(gè)大模型可以自主的調(diào)用一些工具，比如 DMS 系統(tǒng)去分析，并且拿到的結(jié)果可以直接通過(guò)大模型告訴我 SQL 應(yīng)該如何優(yōu)化，直接告訴我結(jié)果，我們只需要采納它就可以解決，整個(gè)操作鏈路會(huì)被縮短，體驗(yàn)就會(huì)提升，從而提升研發(fā)效率。

第四個(gè)是數(shù)字資產(chǎn)，過(guò)去大家寫了代碼放在那都變成了屎山代碼或者說(shuō)是負(fù)債，當(dāng)然里邊有非常多優(yōu)秀的金礦沒有被挖掘出來(lái)，然后還有很多文檔想要找的時(shí)候找不到了。

但是在 AI 時(shí)代，我們做的最重要的事之一就是需要去梳理我們的資產(chǎn)以及文檔，通過(guò) SFT、RAG 的方式去賦能給大模型，讓大模型變得更聰明，更加符合企業(yè)的個(gè)性化理解，所以今天這種人機(jī)交互方式的變化，會(huì)帶來(lái)體驗(yàn)上的變化。

人工智能從剛剛的幾個(gè)影響因素再往下拆，它核心是帶來(lái)了三種人機(jī)交互方式的變化。第一種是 AI 會(huì)變成一個(gè) Copilot，和工具進(jìn)行結(jié)合，然后人可以指揮它幫我們完成一些單點(diǎn)的工具。到第二階段，實(shí)際上大家應(yīng)該有共識(shí)了，它變成 Agent，也就是它具備了一些自主完成任務(wù)的能力，包括自主寫代碼或者做測(cè)試。其實(shí)工具扮演的是一個(gè)多領(lǐng)域?qū)＜?，我們只需要給定上下文并完成知識(shí)對(duì)齊即可。第三個(gè)階段我們判斷 AI 可能會(huì)變成一個(gè)決策者，因?yàn)樵诘诙A段決策者還是人，在第三階段有可能大模型會(huì)具備一些決策能力，包括更高級(jí)的信息整合分析能力。這時(shí)候人會(huì)更多的聚焦于業(yè)務(wù)的創(chuàng)意和糾偏，很多事情都可以交給大模型做。通過(guò)這種不同的人機(jī)模式的變化，讓我們整體的工作效率會(huì)變高。

還有一點(diǎn)是我們剛剛講到的知識(shí)傳遞形式也發(fā)生了根本性的變化。在過(guò)去是通過(guò)口口相傳、通過(guò)培訓(xùn)，老帶新去解決知識(shí)傳遞的問題。未來(lái)很有可能不需要這樣，只需要讓模型具備業(yè)務(wù)知識(shí)和領(lǐng)域經(jīng)驗(yàn)，讓每一個(gè)開發(fā)工程師都使用智能化工具，它的這些知識(shí)就可以通過(guò)工具傳導(dǎo)到研發(fā)過(guò)程中，就會(huì)變成右邊圖上所示的現(xiàn)在 DevOps 的一站式工具鏈。積累了大量代碼和文檔資產(chǎn)后，將這些資產(chǎn)梳理清楚跟大模型放在一起，通過(guò) RAG、SFT，模型嵌入到 DevOps 工具的各個(gè)鏈路，從而又產(chǎn)生更多數(shù)據(jù)，形成了這樣的正向循環(huán)，一線開發(fā)者在這個(gè)過(guò)程中就能享受到資產(chǎn)帶來(lái)的紅利或者說(shuō)能力。

以上就是我從宏觀的角度介紹了現(xiàn)在大模型影響研發(fā)效率的核心因素，以及兩個(gè)最重要的形態(tài)改變：第一個(gè)是人機(jī)交互的形態(tài)發(fā)生了改變，第二個(gè)是知識(shí)傳遞的方式發(fā)生了根本性變化。現(xiàn)在由于各種各樣的技術(shù)限制以及大模型發(fā)展階段的問題，我們做的最好的還是 Copilot 人機(jī)交互模式，所以接下來(lái)就介紹下我們的一些經(jīng)驗(yàn)，如何去打造最佳的這種 Copilot 人機(jī)交互模式。

02 打造最佳 Copilot 姿勢(shì)

我們認(rèn)為代碼開發(fā)的人機(jī)交互模式，目前只能解決比如小任務(wù)的問題、需要人工采納的問題、高頻次的問題，像代碼補(bǔ)全，AI 幫我們生成一段，我們接納一段，再生成一段，再接納一段，這種頻次非常高的問題，還有短輸出的問題，不會(huì)說(shuō)一下子就生成一個(gè)工程，甚至不會(huì)一下就生成一個(gè)類，我們每次都是生成一個(gè)函數(shù)或者幾行。為什么要這樣來(lái)做呢？其實(shí)和模型本身能力的限制有很大關(guān)系。

因?yàn)槲覀儸F(xiàn)在上下文寬度還非常有限，假如要完成一個(gè)需求，沒有辦法把所有的背景知識(shí)全部交給它一次性搞定，所以要不就是通過(guò) Agent 去拆成一堆的小任務(wù)，逐步解決。要不就在 Copilot 模式里讓它完成一個(gè)最簡(jiǎn)單的工作，比如按照一個(gè)注釋去生成一小段代碼，這樣我們叫做解決小任務(wù)。

在人工采納上，人工現(xiàn)在必須對(duì)代碼大模型生成的結(jié)果做判斷。目前做的好的可能也就是30%-40%的采納率，也就是說(shuō)我們有超過(guò)一半的生成代碼實(shí)際上是不準(zhǔn)確的，或者是不符合開發(fā)者預(yù)期的，所以要不斷的消除幻覺問題。

但是讓大模型真正能在生產(chǎn)級(jí)使用最重要的還是要人工確認(rèn)，然后高頻次是不要生成太多，每次生成一點(diǎn)，因?yàn)槿斯とゴ_認(rèn)這段代碼是否 ok 的成本也是影響效能的，后文會(huì)講一些我們的思考和我們做的事情，通過(guò)高頻次去解決準(zhǔn)確性率有限問題。另外短輸出主要是考慮性能和成本問題。

現(xiàn)在代碼助手這種模式，實(shí)際上是特別精確的命中了大模型的一些技術(shù)限制，才讓這樣的產(chǎn)品能夠快速落地，它有一個(gè)非常好的時(shí)機(jī)。在我們看來(lái)，開發(fā)者最喜歡的 Copilot 模式，是以下四個(gè)關(guān)鍵詞：高頻剛需、觸手可及、知我所想、唯我專屬。

第一個(gè)是我們要解決高頻和剛需的場(chǎng)景，這才能讓開發(fā)者覺得這個(gè)東西是真的有用，而不是個(gè)玩具。

第二個(gè)是觸手可及，也就是隨時(shí)可以喚醒它，隨時(shí)可以幫我們解決問題。不再像以前需要通過(guò)各種搜索引擎去搜索代碼，它就像在我身邊一樣，隨時(shí)可以喚醒它幫我解決問題。

第三個(gè)是知我所想，也就是它回答我問題的準(zhǔn)確度，以及它在什么時(shí)機(jī)回答我的問題都是非常重要的。

最后還要為我所屬，它能懂我私有的一些知識(shí)，而不是說(shuō)只了解完全開源的東西。我們把這四點(diǎn)具體再展開討論一下。

高頻剛需

我們需要判斷什么是軟件研發(fā)最高頻的場(chǎng)景。我這邊有一些真實(shí)的數(shù)據(jù)，第一個(gè)數(shù)據(jù)來(lái)自 JetBrains 在 2023 年做的一個(gè)開發(fā)者的生態(tài)報(bào)告，整理了開發(fā)者最耗時(shí)的活動(dòng)，其中可以看到百分之七八十都是編寫代碼，理解代碼及互聯(lián)網(wǎng)搜索、調(diào)試、寫注釋、寫測(cè)試。這幾個(gè)場(chǎng)景實(shí)際上就是代碼智能工具的功能，像通義靈碼這樣的產(chǎn)品最核心解決的問題，其實(shí)就是最高頻的問題。

后面這兩個(gè)數(shù)據(jù)是通義靈碼線上幾十萬(wàn)用戶的數(shù)據(jù)分析。我們現(xiàn)在線上采納的代碼， 73% 來(lái)自于補(bǔ)全任務(wù)，27% 來(lái)自于問答任務(wù)的采納。所以今天大量的 AI 替代人去寫代碼，還是在 IDE 的行間生成，這是從真實(shí)的情況下反映出來(lái)的一個(gè)結(jié)果。后面是使用問答功能的比例，有 76% 的比例是來(lái)自于研發(fā)問答，剩下的 10% 是代碼優(yōu)化和解釋代碼等等一系列的代碼任務(wù)。所以絕大部分的開發(fā)者還是在使用我們的工具去問一些常用的研發(fā)知識(shí)，或者通過(guò)自然語(yǔ)言的方式讓代碼大模型生成一些算法，解決一些小的問題。

其次的 23% 才是我們真正的一些細(xì)節(jié)的代碼任務(wù)，這是給大家一個(gè)數(shù)據(jù)洞察。因此我們就有了核心的目標(biāo)。第一，我們要解決好代碼生成的問題，尤其是在行間生成。第二，要解決研發(fā)問題的準(zhǔn)確度以及專業(yè)性問題。

觸手所及

我們最終要講的是打造沉浸式編程體驗(yàn)，我們希望今天開發(fā)者絕大部分的問題都可以在 IDE 里面解決，而不是需要跳出。

過(guò)去我們的體驗(yàn)是什么？是遇到問題去互聯(lián)網(wǎng)搜索，或者問問別人，問了一圈以后再自己判斷，最終寫上代碼復(fù)制放到 IDE 里面調(diào)試編譯，不通過(guò)了再去查，這樣的話就會(huì)非常耗時(shí)。我們希望能在 IDE 里面直接問大模型，讓大模型幫我生成代碼，這樣體驗(yàn)就很爽。我們通過(guò)這樣的一個(gè)技術(shù)選擇，解決了沉浸式編程體驗(yàn)的問題。

補(bǔ)全任務(wù)是一個(gè)性能敏感型任務(wù)，它的輸出需要在 300 到 500 毫秒，最好不要超過(guò)一秒，所以我們有一個(gè)小參數(shù)模型，它主要是用來(lái)生成代碼的，而且它的大部分訓(xùn)練語(yǔ)料也來(lái)自于代碼。它雖然的模型參數(shù)很小，但是在代碼生成的準(zhǔn)確度上非常高。

第二個(gè)我們要去做好專項(xiàng)任務(wù)，我們還有 20%~30% 實(shí)際上的任務(wù)是來(lái)自于這些，包括注釋生成、單元測(cè)試、代碼優(yōu)化、運(yùn)營(yíng)錯(cuò)誤排查等七項(xiàng)任務(wù)。

我們目前使用了一個(gè)中等參數(shù)模型。這里主要考慮的，一是生成效率，二是調(diào)優(yōu)。一個(gè)非常大參數(shù)的模型，我們調(diào)優(yōu)的成本是很大的，但是在這種中等參數(shù)模型上，它本身的代碼理解和代碼生成效果已經(jīng)不錯(cuò)了，所以我們選擇了中等參數(shù)模型。

然后在大模型上面，尤其是我們 70% 多的研發(fā)問題回答上，我們追求的是高精度，而且追求的是實(shí)時(shí)的一些知識(shí)。所以我們通過(guò)一個(gè)最大參數(shù)的模型，疊加了我們的 RAG 技術(shù)，讓它外掛了一個(gè)近乎于實(shí)時(shí)的基于互聯(lián)網(wǎng)的知識(shí)庫(kù)，所以它回答的質(zhì)量和效果就非常高，并且能大幅消除模型幻覺，提升回答質(zhì)量。我們通過(guò)這樣的三個(gè)模型支持了整個(gè)沉浸式編程的體驗(yàn)。

第二點(diǎn)是我們要實(shí)現(xiàn)多端，因?yàn)橹挥懈采w了更多的端，才可以覆蓋更多的開發(fā)者。目前通義靈碼支持 VS code 和 JetBrains，主要解決的是觸發(fā)問題、展示問題，還有一些交互性問題。

最核心層次下面，我們本地 Agent 服務(wù)是一個(gè)獨(dú)立的進(jìn)程。這個(gè)進(jìn)程跟上面的插件之間會(huì)進(jìn)行通信。這個(gè)進(jìn)程最主要解決的是代碼核心的一些能力，包括代碼智能補(bǔ)全的部分，會(huì)話管理的部分，智能體。

此外，語(yǔ)法分析服務(wù)也非常重要，我們要解決跨文件引用的問題等，都需要語(yǔ)法分析。如果我們要做本地的檢索增強(qiáng)，我們還需要輕量級(jí)的本地向量檢索引擎。所以整個(gè)后端的服務(wù)實(shí)際上是通過(guò)這樣的方式就可以快速的實(shí)現(xiàn)擴(kuò)端。

我們還有一個(gè)特色，我們有一個(gè)零點(diǎn)幾B的本地離線的小模型，來(lái)實(shí)現(xiàn)個(gè)別語(yǔ)言的單行補(bǔ)全，這是可以脫網(wǎng)去做的，包括 JetBrains 最近也上了一個(gè)跑在本地的小模型。通過(guò)這種方式，也會(huì)保證我們的一些數(shù)據(jù)安全隱私問題，比如本地的會(huì)話管理、本地的存儲(chǔ)，全部都放到了本地電腦上。

知我所想

知我所想對(duì)于 IDE 插件這個(gè)工具而言，我認(rèn)為有幾點(diǎn)。第一是觸發(fā)時(shí)機(jī)，在什么時(shí)候觸發(fā)，對(duì)于開發(fā)者體驗(yàn)的影響也非常大。比如我在空格的時(shí)候要不要觸發(fā)？IDE 已經(jīng)生成提示的時(shí)候要不要觸發(fā)？在刪除這段代碼的時(shí)候要不要觸發(fā)？我們大概有超過(guò) 30~50 個(gè)場(chǎng)景去梳理，到底在這個(gè)場(chǎng)景上要不要進(jìn)行代碼觸發(fā)，這部分通過(guò)規(guī)則就可以搞定，只要一點(diǎn)點(diǎn)細(xì)心去摸索，去調(diào)研開發(fā)者體驗(yàn)，就可以解決，這不是很高深的技術(shù)。

但是在代碼生成長(zhǎng)度方面，我們認(rèn)為是比較難的。因?yàn)樵诓煌木庉媴^(qū)的不同的位置，它生成什么樣長(zhǎng)度代碼，直接影響了我們的體驗(yàn)。如果開發(fā)者只是傾向于生成單行代碼，帶來(lái)的問題就是開發(fā)者不能理解整個(gè)生成的內(nèi)容，比如生成一個(gè)函數(shù)，他不知道這個(gè)函數(shù)到底要干什么，生成一個(gè) if 語(yǔ)句，他不知道 if 語(yǔ)句里邊的業(yè)務(wù)邏輯是什么，就沒有辦法完整的判斷功能單元，影響了他的體驗(yàn)。

我們用一些固定的規(guī)則去做，也會(huì)導(dǎo)致一個(gè)問題，即它會(huì)比較死板。所以我們的做法實(shí)際上是基于代碼的語(yǔ)義信息，通過(guò)訓(xùn)練的方式，經(jīng)由大量的樣本，讓模型理解了今天在什么場(chǎng)景下應(yīng)該生成多長(zhǎng)，我們實(shí)現(xiàn)了由模型自動(dòng)判斷類級(jí)別、函數(shù)級(jí)別、邏輯塊級(jí)別及行級(jí)別的生成力度，我們把它叫做自適應(yīng)的生成力度決策。我們通過(guò)做這項(xiàng)大量的預(yù)訓(xùn)練，讓模型去感知，從而提升了生成的準(zhǔn)確度，這塊我們認(rèn)為也是一個(gè)比較關(guān)鍵的技術(shù)項(xiàng)。

再往下最關(guān)鍵的就是如何去消除模型的幻覺，因?yàn)橹挥谢糜X得到足夠的消除，才能夠提升我們的采納率。所以我們一定要實(shí)現(xiàn)基于庫(kù)內(nèi)的跨文件上下文感知，在這里，我們做了很多的基于代碼的語(yǔ)義分析，引用鏈追蹤，相似代碼以及動(dòng)態(tài)語(yǔ)言類型推導(dǎo)等。

最關(guān)鍵的就是想方設(shè)法的去猜開發(fā)者在這個(gè)位置補(bǔ)全他可能需要什么樣的背景知識(shí)，這些東西可能還會(huì)涉及到一些語(yǔ)言、框架、用戶習(xí)慣等，我們通過(guò)各種各樣的東西將它的上下文獲取出來(lái)，并且進(jìn)行優(yōu)先級(jí)排序，把最關(guān)鍵的信息放到上下文里面去，然后給到大模型進(jìn)行推導(dǎo)，讓大模型去消除幻覺。通過(guò)這樣的技術(shù)就可以實(shí)現(xiàn)跨文件上下文感知的測(cè)試集，我們的準(zhǔn)確率從 22% 提升到了 66.9%，我們還在不斷的去精進(jìn)提升補(bǔ)全的效果。

最后一個(gè)是我們本地的庫(kù)內(nèi)檢索增強(qiáng)。剛剛其實(shí)也說(shuō)了，上下文感知也只是猜測(cè)開發(fā)者在觸發(fā)位置的上下文。更多的場(chǎng)景是今天開發(fā)者要問一個(gè)問題，讓大模型基于本地的庫(kù)內(nèi)所有文件去幫我解決一個(gè)問題，比如幫我修復(fù)一個(gè) bug，幫我增加一個(gè)需求，幫我填充一個(gè)文件，自動(dòng)實(shí)現(xiàn)增刪改查，甚至幫我的 Pompt 文件增加一個(gè)新的包的版本，類似這樣的需求其實(shí)有很多，要實(shí)現(xiàn)的話實(shí)際上是要給大模型外掛一個(gè)檢索引擎。因?yàn)槲覀儾豢赡馨颜麄€(gè)工程的文件全部塞給大模型，因?yàn)樯舷挛膶挾鹊挠绊?，我們必須使用到一個(gè)技術(shù)，叫做本地的庫(kù)內(nèi)檢索增強(qiáng)。

這個(gè)功能就是來(lái)實(shí)現(xiàn)我們基于庫(kù)內(nèi)的自由問答的，在本地去建立一個(gè)庫(kù)內(nèi)的檢索增強(qiáng)服務(wù)，我們判斷這樣的方式對(duì)于開發(fā)者的體驗(yàn)是最好的，安全性也是最高的。

代碼不需要上傳到云端，就可以完成整個(gè)鏈路。從整個(gè)鏈路上來(lái)講，開發(fā)者問一個(gè)問題以后，我們就會(huì)去代碼庫(kù)提取需求的關(guān)鍵信息進(jìn)行任務(wù)拆解，拆解完了做本地的向量檢索召回，然后再做檢索的結(jié)果合并及重排，以及去企業(yè)內(nèi)部的數(shù)據(jù)知識(shí)庫(kù)檢索，因?yàn)槠髽I(yè)有統(tǒng)一的知識(shí)庫(kù)管理，是企業(yè)級(jí)的。最終把全部的信息匯總起來(lái)發(fā)送給大模型，讓大模型去生成和解決問題。

唯我專屬

我覺得企業(yè)要想讓代碼大模型真的能實(shí)現(xiàn)一個(gè)非常好的效果，都逃不過(guò)這一關(guān)。比如如何實(shí)現(xiàn)企業(yè)數(shù)據(jù)的個(gè)性化場(chǎng)景，比如在項(xiàng)目管理階段，如何能夠讓大模型按照需求/任務(wù)/缺陷內(nèi)容的一些固有的格式和規(guī)范去生成，幫我們實(shí)現(xiàn)一些需求的自動(dòng)拆解、自動(dòng)續(xù)寫、自動(dòng)總結(jié)等等。

開發(fā)階段可能是大家最關(guān)注的，經(jīng)常有企業(yè)會(huì)講要有符合企業(yè)自己的代碼規(guī)范，引用企業(yè)自己的二方庫(kù)，調(diào)用 API 生成 SQL，包括使用企業(yè)自研的一些前端框架、組件庫(kù)等等，這些都屬于開發(fā)場(chǎng)景。測(cè)試場(chǎng)景也要生成符合企業(yè)規(guī)范的，甚至是理解業(yè)務(wù)的測(cè)試用例。在運(yùn)維場(chǎng)景，要時(shí)刻查找企業(yè)的運(yùn)維知識(shí)，然后去回答，去獲取企業(yè)的一些運(yùn)維的 API 快速生成代碼。這些都是我們認(rèn)為要做的企業(yè)數(shù)據(jù)化個(gè)性化場(chǎng)景。具體的做法是要通過(guò)檢索增強(qiáng)或者微調(diào)訓(xùn)練的方式來(lái)實(shí)現(xiàn)。

在這里我列了一些簡(jiǎn)單的場(chǎng)景和需要注意的事項(xiàng)，包括代碼應(yīng)該怎么處理，文檔應(yīng)該怎么處理，代碼過(guò)來(lái)要進(jìn)行過(guò)濾、清洗、結(jié)構(gòu)化，然后才能夠可用。

在我們訓(xùn)練的過(guò)程中，要去考慮開放域數(shù)據(jù)和私域數(shù)據(jù)的混入。比如我們要去做一些不同的參數(shù)調(diào)整，在檢索增強(qiáng)上，我們要考慮不同的檢索增強(qiáng)策略，我們其實(shí)也是在不斷的進(jìn)行探索，包括如何在代碼生成場(chǎng)景里面命中我們所需要的上下文信息，以及我們?cè)趩柎饒?chǎng)景里面如何去命中我們需要的回答的上下文信息，這屬于檢索增強(qiáng)。

我們要做的就是企業(yè)級(jí)的檢索增強(qiáng)方案，企業(yè)級(jí)的檢索增強(qiáng)方案目前的架構(gòu)圖大概是這樣。中間是知識(shí)庫(kù)的管理服務(wù)，包括數(shù)據(jù)解析的調(diào)度、問題的理解、整理回答、結(jié)構(gòu)化的解析、數(shù)據(jù)分塊等等，核心的能力在中間這塊，向下是我們比較常用的 Embedding 的服務(wù)，包括大模型的服務(wù)、向量的存儲(chǔ)和檢索。

向上是我們管理的一些后臺(tái)，在這個(gè)場(chǎng)景下支持了我們關(guān)于文檔的檢索增強(qiáng)以及代碼生成的檢索增強(qiáng)。代碼生成也就是補(bǔ)全這個(gè)場(chǎng)景的檢索增強(qiáng)它所需要的處理方式和技術(shù)跟文檔其實(shí)還是略有不同。

過(guò)去我們跟復(fù)旦大學(xué)也做過(guò)幾年的學(xué)術(shù)研究，非常感謝他們的付出，我們也有一些論文在發(fā)表，當(dāng)時(shí)我們測(cè)試集的結(jié)果也是用一個(gè)一點(diǎn)幾B的模型，再配合檢索增強(qiáng)，它實(shí)際上的準(zhǔn)確率和效果就可以達(dá)到一個(gè)大概 7B 以上模型的同等效果。

03 未來(lái)的軟件研發(fā) Agent 產(chǎn)品演進(jìn)

我們認(rèn)為未來(lái)軟件研發(fā)一定會(huì)進(jìn)入到 Agent 時(shí)代，也就是說(shuō)它具備一些自主性，并且它可以非常容易使用我們的工具，然后理解人類的意圖，完成工作，最終會(huì)形成一個(gè)如圖所示的多智能體的協(xié)同模式。

就在今年三月份，Devin 的誕生其實(shí)讓我們感覺到這個(gè)事情真真實(shí)實(shí)的被加速了，我們從來(lái)沒有設(shè)想到這個(gè)事情能夠完成一個(gè)真實(shí)的業(yè)務(wù)項(xiàng)目，我們過(guò)去都沒有想象到，甚至我們都覺得這個(gè)事情可能還要一年以后，但是它的出現(xiàn)讓我們覺得，今天真的可以通過(guò)大模型拆解數(shù)百上千個(gè)步驟，并且一步一步執(zhí)行，出現(xiàn)問題它還可以自我反思，自我迭代，有這么強(qiáng)的拆解能力和推理能力讓我們非常意外。

隨著 Devin 的誕生，各個(gè)專家學(xué)者就開始投入，包括我們通義實(shí)驗(yàn)室，馬上發(fā)起的一個(gè)項(xiàng)目叫 OpenDevin。這個(gè)項(xiàng)目在短短的幾周內(nèi) star 數(shù)就超過(guò)了 2 萬(wàn)，可以看到大家對(duì)這個(gè)領(lǐng)域非常的熱情。然后馬上開源了 SWE 的 Agent 項(xiàng)目，把 SWE- bench 的解決率又推升到了 10% 以上，過(guò)去的大模型都在百分之幾，推升到 10% 已經(jīng)接近了 Devin 的表現(xiàn)，所以我們判斷在這個(gè)領(lǐng)域的學(xué)術(shù)研究會(huì)非常快，我們大膽猜測(cè)一下，很有可能在 2024 年年中左右的 6 到 9 月份，很有可能 SWE- bench 的解決率會(huì)超過(guò) 30%。

我們大膽猜測(cè)一下，如果能夠達(dá)到百分之五六十解決率的話，它的測(cè)試集實(shí)際上是一些真實(shí)的 Github issue，讓 AI 完成 Github 上面的 issue，可以去修復(fù) bug，去解決需求的這樣一個(gè)測(cè)試集。如果這個(gè)測(cè)試集能夠讓 AI 的自主完成率達(dá)到百分之五六十，我們認(rèn)為真的是可以在生產(chǎn)級(jí)中落地了。至少一些簡(jiǎn)單的缺陷可以交給它來(lái)修復(fù)，這是我們看到的目前業(yè)界的一些最新的進(jìn)展。

但是這張圖也不是馬上就能實(shí)現(xiàn)的，現(xiàn)在從技術(shù)路線上來(lái)講，我們會(huì)沿著這四步逐步實(shí)現(xiàn)。

第一步我們現(xiàn)在還在做單庫(kù)的問答 Agent，這個(gè)領(lǐng)域是非常前沿的，我們現(xiàn)在在做單庫(kù)的問答 Agent，近期會(huì)上線。

下一步我們希望推出能獨(dú)立完成編碼任務(wù)的 Agent，它的作用主要是具備一定的自主規(guī)劃能力，可以使用一些工具去了解背景知識(shí)，能夠自主的完成單庫(kù)范圍內(nèi)的編碼任務(wù)，還不是跨庫(kù)，可以想象一個(gè)需求有多個(gè)代碼庫(kù)，然后前端也改、后端也改，最終形成一個(gè)需求，我們覺得還很遠(yuǎn)。

所以我們先實(shí)現(xiàn)單庫(kù)的編碼 Agent，下一步我們會(huì)去做測(cè)試 Agent，測(cè)試 Agent 可以基于代碼 Agent 的生成結(jié)果，自動(dòng)完成一些測(cè)試任務(wù)，包括理解任務(wù)的需求、閱讀代碼、生成測(cè)試用例，并且自主運(yùn)行。

如果這兩步的成功率做的比較高的話，我們就會(huì)進(jìn)入到第三步。讓多 Agent 基于 AI 調(diào)度共同完成任務(wù)，從而實(shí)現(xiàn)從需求到代碼到測(cè)試的全流程自主化。

從工程的角度來(lái)講，我們會(huì)一步一步這么來(lái)走，確保每一步都達(dá)到一個(gè)比較好的生產(chǎn)級(jí)落地，最終去做產(chǎn)品。但是從學(xué)術(shù)來(lái)講，他們研究的速度會(huì)比我們更快，現(xiàn)在我們是從學(xué)術(shù)、工程討論的，我們還有第三個(gè)分支就是模型演進(jìn)。這三條路就是我們現(xiàn)在阿里云和通義實(shí)驗(yàn)室一起聯(lián)合在做的一些研究。

最終，我們會(huì)形成一個(gè) Multi-Agent 概念架構(gòu)，用戶可以跟大模型進(jìn)行對(duì)話，大模型可以進(jìn)行任務(wù)的拆解，然后有一個(gè)多 Agent 協(xié)同系統(tǒng)。這個(gè) Agent 可以外掛一些工具，它有自己的運(yùn)行環(huán)境，然后多 Agent 之間可以互相協(xié)同，它們還會(huì)共享一些上下文機(jī)制。

這個(gè)產(chǎn)品圖會(huì)分為三層。最下面是基礎(chǔ)層，對(duì)于企業(yè)來(lái)講，可以先把基礎(chǔ)層做好。比如現(xiàn)在可以引入一個(gè)代碼大模型，我們雖然沒有馬上實(shí)現(xiàn) AI Bot，但是現(xiàn)在已經(jīng)具備了 IDE 代碼生成插件的這些能力，已經(jīng)可以做一些工作了，就是 Copilot 的模式。

Copilot 模式在基建層上面，進(jìn)化了 Agent 這一層，實(shí)際上基建是可以復(fù)用的。該做的檢索增強(qiáng)、微調(diào)訓(xùn)練和知識(shí)庫(kù)，現(xiàn)在就可以做起來(lái)了。這些知識(shí)的梳理，資產(chǎn)的積累，是來(lái)自于原來(lái) DevOps 平臺(tái)的積累?，F(xiàn)在就可以通過(guò)一些提示詞工程的方式，將現(xiàn)在基礎(chǔ)的能力層跟整個(gè) DevOps 工具鏈進(jìn)行結(jié)合。

我們做了一些實(shí)驗(yàn)，在需求階段要想讓這個(gè)大模型來(lái)實(shí)現(xiàn)一個(gè)需求的自動(dòng)拆解，我們可能只需要將過(guò)去的一些拆解數(shù)據(jù)，還有現(xiàn)在的需求拼成一個(gè) prompt 給大模型，大模型就可以比較好的去完成拆解并且完成人員的分配。在實(shí)驗(yàn)中發(fā)現(xiàn)，結(jié)果的準(zhǔn)確率還是蠻高的。

其實(shí)現(xiàn)在整個(gè) DevOps 工具鏈，并不需要所有東西都要用 Agent或者都要用 Copilot。我們現(xiàn)在用一些提示詞工程，就有很多場(chǎng)景可以馬上去賦能，包括我們?cè)?CICD 過(guò)程中的自動(dòng)排錯(cuò)，在知識(shí)庫(kù)領(lǐng)域的智能問答等都可以實(shí)現(xiàn)。

在實(shí)現(xiàn)多 Agent 以后，這個(gè) Agent 可以在 IDE 里面透出，也可以在開發(fā)者的門戶，即 DevOps 平臺(tái)透出，甚至在我們的 IM 工具里面透出。它實(shí)際上是一個(gè)擬人的智能體。本身這個(gè)智能體它會(huì)有自己的工作區(qū)，在這個(gè)工作區(qū)里我們的開發(fā)者或者說(shuō)管理者可以去監(jiān)控它到底是如何幫我們完成代碼編寫的，如何幫我們完成測(cè)試的，它到底在互聯(lián)網(wǎng)上獲取了什么樣的知識(shí)去完成工作，會(huì)有一個(gè)它自己的工作空間，最終實(shí)現(xiàn)整個(gè)任務(wù)的完整流程。