碼農狂喜！微軟提出CodePlan，跨168個程式碼庫編碼任務，LLM自動化完成

對於大模型來說，擅長的是本地化編碼任務。

如果任務涉及多個相互依賴的文件，LLM無法解決這個問題

微軟研究人員為此設計了一個名為CodePlan的任務無關的神經網路框架

圖片

#論文網址：https://arxiv.org/pdf/2309.12499.在pdf

論文中，CodePlan綜合了多步驟編輯鏈（chain-of-edits），是一種將程式分析、規劃和LLM結合在一起的新方法。

一起來具體看看，CodePlan是如何設計的？

CodePlan：大模型規劃

#軟體工程活動中，例如軟體包遷移、修復靜態分析或測試的錯誤報告，以及向程式碼庫新增類型提示或其他規範，涉及到對整個程式碼儲存庫的普遍編輯。

研究人員規劃這些活動，以實現"儲存庫層級的編碼任務"

編碼工具如GitHub Copilot、Code Whisperer已經獲得了大模型能力的支持，為碼農在本地化編碼問題上提供了解決方案

#然而，事實是，「儲存庫層級的編碼任務」更加複雜，無法直接透過LLM解決，因為儲存庫中的程式碼是相互依賴的，整個儲存庫可能太大而無法納入提示

這項研究中，微軟團隊將庫級編碼框架作為一個規劃問題，並提出了一個任務不可知的框架，稱為CodePlan。

CodePlan綜合了一個多步驟的編輯鏈（計畫） ，其中每一步都會呼叫程式碼位置上的LLM。該程式碼位置上的上下文來自整個儲存庫、先前的程式碼變更和特定於任務的指令。

CodePlan是一種新型組合，它基於增量依賴分析、變更可能影響分析和自適應規劃演算法

圖片

如下圖，展示了複數庫API的變化，微軟研究人員的任務是根據這項變化遷移程式碼庫。

圖片

在圖3的左邊展示了程式庫中與使用複數庫相關的部分

具體來說，Create.cs檔案中的方法func，呼叫了函式庫中的create_complex方法，Process.cs檔案中的方法Process.cs呼叫了func。

圖片

研究人員將任務描述和func主體從圖1傳遞給LLM，以產生修改後的func程式碼，如圖3右側所示

可以看到，LLM已經正確地編輯了對create_complex API的調用，以便它返回一個Complex類型的對象，而不是兩個浮點值的元組。

注意，這個編輯導致了方法func的簽章改變了－它現在回傳了一個Complex類型的物件。

需要修改的是：需要修改方法func的呼叫者，例如在Process.cs檔案中的process方法，如圖3左下角所示。如果不對process方法的主體進行適當的修改，程式碼將無法建置！

圖3右下方顯示了process方法的適當修改，它能使版本庫達到一致的狀態，從而在編譯時不會出錯。

研究人員的主要任務是建立一個「儲存庫層級的編碼系統」，該系統能夠自動產生編輯所需的派生規範

#LLM驅動程式的函式庫級編碼任務定義如下:

圖片

在CodePlan的整體框架中，輸入包含一個儲存庫、一個透過自然語言指令或一組初始程式碼編輯表達種子規範的任務、一個正確性oracle和一個LLM

CodePlan建立了一個計劃圖，其中每個節點都代表LLM需要執行的程式碼編輯任務，而邊表示目標節點需要在來源節點之後執行

CodePlan監控程式碼編輯，並自適應地擴展計畫圖。

一旦計畫中的所有步驟都已完成，儲存庫將由oracle進行分析。如果oracle驗證了資源庫，則任務完成。如果發現錯誤，錯誤報告將作為下一輪計劃產生和執行的種子規範。

圖片

此外，CodePlan演算法也維護了一個依賴關係圖，圖4說明了依賴關係圖的結構。

圖片

刷新SOTA

研究人員對CodePlan在兩個存儲庫級任務上的有效性進行了評估：包遷移（C#）和時態代碼編輯（Python）

每個任務在多個程式碼庫上進行評估，每個程式碼庫都需要對多個檔案（2-97個檔案）進行相互依賴的變更。

圖片

以前從未有過使用LLM自動完成這種複雜程度的編碼任務

#研究結果顯示，與基準相比，CodePlan更符合基本事實，能夠使5/6個儲存庫通過有效性檢查，例如無錯誤建置和正確的程式碼編輯

總的來說，CodePlan為自動化複雜的庫級編碼任務提供了一種有前途的方法，既提高了生產效率，又提高了準確性

它成功地應對了許多挑戰，為高效可靠的軟體工程實踐開闢了新的可能性

#參考資料：##https:// www.php.cn/link/23b1f559d8bd157d0d741c83957ed4f2#

以上是碼農狂喜！微軟提出CodePlan，跨168個程式碼庫編碼任務，LLM自動化完成的詳細內容。更多資訊請關注PHP中文網其他相關文章！