智能編碼工具的快速普及是否會帶來全新的編程模式?“大力出奇跡”的規(guī)律還將繼續(xù)適用嗎?本文節(jié)選自 QCon 北京特別策劃圓桌節(jié)目，內容摘自阿里云通義靈碼產品技術負責人陳鑫在圓桌對話里的精彩回答。全文見:Sora很難跟進?微調就不是一個崗位?大力出奇跡將繼續(xù)適用?大模型將對軟件生態(tài)帶來哪些變化?

點擊進入通義靈碼官網，體驗工具強大的能力:https://tongyi.aliyun.com/lingma

觀點1:智能編碼工具將被更加廣泛的應用，甚至出現全新的編程模式。不擅長利用大模型來輔助代碼開發(fā)的程序員未來一段時間將被淘汰。

陳鑫（神秀）:去年，ChatGPT 火了以后，我們立即開始著手利用大模型技術進行代碼智能生成方向的工作。在此之前，我們已經有些探索，我們團隊大約在2021年開始嘗試代碼工具的研發(fā)。起初，我有些悲觀，因為我覺得以現在的投入，無論是在數據、算法還是人才方面，都無法超過當時 GitHub 的投入。隨著大語言模型的火熱，我們意識到這個方向的商業(yè)化價值以及給開發(fā)者帶來的價值都是巨大的。因此，去年年初，通義靈碼就成為通義系列大模型產品家族的一員。

通義靈碼是一款基于通義大模型的智能編碼助手，提供自然語言生成代碼、單元測試生成、代碼優(yōu)化、注釋生成、智能問答等能力，通義靈碼上線4個月，目前下載量已經超過130萬，在國內 AI 編碼工具領域使用率第一。但是，從最開始的產品發(fā)布、到現在靈碼的產品能力獲得用戶的一致好評，這中間我們經歷了非常多的困難。

最開始，我們嘗試了基于開源模型，然后基于通義的基礎模型進行訓練，這其中挑戰(zhàn)與機遇并存。一方面，我們感覺與 Github C o p i ot 的差距在逐步縮小，但我們也非常擔心出現 Sora 這種情況，即突然有一個全新的架構或算法來顛覆我們之前的努力。另一方面，從國內接受度來看，最近一些媒體包括我們自己也進行了廣泛調研，發(fā)現開發(fā)者對 AI 編碼工具的接受度非常高，甚至有報道稱80% 到90% 的開發(fā)者都在采用相關工具，這就意味著這種生產力工具對開發(fā)者的價值是實實在在的。

代碼智能生成工具可能是業(yè)內最成功的大模型相關應用之一。我們現在跟很多客戶接觸，客戶也覺得在基礎模型的落地上需要探索很多場景，解決方案的復雜度很高，而代碼模型的門檻非常低。我們發(fā)現大模型代碼生成在 IDE 編碼場景下非常適合當前的技術現狀，因為不僅用戶的接受度高，而且特別適合當前的技術現狀。我認為它在這個領域的成功可能是必然。

我們最近訪談了很多企業(yè)，發(fā)現一些先驅型企業(yè)已經在思考如何使他們的代碼框架和研發(fā)模式適應 AI。這可能是許多人未曾思考過的問題，如今 AI 對代碼的理解方式還存在一定局限性，但我們可以通過一些調整讓 AI 生成的準確率更高。

我們最近訪談的一個客戶，他們的做法是讓高級工程師用自然語言編寫偽代碼，然后將其定義好的數據和接口與自然語言注釋一起交給大模型生成代碼。然后初級工程師對其進行修正，這樣提高了研發(fā)效率，也提升了高級工程師的價值。初級工程師的效率也得到了提升，整體上提升了專業(yè)性，不再是一個人從頭到尾完成。這種方式避免了重復工作和精力浪費，企業(yè)未來可能會考慮采用所謂的 AI 原生（AI Native）研發(fā)模式。

國外一些項目已經嘗試使用自然語言框架，按照 AI 理解的方式生成代碼，大模型幫助生成整個工程的代碼，生成的代碼既有注釋又有代碼，這樣如果出現變更，大模型可以很容易理解它自己生成的代碼，形成良性循環(huán)。我認為這可能會在一年內實現，隨著基礎模型能力和理解力的提升以及 AI 原生編程框架的發(fā)展，可能會出現全新的代碼編寫模式。

觀點2:開放模型擁有廣闊的前景，大模型未來的競爭很可能是流量入口之爭、是生態(tài)之爭。而谷歌是否會將 Gemma 開放模型融入 Android 和 Chrome 生態(tài)是值得期待的。

陳鑫（神秀）:在模型開源方面，阿里云做了很多工作，包括開源了7B、14B 等模型，前幾個月還開源了72B 和72B 模型的1.5版本。我們內部也是通過外面媒體得知有新版本的消息，之后才進行模型的升級。我覺得阿里云在開源領域非常用心，特別是在通義團隊這邊。

