“思考更長時間”而非“模型更大”是提升模型在復雜軟件工程任務中表現的有效途徑

作者：明巍/臨城/水德

還在為部署動輒數百 GB 顯存的龐大模型而煩惱嗎？還在擔心私有代碼庫的安全和成本問題嗎？通義靈碼團隊最新研究《Thinking Longer, Not Larger: Enhancing Software Engineering Agents via Scaling Test-Time Compute》探索了如何通過擴展測試時計算（Test-Time Compute Scaling, TTS），讓個人可部署的開源大模型（如僅需單卡運行的 32B 模型），達到與頂級閉源模型（如 DeepSeek R1, OpenAI o1）相媲美的代碼推理和問題解決能力。

核心亮點：

性能飛躍：32B 模型在結合了兩種 Test Time Scaling 策略后，在 SWE-bench Verified 基準上，成功解決了 46.0% 的真實 GitHub Issue，與 DeepSeek R1 和 OpenAI o1 等更大規模的業界領先模型表現相當；
實證 TTS 現象：內部 TTS (Internal TTS) 通過高質量、多階段的合成開發軌跡進行訓練，讓模型學會深度思考，模型在面對更有挑戰的問題時，會動態地分配更多計算資源（輸出更多 Token），這驗證了“思考更長時間”確實能提升模型解決復雜任務的能力。
最優開發過程搜索：在軟件開發的關鍵決策點（如倉庫理解、故障定位）進行干預，利用過程獎勵模型和結果獎勵模型指導搜索，以更優的計算效率找到最佳解決方案。同時利用更大的推理 budget 會產生更優的性能。

方法：內外兼修的 Test-time Scaling 策略

我們提出了一個統一的測試時計算（TTS）擴展框架，包含兩種互補策略：

1. 內部 TTS (Internal Test-Time Scaling)：內化深度思考能力

高質量軌跡合成 (High-Quality Trajectory Synthesis)：
- 數據源：從 GitHub 上篩選超過 1000 星標的高質量倉庫，收集真實的 <issue, pull-request, codebase> 三元組數據。
- 初始過濾：應用啟發式規則過濾數據，例如，保留描述足夠詳細的 issue (≥20 字符, ≤3 超鏈接)，以及修改量適中 (1-5 個代碼文件, 非純測試文件修改) 的 PR。
- 環境構建與驗證：利用 ExecutionAgent 嘗試為每個倉庫自動構建可執行的測試環境，確保后續能夠進行真實的補丁驗證。無法成功構建或運行環境的倉庫被排除，最終形成包含約 9000 個 issue 和 300 個倉庫的高質量數據集。
軌跡引導與增強 (Trajectory Bootstrapping)：
基礎框架：基于開源的 SWE-SynInfer 框架（包含倉庫理解、故障定位、補丁生成三個階段），增加了補丁驗證 (Patch Verification) 階段，形成 SWE-SynInfer+ 框架。在此階段，模型需生成復現代碼來自動驗證補丁有效性，并在失敗時進行迭代優化。
引導模型：使用開源推理模型 DeepSeek R1作為教師模型，在其多次內部推理迭代和優化的能力下，生成詳盡的、包含多輪思考與修正的長思維鏈（Long CoT）軌跡。
開發上下文的拒絕采樣 (Development-Contextualized Rejection Sampling)：
- 多維質量把關：對生成的軌跡進行嚴格的多維度驗證和過濾：
  - 倉庫理解準確性：檢查模型識別的待修改文件是否與開發者實際修改的文件一致。
  - 故障定位準確性：確認模型生成的補丁是否作用于開發者實際修改的代碼位置（類、函數、代碼塊）。
  - Issue 復現代碼有效性：驗證生成的復現代碼能否在原始代碼上觸發問題，在應用開發者補丁后問題消失。
  - 補丁正確性：應用模型補丁后，運行其生成的復現代碼和倉庫原有的單元測試，檢查問題是否解決且無新問題引入。
  - 復雜性過濾：篩除掉基礎模型（Qwen2.5 Coder 32B）無需復雜推理就能一次性解決的簡單問題，確保訓練數據能有效激發模型的深度推理潛力。
- 保留有效中間步驟：如果一個軌跡的補丁驗證失敗，但之前的倉庫理解、故障定位等步驟是正確的，保留這些正確的中間步驟數據，避免浪費有價值的推理過程信息。
推理式訓練 (Reasoning Training)：
- 學習目標：采用標準的監督學習，優化模型生成正確推理動作（包括思考過程和最終行動）的條件概率。損失函數同時計算軌跡中每個步驟的 “思考（think）”（規劃、反思、修正等）和 “回答（answer）”（最終輸出的 API 調用、代碼補丁等）部分，促使模型學習完整的決策過程。
- 歷史信息剪枝：為提高多輪推理效率，借鑒 DeepSeek R1 的機制，在生成第 i 步時，歷史上下文中只保留第 i-1 步的 answer 部分，舍棄 think 部分，減少冗余信息。

2. 外部 TTS (External Test-Time Scaling): 優化決策搜索路徑

