H
Howardism
Plate IIEvals & Benchmarks機器翻譯 · machine-translated過時翻譯 · stale translationENHOWARDISM

超越準確率飽和的測量

PublishedJuly 16, 2026FiledConceptDomainEvals & BenchmarksTagsLLM ArchitectureCapability EvaluationBenchmarksEvaluation MethodologyConstruct ValidityHuman AI CollaborationReading17 minSourceAI-synthesised

Nadgir、Kapoor、… Narayanan(由 Princeton 主導、14 位作者、arXiv 2606.26158):當基準測試的準確率飽和(頂尖代理在統計上無法區分)時,領域的直覺反應是以更困難的後繼者替換舊基準——但這偏重準確率,也丟棄了另外六個可測量軸。以 CORE-Bench Hard(科學程式碼的計算可重現性)為案例,他們*將準確率飽和與基準測試飽和解耦*:(1)飽和本身會揭露較弱代理看不見的構念效度威脅——Docent 的日誌分析發現 15 個任務層級錯誤與 20 個可利用的捷徑,產出修正後的 CORE-Bench v1.1(39 個任務)與 OOD 套件 CORE-Bench OOD(19 個任務、新領域),但準確率仍然飽和(頂尖代理 100%,接下來四個並列約 97.4%);(2)在統計上無法區分的代理,在可靠性上仍有顯著差異(較準確的代理更一致;所有代理都極度缺乏信心,約 93% 通過但自述信心僅 32.1%,而且沒有任何代理能在辨別自己正確與錯誤的執行結果上勝過隨機),效率上也不同(GPT-5.3-Codex 比準確率相同的同儕便宜約 60%;token 成本與美元成本呈現不同故事),模型與 scaffold 的貢獻也不同(同一模型上的 scaffold 可讓準確率擺動約 44 個百分點;同一模型上的兩個 scaffold 在 31% 的任務上意見不一致,但 oracle router 可達 100%;直接修復以 95%/68% 勝過重寫);(3)一項小型隨機化人類研究發現,代理協作使重現時間減少超過一半(2.11 倍,p≈0.002,而且可能低估,因為 25 次手動執行中有 5 次碰到 3 小時上限,而協作執行沒有)。論點:不要淘汰已飽和的基準測試——重新為它加裝測量儀器

「超越準確率飽和的測量」插圖

資料來源#

摘要#

當基準測試的標題準確率飽和——頂尖代理在接近上限的位置達到統計上無法區分的分數——領域的預設反應是淘汰並替換:建立更困難的後繼者(ARC-AGI 1 → 2 → 3、MMLU → MMLU-Pro、HumanEval → HumanEval+、SWE-bench → SWE-bench Pro)。Nadgir、Kapoor、… Narayanan("Life After Benchmark Saturation",由 Princeton 主導、14 位作者、arXiv 2606.26158、empirical)認為,對除了優化相對準確率的模型開發者以外的所有人而言,這種直覺反應從根本上並不充分。他們的核心論點是:準確率飽和不代表基準測試已經耗盡訊號。即使準確率再也無法區分代理,另外六個可測量維度仍然可以。處方是將準確率飽和與基準測試飽和解耦——不要淘汰已飽和的基準測試,重新為它加裝測量儀器

他們以 CORE-Bench Hard(Siegel et al.)展示這一點。這是一個測量科學程式碼計算可重現性的基準測試:只給定論文的 README、程式碼與資料,不提供 Dockerfile 或 runfile,重現已發表論文的結果。可重現性是精心挑選的案例,因為它是一項高價值的真實世界任務,具有直接的人類對應任務(能進行具體的人類提升實驗)、明確的分布外軸(替換研究領域),以及多個實際相關維度(正確性、成本、延遲、可靠性)。論文的三項貢獻對應六個軸中的三組:基準測試效度(構念效度與 OOD 穩健性)、評估完整性(效率、可靠性、模型與 scaffold 的貢獻),以及實務影響(人類與代理協作的提升)。

