SWE-Critix:用 SFT 加強化學習訓練“通用驗證器”,給程式設計智慧體的長軌跡判成敗並說明理由,準確率從 57% 提到 78%
論文 2610.13356 針對“沒有現成評測器時,如何判斷程式設計智慧體做對了沒有”:先用教師模型對同一問題的成功與失敗軌跡做對比分析,生成少量帶推理鏈的監督資料,再用不含推理鏈的軌跡做強化學習,訓練出 30B 級的驗證器。在 4.3 萬多條長軌跡的留出測試集上,基礎 Qwen3-30B-A3B 推理模型準確率為 57%,監督微調後 66%,強化學習後 78%。模型、資料集和訓練程式碼已開源。
論文 2610.13356 於 2026 年 10 月中旬出現在 arXiv 上,題目是《SWE-Critix:為評估程式設計智慧體軌跡而後訓練通用驗證器》。它抓住的問題,隨著程式設計智慧體越來越能幹而越來越突出:它們不再只是寫一段程式碼,而是能檢查倉庫、改檔案、執行命令和測試、解讀反饋並反覆修改,從單個函式的生成擴充套件到倉庫級的議題解決,乃至長週期的軟體開發任務。智慧體越自主,就越需要可靠地驗證它的執行軌跡,也就是它一步步解決任務的完整記錄。可是在真實的端到端任務裡,常常沒有一個現成的、定義了成功標準的評測器。於是就需要一個驗證器,判斷智慧體是否完成了任務,失敗時還要指出原因。 難點在於軌跡本身。一條軌跡可以包含數百輪穿插的使用者輸入、環境反饋和模型回覆,比一次性的模型回答難檢查得多。論文引用的一個例子說,LoLBench 裡的任務軌跡跨越 53 到 532 輪。作者把現有做法沿兩個維度整理:驗證的物件是隻看最終結果(比如提交的補丁),還是也檢查過程以發現不良的中間行為;驗證的方法是不訓練還是訓練。不訓練的方法直接用通用大模型或基於規則的評判;訓練的方法則學習專門的評論器,又可以按是否只輸出標量獎勵來區分。按這個分類,基於訓練、程序導向的通用驗證還沒有被充分探索。SWE-Critix 就想填這個空白:給定任務和執行軌跡,學到的驗證器既預測完成與否,又生成一段自然語言分析來解釋判斷。
訓練管線分幾步。資料來自 CoderForge-Preview(摘要中寫作 CodeForge-Preview),這是一個大型開放資料集,包含 25.8 萬條軌跡(15.5 萬條透過、10.3 萬條失敗),覆蓋 1,655 個倉庫的 5.1 萬個議題。這些軌跡由 OpenHands 框架搭配 Qwen3-Coder-480B 生成,來自三個提供可執行環境的任務來源。作者進一步剔除超過 64K 詞元或沒有提交補丁(比如任務未完成)的軌跡,過濾掉 16% 的資料,再把剩下的分成監督微調、強化學習和測試三份。監督微調集裡,從每個同時含有成功與失敗軌跡的議題各挑一條成功和一條失敗;強化學習集則包含所有剩下的失敗軌跡,並按議題輪流取樣成功軌跡直到兩類平衡,以儘量覆蓋不同的議題。 監督階段的關鍵是推理鏈的來源。作者用更強的教師模型(GPT-5.5)對每一對成功與失敗軌跡做對比分析,總結各自的過程、錯誤模式和導致成敗的關鍵因素,並把得到的推理鏈後處理成適合逐條判斷的形式,然後組裝成監督微調樣本。選擇成對比較,是依據先前的研究:大模型做成對評判比做單個評判更好。他們從 Qwen3-30B-A3B-Thinking-2507 出發微調,在 16 個節點共 128 塊華為昇騰 910B 的 NPU 上,用 MindSpeed-LLM 訓練三個輪次、975 次迭代,大約 15 小時。強化學習階段則使用其餘 91.3% 只有單元測試結果、沒有推理鏈的資料,獎勵是簡單的基於規則的結果獎勵:預測的判斷與單元測試得出的真實結果一致得 +1,否則 -1。訓練用 VeRL 與 GRPO,組大小為 8,在 8 個節點共 128 塊昇騰 910C 的 NPU 上進行,一個輪次 3,396 次迭代,約需 533 小時。
評測很直接:能不能分辨成功與失敗的軌跡。測試集有 4.3 萬多條長軌跡,每個模型對每個樣本只評測一次,用 vLLM Ascend 部署在一個含 16 塊昇騰 910C 的節點上,並報告準確率,以及正類(成功)與負類(失敗)的精確率、召回率和 F1。結果顯示出清晰的遞進。基礎 Qwen3 MoE 模型強烈傾向於把軌跡判為正確,負類召回率在所有子集上幾乎為零,而且 9.6% 的回覆不符合要求的輸出格式,無法可靠提取判斷。監督微調同時緩解了這兩個問題,所有回覆都嚴格遵守提示的格式,對正類的偏向也明顯減輕。繼續做強化學習,整體準確率從 66% 升到 78%;監督微調主要糾正的是基礎模型的強烈正向偏置,而強化學習進一步增強了判別能力,把正類召回率從 67% 提到 85%,且沒有明顯犧牲負類召回率。 作者也坦率地寫了不足。其一,R2E-Gym 子集上的表現明顯低於 SWE-Rebench 和 SWE-Smith,一種可能的解釋是它的資料量較小。其二,模型識別失敗軌跡的能力仍然較弱,整體負類召回率只有 64%,這說明失敗軌跡的模式更多樣、訊號更細微,更難與成功軌跡區分。未來工作裡,作者計劃引入 Open-SWE-Traces 等其他資料來源,用不同模型與框架的組合合成軌跡,並研究 2 比 1、1 比 2、4 比 1 等不同的正負類比例,而不僅是平衡配比。需要注意的是,所有軌跡都由同一個框架和同一個模型生成,這意味著驗證器在別的框架、別的模型上的表現尚無證據。 我們的判斷是,SWE-Critix 的意義在於證明“帶理由的判斷”可以透過相對簡單的兩階段流程學出來,並且把模型和訓練程式碼公開,方便別人復現和改進。同時要看清它的邊界:這是一份自稱初步的評估,每個樣本只測一次;78% 的準確率意味著仍有明顯的誤判;對失敗軌跡的識別比對成功軌跡弱,而在實際使用裡,漏掉失敗往往比誤報更危險。如果團隊想在自己的程式設計智慧體流水線裡用這類驗證器,更穩妥的做法是把它當作輔助訊號,與單元測試、人工抽查和獨立的評測環境一起使用,並先在自己的軌跡上測一遍分類表現,再決定放在哪個環節。
Sources
FAQ
SWE-Critix 要解決什麼問題?
真實的端到端軟體工程任務裡,往往沒有現成的、定義成功標準的評測器。需要一個驗證器來判斷智慧體是否完成任務,並在失敗時指出原因。難點是軌跡可能含數百步與倉庫、工具的互動。現有驗證器要麼直接用通用大模型,要麼訓練只輸出標量獎勵的評論器。
它是怎麼訓練的?
先用更強的教師模型(GPT-5.5)對同一問題的一條成功軌跡和一條失敗軌跡做對比分析,總結各自的過程、錯誤模式與成敗關鍵,據此構造少量帶推理鏈的監督微調樣本;再對其餘 91.3% 沒有推理鏈、只有單元測試結果的資料做強化學習,獎勵規則是預測與測試結果一致得 +1,否則 -1,使用 GRPO。
結果怎樣,有什麼侷限?
在超過 4.3 萬條長軌跡的留出測試集上,準確率從基礎模型的 57% 提高到 SFT 後的 66% 和 RL 後的 78%;正類召回率從 67% 提高到 85%,但對失敗軌跡的召回僅 64%。R2E-Gym 子整合績明顯偏低,可能與資料量較小有關。作者稱這是初步評估,每個樣本只評測一次。