智能編碼工具的快速普及是否會帶來全新的編程模式？“大力出奇跡”的規律還將繼續適用嗎？本文節選自 QCon 北京特別策劃圓桌節目，內容摘自阿里雲通義靈碼產品技術負責人陳鑫在圓桌對話裏的精彩回答。全文見：Sora很難跟進？微調就不是一個崗位？大力出奇跡將繼續適用？大模型將對軟件生態帶來哪些變化？
觀點 1：智能編碼工具將被更加廣泛的應用，甚至出現全新的編程模式。不擅長利用大模型來輔助代碼開發的程序員未來一段時間將被淘汰。
陳鑫（神秀）： 去年，ChatGPT 火了以後，我們立即開始着手利用大模型技術進行代碼智能生成方向的工作。在此之前，我們已經有些探索，我們團隊大約在 2021 年開始嘗試代碼工具的研發。起初，我有些悲觀，因爲我覺得以現在的投入，無論是在數據、算法還是人才方面，都無法超過當時 GitHub 的投入。隨着大語言模型的火熱，我們意識到這個方向的商業化價值以及給開發者帶來的價值都是巨大的。因此，去年年初，通義靈碼就成爲通義系列大模型產品家族的一員。
通義靈碼是一款基於通義大模型的智能編碼助手，提供自然語言生成代碼、單元測試生成、代碼優化、註釋生成、智能問答等能力，通義靈碼上線 4 個月，目前下載量已經超過 130 萬，在國內 AI 編碼工具領域使用率第一。 但是，從最開始的產品發佈、到現在靈碼的產品能力獲得用戶的一致好評，這中間我們經歷了非常多的困難。
最開始，我們嘗試了基於開源模型，然後基於通義的基礎模型進行訓練，這其中挑戰與機遇並存。一方面，我們感覺與 Github Copilot 的差距在逐步縮小，但我們也非常擔心出現 Sora 這種情況，即突然有一個全新的架構或算法來顛覆我們之前的努力。另一方面，從國內接受度來看，最近一些媒體包括我們自己也進行了廣泛調研，發現開發者對 AI 編碼工具的接受度非常高，甚至有報道稱 80% 到 90% 的開發者都在採用相關工具，這就意味着這種生產力工具對開發者的價值是實實在在的。
代碼智能生成工具可能是業內最成功的大模型相關應用之一。 我們現在跟很多客戶接觸，客戶也覺得在基礎模型的落地上需要探索很多場景，解決方案的複雜度很高，而代碼模型的門檻非常低。我們發現大模型代碼生成在 IDE 編碼場景下非常適合當前的技術現狀，因爲不僅用戶的接受度高，而且特別適合當前的技術現狀。我認爲它在這個領域的成功可能是必然。
我們最近訪談了很多企業，發現一些先驅型企業已經在思考如何使他們的代碼框架和研發模式適應 AI。這可能是許多人未曾思考過的問題，如今 AI 對代碼的理解方式還存在一定侷限性，但我們可以通過一些調整讓 AI 生成的準確率更高。
我們最近訪談的一個客戶，他們的做法是讓高級工程師用自然語言編寫僞代碼，然後將其定義好的數據和接口與自然語言註釋一起交給大模型生成代碼。然後初級工程師對其進行修正，這樣提高了研發效率，也提升了高級工程師的價值。初級工程師的效率也得到了提升，整體上提升了專業性，不再是一個人從頭到尾完成。這種方式避免了重複工作和精力浪費，企業未來可能會考慮採用所謂的 AI 原生（AI Native）研發模式。
國外一些項目已經嘗試使用自然語言框架，按照 AI 理解的方式生成代碼，大模型幫助生成整個工程的代碼，生成的代碼既有註釋又有代碼，這樣如果出現變更，大模型可以很容易理解它自己生成的代碼，形成良性循環。我認爲這可能會在一年內實現，隨着基礎模型能力和理解力的提升以及 AI 原生編程框架的發展，可能會出現全新的代碼編寫模式。
觀點 2：開放模型擁有廣闊的前景，大模型未來的競爭很可能是流量入口之爭、是生態之爭。而谷歌是否會將 Gemma 開放模型融入 Android 和 Chrome 生態是值得期待的。
陳鑫（神秀）： 在模型開源方面，阿里雲做了很多工作，包括開源了 7B、14B 等模型，前幾個月還開源了 72B 和 72B 模型的 1.5 版本。我們內部也是通過外面媒體得知有新版本的消息，之後才進行模型的升級。我覺得阿里雲在開源領域非常用心，特別是在通義團隊這邊。
開源模型對企業，尤其是中大型企業的整體業務能力構建起到了關鍵作用。有了開源版本，企業可以以較低的成本進行實驗，而不必花費大量資金購買商業化模型。企業可以先利用開源模型做一些實驗，並結合一些 Prompt 的調優，就可以得到比較好的結果。
從我對企業的觀察來看，開源對大模型產業的推進非常關鍵。我擔憂現在模型參數量的增加會帶來更大的算力需求。雖然開源模型的參數量越來越大，但企業面臨的最大難題仍然是缺乏足夠的算力。即使是 2B 模型的訓練成本也很高，而現在很多企業甚至連推理資源都買不到，更別說進行訓練了。企業需要考慮在公共雲上構建訓練，而不是自建。很多企業過去可能不考慮上公共雲，但是現在這個問題可能會長期存在。企業需要權衡自建和使用公共雲的成本，並考慮自建是否會導致錯過競爭優勢。
雖然現在各個廠商都在推動開源，但是將開源的價值真正落到企業的生產效益中仍然面臨許多挑戰。但我相信各個廠家已經意識到了這一點，並且可能會在未來幾個月推出更多的芯片，希望能夠解決企業面臨的算力問題，包括雲上算力的問題，希望我們能夠儘快度過這個難關。
觀點 3：簡單的標註被 AI 取代，複雜標註對“人”的要求越來越高。
陳鑫（神秀）： 這個話題我們非常感同身受，因爲代碼大模型的質量與高質量數據息息相關。提升模型本身的能力主要依賴於高質量數據，而代碼領域又是一個專業的領域。過去幾個月，我們花費了大量時間和資深專家去處理數據，只有將數據處理到足夠好，才能獲得更好的調優結果。
代碼優化是一項艱鉅的任務。 我們需要確定有問題的代碼，解決 bug 後優化的代碼，優化的原因可能是風格問題、內存泄漏或安全性問題等。數據收集、處理和分析是關鍵，對下游任務的影響很大。我們在調整大模型以準確預測開發者行爲和生成期望結果的過程中，需要處理大量數據，包括各種語言的語法分析、切分和數據構造等。預訓練過程中可能會發現數據處理中的 bug，導致生成代碼中出現語法錯誤或不合適的情況，需要返回修正。這一工作量較大且需要資深專家。
剛開始的階段，人們可能認爲數據標註不需要大量人工，會考慮使用 AI 代替，但隨着深入瞭解，發現這些看似容易的事情實際上還是需要專家去做。未來，有經驗的程序員可能會投入更多時間到企業內部的數據標註和處理，並訓練企業專屬的代碼模型，以生成符合企業規範要求的代碼。
GitHub Copilot 過去一直未推出企業個性化套件，直到最近才推出了類似於私有化模型的訓練方法，通義靈碼的個性化套件也將在 4 月份上線。 我們預測接下來的趨勢是，各個企業的員工可能都在嘗試使用 AI 工具進行編碼，隨後各公司可能需要專人投入到數據處理和標註，以訓練企業私有模型。
對於專家和工程師來說，尤其是那些曾經從事代碼框架、中間件、規範、基礎 SDK 和 API 開發的人，他們首先會將這些內容編寫出來，然後將這些內容融入到大模型中，以便所有人都能從代碼生成中受益，這是未來各企業需要考慮的重要問題。
觀點 4：通過公共雲平臺獲取算力是算力緊缺的當下值得企業認真考慮的解決方案，短期內我們可能很難擺脫“大力出奇跡”的規律。
陳鑫（神秀）： 在代碼領域，我們觀察到一個明顯的趨勢：具有較大參數量的模型（例如 72B）在推理能力和理解能力上，尤其是處理長上下文方面，表現得比小參數模型要好得多。例如，當你要求模型爲 1,000 行代碼生成註釋或單元測試時，小參數模型可能在處理前一兩百行代碼時還能保持正常，但隨後性能會逐漸下降，甚至可能出現偷懶、忘記任務或開始出錯的情況，而參數量較大的模型則能更好地處理這些問題。
我認爲在一段時間內，尤其是在代碼領域，我們無法擺脫“大力出奇跡”的規律。 對於一些簡單的任務，使用非常大的參數模型可能並不必要。例如，在通義靈碼平臺上，線上也並不全是使用千億參數的模型。我們有不同參數規模的模型，如百億參數、幾十億參數的模型，並且會根據任務的不同，將任務調度到相應的模型上。我們也在嘗試形成各種專家模型的組合，並計劃進行 DevOps 整個全鏈路的智能化改造。這有點類似於企業的流程再造， 只是 DevOps 的軟件生產流程與企業生產流程相似。在這個流程中，並不是所有的任務都需要使用非常大的參數模型。我們可以通過組合各種不同參數規模的模型，以及訓練出的下游任務能力，來完成流程的改造。
我認爲，使用多大規模的模型是需要企業去不斷嘗試的。但首先，我們需要解決算力問題。一旦解決了初始的算力問題，我們就可以開始逐步前進。至於後續的芯片問題，我相信最終也會得到解決。包括許多互聯網大廠和國內頂尖的芯片製造企業，現在都在努力去創造一些改變。
觀點 5：微調工程師崗位可能並不存在，但微調是一項必備技能，瞭解業務並將其需求轉化爲真正的 Prompt 纔是真正的價值點。
陳鑫（神秀）：如果你想要進行微調，但不理解業務，那麼你的價值就會非常有限。 如果將微調定義爲一個崗位，那麼這個崗位應該具有深厚的價值，並且需要長期的積累和能力。
如果這個崗位的價值和能力很容易被替代，或者很容易學習，那麼它可能就不會成爲一個獨立的崗位。以我們的例子來說，通義靈碼本身就包含了一個非常簡單的微調訓練平臺。這是因爲我們把工程師在微調代碼模型的所有經驗都內置到了平臺中，並且添加了一些配置。一個工程師通過一兩天的培訓，基本上就能掌握這些概念，開始進行微調工作。在代碼領域，至少在我看來，這個門檻並沒有大家想象的那麼高。但在其他領域，門檻可能會更高。
對於專家知識來說，如何選擇合適的數據、如何處理數據、如何解決出現的問題、如何校正訓練不佳的模型、如何通過不斷實驗訓練出符合預期的模型，以及是否清楚自己訓練模型的目的，這些都是微調工程師需要考慮的問題。例如，如果你想要微調模型以理解特定的 SDK 庫，並在代碼補全時生成可以直接調用企業內部 SDK 或 API 的代碼，那麼你需要考慮如何教會模型實現這一點，構造什麼樣的數據，如何標註數據，以及如何篩選和處理數據。這些問題可能不是一個簡單的微調工程師就能解決的。
未來，像原來的效能工程師或者中臺的資深研發人員可能都需要具備微調的能力，將自己的代碼資產訓練到大模型中，讓整個公司的人都能使用。所以，未來每個人都需要具備理解模型、處理數據和進行微調的能力，如果這成爲一個必備技能，那麼就不會存在一個專門稱爲“微調工程師”的崗位了。
觀點 6：2024 年，Agent 將率先在 B 端落地。今年下半年，我們預計將看到大量 Agent 相關的實踐和落地案例。
陳鑫（神秀）：關於 AI Agent 的話題，我認爲今年它肯定會非常火熱，甚至在代碼領域也會受到關注。根據當前的趨勢，我們可以預見這個過程將分爲幾個步驟。首先，大家會開始採用能夠進行代碼生成或續寫的模型。接下來，會進行企業個性化的定製。正如我們之前討論的微調，實際上已經涉及到了這個過程。然後，我們會進一步擴展這些模型的能力，目標是提高整個軟件生產鏈條的效率。爲了實現這一目標，我們肯定會利用 AI Agent 技術。
在沒有模型的時候，我們需要訓練這個“大腦”，然後通過像通義靈碼這樣的平臺，專注於完成最核心、價值最大的任務。完成這些任務後，接下來就是構建 AI Agent。我們會搭建好平臺，讓各個企業基於這個平臺構建自己的 AI Agent。研發領域的場景可能有上百甚至幾百個，如果每個企業都進行個性化定製，那將是成千上萬的需求，這顯然不是一個團隊能夠獨立完成的。
現在，各方面的技術探索已經非常成熟，我認爲今年確實是 AI Agent 落地的關鍵一年。經過去年一年對模型和參數的優化，今年我們應該開始考慮企業個性化以及 AI Agent 的實際應用。我們已經看到，2024 年將有大量行業領先的客戶開始在代碼生成或代碼助手領域落地。一旦他們起到了帶頭作用，相關的實踐經驗將會被大家所看到。
目前，我們在網上很少看到關於 AI Agent 實踐的案例，這是因爲整個行業還沒有發展到那一步。預計 6 月份之後，將會有實踐經驗出現，下半年將會有大量 AI Agent 落地的場景和效果展示的文章，我對 AI Agent 的發展前景抱有極大的期望，這也是我們今年建設的重點。
點擊此處，體驗通義靈碼，開驚喜 AI 盲盒。