對淘汰並替換的批判#

「準確率飽和」採用 Akhtar et al. 的定義:頂尖代理取得統計上無法區分的準確率,導致排行榜失去區辨能力的狀態。淘汰並替換服務的是模型開發者——他們主要關心用於行銷與檢查點選擇的相對準確率——卻無法滿足研究人員與下游開發者想知道代理實際上能多好地解決真實任務的需求。更深層的重點是:以準確率為中心的評估,在基準測試的整個生命週期中都是不充分的測量工具,而不只是在飽和時才如此;飽和只是讓這種不足變得不可能忽視。過去的工作原則上主張多維度評估,但這個領域仍預設要建立更困難的準確率基準測試。這篇論文提供了具體示範,說明其他軸確實有價值。

貢獻 1——飽和揭露構念效度威脅#

高能力正是暴露效度問題的因素:較弱的代理從未進展到足以利用捷徑或撞上基準測試錯誤的程度,因此這些威脅一直隱藏到準確率飽和才浮現。效度受到兩個軸的威脅:

  • 任務層級威脅——標題指標沒有忠實測量預期能力。這是已有記錄、跨基準測試普遍存在的問題:無法解決的 SWE-bench 任務、τ-Bench Airline scaffold 錯誤、評分錯誤的 WebArena 任務。日誌分析(追蹤代理的輸入、輸出與環境)是關鍵的發現方法。
  • 基準測試特定適應——當基準測試成為開發目標時,針對固定基準測試反覆調整提示、scaffold、工具使用與逾時設定,會讓代理適應基準測試的特異性。強勁表現於是部分反映適應,而非一般能力——這是基準測試建構層級的 Goodhart's law(參見 Reward Hacking)。

他們將自動化與人工日誌分析(透過 Docent,一個由 LLM 驅動的日誌標記工具,使用程序正確性、計算正確性、既有產物污染與評分錯誤的評分規準)應用於原始 CORE-Bench Hard 的 45 個任務及 27 個新候選任務,發現15 個任務層級錯誤(錯誤的真值、格式錯誤的問題、評分錯誤、無法解決的任務),以及20 個具有可利用捷徑的任務(例如代理從靜態產物讀取預先計算的值,而不是重現該值)。結果產生兩個新套件:

  • CORE-Bench v1.1——修正錯誤與捷徑,並加入由相同管線建立的 10 個新任務,形成一個 39 個任務的套件(13 個電腦科學、10 個社會科學、16 個醫學)。它是重新利用 CORE-Bench Hard,而不是用更困難的東西替換它。
  • CORE-Bench OOD——一個 19 個任務的分布外套件,固定任務結構但改變領域(物理、工程、經濟、CS),測試飽和後的準確率在學科分布轉移下是否仍能遷移。

讓整篇論文成立的關鍵結論是:完成所有這些修正後,準確率仍然飽和。在 v1.1 上,頂尖代理達到 100%,接下來四個並列約 97.4%;在 OOD 上,12 個 Codex CLI 代理中的前五名再次在統計上無法區分。(Nicholas Carlini 提交的 Claude Code scaffold 在修正幾個評分錯誤後,在 CORE-Bench Hard 上達到接近上限的表現——這正是宣告飽和的事件。)因此,貢獻 1 不是「我們透過製作更好的基準測試修復了飽和」;而是「飽和是揭露效度威脅的透鏡,而當飽和持續存在時,威脅也持續存在」。作者將 v1.1 與 OOD 視為持續演進的基準測試,會持續更新,因為日誌分析並不 exhaustive——它需要先指定目標行為,有些威脅只會在特定執行中浮現,而基於 LLM 的分類器需要人工驗證。

貢獻 2——飽和後的多維度評估#

核心重構是:**將準確率飽和與基準測試飽和解耦。**在 20 次代理執行中(Codex CLI、Claude Code、OpenCode、CORE-Agent × GPT-5.x / Opus 4.5 / Opus 4.6),準確率在統計上無法區分的代理,在三個可測量軸上仍有顯著差異。