基于開發流程的搜索策略 (Development-Process-Based Search, Dev-Search)：
- 核心思想：軟件工程任務是長鏈條決策過程，中間步驟的錯誤會嚴重影響最終結果。我們摒棄僅在終點驗證或對每一步都進行低效驗證的做法，選擇在三個關鍵決策階段（倉庫理解、故障定位、補丁生成）集中進行搜索和評估，以高效利用計算預算。
過程獎勵模型 (Process Reward Model, PRM) 引導：
- 訓練目標：訓練 PRM（基于基礎模型微調）來判斷中間輸出的正確性（二元分類任務）。例如，判斷識別的文件是否正確，定位的代碼位置是否準確。
- 引導方式：在每個階段生成 N 個候選輸出，使用 PRM 對其打分，保留 Top-k 的高分候選進入下一階段，實現輕量級的、有指導的 Beam Search，有效剪枝低潛力路徑。
執行驗證與結果獎勵模型 (Outcome Reward Model, ORM) 排序：
- 補丁驗證：在補丁生成階段，利用模型生成的復現代碼和倉庫自帶的回歸測試，對候選補丁進行執行驗證，確保其有效性且不破壞原有功能。
- 最終排序：對于通過執行驗證的多個候選補丁（可能存在多個），使用 ORM 進行最終排序。ORM 基于 DPO 進行訓練，學習偏好“通過所有測試”的補丁優于“未通過測試”的補丁。重要的是，ORM 僅需 Issue 描述和候選補丁作為輸入，不依賴中間推理步驟，易于集成。

所有模型均基于開源的Qwen2.5 Coder 32B模型進行訓練，該模型可在消費級顯卡上進行部署。

實驗評估：

1. 整體性能 SOTA：

結果：訓練的 SWE-Reasoner 32B 模型結合了內部和外部 TTS (Unified TTC, budget=8) 后，達到了 46.0% 的 Issue 解決率。
對比：在 ≤100B 參數量級的模型中處于領先地位，超越了如 DeepSeek R1 671B (41.20%) 等更大的開源模型，并且接近業界頂尖的閉源模型 Claude 3.5 Sonnet v2 (46.20%) 和 OpenAI o1 (45.60%) 。（詳見圖1和表1）
泛化性與獨特性：該模型在 SWE-bench 覆蓋的 12 個不同 Python 倉庫 上均表現出魯棒的性能，在多數倉庫上媲美或超越 DeepSeek R1 671B（詳見圖2）。此外，通過與其他模型的解決實例對比，我們的方法能夠獨立解決 17 個 其他模型無法解決的 Issue，展現了獨特的解題能力。

圖 1: 在 SWE-Bench Verified 上，對具有擴展測試時間計算的較小 LLM 與較大模型的性能進行比較

表 1: 與不同模型和框架在 SWE-bench Verified 基準上的性能比較。

圖 2: 針對不同倉庫的 issue 解決率比較

內部 TTS 研究分析：

不同難度性能優勢：Long CoT 訓練相比 Short CoT 訓練在解決更難 issue 上提升明顯（基于社區解決頻率劃分的 Level 5，效果提升約 6 倍，詳見圖 3）。
Test-Time Scaling 現象：Reasoning 模型在解決更難的問題上會嘗試輸出更多 token，有明顯的 test-time scaling 現象（SWE-Reasoner 和 OpenAI o1），Claude 3.5 Sonnet 也有這個 TTS 現象，但是整體輸出 token 較少。而 Short CoT 模型則沒有這種明顯的自適應計算行為（詳見圖 4）。

圖 3: 在不同難度的 SWE-bench Verified 上的不同模型的解決率

圖 4: 在不同難度的 SWE-bench Verified 上的不同模型的平均輸出 tokens 比較

外部 TTS 研究分析：

Dev-Search 策略優勢，在控制相同推理預算（Rollout 次數 1, 2, 4, 8）的條件下，我們提出的 Dev-Search 策略始終優于僅依賴執行驗證 (Exec)、執行驗證+ORM (ORM_Exec) 或投票 (Voting) 的基線方法。這證明了在關鍵開發流程中進行干預和指導能帶來更優的搜索效率。（詳見圖 5）
預算與性能關系 (TTS)：增加推理預算（Generation Budget）通常能帶來性能的提升，再次驗證了外部 TTS 的有效性。預算的增加對于解決簡單和中等難度（Level 1-4）的問題提升尤為明顯。
高難度任務瓶頸：對于最高難度（Level 5）的問題，過高的推理預算反而可能導致性能輕微下降。這暗示對于極其復雜的任務，僅靠外部搜索擴展可能已觸及模型內在推理能力的瓶頸，需要內部 TTS（想得更深）的共同作用或更強的基礎模型能力。（詳見圖 6）

圖 5: 不同搜索方式在相同 budget 下的性能比較

圖 6: 在不同難度的 SWE-bench Verified 上使用不同 budget 的能力比較

結論

本研究成功展示了通過統一的測試時計算（TTS）擴展框架，可以顯著增強個人可部署的開源 SWE Agent 的代碼推理和問題解決能力。我們證明了“思考更長時間”（增加推理計算）而非“模型更大”（增加參數）是提升模型在復雜軟件工程任務中表現的有效途徑。這項工作為在資源受限環境下（如私有部署）使用和發展高性能 SWE Agent 開辟了新的可能性。