準確衡量模型能力對於穩健的部署和安全決策至關重要，這也包括 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 的調查代理進行審計，這些代理被賦予任務儲存庫和環境的存取權限。這有助於它們區分合理的任務模糊性（通常可以透過研究附近程式碼和儲存庫慣例來解決）與真正的規範不足。代理可以運行測試、檢查儲存庫中的檔案，並調查模型的嘗試及其在任務上的常見失敗模式。在這些深入審計獨立重複多次後，研究人員審查了摘要，做出了最終判斷，並標記了可能的問題。

人工標註活動

同時，我們對被標記的子集進行了人工標註活動。我們與經驗豐富的軟體工程師合作，他們在審查任務之前接受了基準測試目標、問題分類和邊緣案例的培訓。每個任務都由五位工程師審查。

審查人員在將管道分析或記錄作為輔助背景之前，會根據可見的問題陳述、測試案例和真實參考解決方案（稱為黃金補丁）形成獨立判斷。然後，審查人員根據具體證據分配標籤和嚴重性評級，並將分歧或信心不足的案例升級以進行進一步審查。

人工審查人員比調查代理更有可能將任務標記為有問題。兩種審查路徑在類別上也存在一些分歧，但在所有被標記的任務中，「沒有問題」都不是最常見的人工標籤。在代理管道標記的類別中，審查人員的判斷有 74% 的情況是重疊的。

與代理管道相比，人工審查人員也更有可能為一個任務選擇多個標籤，這表明他們發現任務以多種方式存在問題，或者無法清晰地歸入單一類別。這表明代理加審查人員的管道產生了保守的標註：它捕捉到了人類識別出的相同廣泛失敗模式，同時低估了審查人員發現額外或重疊問題的案例。最大的差異在於測試覆蓋率不足，人類將其選為基準測試中 9.4% 的最常見問題，而代理管道的比例為 4.1%。

失敗模式

在某些情況下，任務提示詞規定了特定的實作方式，但隱藏的測試案例卻期望不同的行為。

討論

我們發現的問題，加上 SWE-bench Verified 中類似的案例，凸顯了嚴格檢查基準測試的重要性。開源儲存庫中的問題和拉取請求最初是為了人類協作而創建的，通常透過維護者和貢獻者之間的長時間來回溝通。因此，問題描述、合併的程式碼和單元測試並不總是能完美對齊，形成清晰、獨立的任務來可靠地評估模型。

特別是，拉取請求中包含的測試可能過於嚴格，因為它們是為了驗證特定變更而編寫，而不是為了定義一個與實作無關的任務解決標準。同時，現在比以前更容易檢測評估缺陷。隨著模型能力的提升，我們可以利用這些模型以更深入、更一致的方式檢查提示詞、測試、補丁、追蹤和邊緣案例，這有助於發現以前大規模查找成本高昂或不切實際的基準測試問題。

我們希望更廣泛的評估社群能夠開發由經驗豐富的軟體開發者專門為測試模型能力而建立的新基準測試。這種方法可以保持我們衡量模型能力所需的高標準和真實性，並允許在整個過程中進行更好的人工監督。鑑於本次分析中發現的問題，我們撤回了我們之前採用 SWE-Bench Pro 的建議。

最終，評估應該透過難以作弊、易於信任且真正反映模型能力或對齊的基準測試來提供有意義的訊號。由於這些結果會影響 OpenAI 的部署和安全決策，我們追蹤的評估必須是有效且具資訊性的。