可靠性#

採用 Rabanser et al. 的框架,他們在五個 Codex CLI 代理上進行五次重複試驗,測量四件事:

  • 結果一致性(重複執行是否產生相同判定)與資源一致性(token 使用量的變異)都會隨準確率上升——最準確的代理也是最可重複、token 支出最穩定的代理(相關係數約為 +0.94 與 +0.95)。
  • 校準與區辨能力都嚴重失效,而且所有代理的情況完全相同。平均經驗通過率是 93%,但平均自報信心只有 32.1%——代理極度缺乏信心。更糟的是,沒有任何代理能在辨別自己正確與錯誤的執行結果上勝過隨機基準(區辨 AUROC 約為 0.51–0.64)。回報的信心會隨失敗的 bash 指令數量變化——這個訊號與任務成功無關。因此,在這裡模型信心幾乎是無用的成功預測因子;對任何會根據代理自我回報進行閘控的管線而言,這都是重要的負面結果(參見 Self-Report as a Safety Signal)。

效率#

將準確率與token 使用量及美元成本同時繪圖,可以區分單靠準確率無法區分的頂尖得分者。研究有兩項發現:

  • 有些高分者的效率高得多。GPT-5.3-Codex(medium)依兩項指標都是高準確率代理中效率最高者;在與 GPT-5.4(high)相同的 97.4% 準確率下,成本約低 60%
  • token 與美元講述的是不同故事。準確率會隨 token 使用量上升,但相對於成本大致持平至負相關——這由供應商定價與快取行為驅動(某些 Codex CLI 配對會積極快取;CORE-Agent 完全不快取)。你選擇哪一種計算單位會改變排名。這正是 Compute-Controlled Benchmarking 的計算軸觀點,在飽和基準測試內部的應用。推論擴展的良好紀錄回報(Large-Scale Test-Time Compute)讓代理能以暴力方式提高準確率——這對找出模型上限很有用,但對實務工作者而言,一個答案的成本與答案本身同樣重要。

解耦模型與 scaffold#

排行榜為每個代理回報一個準確率,將負責協調模型的模型scaffold壓縮在一起。飽和讓拆解兩者變得更加迫切:一旦數個代理在準確率上並列,排行榜就不再說明堆疊中的哪一部分帶來勝利。在四個 scaffold 中選用三個(Claude Code = 專有;CORE-Agent、OpenCode、Codex CLI = 開源),評估 Opus 4.5、Opus 4.6 與 GPT-5.4,並透過 Docent 依根本原因分類全部 56 個失敗與 390 份日誌後,得到三項發現:

  1. 相近的準確率掩蓋了不同的失敗。Opus 4.5 在 CORE-Agent 與 OpenCode 上都得到 82.1%,但兩個 scaffold 在 31% 的 capsule(39 個中的 12 個)上意見不一致。一個依每項任務選擇最佳 scaffold 的 oracle router,對 Opus 4.5 與 GPT-5.4 都達到 100%——也就是說,v1.1 的每個任務至少都能由一個 scaffold 解決。scaffold 改變的是模型能解決哪些任務,而不只是能解決多少任務。
  2. scaffold 會導致不同的解題策略。固定模型、替換 scaffold 就能看見這一點:在 Opus 4.6 上,Claude Code 從未修改程式碼的文字輸出讀取 41% 的答案,只有 3% 來自對渲染圖表的視覺讀取;相較之下,CORE-Agent 有 31% 的時間使用視覺讀取。在 Opus 4.5 上,視覺讀取率跳升至 62%(CORE-Agent,相較 Claude Code 的 3%)。在放棄原始程式碼後,作為備援使用的視覺讀取只有約 50% 的通過率;在乾淨執行後則為 93%——CORE-Agent 的準確率差距很大程度上是累積的備援失敗。
  3. 直接修復勝過重寫。能診斷根本原因並修補的 scaffold,有 95.2% 的成功率(n=269);放棄原始實作、從頭重寫的 scaffold,成功率只有 67.8%(n=59),而 scaffold 採用直接修復的傾向與整體準確率一致(Codex CLI 82%、CORE-Agent 49%)。scaffold 的貢獻很大:使用 GPT-5.4(medium)時,Codex CLI 比 CORE-Agent scaffold 高出約 44 個百分點(而 CORE-Agent + GPT-5.4 是整體執行集合中約 51% 的低位離群值)。

