大型模型首次直接理解程式碼圖：無需代理程式自動修復錯誤，榮登SWE-Bench開源模型榜單

AI自動修復錯誤，解決率高達 44%！這是全球開源模型的最新、最強水平。

來自螞蟻金服的開源新模型，在 SWE-bench Lite 上超越所有開源方案，效能媲美閉源模型。

具體表現如下，在 SWE-bench Lite 上：

所有開源模型方法 (Open Weight Model) 中排名第一；

所有開源系統方法 (Open Source System) 中排名第六；

整體排名第 14；

優於目前榜單上最好的開源模型 "KGCompass" 7.33%。

他們首創將程式碼倉庫圖模態整合至大型模型 (Code Graph Model, CGM)，讓大語言模型能直接理解程式碼圖，更有效率地修復錯誤、補齊程式碼。

這徹底擺脫對黑箱模型 (如 GPT-4 或 Claude 3.7 等) 和複雜代理程式工作流程的依賴，實現更可控、透明、安全的軟體工程自動化。

而且，CGM 完全基於開源模型。要知道，開源模型在 SWE-bench 上的表現通常不夠好，此前幾乎所有 SOTA 級方案都是基於閉源模型實現。而 CGM 基於 Qwen 模型，做到了可與閉源模型媲美的水平。

CGM僅需 4 步驟就能快速定位、生成修補程式，省去代理程式方案中複雜的編排過程，效率直線提升。

讓 AI 真正理解大型模型程式碼庫

自大型模型趨勢以來，AI 程式設計迅速崛起，尤其是在編寫函數這類小任務上的表現出色，例如在 HumanEval 等基準測試上，許多模型的準確度已經超過 90%。

然而真實的軟體工程遠比「編寫一個函數」複雜得多。像錯誤修復、功能增強這樣的任務，通常需要跨檔案、跨模組操作，並要求模型理解專案中複雜的結構、依賴關係和類的繼承體系。

現在的主流方法通常是使用基於閉源模型的代理程式。它們可以模擬人類程式設計師行為，如觀察程式碼、呼叫工具、多輪互動等完成任務。

但這類方法也存在幾個問題：

行為路徑不可控，容易累積推理誤差；

依賴 GPT-4、Claude 等閉源模型，難以私有化部署或客製化；

工程成本高，效率不高。

與此同時，當前使用開源模型的方案，很難實現 SOTA 級效果。

為此研究團隊提出：能否只用開源模型、不依賴代理程式，解決倉庫級任務？CGM 由此而生。

🔍圖結構與大型模型深度融合

CGM 採用類似視覺-語言模型 (Vision-Language Model, VLM) 的跨模態建模方式。它將傳統 LLM 的文本理解能力與程式碼倉庫的結構圖 (Graph) 結合，形成一種圖-語言多模態模型。模型核心融合了兩個模態：

圖模態：將倉庫建構為結構化圖，節點包括函數、類別、檔案、套件等 7 種類型，邊表示呼叫、包含、繼承等依賴；

語言模態：使用者輸入的自然語言描述和程式碼提示，驅動模型生成修補程式或回答。

模型輸入為程式碼圖和文字形式的提示，將在 LLM 中對結構-語義進行雙模態對齊。

具體結構融合方法如下：

使用小型編碼器 (CodeT5+) 對每個節點進行編碼，壓縮為單個「節點標記」(node token)，每個節點內依照最多 512 個標記的文本區塊切分。

透過一個配接器 (一個兩層 MLP) 將編碼後的節點表徵映射到 LLM 輸入嵌入空間中。相當於將 LLM 上下文擴展 512 倍，能更好處理海量的程式碼倉庫上下文。

使用圖感知注意力遮罩 (Graph-aware Attention Mask)。替代 LLM 中原有的因果注意力，使注意力機制只作用於相鄰節點間。類似於 GNN 的訊息傳遞機制，能夠讓 LLM 直接感知和利用程式碼的結構依賴關係。

✏️兩階段訓練：結構理解 + 問題泛化

基於此模型架構，團隊透過兩階段訓練讓 LLM 能夠理解程式碼圖的拓撲結構。

階段一：子圖重構預訓練

為了訓練 CGM 有效捕捉程式碼圖的語義和結構資訊，團隊設計了一個「圖生程式碼 (Graph-to-Code)」任務。從大型程式碼圖中隨機取樣出子圖 (限制節點數量以控制輸出程式碼長度)，模型需要根據這些輸入的子圖 (僅包含節點類型和連接關係，不含完整的程式碼內容) 來重建出原始的程式碼片段。

然後採用層級化方法，保持重建程式碼的結構一致性和可讀性。依照拓撲排序與行號順序拼接倉庫上下文：高級別節點 (如 REPO、PACKAGE) 置於輸出序列或檔案的起始；檔案節點透過拓撲排序確定順序；檔案內節點 (如 CLASS、FUNCTION) 則按行號順序拼接。

階段二：噪音增強微調

此階段使用真實的 GitHub 問題-修復補丁資料對 CGM 進行微調。

模型學習基於兩項輸入生成程式碼補丁：(i) 一個相關的程式碼子圖；(ii) 一段文字提示，指明根據補丁可能需要修改的實際檔案。為了提升模型的強韌性，特意在提示中引入了 10% 的噪音輸入：例如，提示中可能包含一個實際上無需修改的不相關檔案，或者遺漏至少一個本應被修改的關鍵檔案。在訓練中引入這種受控的噪音有助於模型更好地泛化到實際輸入資訊不完整或包含干擾的場景。

📎推理階段：Graph-RAG 框架替代代理程式

最後，為了進一步提升實際應用能力，CGM 建構了一個無代理程式輕量化框架 Graph-RAG。

它還原了人類程式設計師錯誤修復工作流程，但比現有代理程式方案效率更高。

核心模組數量從 10 個進一步精簡到 4 個：改寫器 → 檢索器 → 重排器 → 生成器 (CGM 模型)。

改寫器 (Rewriter)：改寫問題描述，提取關鍵字與相關檔案；

檢索器 (Retriever)：透過語義與結構檢索，從程式碼圖中抽取連通子圖；

重排器 (Reranker)：排序檢索結果，選擇最關鍵檔案用於生成；

生成器 (Reader)：結合子圖與提示生成最終修復程式碼。