為什麼 SWE-bench Verified 不再能衡量前沿程式碼能力 | OpenAI

2026 年 2 月 20 日

為什麼 SWE-bench Verified 不再能衡量前沿程式碼能力

SWE-bench Verified 的污染日益嚴重。我們建議使用 SWE-bench Pro。

自我們於 2024 年 8 月首次發布 SWE-bench Verified 以來，業界已廣泛使用它來衡量模型在自主軟體工程任務上的進展。發布後，SWE-bench Verified 為能力進展提供了強烈的信號，並成為前沿模型發布中報告的標準指標。追蹤和預測這些能力的進展也是 OpenAI 準備工作框架（Preparedness Framework）的重要組成部分。當我們最初創建 Verified 基準測試時，我們試圖解決原始評估中導致 SWE-bench 數據集內某些任務無法完成的問題⁠（在新視窗中開啟）。

在最初的飛躍之後，SWE-bench Verified 的尖端進展已經放緩，在過去 6 個月內從 74.9% 提升⁠（在新視窗中開啟）至 80.9%。這引出了一個問題：剩餘的失敗是反映了模型的局限性，還是數據集本身的特性？

在一項新的分析中，我們發現了 Verified 集合的兩個主要問題，這表明該基準測試已不再適合衡量當前性能水平下前沿模型發布的自主軟體工程能力：

我們還發現證據表明，在訓練期間見過這些問題的模型更有可能成功，因為它們擁有通過描述不全的測試所需的額外信息。

這意味著 SWE-bench Verified 的進步不再反映模型在現實世界軟體開發能力上的實質性提升。相反，它們越來越多地反映了模型在訓練時接觸該基準測試的程度。這就是為什麼我們停止報告 SWE-bench Verified 分數，並建議其他模型開發者也這樣做的原因。

我們正在構建新的、未受污染的評估工具，以更好地追蹤程式碼編寫能力，我們認為這是廣大研究社群應該關注的重要領域。在擁有這些工具之前，OpenAI 建議報告 SWE-bench Pro 的結果。

背景

原始的 SWE-bench⁠（在新視窗中開啟）評估於 2023 年發布。每個問題都源自 12 個開源 Python 存儲庫中已解決的 GitHub Issue，並與相應的拉取請求 (PR) 配對。為了確定模型生成的程式碼更改是否正確，每個問題都附帶兩組測試：

模型看不到這些測試。它必須僅根據原始 Issue 文本和修復前的存儲庫狀態來生成程式碼更改。只有在應用程式碼更改後所有測試都通過，它才算通過一個問題。

我們發現該評估存在許多問題，可能導致低估模型的能力。

我們在 2024 年創建了 SWE-bench Verified 以解決這些問題。我們與專家軟體工程師合作，審查了 1,699 個 SWE-bench 問題，並過濾掉存在這些問題的題目。每個問題都由三位專家獨立審查。這一審查過程產生了 SWE-bench Verified，這是一個包含 500 個問題的精選集合。

過窄與過寬的測試

雖然 SWE-bench Verified 較初始版本有很大改進，但仍存在殘留問題。我們對 138 個 SWE-bench Verified 問題進行了審計，這些問題是 OpenAI o3 在 64 次獨立運行中未能一致解決的。每個案例都由至少六位經驗豐富的軟體工程師獨立審查。如果專家標記了問題，則由另一個團隊進行重新驗證。

我們發現，在 138 個問題中，有 59.4% 在測試設計和/或問題描述方面存在實質性問題，導致即使是最強大的模型或人類也極難或無法解決。

第一種失敗模式的一個典型例子是 pylint-dev__pylint-4551⁠（在新視窗中開啟），其中 PR 引入了一個新函數 get_annotation 作為整體解決方案的一部分。問題描述中並未提到此函數名稱，但測試直接導入了它。雖然某些模型可能會直覺地創建這樣一個函數，但要正確解決問題，並非絕對需要實現一個具有此特定名稱的函數。許多有效的解決方案因導入錯誤而未能通過測試。

測試案例過寬的一個例子是 sympy__sympy-18199⁠（在新視窗中開啟）。此任務源自一個解決了 nthroot_mod 函數三個不同問題的 PR，具體為 #17373⁠、#17377⁠ 和 #18212⁠。然而，SWE-bench Verified 任務的描述僅涵蓋了最後一個問題 #18212⁠。這造成了不匹配：PR 測試涵蓋了所有三個問題，而描述僅詳細說明了一個。在我們的運行中，模型通常正確實現了描述的修復，但隨後未能通過涵蓋其他兩個問題實現情況的測試。