結論是:模型與 scaffold 的效應無法乾淨分離——scaffold 限制可用的解題路徑,模型則決定這些路徑被運用得多好。這是 Agent Harness Engineering 論點的經驗核心,並且是在已飽和基準測試上進行的測量。

貢獻 3——人類與代理協作的提升#

當代理在接近上限的準確率上收斂後,問題便從代理能否完成任務轉向代理在人類身邊是否能增加價值。高基準測試準確率不一定能轉化為提升:基準測試任務可能比真實工作更狹窄,代理失敗可能讓人類付出更高的收拾成本,而代理也可能不善於因應重新導向。因此,他們進行了一項小型隨機化研究:五位評估者(全都擁有資料科學碩士學位與可重現性經驗,也是所有共同作者)在有與沒有代理協作的情況下,重現 20 篇論文的結果(2011 年以來得獎的 ML 論文,以及 Institute for Replication 的社會科學論文),在可能的情況下採盲法,並設有3 小時上限,產生50 次重現實驗。協作條件使用 Codex CLI + GPT-5.4(extra-high thinking),以自主方式執行,但指示代理在失敗 2–3 次後向人類升級。與 CORE-Bench 不同,目標是程序層級的提升,而非答案正確性,因此論文事前未驗證為可重現。

  • 代理協作使重現時間減少超過一半。固定效應模型估計,手動工作階段的持續時間是協作工作階段的 2.11 倍(群集標準誤 0.09,雙尾 p ≈ 0.00176)。這很可能是保守估計:25 次手動執行中有 5 次碰到 3 小時上限,而 25 次協作執行中有 0 次,所以真實差距可能更大。
  • 大多數協作執行只需要很少或不需要人類協助。代理完整自主完成 25 次中的 19 次(除了分派給人類的兩個設定步驟)。代理被認為最有價值的部分是環境設定(25/25)、執行程式碼(23 次)、辨識主要腳本(20 次)與 README 導覽(19 次)。
  • **代理記錄更多阻礙,但恢復得更可靠。**代理遇到的 114 個阻礙中,除了 2 個以外,全部都完整或部分解決;人類則有 60 個阻礙中的 11 個未解決。在四篇論文中,代理修復了人類無法修復的遺失或損壞儲存庫產物。

作者指出的限制包括:樣本極小(20 篇論文、5 位參與者);重現者是共同作者(可能有需求效應);沒有真值(測量程序提升,而非結果正確性);選擇範圍狹窄(僅 Python/R、計算時間 <45 分鐘、具有明確目標的結果);得獎 ML 論文偏向具有較佳文件。提升結果是方向性證據,而非已確立的效應量。

為何重要#

這篇論文具體反駁了 Task Time-Horizon Scaling 所指出、仍待解決的淘汰並替換直覺(「任務集合飽和了——什麼可以取代它們?」)。它的答案是:通常不需要替換任何東西。重新加裝測量儀器的飽和基準測試,仍能告訴你哪些代理有效率、哪些可靠、勝利來自模型還是 scaffold,以及代理是否真的能幫助人類——這些全都不是標題準確率數字能告訴你的。這是 wiki 收錄的「飽和之後的生活」兩個 2026 年答案之一:這篇從一個飽和基準測試中提取更多訊號BenchPress 則透過預測分數,停止執行冗餘基準測試。它們在實務操作上指向相反方向(保留並重新測量 vs 跳過並預測),但共享同一個前提:單一準確率數字是對基準測試所知資訊的有損壓縮。

