在開發大型語言模型（LLM）時，衡量模型在程式開發（Coding）上的能力至關重要，因為這直接影響到模型的部署決策與安全性評估。然而，OpenAI 最近針對業界廣泛使用的評測基準 SWE-bench Pro 進行的審計發現，許多評測數據其實存在嚴重缺陷，導致評測結果中夾雜了大量雜訊。
什麼是評測中的信號與雜訊
在技術評測中，信號（Signal）是指能真實反映模型能力的數據。例如，如果模型無法解決一個複雜的 Bug，這應該是因為模型缺乏邏輯推理或對該語言的掌握度不足。而雜訊（Noise）則是來自於評測集本身的錯誤，例如測試案例寫錯了，導致即使模型給出了正確答案，系統仍判定為失敗。當雜訊過多時，開發者會誤以為模型能力不足，或者誤以為模型已經突破，導致研究方向偏移。
SWE-bench Pro 的設計初衷與問題
SWE-bench Pro 的目的是透過模擬真實世界的軟體工程任務，測試模型在長週期、複雜情境下的 Agentic Coding 能力（即模型能像工程師一樣自主分析、修改並驗證代碼的能力）。它的任務來源是從公開或私有的程式碼倉庫中，自動提取功能變更的歷史紀錄。
然而，OpenAI 發現這個基準集約有 30% 的任務是損壞的（Broken）。這意味著模型在這些任務上的失敗，可能根本不是因為模型不夠聰明，而是因為題目本身有問題。
評測缺陷的四大類別
透過自動化分析管線與資深工程師的人工審核，OpenAI 將這些損壞的任務歸納為四類：
第一類是過於嚴苛的測試（Overly Strict Tests）。測試案例強制要求特定的實作細節，而非功能結果。例如，只要空格多了一個，即便功能完全正確，測試也會判定失敗。
第二類是描述不足的提示詞（Underspecified Prompts）。題目給出的需求不完整，但隱藏的測試案例卻要求模型必須滿足某些未提及的條件，這讓模型在缺乏資訊的情況下無法猜中正確答案。
第三類是覆蓋率不足的測試（Low-coverage Tests）。測試案例太簡單，導致模型即使只修復了一小部分 Bug，或者給出了一個不完整但能勉強通過的方案，系統也會判定為成功，產生虛高的得分。
第四類是誤導性的提示詞（Misleading Prompt）。題目描述的方向與測試案例的要求相反或矛盾，導致模型被誘導至錯誤的實作路徑。
為什麼自動化評測會出錯
這類評測集通常是從開源專案的 Pull Request（PR，合併請求）中自動生成的。但在現實開發中，PR 的描述、最終合併的代碼以及單元測試，是經過開發者與維護者多次對話、反覆修改後才定案的。
將其直接抽離成獨立的評測任務時，會遺失這些對話脈絡。此外，工程師寫單元測試通常是為了驗證特定的一次改動，而非定義一個通用且獨立的標準。這導致自動生成的評測集在嚴謹度上與真實的工程需求存在落差。
如何更有效地審核評測集
為了找出這些問題，OpenAI 建立了一套品質保證管線：首先使用自動化過濾器標記可疑任務，接著利用基於 Codex 的調查代理人（Investigator Agents）進入程式碼環境進行深度分析，最後由五名資深軟體工程師進行獨立審核。
有趣的是，隨著模型能力的提升，我們現在可以用強大的模型來審核舊的評測集。這種以 AI 審核 AI 的方式，能比以往更快速、更低成本地發現大規模數據集中的缺陷。
實務建議與結論
對於追蹤模型能力的工程師而言，這次案例提供了一個重要提醒：不要盲目信任任何第三方基準集的得分。一個高品質的評測集應該具備三個特質：難以作弊（Hard to game）、值得信賴（Easy to trust）且能真實反映能力（Reflective of capability）。
OpenAI 因此撤回了先前推薦使用 SWE-bench Pro 的建議，並呼籲社群應由資深開發者專門設計、而非僅靠自動抓取生成的評測基準，以確保評測結果能提供真正的技術信號。
來源：openai.com - Separating signal from noise in coding evaluations
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。