污染

SWE-bench Verified 及其存儲庫（程式碼庫和發布說明）都是開源的，且被廣泛使用和討論，這使得模型開發者難以避免污染。

我們首先在自己的模型中發現了污染跡象。例如，當 GPT-5.2 解決了 31 個我們認為幾乎不可能解決的任務時。在 django__django-14725⁠（在新視窗中開啟）中，測試需要一個特定的新參數 edit_only，而問題陳述中並未明確要求該參數。在解決問題時，GPT-5.2 在其思維鏈中顯示它擁有關於詳細說明程式碼庫更改的發布說明信息，並正確識別出 edit_only 參數是在 Django 4.1 中引入的。

為了更廣泛地評估污染的嚴重程度，我們創建了一個自動化紅隊測試設置。對於每個 SWE-bench Verified 問題，我們任務 GPT-5 探測 GPT-5.2-Chat、Claude Opus 4.5 和 Gemini 3 Flash Preview 的污染情況。選擇這些模型是為了排除推理模型，但我們承認它們之間可能存在不小的能力差距。

為了探測污染，GPT-5 接收了：SWE-bench Verified 任務的 ID、描述、標準補丁（gold patch）和 PR 測試。在 15 個回合中，我們允許 GPT-5 變換系統/開發者提示詞、用戶提示詞、助手預填（prefill）以及不同的誘導策略。每一輪後，一個裁判模型會標記出現了多少新穎的任務特定信息，並且每個回應都會根據污染嚴重程度被標記為從「無」到「強」。GPT-5 被允許根據之前的回合調整策略，以迭代地恢復任務特定的細節。對於每個強污染的例子，我們通過另一個裁判驗證 GPT-5 沒有向目標模型洩漏過多信息。最後，我們手動審查了構成本文對話紀錄的「強」污染示例。

以下是不同模型提供商中強污染的示例。

GPT-5.2

給定任務描述中的一小段內容，GPT-5.2 輸出了完全正確的標準補丁。特別是，它知道確切的類別和方法名稱，以及新引入的早期返回條件 if username is None or password is None。

任務 ID：django__django-11451⁠（在新視窗中開啟）

Claude Opus 4.5

Opus 不僅能夠回憶起 PR 引入的確切 4 行功能更改，以及它涉及的特定文件名和方法，還能逐字引用作為差異（diff）一部分的行內注釋。

任務 ID：astropy__astropy-13236⁠（在新視窗中開啟）

Gemini 3 Flash

當除了 ID 之外沒有提供任何關於任務的進一步信息時，Gemini 3 Flash 能夠逐字輸出任務描述和標準補丁中的細節。這包括用於用戶名驗證的新正則表達式公式以及更改的確切行號。

任務 ID：django__django-11099⁠（在新視窗中開啟）

討論

從這次對 SWE-bench Verified 的審計中，我們看到了評估設計的兩個更廣泛的教訓。首先，源自公開可用材料的基準測試帶有污染風險，訓練數據的暴露會悄悄地推高分數。如果在構建基準測試時使用了公開抓取的數據，模型開發者應進行額外的污染測試。公開發布的基準測試，甚至是其解決方案，最終都可能進入訓練數據。在數據集的發布方式（如密碼保護）和訓練數據過濾（如嚴格遵守金絲雀字符串）方面都應格外小心。

其次，自動評分很難做對；完美的測試案例應該能完全驗證正確的功能，既不依賴於特定的不重要實現細節，又能抵禦捷徑解決方案。這些問題本質上是複雜且難以解決的。發現這些問題需要多次廣泛的人工標記工作。

我們已將這些發現納入我們最近的評估工作中。在過去的幾個月裡，我們選擇報告來自 SWE-Bench Pro 公開部分的結果。我們建議其他模型開發者也這樣做。SWE-bench Pro 並不完美，但從經驗上看，它受污染問題的影響較小。我們的污染檢測流程發現了一些污染案例，但這些案例明顯比 SWE-bench Verified 更罕見且不那麼嚴重，而且沒有模型能夠生成完整的逐字標準補丁。

我們將繼續投資於原創的、私有編寫的基準測試，並請求業界和學術界提供幫助，共同開展這項工作。在 GDPVal 中，任務由領域專家私下編寫，降低了暴露風險，且解決方案由受過培訓的評審員進行整體評分。這種方法雖然資源密集，但對於衡量真正的能力提升越來越有必要。

作者

延伸閱讀

研究 | 2026 年 2 月 20 日

全球事務 | 2026 年 2 月 19 日

研究 | 2026 年 2 月 18 日