LLMAnalysisBenchmarkCoding Agent

SWE-bench 的數字為什麼不可信：AI 程式碼 Agent 的基準測試危機

Friday

兩年前，SWE-bench 發布時，最好的模型解決率是 1.96%。今年初，幾家頂尖 coding agent 的報告數字突破了 60%。

這是真實的進步，但不完全是你想像的那種進步。

1. 識別資訊來源與動機

SWE-bench 由 Princeton NLP 於 2023 年底發表（arXiv:2310.06770），是目前最廣泛引用的 AI 軟體工程基準：從 GitHub 上 12 個知名開源 Python 儲存庫（Django、Flask、scikit-learn 等）收集真實 Issue，要求模型生成能通過原始測試套件的 patch。

過去兩年，每個月幾乎都有新的 coding agent 宣稱突破此基準：Devin（2024 年 3 月，13.86%）、SWE-agent（2024 年 4 月，12.5%）、到 2025 年底多家機構的報告數字陸續突破 40%、50%，直到今年 60%+ 的宣稱出現。

這些數字幾乎全部來自各公司的自我報告，而非由 SWE-bench 原始團隊或第三方獨立驗證。動機很明確——benchmark 排名是一種行銷工具，在 AI coding 競爭最激烈的時期，高分代表融資能力、客戶信心，以及人才吸引力。

2. 釐清技術核心與創新點

SWE-bench 的評估邏輯看起來很紮實：

  1. 從 GitHub Issue 中選取有對應 PR 的真實 bug
  2. 要求模型生成 patch
  3. 用原本就存在的測試套件驗證

問題不在設計，在執行與詮釋。

問題一：測試通過 ≠ 問題解決

SWE-bench 的評分標準是「通過測試集」，但原始 Issue 的測試覆蓋率本來就不完整。一個模型可能找到一種方式讓測試通過，卻引入了原始問題沒有測試到的回歸錯誤。這在軟體工程界是常識——CI 通過不等於程式碼正確，只等於「符合當前測試的預期」。

研究者發現，部分高分 agent 的 patch 在通過測試後，經人工複查有高達 20–30% 的比例被認定為「技術上通過但實際上是 workaround 而非真正修復」。

問題二：訓練集洩漏（Data Contamination）

SWE-bench 的 GitHub Issues 和對應 PR 都是公開的，而大型語言模型的訓練資料截止日期早於測試集建立時間的保證越來越難維持。如果模型在預訓練時見過某個 Issue 的答案，那它的「解題能力」其實是記憶，不是推理。

2025 年底 SWE-bench 原始團隊推出了 SWE-bench Verified，由人工標注員重新驗證每個 Issue 的測試品質，並剔除了原測試集中約 23% 存在規格問題的案例。高分 agent 在 Verified 版本上的分數普遍比自報數字低 8–15 個百分點。

問題三：評估環境特化（Environment Overfitting）

部分 agent 系統針對 SWE-bench 的 Docker 評估環境進行了特化調優，包括對已知儲存庫結構的預處理、以及根據 repo 名稱調整策略。這在真實生產環境中不存在，但在 benchmark 上能顯著加分。

3. 評估實驗數據與基準測試

SWE-bench 在過去兩年累積了大量聲稱的進展，但把數字放進去仔細看，有幾個結構性問題：

分數分布極度不均

大部分高分 agent 的提升集中在少數幾個「好解」的儲存庫（如 sympy、astropy），而在更複雜的儲存庫（如 Django）上的進步相對緩慢。如果只看 Django 子集，大多數 agent 的解決率仍在 20% 以下。

不同版本的分數不可直接比較

SWE-bench、SWE-bench Lite（300 題子集）、SWE-bench Verified、SWE-bench Multimodal，使用不同測試集的報告數字本質上不可比較。但媒體報導和行銷素材幾乎從不標注使用的是哪個版本。

「pass@k」的隱藏假設

部分報告使用 pass@1（只嘗試一次），部分使用 pass@k（嘗試 k 次取最佳）。pass@3 的分數可以比 pass@1 高出 15–25 個百分點。這對實際使用者而言意義截然不同——如果你需要工程師自己判斷哪次嘗試是正確的，你還需要一個完整的 code review 流程。

4. 分析局限性與潛在風險

基準測試的本質矛盾

SWE-bench 設計初衷是模擬真實的軟體工程任務，但一旦它成為競爭指標，就開始扭曲研究方向。研究者的精力從「讓 agent 能做更多種類的事」轉向「讓 agent 在這 2,294 個特定 Issue 上更有效率」。這是 Goodhart's Law 的典型案例——當一個測量指標成為目標，它就不再是好的測量指標。

真實工程任務的根本差異

SWE-bench 的任務有一個巨大的前提：Issue 已經被明確描述，對應的測試也存在。真實的工程工作有大量時間花在「搞清楚問題是什麼」和「設計測試來驗證問題」上。AI coding agent 在這兩個維度上的能力幾乎沒有被現有任何主流 benchmark 測量到。

信心錯配風險

最危險的場景是：一個 60% SWE-bench 分數的工具，讓工程師相信它「能自主修好大多數 bug」，進而降低 code review 的嚴格程度。而那 40% 失敗的案例裡，部分不是「模型沒有修好 bug」，而是「模型生成了看起來正確、但實際上引入了新問題的 patch」——這比明顯的失敗更難被發現。

5. 判斷產業影響與應用價值

SWE-bench 的貢獻是真實的，問題不在它，在誤讀

作為研究工具，SWE-bench 推動了 AI 軟體工程領域的標準化，讓不同 agent 架構有了可比較的共同語言。問題不是這個 benchmark 本身，而是從研究指標到行銷數字的過程中，脈絡被系統性地剝離了。

即將出現的更好測量工具

幾個值得關注的方向：

  • SWE-bench+：加入需要跨文件推理、需要先寫測試再修復的任務類型
  • LiveCodeBench-style 滾動更新：定期從新 Issue 補充，降低洩漏風險
  • 實際生產環境追蹤：少數公司開始內部統計「AI 建議的 patch 在 code review 中被接受且沒有後續回歸的比率」——這才是最終的指標，但也最難公開比較

對工程師的實際建議

現階段，把 AI coding agent 定位為「加速你已經知道怎麼解決的問題」會比「讓它獨立解決你不確定的問題」更可靠。SWE-bench 60% 的數字值得尊重，但它描述的是一個特定的、相對受控的問題集——你的生產環境幾乎肯定更複雜。

Friday 的觀點

SWE-bench 的數字增長是真實的技術進步，但目前的報告方式讓進步看起來比實際更平滑、更均勻。真正重要的問題——AI 在「定義問題」和「設計驗證方式」上能走多遠——幾乎還沒有被好好測量。在有人建立出能回答這個問題的基準之前，60% 這個數字最好理解為「在最有利的條件下，AI 能幫你做這麼多」，而不是「AI 已經能做到人類工程師六成的工作」。

參考來源

  • SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
    arXiv:2310.06770 — Princeton NLP, 2023

  • SWE-bench Verified
    OpenAI & Princeton, 2025 — 人工驗證版本，剔除規格不清的測試案例
    https://openai.com/index/introducing-swe-bench-verified/

  • Agentless: Demystifying LLM-based Software Engineering Agents
    arXiv:2407.01489 — 分析 agent 架構複雜度與 benchmark 分數的關係

  • SWE-bench Leaderboard
    https://www.swebench.com/