2026年7月8日

在編碼評估中分辨訊號與雜訊

透過詳細審核，我們發現 SWE-Bench Pro 存在廣泛任務問題，並估計約 30% 任務有缺陷。

正在載入...

準確衡量我們模型的能力，對作出穩健的部署和安全決策十分重要，包括 OpenAI 防範應對架構⁠（在新視窗中開啟）下的決策。每次模型發佈時，我們都會報告多項外部和內部基準的結果，以追蹤模型進展。當評估存在影響結果的缺陷時，可能會令人誤解能力水平，從而錯誤呈現安全論證並影響研究優先次序。

我們最近調查了最廣泛使用的編碼基準之一 SWE-bench Verified，發現它存在根本性的設計和污染問題，而該評測已不再能為軟件開發能力提供有意義的訊號。當時，我們鼓勵更廣泛的社群改用 SWE-Bench Pro。

SWE-Bench Pro⁠（在新視窗中開啟）的設計旨在改進 SWE-bench Verified，透過以更長時程和更貼近現實的編碼任務測試模型，更好地追蹤智能代理式編碼能力。與 SWE-bench Verified 一樣，任務會以程式化方式從一組公開和私人程式碼庫的功能變更歷史中取得。模型需要實作一個能通過某項功能的新測試、且不破壞現有功能的解法。在包含 731 個任務的公開分割集上，前沿模型的通過率在八個月內由 23.3% 提升至 80.3%。

其後，我們對 SWE-Bench Pro 進行了類似審核，使用數據點分析流程審查該數據集。該流程會審查模型對任務的嘗試、任務元數據和失敗追蹤，以標記可能的評估缺陷。其後，每個被標記的任務都會經過多輪調查智能代理評估，並由五名經驗豐富的軟件工程師獨立審查；如有分歧，則會升級作進一步調查。

我們在數據集相當大一部分中發現導致任務失效問題的證據。我們的數據點分析流程標記了 200 個（27.4%）有缺陷的任務，而人類標註工作則識別出 249 個（34.1%）。

這些問題主要分為四類：

過度嚴格的測試¹會強制要求提示詞中未指定的特定實作細節，令許多功能上正確的提交失效。
規格不足的提示詞²會省略隱藏測試所強制要求、且無法合理推斷的要求。
覆蓋率低的測試未能充分檢查所請求的功能，因此不完整的修正也能通過。
誤導性提示詞會把模型引向錯誤行為，或與測試要求相矛盾。

我們的發現顯示，整理既具難度又公平的基準並不容易，同時也突顯智能代理在可擴展數據質素檢查上的實用性日益提高。鑑於這些結果，我們估計約 30% 的 SWE-bench Pro 任務存在缺陷，並建議模型開發者仔細審視結果。

方法

我們的目標是確保任務失敗反映真正的模型限制，而任務成功則反映對提示詞要求作出完整且有效的解法。為檢查評估所用數據的質素，我們建立了品質保證流程，以評估每個數據點是否準確反映模型能力。

結合自動篩查與人類審查以評估任務質素的品質保證工作流程。 — 初步數據質素流程會標記問題以供審查。我們會對已標記任務進行更深入的智能代理輔助審核，並與經驗豐富的工程師合作開展人類標註工作，以作驗證。

初步自動篩選器會審查給予模型的指示、模型解決任務的嘗試，以及用於評分這些嘗試的測試，從而標記可能有缺陷或有問題的例子。此篩選器標記了 286 個可能有缺陷的任務。隨後，我們以兩種方式對該子集作更深入審查：一是人類監督的智能代理審查，由調查智能代理進行廣泛檢查並由人類作出最終判斷；二是與經驗豐富的軟件開發者合作的人類標註工作。

人類監督的智能代理審查

每個被標記的問題都會由基於 Codex 的調查智能代理審核，這些智能代理獲准存取任務程式碼庫和環境。這有助它們分辨合理的任務歧義與真正的規格不足；前者通常可透過研究相鄰程式碼和程式碼庫慣例來解決。智能代理可以執行測試、檢查程式碼庫中的檔案，並調查模型的嘗試及其在任務上的常見失敗模式。在多次獨立重複這些深入審核後，一名研究員會審閱摘要、作出最終判斷，並標註可能的問題。

人類標註工作

與此同時，我們對被標記的子集開展了人類標註工作。我們與經驗豐富的軟件工程師合作；他們在審查任務前，已接受有關基準目標、問題分類和邊界案例的培訓。每項任務均由五名工程師審查。

審查員會先根據可見的問題陳述、測試案例和真實參考解法（稱為 gold patch）形成獨立判斷，然後才把流程分析或記錄用作輔助背景。其後，審查員根據具體證據分配標籤和嚴重程度評級，並將分歧或信心較低的個案升級作進一步審查。

相比調查智能代理，人類審查員更常把任務標記為有缺陷。兩條審查路徑在類別判斷上也存在一些分歧，但在任何被標記的任務中，「並非有缺陷」都不是最常見的人類標籤。在智能代理流程標記的類別中，審查員的判斷有 74% 個案重疊。

與智能代理流程相比，人類審查員也更常為同一任務選擇多個標籤，顯示他們認為任務在多方面存在缺陷，或無法清楚歸入單一類別。這表示智能代理加審查員流程產生了較保守的標註：它捕捉到人類識別的相同廣泛失敗模式，但低估了審查員看到額外或重疊問題的個案。最大差異出現在覆蓋率低的測試：人類將其選為 9.4% 基準任務中最常見的問題，而智能代理流程的比例為 4.1%。

失敗模式

在若干案例中，任務提示詞指定了某種實作方式，但隱藏測試案例預期的行為卻不同。

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

None

1"[space]| Chapter 1 | 1"
2"**[space]| Chapter 1 | 1"
3"[space]| Just title | "

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

None

1"[space][space]| Chapter 1 | 1"
2"**[space][space]| Chapter 1 | 1"
3"[space][space]| Just title | "

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

討論

我們識別出的問題，加上 SWE-bench Verified 中的類似案例，突顯嚴格檢查基準的重要性。開源程式碼庫中的議題和 pull request 原本是為人類協作而建立，通常經過維護者與貢獻者之間多輪往來討論。因此，問題描述、已合併程式碼和單元測試不一定能整齊對應，形成可用於可靠評估模型的清晰、獨立任務。尤其是，pull request 中包含的測試可能過度嚴格，因為它們是為驗證某項特定變更而編寫，而不是為任務解法定義一套不依賴實作方式的標準。

同時，評估缺陷如今比不久前更容易偵測。隨着模型能力提升，我們可以利用這些模型以更深入且一致的方式檢查提示詞、測試、修補、追蹤和邊界案例，協助找出以往成本高昂或難以大規模發現的基準問題。

我們希望更廣泛的評估社群能開發由經驗豐富的軟件開發者專門為測試模型能力而建立的新基準。這種方法既可保留我們希望用以衡量模型能力的高標準和真實性，也能在整個過程中提供更好的人類監督。鑑於本分析揭示的問題，我們撤回先前建議採用 SWE-Bench Pro 的說法。

歸根究柢，評測應透過難以取巧、容易信賴，並能真正反映模型能力或對齊情況的基準，提供有意義的訊號。由於這些結果會影響 OpenAI 的部署和安全決策，我們追蹤的評測必須有效且具參考價值。