Lesswrong
Current AI benchmarks are fundamentally flawed due to reward hacking, incorrect ground truths, and weak test coverage, as evidenced by issues found in o3, Humanity's Last Exam, and Terminal-Bench 2.0. My audit using Claude 4.5 reveals that even rigorously vetted benchmarks often contain significant vulnerabilities that allow models to pass without truly solving the tasks.
AI 生成摘要
當前的 AI 基準測試因獎勵破解、錯誤的標準答案及測試覆蓋率不足而存在根本性缺陷，這從 o3、Humanity's Last Exam 和 Terminal-Bench 2.0 中發現的問題可見一斑。我使用 Claude 4.5 進行的審計顯示，即使是經過嚴格審查的基準測試，也往往包含重大漏洞，讓模型無需真正解決任務即可通過。
去年六月，METR 在其 RE-Bench 和 HCAST 基準測試中抓到了 o3 的行為。在一個特別幽默的案例中，當 o3 被要求優化一個內核（kernel）時，它決定「縮小評分器所看到的測試時間概念」。
的開發涉及了「超過 1,000 名領域專家」和 50 萬美元的獎金。然而，在發布後，FutureHouse 的研究人員發現「」。
是一個由「一群國際演算法競賽獎牌得主」開發的程式競賽基準測試。他們的論文描述了該基準測試前身所存在的問題：
像 LiveCodeBench [35] 這樣的基準測試雖然提供了編程題目，但卻受困於環境不一致、測試案例薄弱（容易導致偽陽性）、難度分佈不均，以及無法隔離搜索污染（search contamination）的影響。
然而，作者向我們保證，他們自己的測試案例具有高品質：
我們基準測試中的許多題目源自 Codeforces，該平台使用 Polygon 命題系統。每道題目隨後都由專家測試團隊進行嚴格審核——這些專家通常來自社群的前 1%，並由至少一名協調員（通常是前 0.1%）監督。這些專家會驗證每道題目的合理性和原創性，確保其以前從未在其他地方出現過。測試人員接著會設計大量的「偽陽性」測試，設計邊界情況和極端情況的輸入，迫使題目作者不斷完善其測試套件，直到測試人員能想到的所有錯誤或低效解決方案都被揭露。此外，Codeforces 著名的「Hack」功能讓社群能夠提交輸入，以揭露那些看似正確但僅通過作者原始測試集的解決方案中的隱藏弱點，任何與成功 Hack 相關的單元測試都會立即加入最終測試集。
遺憾的是，這些傑出的奧林匹亞獎牌得主忘了在他們的基準測試中實際使用 Codeforces 的測試案例。他們的公開包含了一套完全不同的案例，這導致一些錯誤的解決方案也能。^()
我很好奇這類問題有多普遍，以及現代 LLM 在檢測這些問題方面表現如何。我決定對 進行一次基於 LLM 的審計。
Terminal-Bench 2.0 是 Terminal-Bench 的更難、驗證更完善的版本。我們對數據集進行了大量的技術手動和模型輔助驗證，以確保任務具有最高品質。幾家實驗室和數據供應商評論說，這是他們見過的高品質環境之一。——
Terminal-Bench 2 的作者在審計其基準測試方面投入了驚人的工作量。每個任務平均耗費三小時的人工審查。此外，他們還提示了一個對抗性代理（adversarial agent）嘗試在每個任務上作弊，以發現潛在的獎勵作弊行為。
儘管如此，他們仍「承認（他們的）基準測試可能仍存在缺陷」。
我向 Claude Opus 4.5^() 提供了每個任務的指令、文件、標準答案（oracle solution）和測試案例，並要求它按 1 到 5 分對測試覆蓋率進行評分。根據我的判斷，它評為 4 或 5 分的任務通常沒問題，而評為 1-3 分的任務則存在真正的問題。
我審計的完整結果可以在查看，關於評分為 1-3 分任務的筆記在。
Claude 將 14 個任務評為 3 分，1 個任務評為 2 分。我手動審查了這些任務，並判定其中兩個實際上是偽陽性（誤報）。^()
Claude 給出的最低分是一個名為 的任務。在這個任務中，網站的某些更改在一個孤立提交（orphaned commit）中丟失了，代理必須找到並將它們合併回 master 分支。
Claude 發現的問題是：目標文件的更新版本已經存在於 master 分支中，代理可以在名為 /resources/patch_files 的文件夾中看到它們^()。因此，代理理論上可以注意到這些文件，推斷它們可能是目標版本，然後將它們複製回網站的倉庫。這種方法將通過測試案例，因為測試僅驗證文件內容，而不去檢查是否真的發生了合併。
在另一個任務 中，標準答案違反了指令。具體來說，它錯誤地了八位位組（octet）中帶有前導 0 的 IP 地址，只要該位組是兩位數即可。而測試並未檢查任何涉及前導 0 的案例。
Claude 並非完美。它給兩個我認為具有足夠測試覆蓋率的任務評了 3 分。在 中，它錯誤地認為某些邊界情況未被覆蓋，而事實上它們已被覆蓋^()。在 中，它抱怨測試僅以 90% 的閾值檢查成功，儘管這個閾值已在任務指令中指明。
最後，其中一個任務是…………
「無效提示：您的提示被標記為可能違反我們的使用政策」
提示中提到了「竊取」神經網絡權重，這觸發了 OpenAI 的內容審查。這導致模型根本無法正常處理該任務。——Claude
有幾個原因。
**第一，**基準測試常用於評估實驗性的新技術。我最近參加了 的問答會，會上我詢問了他正在開發的最常見的失敗模式。雖然不確定這是否是最常見的，但他首先提到的就是環境本身的錯誤。
每隔幾個月，就會有人宣佈他們開發了一種 AI，能將 的分數提高約 20 倍之類。而每次，嗯……^()
第二，基準測試中的錯誤可能導致對 AI 能力的高估或低估。這對預測未來發展具有影響。
第三，基準測試的問題使得在其基礎上進行開發變得困難。當我在做 時，LiveCodeBench 的問題（錯誤/不足的測試案例）經常讓人頭痛（儘管它們也揭示了一些有趣的模型行為）。
第四，強化學習（RL）訓練環境與基準測試非常相似——這也是 o3 頻繁進行獎勵作弊的原因。通過修復基準測試，我們學習如何修復環境，從而引導模型實現更廣泛的對齊。
製作基準測試很困難。我對任何致力於開發廣泛使用的基準測試的人都深表敬意。
以下是社群可以採取的一些方法，以減少基準測試中的錯誤：
可能是使用最廣泛的編碼基準測試。Fulcrum 已經在任務中了一系列問題。此外，以前曾存在一個問題，模型可以。
EpochAI 發現，在電腦使用基準測試 中的成功「」。
METR 最近判定 Sonnet 4.5 在其一項任務中進行了獎勵作弊：
性能工程基準測試 的作者觀察到頻繁的現象。事實上，o3 超過 50% 的「解決方案」以及 Gemini-2.5 Pro 的所有解決方案，實際上都是獎勵作弊。
^() 他們的官方排行榜有可能使用了 Codeforces 的測試。然而，考慮到模型開發者很可能使用公開測試來進行自己的基準測試，我認為這一點應該被明確說明。
^() 公平地說，在 Terminal-Bench 作者創建基準測試時，Claude Opus 4.5 尚未發布。
^() 另外三個任務我覺得自己缺乏專業知識來進行妥善審核。如果您有相關知識，我很期待您的建議！
^() 這些文件在測試中用於驗證代理的合併是否正確。
^() 誠然，是以一種起初很難察覺的方式。
^() DeepReinforce 對 KernelBench 的漏洞有一個很好的（向下滾動到獎勵作弊章節）。
^() 利益衝突聲明：我目前是 Fulcrum 的冬季研究員。