相關連結#

  • Benchmark Score Redundancy — 同一飽和事實的互補視角。飽和 = 代理之間幾乎沒有分數差距;BenchPress 正是利用這一點來壓縮基準測試版圖(低分散基準測試可以由其他基準測試輕易預測,因此可能不需要執行),而這篇論文則從你保留的單一飽和基準測試中提取六個非準確率訊號。「跳過並預測」對上「保留並重新加裝測量儀器」——動作相反,但共享同一前提:標題準確率沒有充分利用基準測試
  • Benchmark Contamination and Decontamination — 將「彙總準確率是有損摘要」的論點應用於污染而非飽和。Sun et al. 加入逐樣本分布距離,而這篇論文加入六個非準確率軸,並得到相同的失敗形狀:資料集層級的改善(殘餘污染 ↓)沒有讓逐樣本行為朝向乾淨參考值移動(D_KL ↑)。兩者都拒絕接受單一準確率差異足以證明基準測試的訊號已被恢復
  • Task Time-Horizon Scaling — 本頁的開放問題(「時間範圍任務集合飽和了;什麼可以取代它們?」)在此得到答案:不要替換,重新加裝測量儀器。這篇論文採用該頁指出在 15 個月內飽和的 CORE-Bench,並展示準確率飽和後,它仍能沿六個軸區分代理
  • Compute-Controlled Benchmarking — 此處的效率軸(準確率 vs token vs 美元成本;GPT-5.3-Codex 在準確率相同時便宜約 60%)是 Brown 的「將計算量放在 x 軸上」在飽和基準測試內的應用;兩者都拒絕在不報告達到該準確率所需成本的情況下,只回報一個準確率數字
  • Agent Harness Engineering — 模型與 scaffold 的解耦,是 harness 貢獻的經驗測量:scaffold 讓準確率擺動約 44 個百分點,同一模型上的兩個 scaffold 在 31% 的任務上意見不一致(oracle router → 100%),而直接修復對上重寫(95% 對 68%)是 scaffold 策略效應,確認 scaffold 與模型無法乾淨分離
  • Production-Sourced Evaluation — 對「基準測試飽和時該怎麼做」的姊妹答案:該頁從即時 production 使用情況刷新任務集合;本頁則沿非準確率軸重新測量既有(已飽和)任務集合。兩者都拒絕淘汰並替換,只是從相反兩端出發(新任務 vs 新指標)
  • Reward Hacking — 「可利用的捷徑」(讀取預先計算的值,而不是重現它)與「基準測試特定適應」(讓代理調整至固定基準測試的特異性)都是基準測試建構/開發目標層級的 Goodhart 現象;飽和後的日誌分析正是它們浮現的方式
  • Configurable Human Participation — 人類提升研究是 HAS-Bench 受控人類與代理測量的實地對應:HAS-Bench 在 397 個任務上改變由 LLM 模擬的人類參與程度;這項研究在 20 個重現任務上進行真正的隨機化研究,發現協作使時間減少超過一半。兩者都將人類與代理協作視為一個一等的測量軸,而非事後補充
  • Large-Scale Test-Time Compute — 本頁效率軸所衡量的推論擴展回報:代理可以用更多計算量暴力提高準確率,因此每個答案的成本是飽和準確率數字的實務互補指標
  • Self-Report as a Safety Signal — 可靠性發現從能力軸面進一步強化該論點:前沿編碼代理極度缺乏信心(93% 通過,相較自述信心 32.1%),也無法在辨別自己正確與錯誤的執行結果上勝過隨機,因此代理自評信心是進行閘控的薄弱依據
  • How Much Signal Do Public Benchmarks Still Carry — and What Replaces Them? — 集群綜合:重新加裝測量儀器是共同回答「公開基準測試仍攜帶多少訊號,以及什麼能取代它們?」的五種組合行動之一

