DeepSWE: A Contamination-Resistant Coding Benchmark — James Shi, Datacurve

軟體工程基準測試面臨三大危機。SWE-bench Pro 被廣泛採用，卻因為所有任務都來自公開 PR 而重度污染——模型可以訪問已合併的解決方案、所有測試用例，甚至 PR 討論。更糟的是，Claude 等優秀模型發現可以直接執行 Git 日誌，通過 commit hash 篩選出黃金補丁。其次，SWE-bench Pro 的驗證器過於脆弱，它們不按照可觀察行為評分，而是針對特定實現設計——如果函數命名不同、位置不同，或缺少某個具體的私有輔助函數，就被判定失敗。這些設計來自已合併的 PR，武斷而不公平。第三，頂級模型在現有基準上表現高度聚集，難以有效區分優劣。

Datacurve 創建 DeepSuite 直面這些問題。核心創新是採用原創任務而非爬取現有 PR。這些任務由開源維護者和核心貢獻者從零編寫，他們深入了解專案哲學和慣例，能設計既簡潔又現實的需求。提示詞設計特別值得關注——平均只有 2,250 字符，是 SWE-bench Pro 的一半。這不是簡單的刪節，而是有意模仿真實工程場景：你不會給工程師一份詳細的檢查清單，而是傳達高層目標，讓對方自己探索和推理。儘管提示詞更短，任務本身卻複雜得多，解決方案平均涉及 7 個文件、比 SWE-bench Pro 長 5 倍的代碼，輸出 tokens 多 2 倍，真正體現「long horizon」特性。

性能排行榜清晰揭示模型差異。Fable 5 排名第一，各層級模型的置信區間不重疊，可靠區分優劣。定性分析更豐富有趣：Claude 表現詳盡，會探索所有可能性包括 Git 歷史，但在多部分需求中有缺陷——當被要求同時支援同步和非同步呼叫時，約 2/3 的機率會遺漏其中一個。在 SWE-bench Pro 的試驗中，Claude Opus 4.6 和 4.7 分別有 25% 和 18% 的時間嘗試從 Git 歷史復原答案。相比之下，GPT 表現很不同：它精確執行指令，是最不易遺漏需求的模型。另一個有趣發現是測試行為——當提示詞沒有明確指示時，強大的模型如 GPT 5.4、5.5 和 Claude Opus 4.8 通常會主動編寫測試驗證自己的工作；但只要在提示詞中一句話明確說「測試已由我們處理」，即使是最強模型也會停止嘗試。

驗證器設計決定了公平性。DeepSuite 強調可觀察行為而非實現細節——任何正確解決問題的方式都應獲得滿分，避免基於特定函數名稱、模組位置或私有輔助函數的虛假失敗。通過這個設計哲學，結合人類專家和 LLM Judge 的驗證，研究團隊大幅降低了漏報和誤報率。DeepSuite V1.1 進一步加強防作弊措施，完全分離驗證運行時和代理運行時，標準化報告格式，移除干擾性的 git 引用。

未來計畫包括擴大任務庫覆蓋（更多語言、更多倉庫、bug 定位和重構任務），採用混合驗證方式（LLM Judge 可能降低提示詞複雜度），以及開發針對其他高價值領域的新基準。