嘉賓 | 張樹波
作者 | 凌敏
大模型的出現引發了一場軟體工程革命，它根本性地改變了軟體開發的流程和方式。當下，越來越多的企業開始在實際的研發工作中，結合大模型增強軟體開發在設計、需求、測試、發布和運維等各個環節中的能力，提高質量和效率。
在接受 InfoQ 採訪時，位元組跳動算法專家張樹波表示，大語言模型是一項人工智慧基礎技術的突破，必然會帶來多個行業的變革。2023 年初，位元組跳動智能服務團隊開始啟動大模型 X 智能單測項目。目前，大模型生成單元測試已經在實際業務中落地。
單元測試是保障項目可靠性的重要手段。傳統的智能單測生成依賴靜態分析、動態分析等工具，對不同的語言需要重新適配。隨著模型參數規模的提升，模型的代碼理解、代碼生成能力也大幅提升，使用模型端到端的生成單元測試，可以低成本地將單元測試覆蓋到多種程式語言。然而大模型在單測生成任務上仍存在模型幻覺（隨機生成不存在變量名、方法名）和測試分支覆蓋不全的問題。
為解決以上問題，位元組跳動智能服務團隊發現通過任務微調、強化學習等技術可以提升語言模型的單元測試生成語法正確率和分支覆蓋率。經過測試，他們的基於 Bloom 70 億參數模型的生成效果不弱於通用版 ChatGPT 的水平，並且在低端顯卡上的推理時延只有 ChatGPT 的 25%。且目前大模型單元測試生成分支覆蓋率在實際項目中達到 56%，同時在抖音的 Android、iOS 雙端落地，問題有效性達到 80%，修復率 65%。
在大會開始前，InfoQ 對張樹波進行了專訪，探索位元組跳動是如何在單元測試中落地大模型的，以及大模型對軟體研發工作流的改變。以下為對話實錄，經編輯。
InfoQ：您在今年 9⽉舉辦的 QCon 全球軟體開發⼤會·北京站上的演講主題是《⼤模型助⼒智能單測⽣成》，為什麼會選擇這⼀主題？
張樹波：2022 年底 OpenAI 發布 ChatGPT，其效果令人大為震撼，曾經讓 NLPer 困擾的自然語言處理問題，例如歧義、長程依賴、知識缺失、推理能力不足等，都得到了很大程度的緩解和解決。大語言模型是一項人工智慧基礎技術的突破，必然會帶來多個行業的變革。2023 年初，我們位元組跳動智能服務團隊啟動了大模型 X 智能單測項目，探索至今，大模型生成單元測試已經在實際業務中落地。這其中我們總結出了一些經驗，希望能夠幫助聽眾。
InfoQ：對於這波⼤模型結合軟體開發應⽤熱潮，您觀察到哪些有趣的趨勢？
張樹波：大模型會讓開發更輕鬆。大模型代碼生成會降低開發者編寫重複性代碼，但是不意味者開發門檻降低，開發者需要具備辨識模型生成是否正確，以及對最終上線負責。當前大模型生成的代碼還不能保證絕對正確，甚至有些隱蔽的錯誤，不容易被新手開發者發現。從這個角度來看， 大模型對有經驗的開發者助益更大。
大模型如何改變傳統單測生成？
InfoQ：在⼤模型出現以前，傳統的智能單測⽣成⽅法是什麼樣的？存在哪些痛點？
張樹波：傳統的單測生成應用最廣、最成功的是基於搜索的單測生成，也就是很多場景都會提到的（search based software testing - SBST），其中集成了非常多的程序分析技術，包括各種各樣的靜態分析、動態分析以及遺傳算法甚至 constrain solving。但因為語言的特性不同，同樣的分析技術對不同的語言是需要重新實現的。雖然測試生成的原理在不同語言是通用的，但是強依賴於軟體分析技術，那麼每新增一種新的語言支持，就需要適配一整套分析技術，成本較大。另外，精確的分析可能會依賴於編譯產物，例如動態分析，因此要求目標項目進行編譯後才能進行測試生成，提高了生成所需的前置準備要求。
而基於模型的生成可以直接分析源碼，無需編譯，降低生成的要求，大大擴大適應場景。近幾年來應用 repository mining 提升 test generation 甚至 program repair 效果的工作也在逐漸的增加，說明 NLP 中的一些假設在軟工領域也是成立的，比如現有 repository 中包含了 test generation 甚至 program repair 中需要的知識，大家也做了相應的嘗試，學習歷史知識並應用到新的任務中在軟工領域也是大家認可的思路。
InfoQ：應⽤⼤模型後，智能單測⽣成⽅法發⽣了哪些變化？實際效果如何？能完全替代傳統的智能單測⽣成⽅法嗎？
張樹波：這裡先補充一個業務應用背景，智能單測一般在開發者代碼編寫過程中 (IDE) 和在代碼提交後 (CI) 發揮作用，前者要求可讀性、正確性，後者要求正確性、覆蓋率指標。 應用大模型後，智能單測由傳統模版生成 + 遺傳算法的方式向端到端的模型生成方式演化。傳統單測在正確性和覆蓋率指標上仍然比大模型生成的要高，在 CI 過程中，仍占主導位置，大模型在其中作為補充。而在 IDE 中，大模型生成單測的可讀性更好，便於開發者修改，因此在 IDE 中單測更傾向使用大模型生成的結果。
我們智能服務團隊的主要基於 Bloom、starcoder 等開源模型做了測試以及微調，經過測試，其中基於 Bloom 的 70 億參數模型的生成效果不弱於通用版 ChatGPT 的水平，並且在低端顯卡（A30）上的推理時延只有 ChatGPT 的 25%。目前，我們的大型模型單元測試生成分支覆蓋率在實際項目中達到 56%，同時在抖音的 Android、iOS 雙端落地， 問題有效性達到 80%，修復率 65%。同時我們也正在試用火山方舟上大模型的單測生成能力，效果正在評估中。
整體來看，大模型仍有一定局限，發展有個過程，各有千秋，取長補短，可以融合應用 1+1>2，不同場景可以有不同的應用方式。
InfoQ：⼤模型在智能單測⽣成中的應⽤原理是什麼？
張樹波：大模型單測生成屬於代碼生成、文本生成的範疇，旨在通過大模型完成端到端的單測代碼生成。大模型單測生成輸入是待測方法、以及上下文，輸出為單元測試函數。隨著模型規模的提升，模型的代碼理解、單測生成能力也大幅提升。
目前智能服務團隊內使用的大模型基座主要是開源模型，例如 Bloom、Starcoder，基於以上大模型，我們對裸模型以及使用單測訓練數據微調之後模型，分別做了評估，當前選擇了基於 Bloom7B 的微調模型落地。同時我們團隊在 Java、Swift、Go 等多種程式語言的大模型落地計劃，廣泛收集了公開數據集、業務數據集用於微調。
如何提升⼤模型單測⽣成準確性？
InfoQ：您提到⼤模型在單測⽣成任務上仍存在模型幻覺和測試分⽀覆蓋不全的問題，對於這兩個問題，位元組有哪些解決思路？如何提升⼤模型單測⽣成準確性？
張樹波：當前我們使用單測生成任務數據在大模型做了微調，讓大模型專注單測生成。實驗表明， 通過構建高質量的訓練數據，可以顯著提升大模型單測分支覆蓋率指標。基於微調後的大模型，通過引入以編譯器、靜態分析結果作為獎勵的強化學習，可以進一步緩解模型幻覺的問題。微調和強化學習的基本假設是模型在預訓練階段學習到了代碼相關知識，通過微調或強化學習，可以激發模型的潛力，或讓模型跟隨特定偏好，輸出更好結果。如果預訓練階段沒有過多的對應任務領域的語料，通過繼續預訓練的方式可以讓模型適配這一領域，然後進行後面的微調和強化學習，可以取得更好的結果。
除了以上方式，另外一種簡單粗暴的方式是提升模型規模，規模越大，能力上限越高。
InfoQ：除此之外，⼤模型在單測⽣成中還有那些局限性？是否會遇到數據質量問題？是否需要考慮隱私和安全問題？有哪些措施可以確保數據安全？
張樹波：大模型在單測生成瓶頸在能給大模型提供多少背景信息，如果是一個簡單的函數，沒有涉及任何其他自定義的類，大模型未來可以完美解決，但是涉及其他的類的，甚至是多層的，外層信息稀疏性，會提高輸入的上下文輸入長度，在實際落地中會在輸入長度和生成效果之間做一個取捨。微調數據質量非常重要，決定模型是否可用的關鍵因素。關於數據安全問題，火山方舟提出了全方位的大模型安全架構，為模型訓練方和使用者提供安全可信環境。
InfoQ：在⼤模型助⼒智能單測⽣成的過程中，位元組團隊內還積累了哪些經驗和教訓？對於希望在項⽬中應⽤⼤模型進⾏智能單測⽣成的團隊，您會給他們提供哪些建議？
張樹波: 不僅是在大模型助力智能單測生成這個方向，所有大模型 X 某某類似的應用落地都是一項系統工程。在大模型落地過程中，其他兄弟團隊給予了大量的經驗和技術支持。
InfoQ：您認為在⼤模型助⼒智能單測⽣成⽅⾯，還有哪些需要進⼀步研究和探索的領域 / 挑戰？⼤模型在智能單測⽣成領域的未來發展趨勢是什麼樣的？
張樹波：目前，我們對於 LLM 的應用仍比較初級，所以首先是最基礎的研究，如何正確激發大模型在單測任務上的潛力，讓大模型發揮全部的效果。目前我們探索的手段包括但不限於任務微調、prompt engineering、RL，然後是下一個階段，如何讓模型不斷地增強在特定場景中的效果。另外，大模型的能力和發展讓原本一些無法通過自動化解決的問題有了新的可能性，比如經典的 oracle problem，不僅僅是困擾單測生成，GUI 的測試、program repair 的落地都受限於這個經典問題。如果大模型能夠解決 oracle problem，剛才提到的多種軟工技術，會迎來又一個落地的春天，而我們對於這個趨勢充滿信心。
「大模型將對研發模式產生顛覆性改變」
InfoQ：⼤模型在軟體研發⼯作流中最⼤的價值是什麼？⼤模型對軟體研發⼯作流的改變，將會如何影響軟體開發⾏業的未來發展趨勢？
張樹波：毫無疑問，大模型將對研發的模式產生顛覆性的改變，但這個改變並不會在一夜之間就發生，會是一個持續漸進的過程，三年五年甚至十年。隨著大模型的不斷發展和進化，對於研發工作流的影響程度會逐漸加深加強。副駕駛 Copilot 是一種比較可能的切入和演進方式，一開始會在一些比較合適的小場景，Copilot 以半自動化的方式對特定任務進行賦能和提效（比如單測的生成），然後隨著模型對代碼的理解能力和推理能力增強，推理結果置信度提升，模型在任務中的重要程度逐步增加，在一些任務上達到和人類同等重要的參與程度。
同時，能力可以泛化推廣到其他相似或者相關的任務，比如 defect detection、fault localization、program repair 等等，成為開發者的「強化外骨骼」或者最佳搭檔。甚至有可能在不遠的將來，實現通過 prompt 研發和調試軟體，就像《西部世界》中的場景一樣。
InfoQ：⽬前市⾯上存在很多結合⼤模型的研發效能⼯具，但在⼀些企業的端到端落地過程中並不理想，也沒有實現提效的突破，這背後可能存在哪些問題？不同規模的企業如何通過⼤模型實現最優的研發效率和質量？
張樹波：大模型適合做推理任務，這是之前單體小模型不具備的能力。在這個基礎上，可以反觀大模型是否在做這類事情。另外當前市面上的開源大模型或者大模型 API 都是通用大模型接口，如果直接在某個領域應用可能存在領域的 gap。大模型本身也存在問題，例如大模型生成內容是有偏的，而且存在模型幻覺、推理錯誤等問題。同時研發效能工具的需要結合具體業務落地，我們智能服務團隊，在抖音、直播、剪映做了很多開創性的研發效能實踐，歡迎大家與我們合作。
大模型應用可以分為幾個層次，API 調用、模型微調、模型繼續預訓練、模型預訓練，成本依次呈幾何級數遞增，不同規模企業可以簡單衡量下投入產出比，來確定在哪個層面應用大模型。
InfoQ：⼤模型會對程式設計師帶來哪些衝擊？程式設計師和⼤模型如何更好地共⽣，實現 1+1＞2 的效果？
張樹波：我不認為大模型會減少對程式設計師的需求量，因為現在大模型還不能替代程式設計師，也不能為最終結果負責。在我們智能服務團隊的實際業務中，我們把程式設計師當成客戶，模型生成的單測為程式設計師服務，自動化單測檢測出來的問題需程式設計師解決，大模型和程序本身是共生的關係。
大模型生成代碼能力增強的同時，需要程式設計師提升自己的專業能力，能快速判斷大模型生成的代碼是否正確以及生成質量的高低。程式設計師能力越強，使用大模型生成代碼的質量也會越高，因為通過使用不同的 prompt，可以生成不同質量的代碼。程式設計師應該擁抱大模型，它可以提高代碼編寫效率，對於一些常識性的問題，它也能做到有問必答，省去網上搜索的時間。
嘉賓簡介
活動推薦
以「啟航·AIGC 軟體工程變革」為主題的 QCon 全球軟體開發大會·北京站將於 9 月 3-5 日在北京•富力萬麗酒店舉辦，此次大會策劃了大模型應用落地、面向 AI 的存儲、AIGC 浪潮下的研發效能提升、大前端融合提效、LLMOps、異構算力、微服務架構治理、業務安全技術、構建未來軟體的程式語言、FinOps 等近 30 個精彩專題。
IPv4 開始收費！新的 IT 災難？
愛奇藝VR公司業務停滯，員工或被欠薪；阿里雲開源通義千問 70 億參數模型，免費可商用；華為正式發布鴻蒙 4，接入大模型｜Q資訊
年薪超 600 萬，比技術總監還高：電影行業 AI 產品經理的崛起
都在追「新潮」技術，但你有大廠們的動作快嗎？