Microsoft教緊AI Debug啲Code
微軟研究院推出了 debug-gym，這是一個新穎的環境，旨在訓練AI 編碼工具進行複雜的程式碼除錯。
隨著人工智慧在軟體開發中的作用不斷擴大，debug-gym 旨在解決一個關鍵瓶頸：雖然人工智慧可以有效地產生程式碼，但調試仍然是開發人員的主要時間消耗。
人工智慧編碼助理的普及正在提高開發人員的工作效率。 GitHub 執行長 Thomas Dohmke 在 2023 年預測，「很快 80% 的程式碼將由 Copilot 編寫」。
這一趨勢在整個行業中都很明顯，大型企業和新創公司都越來越依賴人工智慧來產生程式碼。 Y Combinator 的 Garry Tan 強調了這一點，並指出在他們最新一批新創公司中，有四分之一的程式碼是由大型語言模型 (LLM) 編寫的。
然而，軟體開發的現實涉及的調試遠比初始程式碼編寫要多。
微軟研究團隊表示：“作為流行開源存儲庫的維護者，這引起了我們的共鳴。”他們提出了一個引人注目的問題：“但是，如果人工智能工具可以針對數百個未解決的問題提出解決方案，而我們所要做的就是在合併之前批准它們，那會怎樣呢？”
彌合差距：人工智慧的互動式調試
研究人員將調試定義為修復程式碼的互動式迭代過程。開發人員通常會對崩潰形成假設，透過逐步執行程式碼來收集證據，檢查變數值（通常使用 Python 偵錯器、pdb 等工具），並重複此循環，直到問題解決為止。
研究人員將調試定義為修復程式碼的互動式迭代過程。開發人員通常會對崩潰形成假設，透過逐步執行程式碼來收集證據，檢查變數值（通常使用 Python 偵錯器、pdb 等工具），並重複此循環，直到問題解決為止。
Debug-gym 旨在為 AI 代理配備類似的程式碼調試能力。它問道：“LLM 可以在多大程度上使用 pdb 等互動式偵錯工具？”
該環境為程式碼修復人工智慧代理提供了主動資訊搜尋的工具，擴展了它們的行動和觀察能力。 debug-gym 中的代理可以設定斷點、導航程式碼、檢查變數值、建立測試函數，並根據其信心等級選擇是否進一步調查或重寫程式碼。
微軟團隊解釋說：“我們相信，使用適當的工具進行交互式調試可以使編碼代理能夠處理現實世界的軟體工程任務，並且是基於 LLM 的代理研究的核心。”
這些增強型代理程式提出的修復方案（經過人工批准）將以特定的程式碼庫上下文、程式執行細節和文件為基礎，而不僅僅是基於訓練資料的猜測。
Debug-gym 的建構基於幾個關鍵考慮：
- 儲存庫級處理：代理程式可以存取和修改整個程式碼儲存庫內的檔案。
- 穩健性和安全性：程式碼執行發生在沙盒 Docker 容器內，隔離環境以防止有害操作，同時允許徹底的測試。
- 可擴展性：該平台設計用於輕鬆整合新的調試工具。
- 基於文字的互動：觀察以結構化文字（如 JSON）呈現，操作使用簡單的文字語法，確保與現代 LLM 相容。
研究人員可以將 debug-gym 與自訂儲存庫一起使用，並使用 Aider（簡單函數產生）、Mini-nightmare（簡短、有缺陷的範例）和 SWE-bench（需要深入程式碼庫理解的現實問題）等基準來評估代理效能。
早期成果令人鼓舞
初步實驗涉及一個基於提示的簡單代理，使用各種 LLM（包括 Claude 3.7、OpenAI o1 和 OpenAI o3-mini），配備 eval、view、pdb、rewrite 和 listdir 等調試工具。
儘管即使有了這些工具，解決 SWE-bench Lite 等複雜問題仍然具有挑戰性（成功率很少超過 50%），但與沒有調試工具的代理相比，性能提升顯著。
在有調試工具的情況下，SWE-bench Lite 的成功率相對提高了：Claude 3.7 提高了 30%，OpenAI o1 提高了 182%，OpenAI o3-mini 提高了 160%。
研究人員將整體困難歸因於目前 LLM 訓練資料集中缺乏連續決策資料（如除錯追蹤）。然而，顯著的改善證實了該研究方向的潛力。
培養AI代碼調試專家
微軟研究團隊認為，下一步是專門針對互動式除錯對 LLM 進行微調。這需要建立專門的資料集，在偵錯器中收集資訊以解決問題時記錄代理互動。
與標準推理任務不同，互動式調試涉及動作、環境回饋和後續決策的循環，需要豐富的數據來捕捉整個問題解決序列。
該計劃包括微調一個專門用於收集必要的錯誤修復資訊的“資訊搜尋模型”，然後為主要程式碼生成模型提供相關的上下文。這可能涉及更小、更有效率的資訊搜尋模型，為更大的生成模型提供信息，類似於先進的檢索增強生成 (RAG) 系統，從而可能節省 AI 推理成本。
透過開源 debug-gym，微軟研究院邀請更廣泛的社群為推進互動式調試代理做出貢獻，更廣泛地說，為能夠主動從環境中尋找資訊的人工智慧代理做出貢獻。