重點
- Google Cloud AI Research 與劍橋大學在 10 月 1 日上傳 VeriHarness。生成和驗證用同一個模型，驗證時看不到標準答案與評分量表，要從同一題的 10 次 rollout 裡選出或修訂最終產出。
- 動機來自一組統計：APEX-Agents 上，Claude Opus 4.8 十次執行都同意的值有 34% 是錯的；有分歧的說法裡 74% 至少有一個候選是對的，但出現最多次的值只有 47% 正確。
- 只做挑選時，比單次 rollout 平均高 4.4 分（Gemini 3.5 Flash）與 4.1 分（Claude Opus 4.8）；再依證據修訂，增益變成 6.2 與 6.4 分。
- 給同樣工作區與工具、但沒有協定和技能的 agentic verifier，只拿到大約一半的挑選增益。
- 論文公開約 2.6 萬筆 rollout，產生成本超過 10 萬美元。
要解決的問題
長任務 agent 交出的常是報告、試算表、程式修補這類產出。程式和數學有單元測試或證明檢查器可以直接判對錯，一份財報分析就沒有。要核對它，得把數字追回來源、重算、對照多份檔案裡的要求。
論文設定的條件很嚴：驗證者和生成者是同一個模型、同一組工具，沒有更強的評審，也看不到基準的評分器。作者的理由是，前沿模型已經是能拿到的最強模型，現實裡沒有更強的模型來監督它。固定模型也確保增益只能來自 rollout 本身與任務環境。
既有的測試時方法多半只讀 rollout。多數決與 self-consistency 把最常見的答案當成對的；LLM-as-a-judge 讀完各個 rollout 再打分。這兩類都只用到模型已經相信的內容，沒有回到環境裡找證據。
共識會藏錯，分歧會留下對的答案
作者把產出拆成一條條說法（claim），例如「FY2025 營收是 1.2 億歐元」。同一個問題在 N 次 rollout 裡的答案分布，用熵來分類：熵為 0 叫共識，大於 0 叫分歧。缺漏也算一種值。
統計用的是 Claude Opus 4.8 在 APEX-Agents 上的 10 次 rollout，涵蓋 434 題、1,692 條說法，其中 917 條共識、775 條分歧。對錯用基準自己的評分項目判定，驗證者看不到這些評分。
| 統計 | 比例 |
|---|---|
| 共識值被判錯 | 34% |
| 分歧說法裡至少一個候選正確 | 74% |
| 分歧說法裡出現最多次的值正確 | 47% |
這三個數字決定了設計。共識錯誤靠投票或挑選改不掉，因為每個候選都一樣錯。分歧裡常有正確答案，多數決卻會把它丟掉。
架構
VeriHarness 把驗證者寫成「模型加上一個 harness」：工作區、取證工具、驗證協定、技能庫。每次 rollout 的產出、最終工作區狀態與動作軌跡，都以檔案形式放進唯讀沙盒，沙盒沒有網路，只有輸出目錄可寫。驗證者能讀檔、搜尋、跑 shell 指令重算數字。
協定把工作分給三個彼此獨立的 context：
- 分歧裁決者：找出各 rollout 說法不同的地方，把候選值追回來源與計算，選最能區分候選的檢查去跑，排除與證據矛盾的候選。所有候選都被推翻時，只有證據能確立新值才記錄，否則標為未解決。
- 共識挑戰者：針對大家都同意的值，先想它可能怎麼錯，再到環境裡測。它檢查三類：共識數值（重算、比對單位與幣別）、共識解讀（期間、檔案版本、定義）、共識遺漏（每個 rollout 都漏掉的要求）。
- 裁定：開一個新的 context，讀前兩者的證據紀錄，選出缺陷最少的 rollout 當底稿，列出有證據支持的修訂計畫與仍未解決的說法，最後依計畫修改底稿。
論文的例子：三次 rollout 裡兩次引用草稿報 1 億、一次引用定稿報 1.2 億，三次都寫美元。裁決者查版本紀錄，確認定稿取代草稿，支持 1.2 億；挑戰者查來源中繼資料，發現大家共用的幣別應該是歐元。
技能是短文字檔，可附腳本，告訴驗證者「該檢查什麼」。人工撰寫的技能庫有 18 個，分四類：6 個取證技能（讀 xlsx、PDF、docx、pptx、檔案包、程式修補）、4 個裁決技能、3 個挑戰技能、5 個修訂技能。技能裡不放特定題目的答案。
結果
測試涵蓋五個工作區基準：APEX-Agents（480 題，銀行、法律、顧問）、Workspace-Bench Lite（100 題）、WorkBuddy Bench（200 題，程式、辦公、網頁）、SpreadsheetBench 2（321 題）、JobBench（65 題）。每題每個模型先凍結 10 次 rollout，所有方法拿同一批候選。Gemini 3.5 Flash 與 Claude Opus 4.8 各自同時當生成者與驗證者，思考等級設為 high，報告三次驗證執行的平均。
下表是五個基準的未加權平均。
| 方法 | Gemini 3.5 Flash | Claude Opus 4.8 |
|---|---|---|
| 單次 rollout（池平均） | 47.2 | 49.6 |
| 多數決 | 47.5 | 50.4 |
| Best-of-N 評審 | 47.3 | 50.6 |
| 兩兩淘汰賽 | 49.1 | 51.3 |
| LLM-as-a-Verifier | 49.5 | 51.2 |
| Agentic verifier（有環境存取） | 49.4 | 51.6 |
| VeriHarness（只挑選） | 51.6 | 53.7 |
| 挑選上限（依評分器選最好的 rollout） | 62.7 | 63.1 |
| 彙整整池重寫 | 49.9 | 52.3 |
| Agentic verifier + 修訂 | 50.7 | 53.1 |
| VeriHarness（挑選 + 修訂） | 53.4 | 56.1 |
在 10 個「模型 × 基準」組合裡，VeriHarness 的挑選分數都是基準線方法中最高，增益也都大於跨次執行的標準差。加上修訂後，十個組合全部再提升。單一基準最大的增益是 Opus 在 APEX-Agents 上 +11.7（35.8 → 47.5），以及 Flash 在 Workspace-Bench Lite 上 +8.9。
兩個對照組特別說明增益的來源：
- Agentic verifier 和 VeriHarness 有相同的沙盒與工具，只缺協定與技能。它的挑選增益是 2.2 分（Flash）與 2.0 分（Opus），約為 VeriHarness 的一半。
- 「彙整整池重寫」讓模型不碰環境、直接把 10 份產出合成一份新的，在每個基準上都低於 VeriHarness。作者據此認為修訂的增益來自證據紀錄。
把同一份協定與技能放進 Gemini CLI、Claude Code、Codex 執行，Flash 在每個基準上都和自家實作相差 2 分以內。Opus 在 JobBench 上掉回單次 rollout 的水準，Claude Code 在 SpreadsheetBench 2 上也是。
增益從哪裡來
兩個角色各補不同的錯。 Opus 的五基準平均，只開裁決者是 54.3，只開挑戰者是 52.6，兩者都開是 56.1。拿掉技能庫是 53.8。把兩項調查放進同一個 context 是 55.3，少 0.8 分。Flash 的順序相同。
挑選增益集中在有分歧的題目。 Opus 在 APEX-Agents 的 154 個共識池（10 次答案都一樣）上，挑選結果只比池平均高 0.6 分；262 個分歧池則高 6.1 分。分歧池裡，低熵池高 4.5 分，中熵池高 7.7 分。
共識錯誤為什麼留下來。 作者把挑戰者維持原判、但其實 10 次都錯的共識說法分類：
| 挑戰者測的說法與被評分項目的關係 | 比例 |
|---|---|
| 測的是上游輸入或中間量，錯誤在更下游 | 70% |
| 同一個量，但定義、期間或來源版本不同 | 14% |
| 直接確認了錯誤的值 | 12% |
| 遺漏或對應雜訊 | 4% |
挑戰者從沒推翻過一個 10 次都對的說法。它的盲點在於停在 rollout 停下的地方：驗算的中間結果正確，錯誤出在後面一步。
技能能從失敗裡長出來
自我演化實驗只用 Claude Opus 4.8，在 APEX-Agents 與 SpreadsheetBench 2 上做。題目約以 3
切成開發集與保留集，共用來源檔案的題目歸在同一邊。每一輪，模型讀開發集的失敗案例與評分器逐項回饋，提出 3 到 5 個候選技能庫，開發分數不低於現行庫才替換。保留集分數每輪記錄，但不參與任何選擇。四個條件：A 空庫、B 人工庫、C 從 A 演化、D 從 B 演化。
- C 比 A 在保留集上高 11.0 分（APEX-Agents）與 5.7 分（SpreadsheetBench 2），而且兩個基準都超過 B。
- D 在兩個基準都是最高，比 B 多 6.8 與 3.7 分。
作者人工比對四個演化庫裡的 95 條檢查：5 條重述人工庫、48 條把人工檢查具體化（加腳本、常數或文件類型）、42 條是新的。APEX-Agents 與 SpreadsheetBench 2 的兩次獨立演化，都長出同一條規則：重算結果和池裡的值一致，不能當作確認。
成本
依牌價計算，快取輸入按快取價計。只挑選時，Flash 每題 1.44 美元，Opus 每題 3.92 美元。加上修訂的成本約為只挑選的三倍。作者說 86% 到 91% 的輸入 token 命中快取；若快取也按全價計，挑選成本變成 Flash 5.40 美元、Opus 13.06 美元。多數決、Best-of-N 與 CLI 的成本是用呼叫次數和 context 大小估的，彙整基準線沒有計量。
這些數字只算驗證。每題先跑 10 次 rollout 的生成成本另計，所有方法用的是同一批 rollout。
跟 ThinkingBox 差在哪
昨天介紹的 ThinkingBox 也讓同一題跑很多次，但兩者處理的是不同問題。
| ThinkingBox | VeriHarness | |
|---|---|---|
| 性質 | 評測基準 | 測試時的驗證方法 |
| 重複執行的用途 | 量 agent 每次都做對的機率 | 當作驗證者的素材，從中找分歧與共識 |
| 判對錯的依據 | 隱藏的可執行檢查，比對資料庫終端狀態 | 驗證者看不到評分器，只能到工作區找證據 |
| 輸出 | 每個模型的 pass@1、20 次全過等分數 | 一份挑選或修訂後的產出，加上逐條證據紀錄 |
| 適用任務 | 有乾淨終端狀態可比的業務流程 | 報告、試算表等沒有可執行測試的產出 |
ThinkingBox 問的是「這個模型可不可靠」。VeriHarness 承認單次 rollout 不可靠，然後利用多次 rollout 之間的差異，把最後交出去的那一份做得更好。
限制
- 每題要 10 次 rollout。 作者說這是測試時擴展的標準預算，比較時所有方法生成成本相同。實際部署仍要先付這筆生成成本。
- 不給單一 rollout 分數。 輸出是產出與證據紀錄，沒有可校準的 rollout 層級分數，暫時不能直接當獎勵訊號。
- 只研究同模型驗證。 換成更強的驗證者可能分數更高，但那會混進模型能力差距，論文沒有處理。
- 延遲。 驗證是多輪調查，會拉長完成時間，作者把目標鎖定在品質比反應速度重要的產出。
- 評分器本身也是模型。 APEX-Agents 與 JobBench 用 Gemini 3 Flash 逐項評分；Workspace-Bench Lite 用以 Claude Opus 4.8 驅動的 Claude Code 當評審，和 Opus 設定下的驗證者是同一個模型。
- 挑選離上限還遠。 只挑選時的平均是 51.6 與 53.7，「依評分器挑最好 rollout」的上限是 62.7 與 63.1，還差約 9 到 11 分。
- 自我演化的證據較窄。 只有一個模型、兩個基準，保留集分數是點估計，作者寫明沒有建立統計顯著性。
- 測試範圍。 WorkBuddy Bench 的資安領域常觸發模型 API 的安全警示，沒有納入。