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%）。

問題主要分為四類：

過於嚴格的測試¹會強制要求提示詞未指定的特定實作細節，使許多功能正確的解法無法通過。
需求說明不完整的提示詞²漏掉隱藏測試會要求、又無法合理推斷的需求。
低覆蓋率測試對所要求功能的檢查不足，因此不完整的修正也能通過。
誤導性提示詞會把模型引向錯誤行為，或與測試要求相矛盾。

我們的發現指出，要打造難度高又不失公平的基準並不容易，也顯示智慧體在可擴展資料品質檢查上的效用日益提升。根據這些結果，我們估計 SWE-bench Pro 約有 30% 的任務存在問題，並建議模型開發者審慎檢視結果。

方法論

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

結合自動篩選與人工審查的品質保證工作流程，用於評估任務品質。 — 初步的資料品質流程會標記問題以供審查。我們透過更深入的智慧體輔助稽核，以及由資深工程師參與的人工標註作業，來驗證被標記的任務。

初步的自動篩選器會審查提供給模型的指示、模型解決任務的嘗試，以及用於評分這些嘗試的測試，藉此標記可能有缺陷或有問題的範例。此篩選器標記出 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":

無

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":

無

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 中的類似案例，凸顯了嚴格檢查基準的重要性。開源程式碼庫中的 issue 與 pull request 原本是為人類協作而建立，通常經過維護者與貢獻者之間長時間的來回討論。因此，問題描述、合併後的程式碼與單元測試，並不總能構成乾淨、獨立、能可靠評估模型的任務。尤其是 pull request 中包含的測試可能過於嚴格，因為這些測試是為驗證特定變更而撰寫，而非為解決任務定義出與實作方式無關的標準。

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

我們希望更廣泛的評估社群能開發新的基準，由資深軟體開發者專門為測試模型能力而建立。這種做法能維持衡量模型能力所需的高標準與真實性，也讓整個過程能有更完善的人工監督。鑑於本分析揭露的問題，我們撤回先前採用 SWE-Bench Pro 的建議。

歸根究柢，評估應透過難以投機取巧、易於信任，且能真實反映模型能力或對齊情況的基準，提供有意義的訊號。由於這些結果會影響 OpenAI 的部署與安全決策，我們追蹤的評估必須有效，且能提供充分資訊。