開源模型對企業(yè)，尤其是中大型企業(yè)的整體業(yè)務能力構建起到了關鍵作用。有了開源版本，企業(yè)可以以較低的成本進行實驗，而不必花費大量資金購買商業(yè)化模型。企業(yè)可以先利用開源模型做一些實驗，并結合一些 Prompt 的調優(yōu)，就可以得到比較好的結果。

從我對企業(yè)的觀察來看，開源對大模型產業(yè)的推進非常關鍵。我擔憂現在模型參數量的增加會帶來更大的算力需求。雖然開源模型的參數量越來越大，但企業(yè)面臨的最大難題仍然是缺乏足夠的算力。即使是2B 模型的訓練成本也很高，而現在很多企業(yè)甚至連推理資源都買不到，更別說進行訓練了。企業(yè)需要考慮在公共云上構建訓練，而不是自建。很多企業(yè)過去可能不考慮上公共云，但是現在這個問題可能會長期存在。企業(yè)需要權衡自建和使用公共云的成本，并考慮自建是否會導致錯過競爭優(yōu)勢。

雖然現在各個廠商都在推動開源，但是將開源的價值真正落到企業(yè)的生產效益中仍然面臨許多挑戰(zhàn)。但我相信各個廠家已經意識到了這一點，并且可能會在未來幾個月推出更多的芯片，希望能夠解決企業(yè)面臨的算力問題，包括云上算力的問題，希望我們能夠盡快度過這個難關。

觀點3:簡單的標注被 AI 取代，復雜標注對“人”的要求越來越高。

陳鑫（神秀）:這個話題我們非常感同身受，因為代碼大模型的質量與高質量數據息息相關。提升模型本身的能力主要依賴于高質量數據，而代碼領域又是一個專業(yè)的領域。過去幾個月，我們花費了大量時間和資深專家去處理數據，只有將數據處理到足夠好，才能獲得更好的調優(yōu)結果。

代碼優(yōu)化是一項艱巨的任務。我們需要確定有問題的代碼，解決 bug 后優(yōu)化的代碼，優(yōu)化的原因可能是風格問題、內存泄漏或安全性問題等。數據收集、處理和分析是關鍵，對下游任務的影響很大。我們在調整大模型以準確預測開發(fā)者行為和生成期望結果的過程中，需要處理大量數據，包括各種語言的語法分析、切分和數據構造等。預訓練過程中可能會發(fā)現數據處理中的 bug，導致生成代碼中出現語法錯誤或不合適的情況，需要返回修正。這一工作量較大且需要資深專家。

剛開始的階段，人們可能認為數據標注不需要大量人工，會考慮使用 AI 代替，但隨著深入了解，發(fā)現這些看似容易的事情實際上還是需要專家去做。未來，有經驗的程序員可能會投入更多時間到企業(yè)內部的數據標注和處理，并訓練企業(yè)專屬的代碼模型，以生成符合企業(yè)規(guī)范要求的代碼。

GitHub C o p ilot 過去一直未推出企業(yè)個性化套件，直到最近才推出了類似于私有化模型的訓練方法，通義靈碼的個性化套件也將在4月份上線。我們預測接下來的趨勢是，各個企業(yè)的員工可能都在嘗試使用 AI 工具進行編碼，隨后各公司可能需要專人投入到數據處理和標注，以訓練企業(yè)私有模型。

對于專家和工程師來說，尤其是那些曾經從事代碼框架、中間件、規(guī)范、基礎 SDK 和 API 開發(fā)的人，他們首先會將這些內容編寫出來，然后將這些內容融入到大模型中，以便所有人都能從代碼生成中受益，這是未來各企業(yè)需要考慮的重要問題。

觀點4:通過公共云平臺獲取算力是算力緊缺的當下值得企業(yè)認真考慮的解決方案，短期內我們可能很難擺脫“大力出奇跡”的規(guī)律。

陳鑫（神秀）:在代碼領域，我們觀察到一個明顯的趨勢:具有較大參數量的模型(例如72B)在推理能力和理解能力上，尤其是處理長上下文方面，表現得比小參數模型要好得多。例如，當你要求模型為1，000行代碼生成注釋或單元測試時，小參數模型可能在處理前一兩百行代碼時還能保持正常，但隨后性能會逐漸下降，甚至可能出現偷懶、忘記任務或開始出錯的情況，而參數量較大的模型則能更好地處理這些問題。

