OpenAI公開挑戰AI產業最受關注的程式設計基準之一，主張SWE-Bench Pro中有相當大比例的任務可能存在足以扭曲模型比較的缺陷。OpenAI新發布的分析指出，該公司稽核發現基準中約有30%的任務可能已損壞。
這項發現的重要性不只在於一個資料集。像SWE-Bench Pro這類程式設計基準，已成為衡量代理式軟體開發進展的簡寫指標，影響研究優先順序、發表訊息，某些情況下也影響企業對哪個模型最適合程式設計工作的看法。OpenAI的核心觀點是：如果底層任務本身不可靠，那麼頭條成績可能比許多模型開發者與買家所假設的，更少反映真實的軟體工程能力。
為什麼OpenAI要質疑業界倚賴的基準
根據OpenAI的說法，該公司是在先前得出SWE-bench Verified存在重大設計與污染問題後，才開始檢視SWE-Bench Pro。當時OpenAI曾表示，已鼓勵更廣泛的社群轉向SWE-Bench Pro，作為評估更長期、更貼近現實的程式設計任務的更強測試。
這個較新的基準之所以有影響力，部分原因在於它看起來展現了快速進展。OpenAI寫道，在731個任務的公開切分上，前沿模型在八個月內通過率從23.3%提升到80.3%。這種幅度的跳升，通常會被解讀為實務程式設計能力的大幅提升。
OpenAI現在認為，這些結果需要更謹慎看待。在最新稽核中，該公司表示其內部資料點分析管線將200個任務，也就是資料集的27.4%，標記為損壞。另一項人工標註活動則辨識出249個任務，也就是34.1%，為損壞。根據這些審查，OpenAI估計SWE-Bench Pro約有30%的任務存在缺陷。
該公司的立場並不是每個任務都無法使用，也不是完全沒有訊號。相反地，它是在警告：基準結果應被謹慎解讀，因為相當一部分測試可能會懲罰正確行為，或獎勵不完整的修補。
OpenAI指出的具體失敗模式
OpenAI的分析將問題分成幾個類別，對任何做過評估的人來說都不陌生，尤其是在以隱藏測試取代人工判斷的軟體任務中。
第一類是過於嚴格的測試。根據OpenAI，有些任務要求非常特定的實作細節，但這些細節並未在提示中說明。這代表模型即使產生功能上正確的解法，仍可能失敗。
第二類是不夠明確的提示。在這些情況下，OpenAI表示隱藏測試會強制執行無法從任務描述中合理推得的要求。這造成模型被要求做的事情與實際評分標準之間不一致。
第三個問題是測試涵蓋率不足。OpenAI說，有些測試沒有充分檢查所要求的功能是否真的已被實作，讓部分或不完整的修補也能通過。對評估AI程式設計系統的買家而言，這正好是過於嚴格測試的反向失敗模式：基準可能會高估能力，而不只是低估。
OpenAI也指出了一些誤導性的提示，會引導模型朝向與後續測試預期相衝突的行為。該公司舉了一個涉及Markdown目錄格式的例子，其中可見提示與隱藏測試案例只差一個前置空白。在那種情況下，即使模型完全依照提示字面執行，仍可能被判錯。
這個例子正切中更廣泛批評的核心。許多軟體問題與 pull request 來自真實的協作儲存庫，而不是整潔的評估題。OpenAI認為，當這些素材被轉換成基準時，提示、參考修補與測試不一定能彼此充分對齊，難以支撐可靠評分。
稽核如何進行，以及不確定性仍在哪裡
這則故事中最堅實的事實來自OpenAI自己公布的方法論，但它仍然是供應商報告的結果，而非第三方獨立基準審查。
OpenAI表示，它建立了一套品質保證管線，用來檢查任務指示、模型嘗試、後設資料與失敗軌跡，以找出可能有問題的案例。該公司說，第一個自動化過濾器先標出286個潛在損壞任務，供進一步審查。
接著，OpenAI使用兩條平行審查路徑。一條是具備Codex的調查型代理，可存取儲存庫與執行環境，讓它們能檢查檔案、執行測試並分析模型失敗。另一條則是由經驗豐富的軟體工程師參與的人工作業標註活動。OpenAI表示，在這個審查流程中，每個被標記的任務都由五位工程師檢視，分歧則會往上升級。
OpenAI報告指出，人工審查者通常比代理管線更容易將任務判定為損壞。該公司也表示，在被標記的任務中，審查者判斷與代理管線的類別重疊率為74%，而且在任何被標記的任務中，「未損壞」都不是最常見的人類標籤。
這些細節強化了公司主張：問題不只限於零星邊緣案例。不過，從已公開材料仍有其限制。可取得的來源證據並未包含SWE-Bench Pro維護者的外部回應，也沒有提供在修正後資料集版本上對主要模型進行並列重評的結果。因此，雖然OpenAI提出了基準存在相當雜訊的有力論點，但對模型排名的確切影響，從目前證據仍無法完全釐清。
為什麼這件事對模型開發者與企業買家很重要
對AI實驗室而言，直接的含意是：程式設計基準上的勝利，可能沒有看起來那麼持久。如果將近三分之一的任務有缺陷，排行榜差距也許反映的是提示與測試不匹配、實作假設，或測試涵蓋不足，而非模型能力的真實差異。
這對打造AI代理來處理軟體工作的團隊尤其重要。SWE-Bench Pro一直被定位為衡量較長期程式設計行為的重要測試，更接近代理系統在生產環境中的表現。若其任務實質上有缺陷，開發者就需要更完整的評估堆疊，包括儲存庫層級測試、人工審查、回歸分析，以及真實部署指標，而不是單一公開分數。
對企業AI買家而言，OpenAI的警告提醒大家，不要把基準通過率直接等同於可上線部署。某個模型即使在SWE-Bench Pro表現很好，在真實程式碼庫中仍可能面臨可靠性、歧義或測試完整性的挑戰。反過來，某個在基準上看起來較弱的模型，也可能只是被任務本身的缺陷所拖累。
這同時也是治理議題。OpenAI明確把基準品質與其Preparedness Framework下的安全與部署決策連結在一起。邏輯很直接：如果評估高估或低估能力，就可能扭曲產品發佈選擇與風險評估。這一點不只適用於OpenAI，也不只適用於程式設計基準。隨著模型越來越常以代理式行為接受評估，糟糕的基準管理已成為戰略問題，而不只是學術問題。
該公司對代理輔助稽核的強調也很值得注意。OpenAI其實是在主張：被測試的那類系統，也可以幫忙除錯測試本身。這種做法是否會成為標準，取決於外部研究者是否接受：基於代理的審查可以提升資料集品質，而不會再引入另一層模型依賴偏差。
證據、主張，以及哪些屬於供應商報告
這則故事的核心主張屬於供應商報告：OpenAI表示，根據其內部稽核流程與自行組織的人工作業審查活動，SWE-Bench Pro約有30%的任務損壞。
OpenAI也報告指出，前沿模型在該基準731個任務的公開切分上，八個月內從23.3%提升到80.3%。在本文中，這個數字應被視為OpenAI引用的基準趨勢，而不是獨立驗證的市場指標。
方法細節則更具體。OpenAI說，自動過濾器標出了286個任務，資料點分析管線判定200個任務損壞，而人工標註活動則判定249個損壞。它也表示，五位資深工程師審查了每個被標記的任務，而且審查者判斷在74%的被標記案例中與代理管線重疊。
根據目前可得證據仍未被驗證的是：基準維護者或其他實驗室會如何分類相同任務、修正後的任務是否會實質改變模型排行榜，以及除SWE-bench Verified與SWE-Bench Pro之外，鄰近程式設計基準是否也出現類似錯誤率。
接下來要觀察什麼
第一個要觀察的訊號，是SWE-Bench Pro維護者是否會發表回應、修訂版資料集，或正式反駁。如果他們同意OpenAI相當大一部分的發現，這個基準可能會很快更新；如果他們不同意結論，產業可能需要一個獨立裁定流程。
第二，留意大型實驗室是否改變程式設計表現的呈現方式。如果未來模型發表較少強調SWE-Bench Pro，而更多聚焦私有評估套件、儲存庫層級測試，或任務完成研究，這將顯示外界對公開程式設計排行榜的信心正在減弱。
第三，要注意OpenAI是否會針對使用Codex或相關調查代理進行基準稽核，釋出更多工具或方法論。可重現的稽核管線，可能影響業界如何驗證的不只是程式設計資料集，也包括更廣泛的AI代理評估。
最後，更大的問題是：基準膨脹是否已成為快速變動模型類別中的反覆模式。OpenAI先前曾批評SWE-bench Verified，如今又對SWE-Bench Pro提出問題。如果下一代程式設計評估也遇到類似麻煩，市場可能會轉向混合證據：公開基準、客戶遙測，以及受控的真實工作流程測試，而不是單一數字排行榜。
Creati.ai觀點
OpenAI的分析之所以重要，與其說是因為它攻擊了一個基準，不如說是因為它揭露了AI衡量中的結構性問題。業界想要乾淨、可比較的程式設計模型數字，但軟體任務本來就很混亂。當提示、隱藏測試與參考修補都取自真實儲存庫時，微小的不一致就可能悄悄把評估變成噪音。這對想優化模型的開發者，以及想放心採購的企業，都是問題。
實務上的重點，不是停止使用SWE-Bench Pro、SWE-bench Verified或其他公開基準，而是把它們從最終裁決降級為方向性輸入。對於推出AI代理的團隊來說，基準素養如今已是產品工作的一部分：要理解一個分數真正衡量了什麼、漏掉了什麼，以及它可能有多脆弱。能在程式設計領域贏得信任的實驗室，會是那些把強勁的公開結果、透明的評估設計、真實工作流程證據，以及自我稽核能力結合在一起的團隊。
