這篇論文是 Google 關於運用大型語言模型（LLMs）進行程式碼遷移的經驗報告，旨在分享 Google 在企業環境中應用 LLM 進行各種遷移案例的經驗，並期望其他業界人士能從中受益。論文重點摘要如下：
一、 背景介紹
- Google 的產品部門（如廣告、搜尋、Workspace 和 YouTube）擁有成熟的軟體開發組織，面臨著許多軟體開發挑戰：
- 龐大且成熟（超過 20 年）的程式碼庫。
- 需跟上快速變化的商業環境，保持程式碼的靈活性。
- 需維護程式碼並使用新的框架來滿足當前的功能需求。
- 軟體開發品質和敏捷性是市場競爭的關鍵因素，即使這些產品部門提供的服務本身並非軟體產品。
- Google 採用了軟體工程原則（如單一程式碼庫、分析工具、嚴格的程式碼審查、CI/CD 等），這些原則已成功應用於所有產品部門。
- 在 LLM 時代，軟體工程實踐正在經歷全行業的變革，Google 也不例外。Google 在兩個層面運用 AI 技術於內部軟體工程：
- 通用 AI 工具： 為所有 Google 員工設計，涵蓋所有產品部門。這些技術由 Google 為 Google 打造，包括程式碼自動完成、程式碼審查、問題解答等。這些工具在 Google 內部和外部社群都取得了巨大成功。
- 客製化解決方案： 為每個產品部門量身打造，例如特定的程式碼遷移、程式碼效率最佳化和測試生成任務，在這些任務中，Google 有效地以客製化方式使用 LLM。
二、 客製化 LLM 程式碼遷移
- 動機： Google 過去使用大型規模變更的特殊基礎架構進行程式碼遷移，但對於需要完成的程式碼遷移類型，這些「確定性」的程式碼變更解決方案效果不佳。這是因為上下文線索和實際需要進行的變更具有相當大的差異性，難以透過確定性程式碼轉換過程完成。而現代 LLM 正好能有效解決這個問題，並且與設計其他客製化程式轉換系統（例如基於程式合成）相比，LLM 的應用門檻更低。
- 目標： 尋找 LLM 能夠提供額外價值的機會，無需維護難以維護的基於 AST（抽象語法樹）的轉換，同時具備合理的應用規模以證明其價值。
- 方法：
- 使用 LLM 提示來建立包含客製化部分的通用工作流程，以及程式碼遷移中的一些子步驟，例如檔案發現和驗證。這種方法允許快速加入新的用例，因為 Google 建立了一個可重複使用且可調整的子步驟庫。
- 強調 LLM 只是完整解決方案的一部分，該解決方案還包括一些基於 AST 和符號的技術，以及一些純粹的流程問題，例如變更部署。LLM 的作用集中在編輯生成上。需要識別進行變更的位置，以及需要驗證是否執行了正確操作的部分，主要使用確定性 AST 技術處理，但也有一些案例由 LLM 支援。
- 成功指標： AI 至少節省 50% 的端到端工作時間。這個時間不僅包括變更生成本身（程式碼重寫），還包括尋找遷移位置、進行審查和部署變更。
- 影響：
- 節省時間：所有案例研究中，AI 在程式碼變更本身提供的加速效果更高，但將成功指標設定為整個開發過程，可以提供更清晰的影響目標，並與業務成果（快速完成遷移）保持一致。
- 程式碼品質：目前，程式碼品質是透過人工審查過程來保證的，與純粹人工生成的程式碼相同。AI 是否會對品質產生長期影響還有待觀察。
三、 案例研究
論文中詳細描述了四個不同的程式碼遷移案例研究：
- Int32 到 Int64 ID 遷移： Google 廣告中有數十種數值唯一「ID」類型用作處理器（例如使用者、商家、廣告活動等），這些 ID 最初在 C++ 和 Java 中定義為 32 位元整數。但隨著 ID 數量的增長，預計它們會比預期更快地超出 32 位元容量。使用 LLM 驅動的程式碼遷移流程，Google 估計節省了 50% 的遷移時間。
- JUnit3 到 JUnit4 遷移： Google 的一些團隊仍在使用舊的 JUnit3 程式庫。手動更新所有程式碼需要巨大的投資，並且舊的測試會對程式碼庫產生負面影響。因此，Google 使用 LLM 遷移堆疊自動將舊測試遷移到新的 JUnit4 程式庫。透過這種技術，Google 在 3 個月內成功遷移了 5,359 個檔案，修改了超過 149,000 行程式碼。最終，大約 87% 的 AI 生成的程式碼在沒有任何變更的情況下被提交。
- Joda Time 到 Java Time 遷移： Google 程式碼庫的某些部分仍在使用 Joda time 程式庫，而不是標準的 java.time 套件。這個遷移的挑戰在於變更不僅限於單一方法，還經常需要變更類別的公開介面和欄位。Google 使用基於 Kythe 的管道構建叢集解決方案，並利用 Gemini 的巨大上下文窗口來遷移整個叢集。這個遷移仍在進行中，但目前的估計顯示，Google 能夠節省大約 89% 的時間。
- 清理實驗程式碼： Google 使用數千個持續運行的實驗來改進其產品。實驗通常透過程式碼中的標記實現，這些標記從外部接收值。實驗結束後，需要清理與之相關的程式碼。Google 使用 AI 來完成這項工作，包括發現標記引用位置、刪除對實驗標記的程式碼引用、簡化依賴於實驗標記的條件運算式、清理無效程式碼以及更新測試。
四、 討論與結論
- LLM 為大型程式碼庫的現代化和更新提供了重大機遇，它們具有高度靈活性，因此可以將各種程式碼轉換任務納入類似的流程中並取得成功。這種方法有可能從根本上改變大型企業維護程式碼的方式。
- LLM 與 AST 相結合可以更好地完成任務。許多程式碼遷移可以分為離散的步驟，每個步驟可以使用 LLM 生成、LLM 內省，也可以使用傳統方法，例如基於 AST 的技術，甚至類似 grep 的搜尋。
- 將任務分解成更簡單的子任務，可以讓開發人員更快地迭代並「分而治之」解決問題。
- 雖然 LLM 可以為變更生成本身節省大量時間，但仍需要額外的工具來進一步減少或加速人工參與。程式碼審查和變更部署仍然需要人工操作，並且可能迅速成為大型程式碼遷移過程中的瓶頸。
- 除了模型級別的效能之外，更重要的是模型級別的效能如何轉化為業務級別的成果。
- 廣泛使用生成式 AI 和客製化技術會帶來隱性成本：必須培訓大量工程師使用這些技術。
- 企業需要不斷評估投資客製化模型以獲得更好結果的「曲線下面積」，與使用現成模型相比的成本效益。
五、 Google 做法的優缺點
優點：
- 大幅提高效率： 利用 LLM 自動化程式碼遷移，可以顯著減少人工工作量，加快遷移速度，並節省大量時間和資源。
- 降低門檻： 相比於傳統的基於 AST 的技術，LLM 的應用門檻更低，更易於上手和使用。
- 提升程式碼品質： 透過 LLM 進行程式碼變更，可以確保程式碼的一致性和正確性，並減少人為錯誤。
- 解決技術債務： 透過 LLM 驅動的程式碼遷移，可以有效解決長期存在的技術債務，提升程式碼庫的健康度。
缺點：
- 需要額外訓練： 工程師需要接受使用 LLM 和相關工具的培訓，才能有效地應用於程式碼遷移。
- 模型偏差風險： LLM 模型可能存在偏差，導致生成的程式碼出現意外的錯誤或問題。
- 過度依賴 AI： 過度依賴 AI 進行程式碼遷移，可能會導致工程師失去對程式碼的理解和掌控能力。
- 人工審查仍然必要： 即使使用 LLM 進行程式碼遷移，人工審查仍然是不可或缺的環節，以確保程式碼的品質和安全性。
總體而言，Google 利用 LLM 進行程式碼遷移的做法具有顯著的優勢，可以大幅提高效率和程式碼品質。然而，也需要注意潛在的風險和挑戰，並採取適當的措施來減輕這些風險。
source: How is Google using AI for internal code migrations?
發表迴響