我認為在一段時間內，尤其是在代碼領域，我們無法擺脫“大力出奇跡”的規(guī)律。對于一些簡單的任務，使用非常大的參數模型可能并不必要。例如，在通義靈碼平臺上，線上也并不全是使用千億參數的模型。我們有不同參數規(guī)模的模型，如百億參數、幾十億參數的模型，并且會根據任務的不同，將任務調度到相應的模型上。我們也在嘗試形成各種專家模型的組合，并計劃進行 DevOps 整個全鏈路的智能化改造。這有點類似于企業(yè)的流程再造，只是 DevOps 的軟件生產流程與企業(yè)生產流程相似。在這個流程中，并不是所有的任務都需要使用非常大的參數模型。我們可以通過組合各種不同參數規(guī)模的模型，以及訓練出的下游任務能力，來完成流程的改造。

我認為，使用多大規(guī)模的模型是需要企業(yè)去不斷嘗試的。但首先，我們需要解決算力問題。一旦解決了初始的算力問題，我們就可以開始逐步前進。至于后續(xù)的芯片問題，我相信最終也會得到解決。包括許多互聯網大廠和國內頂尖的芯片制造企業(yè)，現在都在努力去創(chuàng)造一些改變。

觀點5:微調工程師崗位可能并不存在，但微調是一項必備技能，了解業(yè)務并將其需求轉化為真正的 Prompt 才是真正的價值點。

陳鑫（神秀）:如果你想要進行微調，但不理解業(yè)務，那么你的價值就會非常有限。如果將微調定義為一個崗位，那么這個崗位應該具有深厚的價值，并且需要長期的積累和能力。

如果這個崗位的價值和能力很容易被替代，或者很容易學習，那么它可能就不會成為一個獨立的崗位。以我們的例子來說，通義靈碼本身就包含了一個非常簡單的微調訓練平臺。這是因為我們把工程師在微調代碼模型的所有經驗都內置到了平臺中，并且添加了一些配置。一個工程師通過一兩天的培訓，基本上就能掌握這些概念，開始進行微調工作。在代碼領域，至少在我看來，這個門檻并沒有大家想象的那么高。但在其他領域，門檻可能會更高。

對于專家知識來說，如何選擇合適的數據、如何處理數據、如何解決出現的問題、如何校正訓練不佳的模型、如何通過不斷實驗訓練出符合預期的模型，以及是否清楚自己訓練模型的目的，這些都是微調工程師需要考慮的問題。例如，如果你想要微調模型以理解特定的 SDK 庫，并在代碼補全時生成可以直接調用企業(yè)內部 SDK 或 API 的代碼，那么你需要考慮如何教會模型實現這一點，構造什么樣的數據，如何標注數據，以及如何篩選和處理數據。這些問題可能不是一個簡單的微調工程師就能解決的。

未來，像原來的效能工程師或者中臺的資深研發(fā)人員可能都需要具備微調的能力，將自己的代碼資產訓練到大模型中，讓整個公司的人都能使用。所以，未來每個人都需要具備理解模型、處理數據和進行微調的能力，如果這成為一個必備技能，那么就不會存在一個專門稱為“微調工程師”的崗位了。

觀點6:2024年，Agent 將率先在 B 端落地。今年下半年，我們預計將看到大量 Agent 相關的實踐和落地案例。

陳鑫（神秀）:關于 AI Agent 的話題，我認為今年它肯定會非?；馃?，甚至在代碼領域也會受到關注。根據當前的趨勢，我們可以預見這個過程將分為幾個步驟。首先，大家會開始采用能夠進行代碼生成或續(xù)寫的模型。接下來，會進行企業(yè)個性化的定制。正如我們之前討論的微調，實際上已經涉及到了這個過程。然后，我們會進一步擴展這些模型的能力，目標是提高整個軟件生產鏈條的效率。為了實現這一目標，我們肯定會利用 AI Agent 技術。

在沒有模型的時候，我們需要訓練這個“大腦”，然后通過像通義靈碼這樣的平臺，專注于完成最核心、價值最大的任務。完成這些任務后，接下來就是構建 AI Agent。我們會搭建好平臺，讓各個企業(yè)基于這個平臺構建自己的 AI Agent。研發(fā)領域的場景可能有上百甚至幾百個，如果每個企業(yè)都進行個性化定制，那將是成千上萬的需求，這顯然不是一個團隊能夠獨立完成的。

現在，各方面的技術探索已經非常成熟，我認為今年確實是 AI Agent 落地的關鍵一年。經過去年一年對模型和參數的優(yōu)化，今年我們應該開始考慮企業(yè)個性化以及 AI Agent 的實際應用。我們已經看到，2024年將有大量行業(yè)領先的客戶開始在代碼生成或代碼助手領域落地。一旦他們起到了帶頭作用，相關的實踐經驗將會被大家所看到。

目前，我們在網上很少看到關于 AI Agent 實踐的案例，這是因為整個行業(yè)還沒有發(fā)展到那一步。預計6月份之后，將會有實踐經驗出現，下半年將會有大量 AI Agent 落地的場景和效果展示的文章，我對 AI Agent 的發(fā)展前景抱有極大的期望，這也是我們今年建設的重點。

（舉報）