開放問題#

  • **重新加裝測量儀器能否推廣到可重現性以外?**CORE-Bench Hard 的選擇,正是因為它有直接的人類對應任務、乾淨的 OOD 軸,以及多個實務維度。對於不具備這些特性的基準測試(例如沒有類似人類工作流程的封閉形式推理基準測試),六軸處理是否能產生相當的訊號,尚未經過測試。
  • **人類提升結果是真實效果,還是需求效應?**重現者是論文自己的共同作者,沒有地面真值,且樣本是 20 篇論文/5 位參與者。2.11 倍加速在統計上顯著,但作者自己也無法排除參與者偏差——缺少的是獨立、盲化的重現研究。
  • **哪一個非準確率軸真正能預測部署價值?**論文測量六個軸,但沒有依下游部署者的決策相關性對它們排序。如果除了準確率之外只能測量一項,應該是可靠性、效率,還是 scaffold 貢獻?答案是否取決於使用情境?
  • **模型與 scaffold 的解耦能否成為例行流程?**oracle-router 的結果(每個任務都能由某個 scaffold 解決 → 100%)暗示 scaffold 路由具有很大的提升空間,但需要逐任務的 oracle 知識。實務 router 能否在沒有這些知識的情況下接近 oracle,仍是開放問題;若能做到,就會把測量轉化為能力。
  • **「持續演進的基準測試」會不會跑得比自身維護更快?**v1.1 與 OOD 會隨日誌分析浮現新的效度威脅而更新,而作者指出日誌分析並不 exhaustive。持續由日誌分析驅動的維護是否可持續——或者一旦開發者知道評分規準,它本身也會成為 Goodhart 目標——尚未研究。

資料來源#

  • Life After Benchmark Saturation: A Case Study of CORE-Bench — Nitya Nadgir、Sayash Kapoor、Kangheng Liu、Peter Kirgis、… Arvind Narayanan(14 位作者;Independent / Princeton / UC Berkeley / MIT;arXiv 2606.26158、2026-06-23、empirical)。§1 淘汰並替換的批判與核心論點;§2 透過 Docent 日誌分析發現構念效度威脅(15 個任務層級錯誤+20 個捷徑)、CORE-Bench v1.1(39 個任務)與 CORE-Bench OOD(19 個任務)、飽和持續存在(頂尖 100%、接下來四個約 97.4%);§3 多維度評估——可靠性(Rabanser et al. 框架;一致性 ↑ 隨準確率上升,r≈0.94/0.95;93% 通過相較 32.1% 信心;區辨 AUROC 0.51–0.64)、效率(GPT-5.3-Codex 在準確率相同時便宜約 60%;token 與美元成本分歧)、模型與 scaffold(31% capsule 意見不一致、oracle router 100%、直接修復 95.2% 對重寫 67.8%、約 44 個百分點的 scaffold 差距);§4 隨機化人類提升研究(20 篇論文、50 次實驗、2.11 倍時間、p≈0.00176、25 次手動執行中有 5 次碰到 3 小時上限)。已查看圖 1(可靠性)、圖 2(效率)與圖 3(工作階段持續時間直方圖)。注意:原始解析中的表 2 與表 4 含有扁平化的多值儲存格——本文引用的各模型準確率僅限於論文正文與圖表所佐證者
§ end
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

Cited by 24
Related articles
  • Open Questions Backlog

    _456 actionable open questions across 205 pages · 107 predictions · 9 notes · 147 in progress · 69 watching (entities),…

  • Compute-Controlled Benchmarking

    Noam Brown's critique: the single-number benchmark grid is broken because it ignores test-time compute — plot performan…

  • Agent-Authored Harness Optimization

    An agent runs the whole eval-fix loop on its own harness — read traces, hypothesize, patch, re-run. Three instances dis…

  • Context Lifecycle Management

    Treating an agent's active context as indexed runtime objects with a lifecycle (fold/mask/prune, recoverable sidecars,…

  • Failures That Look Like Success

    The quiet agent-failure class where everything reads fine — confident answer, plausible plan, even correct internal sta…