本文作者：汪晟傑
導語:AISE（AI Software Engineering）有人說是軟件工程 3.0，即基於大模型（LLM - Large Language Model）時代下的軟件工程。那麼究竟什麼是 AISE，他的發展歷程對軟件工程產生怎樣的變化。本次主題文章會分爲五大部分：
1、軟件工程 3.0 與 AISE
2、基於 LLM 的代碼生成
3、應用形態思考
4、機遇與挑戰
5、小結
軟件工程 3.0 與 AISE
AI 時代下的軟件工程
軟件工程的發展可以分爲三個階段：軟件工程 1.0、軟件工程 2.0 和軟件工程 3.0。在這三個階段中，AI for SE（人工智能在軟件工程中的應用）的發展歷程如下：
軟件工程 1.0
在這個階段，軟件工程主要關注結構化編程、模塊化設計和數據結構。主要集中在基於規則的 MIS 專家系統、模式識別、平臺型工具等方面。當時如 Borland、Sybase 等產品，我在 05 年加入 Sybase PowerBuilder 和 PowerDesigner 產品組，負責過建模工具、MIS 系統開發平臺、UEP 移動開發平臺工具集（後面貢獻給到了 eclipse 開源組織）。這些產品當時試圖解決軟件工程下複雜應用投入產出高的問題，後來推出面向組件開發範式（OOC：面向組件編程）來提高開發效率，快速發佈上線，那個時候還不能稱爲 IDE，我們還是稱 RAD（Rapid Application Development）。當時我們也探索過 Big Code 的語義搜索能力也逐步開始研究等，但受限於當時的計算能力和 AI 技術水平，效果有限。
軟件工程 2.0
軟件工程逐漸從結構化編程轉向面向對象編程。AI for SE 的應用範圍和技術水平得到了進一步發展。例如，基於遺傳算法的優化技術被用於軟件設計和測試；神經網絡技術NLP被用於軟件缺陷預測；自然語言處理技術被用於需求分析和知識表示等。此外，軟件工程 2.0 更聚焦於流程統一，例如一些產品如 CODING DevOps、Gitlab 等。
軟件工程 3.0
在這個階段，軟件工程的關注點從面向對象編程轉向雲計算和 AI。隨着 AIGC 技術的這一年的高速發展，以 LLM 爲首的面向大模型的軟件工程體系也被國內外提出，如 GitLab Duo、Github Copilot X 等，使得 AI for SE 的應用前景變得更加廣泛。例如，深度學習技術被用於代碼生成和補全、缺陷檢測和自動修復；數據挖掘技術被用於軟件過程改進；自然語言處理技術被用於需求分析、代碼審查和文檔生成等。
總之，從軟件工程 1.0 到軟件工程 3.0，AI for SE 的發展歷程可以概括爲從初步嘗試到逐漸成熟，再到廣泛應用。隨着 AI 技術的不斷進步，AI for SE 將在未來的軟件工程領域發揮更加重要的作用。
AI for SE 和 SE for AI
AISE，我先用中文「智能化軟件工程」來定義，實際上他有兩個方向：一個是 AI for SE，另外一個方向是 SE for AI。
這兩個區別，我們先問下 ChatGPT，看看 AI 是怎麼解答的：
可見，軟件工程 3.0 就是 AI for SE，解決軟件工程 2.0 流程中的 AI 化，促使效率提升，流程化簡，讓 AI 在關鍵節點賦能開發。
SE for AI 是另一個維度，即思考軟件工程流程體系怎麼來實現智能化軟件應用，例如 ML-Ops 流程化 AI 應用研發。
這裏我們先圍繞 AI for SE 進行展開，至於智能化應用系統，如最近很火的面向AI的 Mojo 語言、更面向 AI 化的應用框架等等，我們以後再進行闡述。
基於 LLM 的代碼生成
大型代碼語言模型(Code LLM)的興起。其中一個用在軟件工程任務裏面的最基本的一個問題，就是代碼生成。
從 Codex 講起
在 2021 年 7 月 OpenAI 發佈出 Codex 論文《Evaluating Large Language Models Trained on Code》，這個論文當時可能並沒有太大的反響，雖然他們發佈了 HumanEval 的數據集，效果也不錯，但是在衆多文章中並沒有得到太多的關注。論文裏提到了 3 個模型，一個是基於 GPT-3 在代碼上微調來通過文本描述生成代碼的 Codex 模型（非監督學習）；另一個是進行監督訓練，通過文本描述生成代碼的 Codex-S 模型；最後一個是通過代碼生成代碼文本描述的 Codex-D 模型.
代碼微調Codex
利用 GitHub 上面的 5400 萬個公開倉庫，代碼是在 2020 年 5 月從 GitHub 上搜集的，每個 Python 文件是 1MB 以下的。最終我們的數據集是 159GB。
GitHub Copilot
2022 年 Github Copilot 正式上線對外公測，它是基於 Codex 的模型的訓練，背靠 Github 倉庫集，通過精調訓練的一套面向開發者的代碼補全產品。
代碼補全的產品價值
2021 年 10 月 29 日 OpenAI 發佈 Copilot 後，大家去試用有一個很深切的感受，確實是很震撼，它的能力比起之前的技術提升了一大步。
根據 DeveloperSuvey，受訪者認爲人工智能編碼助理將如何改變他們明年的工作，其中編寫代碼佔了 82.55%，70% 的受訪者正在或計劃在開發過程中使用人工智能工具，並且學習者比專業人士更有可能使用它們。
下圖爲騰訊雲 AI 代碼助手針對怎樣達成高用戶價值的思考框架。我們通過代碼模型精調訓練，在代碼補全、技術對話上給開發者提高效率。這點也已在內部進行了多次論證：當產品處於非常好的體驗的時候，會獲得非常高的用戶留存率。這裏提到的代碼生成的體驗，更關注在補全性能、產品交互、以及用戶開發習慣等方面。
在高留存率目標驅動的同時，還必須控制優化好成本，防止高頻訪問導致速度下降與成本上升、從而劣化產品體驗。需要重視 bad case 反饋與處理閉環、針對性專題性能調優、採取批量計算等策略；通過用戶看板觀察總結模型版本升級帶來的能力增益。最終通過一系列平衡手段，實現 AI 代碼助手在補全場景下的產品價值。
應用形態思考
面向開發者的編程提效
開發者有兩大羣體，一類是專業的開發人員，就是軟件工程師，那麼產品目的就是爲了提高開發人員的開發效率，把程序員從簡單重複的勞動中解放出來，從而關注架構、設計等複雜任務。現實場景中，用戶使用代碼生成特性時，通常會嘗試讀生成的代碼，從而決定是否採用或修改生成的代碼段。這是對 AI 項目理解能力的批判性思維，因此我們認爲目前的代碼生成/補全還是在爲 AI 輔助生成建議、生成相似邏輯。
實戰中，在騰訊雲 AI 代碼助手的配合下，我舉三個高頻使用的場景：
- 按 Entity 對象完善 getter/setter，甚至是關聯對象。
- 通過結構體，自動生成 SQL 及 DAO 對象。
第二類是代碼鑽研者、尋求代碼相關解答的開發者。這類用戶有什麼特性呢？他們執著於代碼本身，如算法，特定問題的解答，特定描述下的代碼生成（代碼建議後的試錯）。這類開發者的目的是：創建小的、即時使用的任務型應用程序，比如函數計算程序、支持用戶快速完成日程的任務。當然也有代碼學習者，對於代碼不是很熟悉的，可以通過代碼對話對代碼進行解讀，在對話中進行有效提問。
技術對話和代碼補全在實戰下是相輔相成的，爲了做到更好體驗，技術對話會採用更大規模的模型來獲得更好的推理能力，而代碼生成場景下則會採用更小的代碼模型來獲得更好的寫代碼的體驗感。
高粘性的編程體驗
- Fill in Middle 技術
模型只知道光標之前的代碼，還不能夠精確生成代碼，它還需要光標下文的代碼。解決辦法就是輸入中間填充的技術 (Fill in Middle)。OpenAI 去年在一篇論文中介紹了 FIM 論文，它允許語言模型在訓練過程中納入光標後面的上下文。
論文地址：https://arxiv.org/pdf/2207.14255.pdf
- Fill in Middle的原理簡介：
假設我們有一個如下所示的訓練示例：
我們希望模型學習 jumps over 從前綴 The quick brown fox 和後綴預測中間文本 over a lazy dog。首先，我們進行兩次切割來分隔這些部分，引入新的標記
、、 和
然後我們簡單地轉置中間和後綴：
現在，我們的訓練與之前完全相同，jumps over 從之前的文本預測接下來的文本。
The quick brown fox a lazy dog。該模型自動學習特殊標記的含義，並瞭解到它應該生成在前綴之後但在後綴之前有意義的文本！在推理時，如果我們嘗試填充如下所示的文檔：
我們可以將其呈現爲：
到模型並請求字符，直到模型發出令牌，此時它已成功將前綴與後綴連接起來。
下面幾張截圖是 AI 代碼助手通過 FIM 技術，實現通過光標上下文快速填補中間片段。在真實場景下，非常適合做成對出現的代碼函數，比如：加解密函數、通過 CR 自動生成 U(pdate)D(elete) 函數等。
- 更小的代碼補全模型
代碼補全的觸發時機是真正伴隨在日常開發中的，無時無刻去根據上文生成下文代碼，如下圖所示。所以這裏的模型更應該是小模型。在 AI 代碼助手下，我們將其定義爲補全小模型，帶來的性能收益是巨大的。GitHub Copilot 也嘗試在端上內置更小的微模型，讓成本、速度優先作爲補全產品的前提。
基於混元大模型的 AI 代碼助手的行業產品
未來基於混元會對外推出公測版本，結合小模型提供可商業化、可私有化、可共創合作，爲行業客戶的研發 AI 賦能。
目前支持 Python、JavaScript/TypeScript、Java、C/C++、Go、Rust、swift、SQL 等主流語言，並支持各大主流 IDE 平臺。
AI 代碼助手的產品從開發者的頻次最高的場景作爲切入，以代碼補全作爲優先行業落地的能力，以技術對話模型共創成對話平臺，並計劃接入測試和診斷能力。
機遇與挑戰
面向行業開發的 SMAF 機遇
代碼模型落地企業會遇到很多挑戰。像海外的企業，對於使用 Copilot，ChatGPT 沒有太多的顧慮，但是在國內絕大部分的軟件企業或研發軟件機構，自己企業或機構內部的代碼是不能夠流傳至外網的，需要私有化部署。私有部署往往需要性能強大的 GPU 集羣，全面開發給大型軟件研發團隊使用成本很高；以及企業內網環境使用的的庫或框架無法使用開源項目代碼比如 GitHub 等，怎麼能夠支撐好這些場景都需要考慮如何解決。
騰訊自研的代碼模型也充分考慮到企業內部數據資產監管所面臨的各項挑戰和實際訴求，讓受管控企業也可以在一個受控的環境內將 AI 代碼助手使用起來，並且希望能夠支持全場景。讓項目經理、市場人員、設計、開發及測試人員都可以有自己的實現場景，這是我們主要的目標。
- 什麼是SMAF？
SMAF 包含以下內容：
Security：AISE 產品部署在私有云環境。業務代碼內網託管，通過內部訓練模型，構建集成 IDE 環境，通過自定義邏輯集成業務代碼與模型輸入/輸出，杜絕引入外部安全漏洞；
MaaS：具備多模型統一管理能力。引入多個行業模型，基於不同業務特性和團隊習慣進行二次訓練，從而得到專屬的企業模型；
Analysis：具備指標可觀測看板。定義關鍵指標，對於企業管理者，可以有效觀察團隊使用代碼助手對團隊的提升效果。
Full：覆蓋全開發流程。AI 代碼助手應該覆蓋溝通、編碼、排錯、評審、調優等必要場景。並優先關注編碼，溝通環節注重行業深度落地。
我們在內部進行了長期持續的生產內測，正向反饋逐步增加，統計數數據也證明了產品具備相當的價值，這使我們對產品的進一步優化更有信心。
又如在某外部金融企業客戶的實測中，我們基於多模平臺導入私有化行業模型，基於內部安全合規的語料進行二次訓練和微調，重點打磨代碼補全、技術對話特性，逐步推廣內部試用，完善產品體驗，取得了令人初步滿意的成效。
橄欖型產品設計和多模型接入
企業內部可能會存在多種代碼模型，不同團隊可能會使用不同的模型。而應用側的產品交互體驗，到數據效率報表，這兩端則變化不大。於是我們提出了“橄欖型”的應用設想。什麼是“橄欖型”呢，就是兩端非常的統一，一端是應用交互、執行策略、Prompt設計等高度一致，另一端是數據統計的邏輯，監控和配置平臺等高度一致，實現可管理可插拔。中間鼓出來的部分就是多模型接入。用戶可以根據不同的業務屬性，按需加載不同模型，也可以通過 MaaS 平臺爲企業按需訓練模型，併發布到中間平臺裏，通過配置下發，自動更新端上配置，即可滿足業務對於模型版本的升級。
大模型的“可信”挑戰
現在不管是基於大模型的代碼生成還是其他場景，怎麼樣確保可信非常關鍵。生成的代碼或其他場景的產物不見得 100% 正確。有一些場景比如說娛樂、生圖或者視頻合成，只是在娛樂行業或者廣告行業，沒有嚴格意義上對錯的場景，這些比較好理解，落地還是比較順利的。但是在有確定對錯的場景，如果萬一錯了，造成的後果較大，怎麼去應對如果沒有解決好可能會成問題的。
我們認爲一個值得信賴的代碼生成模型，應該具備：
準確率高；
魯棒性高、穩定性高；
不生成危險代碼，如不安全的代碼、可能產生社會歧視的代碼、可能泄漏隱私的代碼；
行爲可預測可控。
模型“評測”挑戰
關於代碼大模型的能力提升，這也是我們需要持續去應對的。程序語言和自然語言有很大不同，如何針對代碼特性設計模型結構和訓練方式是值得探索和推進的方向。只將靜態代碼輸入給大模型會由於輸入信息量不足而導致大模型對程序的理解不夠，如何構造讓模型更容易學習和理解的輸入數據，比如增加動態執行信息，通過程序語義等價性生成額外的等價程序，會有助於大模型做到程序理解。
如今大家都採用 HumanEval 進行準確度評測，百分比不斷提升，可能百分之七八十在特定的數據集上。但競賽題是比較自包含的，沒有太大的耦合度和環境，怎麼在真實的代碼場景裏能做到更好也是一個開放性的課題，需要大家一起往前推進。
今年年初，還沒有 HumanEval 的時候，我們非常頭疼，怎麼來驗證模型的正確性和可靠性。我們採用了國外的一個開源框架，思路很簡單：用 GPT4 做老師出題，題目從網上搜颳得來，通過 GPT4 搜索和清洗。然後進行模型的兩兩對比。對比打分的也是 GPT4，打分標準依據代碼的五大維度，即：代碼語法、可讀性、運行結果、複雜度、完整性。示例 prompt 如下：
sys_prompt = "你是檢查代碼答案質量的有用而精確的助手。你的任務是評估兩位助手的編碼能力。他們被要求編寫一個代碼程序來解決給定的問題。請查看他們提交的代碼，密切關注他們解決問題的方法、代碼結構、可讀性。請確保助手提交的代碼：1. 根據問題寫出正確邏輯的代碼。2. 包含準確高效的代碼。3. 遵守正確的編碼標準和最佳做法。" sys_prompt1 = "你是檢查代碼答案質量的有用而精確的助手。你的任務是評估兩位助手的編碼能力。他們被要求根據一段不完整的代碼進行代碼補全。請查看他們提交的代碼，密切關注他們解決問題的方法、代碼結構、可讀性。請確保助手提交的代碼：1. 根據問題寫出正確邏輯的代碼。2. 包含準確高效的代碼。3. 遵守正確的編碼標準和最佳做法。" default_prompt = "在你根據問題仔細審查了這兩個提交後，請提供有關其優點和缺點的詳細反饋，以及任何改進建議。您應該首先在第一行輸出，其中包含助手 1 和助手 2 的 0-10 分（0: 回答錯誤；1：無代碼/無意義；10：完美）的兩個分數，例如“9 8”。然後從下一行開始給出額外的評論。" default_ques = "我的問題是：\n" default_ques1 = "需要補全的代碼是：\n"這樣我們得到了很多國內外的評測結果。後來和 humaneval 測試結果進行比對，也具備一定的可參考性。
軟件工程 AISE 全流程覆蓋的挑戰
另一個挑戰是代碼大模型下游任務的生態建設，包括測試、調試等更多下游任務及應用細分領域的拓展，輔助解決更多的工程任務；以及更多支撐上下游任務的工具鏈，包括需求分解、測試用例生成、調試/修復等工具，以更好地支撐智能化軟件工程任務。
我們目前只定位在開發工程師角度，其他流程下的不同角色還沒有探索，也不能僅憑我們來定義。這類人羣有着自己的領域知識、實踐流程等等。
LLM 的規模也許會越來越大，也會有各色的專業垂直 LLM 問世，扎深特定的方向，做透一個點，找到產品和商業價值，並與流程中的其他垂直人羣正交。
AISE 不僅覆蓋開發者。即便是開發域，國內外的研發差異也不同，定義面向國內開發者的研發流程的 AI for SE，需要通過我們對於行業的理解，不斷深入思考並不斷試錯。
小結
整體來講，AI for SE 以及軟件工程 3.0，是我們需要擁抱的能夠讓我們振奮人心的方向，但是我們也要冷靜的思考，AI 和 LLM 是手段，提高效率降本增效是訴求。如何利用好大模型的落地，控制好 LLM 的計算成本，找到行業內研發流程的核心問題，通過 AI 和 LLM 手段去解決，把最高最緊急的痛點去落地解決。由於大模型的挑戰和特殊性，企業也必須冷靜思考，推行安全可信的模型驗證工作，把 AISE 的流程的每個核心場景做透做紮實。
