來自正式環境的評估

資料來源#

• DRACO: a Cross-Domain Benchmark for Deep Research Accuracy, Completeness, and Objectivity
• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog
• GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes
• Introducing System One Models & Jev
• Measuring coding agent misalignment in the wild
• OmniVChat: Synthesizing, Benchmarking, and Training for Native Audio-Visual Dialogue
• Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias
• Sidekick's continual learning loop
• SWE-Bench Pro Verified: A Reliable Benchmark for Software Engineering Agents
• The price is wrong: AI cost calculation has to consider task completion rates, not just token costs

摘要#

來自正式環境的評估是以已部署系統的真實、去識別化使用資料建立基準測試，而不是透過合成生成或人工撰寫提示。其論點是：基準測試的全部價值在於預測真實世界的表現，而最具代表性的任務就是使用者實際提出的任務。DRACO（Perplexity，2026）是具體案例——它的 100 個深度研究任務，取材自數千萬筆真實的 Perplexity Deep Research 查詢；而這套方法才是論文的核心貢獻，與評分規準設計或評分流程不同。

方法（DRACO）#

1. 以難度代理訊號抽樣。 從正式環境流量著手，偏重困難案例：DRACO 抽樣了 1,000 筆後續收到負面反應或明確倒讚的查詢，也就是部署系統處理得最差的查詢。這種做法挖掘系統已經表現出的失敗，合成生成無法如此針對性地鎖定這些失敗。
2. 保護隱私的改寫。 自動化 LLM 流程會剝除 PII 並降低歧義。關鍵在於，任何人工分析者都不會接觸原始使用者查詢——匿名化是先決條件，由架構強制落實，而非事後清理步驟。
3. 朝難度與明確規格擴增。 真實查詢往往規格不足；擴增會加入脈絡（角色設定、輸出格式、來源），並拓展範圍（時間、比較、地理），讓任務定義明確且具挑戰性，同時仍反映使用者的隱含意圖。
4. 篩選出客觀、可處理且困難的任務。 只保留專家成功標準一致、範圍受限且確實有難度的任務。
5. 人工把關。 最後由內部專家審查安全性與品質。整個流程可以端到端自動化，但刻意保留人工擔任最後一道安全與品質關卡。

DRACO 宣稱的成果是：基準測試具備代表性（反映真實領域組成與真實失敗模式），也能持續更新（研究需求與使用情況都會演變，因此流程可以重新生成新任務，而非逐漸僵化）。

核心取捨：代表性與過度規格化#

從正式環境取材能帶來代表性，但讓原始查詢變得可評估的擴增步驟，也可能損害代表性。論文坦言，系統性擴增「降低歧義並改善可重現性，但也有過度規格化任務、降低使用者查詢自然變異的風險。」去識別化加上擴增流程，會把混亂、個人化且含糊的查詢，轉成乾淨、範圍明確、可比較的任務——然而被剝除的某些特徵（歧義、個人脈絡、實際措辭），也正是真實使用之所以真實的一部分。來自正式環境的資料比合成資料更具代表性，但它並非原始正式環境資料。

而任務的代表性，與評分的有效性彼此正交：基準測試可以精準挖掘出適當的正式環境查詢，但若負責評分的評審尚未經過驗證，仍可能給出不可信的結論。Norman et al. (2026)補上另一半——對評分者進行機會校正、位置互換與一致性—偏差稽核——因此，要讓來自正式環境的評估真正可信，既需要具代表性的任務分布，也需要經過驗證的評審。

為何正式環境流量是護城河級的評估資產#

這種方法只有在你擁有能大規模產生流量的已部署系統時才行得通——這正是複利型資料護城河所描述的專有資料優勢。大規模真實使用「受時間限制、依脈絡而定，競爭者不可能重現」；在此，這項資產也能成為評估基礎。擁有正式環境流量的供應商，可以建立具代表性、鎖定難題且持續更新的基準測試；沒有部署系統的競爭者則無法做到——而且可以挑選自家產品目前會失敗的任務（例如倒讚抽樣）。這是指向測量的資料飛輪：使用 → 失敗訊號 → 基準測試 → 產品改進。

反面則是可信度問題（見 DRACO Benchmark）：若基準測試取自某供應商的流量，而且該供應商的產品在其中勝出，就顯然存在利益誘因——人工把關與專家評分規準，部分就是用來回應這項疑慮。

產品迴圈形式：Google 的飛輪#

Google 的代理品質飛輪把相同原則落實為持續性的產品迴圈，而非基準測試。代理會輸出 OTel 追蹤資料；每次正式環境工作階段「都是真實請求……每次失敗都是下一輪現成的測試案例。」完整追蹤資料可以略過推論，直接就地評分；線上監測器持續為即時流量評分，分數漂移時，失敗追蹤資料便交給評估修正迴圈。Google 明確說明順序：合成情境（其使用者模擬器）是冷啟動引導——「合成情境讓你動起來；正式環境資料才讓迴圈變得精準。」因此，正式環境作為評估基礎有三個彼此獨立的應用：DRACO（能力基準測試）、部署模擬（安全預測），以及飛輪（持續品質監測）——這套方法從基準測試建構延伸到日常產品工具。

買方端案例：Databricks 自行建立（2026）#

這種方法從第四個方向出現——不是基準測試供應商，不是產品迴圈，而是客戶為了決定買什麼而自行建立評估。根據 The Register（2026-07-13，case-study，二手報導），Databricks 表示，內部的程式碼基準測試取材自員工針對自家數百萬行程式碼庫實際執行的工程任務。其明確動機是避免基準最佳化造成的污染，而非追求代表性：CTO Matei Zaharia 表示，公司執行這項評估，是因為模型都針對 SWE-Bench 等既有基準調校，而報導指出 OpenAI 曾稱它「已經失效」。評估結果用於採購決策——依模型及 harness 比較每項任務的成本與成功率（每項任務成本高於每個 Token 成本、編排決定 Token 經濟效益）——這正是前述供應商建議賦予評估的決勝用途。

有兩點使它與 DRACO 的流程不同。它取材自正式環境的任務，而非正式環境流量：資料來自員工工程工作，而非去識別化使用者查詢，因此不需要隱私流程，也沒有倒讚這類難度代理訊號。其次，它所主張的代表性以公司為範圍，而非以領域為範圍——Zaharia 承認結果反映 Databricks 自身的程式碼庫，同時指出其他公司也能用自己的程式碼庫執行相同評估。這是本文護城河論點最坦誠的表述：資產無法移轉，但方法可以；擁有大型程式碼庫的買方，已經具備所需的基礎資料。

再往前一步：把正式環境失敗當作訓練訊號（Shopify，2026 年 8 月）#

以上每個案例都是從正式環境取得測試資料。Shopify 對 Sidekick 的說明（McNamara 與 Mazza-Anthony，Shopify Engineering，2026-08-05，case-study——第一方、未複現、自行回報）則把同一條管線用在訓練集：每天從匿名化正式環境流量挖掘困難負例，由前沿模型評審小組提出修正，把修正注入後重新播放對話；若評審重新評分後判定通過，這段重播就會成為強化學習軌跡，評審分數則作為獎勵。評審無法修正的失敗，會升級交由人工標註者依相同評分規準評分。該說明對此做法的理由是：*「在傳統工作流程中，每次失敗都會變成錯誤回報或 Slack 討論串。在飛輪中，這些失敗會自動進入自我修復管線。」*完整機制見代理品質飛輪。

難度代理訊號的差異很有意思，而且方向正好相反。 DRACO 的代理訊號是與受改進系統無關的人類訊號——後續負面反應或明確倒讚。Shopify 使用的則是評審自己的低分：*「評審正確評為低分，且揭露模型弱點的對話。」*這樣做便宜得多，也密集得多（適用於所有流量，而非只適用於引發抱怨的一小部分），但它並不獨立於最佳化對象——同一個評估工具負責選出訓練資料、把關修正、提供 RL 獎勵，並評分結果。因此，評審的盲點在迴圈兩端都看不見：評審錯誤判為高分的案例永遠不會進入語料，而它回報的改進也以自身的尺度衡量。

這個案例呈現了本文提出的開放問題，卻沒有回答它。 下方的倒讚項目提出疑問：依目前失敗情形衡量難度，是否會「讓基準測試成為移動目標，進而偏袒下一個以這些失敗訓練的模型」。Shopify 是這份語料中第一個實際以抽樣失敗訓練的案例，採每日節奏，且說明中沒有留出組，也沒有任何乾淨的資料切分——來自正式環境的訓練與評估資料共用一條管線，並由同一評估工具評分。沒有測量，就沒有定論；改變的是，這項風險如今已在部署環境中出現，而不只是個假說。可移用的原則是：一旦正式環境失敗同時餵入模型權重與評估，難度代理訊號就必須來自模型自身評分者以外的來源，否則就沒有能偵測代理訊號過度擬合的資料切分。

使用者觸發形式：Bridgewater 的 Teach 按鈕（2026）#

以上每個案例都由團隊挖掘正式環境流量。Bridgewater 的 PAT（Bridgewater Associates）則新增一種形式：由專家使用者決定什麼算是失敗，而迴圈如何運用這項判斷才是重點。

兩條路徑平行運作。自主路徑與 Google 的飛輪相似：背景代理持續掃描已完成的投資者對話，「找出 PAT 哪裡出錯」，產生經人工稽核的基準測試，再用來更新脈絡儲存庫與 harness。明確觸發的路徑則是介面中的 Teach 按鈕；它的觸發條件是值得注意的設計選擇——Michael Ran 示範的互動其實沒有任何錯誤：使用者只是要求另一組視覺化圖表，並認為 PAT 本應主動提出這個觀點。捕捉到的訊號是產品未能預先察覺的偏好，而非產品犯下的錯誤——這類失敗無法由自動評分者定義，也無法透過檢視追蹤資料發現，因為每個步驟都成功了。

按下按鈕後，系統會啟動一個代理，從對話中讀取三個指定類別：行為上的錯誤、脈絡缺口，以及可以預先因應的使用者引導。使用者可編輯或接受代理的解讀；送出後，後端依序執行以下流程：

1. 撰寫一個預期會失敗的基準測試——先重現不良行為，讓修正有可驗證的依據。
2. 持續修改脈絡儲存庫或 harness 本身，直到基準測試通過。
3. 重新執行其餘測試套件，確認修正沒有造成回歸。
4. 發送一則 Slack 訊息，附上包含 PAT 擬議修改的拉取請求。

第 1 步是它與本文其他案例的區別：修正前先有一個失敗測試，便能把「代理學到了一些東西」從一句宣稱變成可重現的產物，也讓第 3 步具有意義。第 2 至第 4 步屬於Agent-Authored Harness Optimization——代理編輯自己的 harness——而人工把關點移到PR 審查，不再由基準測試撰寫者把關。所宣稱的效益適用整個代理群：「下次有人帶著類似問題來找 PAT 時，我們預期他們一開始就能用上更好的 PAT 版本」；一位投資者的修正，會為所有人持續累積效益。

目前缺少的是任何對此迴圈的測量。沒有產生的 PR 採納率、測試套件大小或成長速度、Teach 按鈕觸發中有多少比例帶來持久改進的報告，也沒有說明兩位投資者的偏好衝突時會如何處理——對一個失敗屬於偏好而非錯誤的工具來說，這正是設計最容易引發的失敗模式。case-study，第一方，未測量。

與其他方法的對照#

• 合成生成（DeepResearchEval、ReportBench、DRBench）——可擴展，沒有隱私暴露，但任務是模型想像出來的，可能漏掉真實失敗模式。（這份語料中唯一實際測量差異、而非只提出主張的案例是上節的 OmniVChat：完全生成的基準測試，加上一個生成器從未接觸過的 360 段錄影探測集。增幅相符，排名卻不一致。）
• 從即時語料自動生成（DeepScholar-Bench）——DRACO 的表 1 將它歸類為合成資料；以人工撰寫與否來看，這樣分類是對的。但它的任務來自近期 arXiv 論文，每月更新，且限於訓練截止日期之後發表的論文，因此既不是模型想像出來的，也不會受污染。它和本文的方法一樣，透過持續更新的資料流取得可更新性，不需要正式環境流量或隱私流程。代價是，領域範圍取決於語料內容，而且真實使用者意圖完全沒有保留下來。
• 根據訪談或搜尋人工撰寫（xBench、ResearcherBench、DEER）——由人工撰寫且具真實感，但受作者想像力所限，也不是來自即時正式環境系統。
• 取材自正式環境（DRACO）——三種方法中唯一會挖掘真實分布與實際失敗的方式，代價是必須取得部署環境存取權並建立隱私流程。

合成極端案例：方法徹底走到底，再加上錄影探測（2026 年 9 月）#

本文「合成生成」項目一直背負著同一筆未償債務：任務是模型想像出來的，可能漏掉真實失敗模式——只有主張，從未測量，因為從未有人在生成基準測試的同時，也建立錄影對照組來驗證。OmniVChat（He、Chu、Chen 等人，Alibaba Qwen Team + CUHK + SJTU，arXiv 2609.21465，2026-09-18，empirical）是這份語料中第一個同時做到兩者的來源。

為何此處無法從正式環境取材，正是有意思之處。 任務是原生影音對話——使用者的手機攝影機與麥克風，查詢同時嵌入兩種串流。論文指出的限制是：「人們使用自有裝置的開源錄影十分稀少」，而且情境中還有長尾噪音、鏡頭移動與裝置姿勢問題。這正是本文方法從結構上無法處理的案例：確實掌握這類流量的已部署系統（即時語音產品）不會公開資料，而學術實驗室沒有任何部署系統。因此資料來源只能是生成或錄製；論文兩者都做，並進行比較。

生成資料端。 OmniVChat-Studio 是由四個代理組成的引擎——Director（負責所有文字輸入與輸出）、Renderer（提示 → 同步影音片段）、Reviewer（觀看生成片段、撰寫描述與七部分品質報告，並回答聚焦問題），以及確定性的 Validator——單輪流程與多輪流程各有 14 個階段，每條路徑都有上限明確的修復預算，預算耗盡就丟棄整次執行。無論模態為何，以下幾點都值得借鑑：

• 分布是明確指定的，不是觀察得來的。 每個子類別都有一組屬性設定與目標機率；抽樣時使用 Gumbel-top-k，在完整聯合指派空間中競賽，搭配軟性偏好乘數與硬性排除條件（Eq. 7）。這與 DRACO 根據真實流量的難度代理訊號抽樣正好相反：代表性是指定而非估算，因此可稽核，但會以另一種方式出錯——論文承認「小批次可能漏掉罕見組合」，且「後續失敗與品質篩選也可能改變哪些指派進入最終交付集。」
• 觀察與判斷在設計上分開。 Reviewer 回報生成片段中的內容；Director 則將回報與計畫比較後做出判斷。設計說明明確指出「回覆會依據生成內容，而非原定腳本」——參考答案以實際生成的內容為根據，而非以原先提出的內容為準。這是合成資料對應於本文所要求的正式環境標註紀律，也是最容易移植到純文字情境的部分。
• 把關機制確實存在，也會丟棄資料。 先進行確定性驗證，再做語意審查；每次修復都會回到造成缺陷的階段；引擎「會丟棄未完成的執行結果，而不儲存部分實例。」接著還有兩道事後流程：確定性修復音訊尾端瑕疵（2,800 個交付實例中，571 個實例的 695 段片段經過修復；瞬態分數中位數從 86.6 降至 0.02），以及人工檢查每個交付實例。論文以自身的說法解釋原因：語意關卡「使用 Reviewer 的描述與 Director 的判斷」，而「這些代理可能犯下相同錯誤。」

最後這句坦率點出了本文合成資料項目所提到的失敗模式：生成基準測試的品質把關，與生成器彼此相關。此處採取的補救方式是人工檢查 2,800 段片段——比隱私流程便宜，也是無法從正式環境取材時，這條路徑仍能擴展的原因。

錄影資料端，也是讓這項研究可引用的關鍵。 OmniVChat-Bench-Human：360 段手機錄影，12 個單輪子類別、各 30 段，全是中文；表演者依簡明的演員指南即興演出，沒有逐段腳本——「不同於合成對話，這些記錄沒有時間軸、場景設定或配置區塊。」標註流程是合併三份獨立描述，再根據錄影由人工修正，最後不觀看影片，只根據修正後的描述撰寫參考回覆與分級評分規準。這個流程中有一個數字值得記在本文：人工修正前，360 段片段中有 62 段（17.2%）的描述漏掉了使用者說的話——這是真實錄影的標註缺陷率，而合成流程不必承擔這種成本，也具體說明錄製資料並非自然就有更高品質的基礎。

比較結果及其限制。 使用 5,600 段引擎生成的對話訓練後，合成基準測試分數從 0.465 升至 0.652，錄製資料探測集則從 0.402 升至 0.632；與語言相符的對照組（1,034 個中文合成實例）相比，兩條曲線幾乎相同，分別為 0.437 → 0.634 與 0.402 → 0.632。就本文關注的遷移問題而言，這是真正的結果：完全以生成刺激建立的基準測試，能預測同一子類別錄製刺激上的進步。 有三點限制了結論，其中兩點由論文自行指出。探測集只有 360 個實例，涵蓋 17 個子類別中的 12 個，只測單輪、單一語言，沒有延遲或即時中斷。合成資料與錄製資料共用相同形式的評分規準與同一評分者；論文指出，這「並未使任務彼此獨立，也不保證評分者偏差會互相抵銷。」至於排名證據，結果則與能力水準相反：Gemini-3.5-Flash 在合成基準測試領先，Gemini-3.7-Flash 卻在錄製探測集領先，因此兩種評估工具對訓練是否有幫助看法一致，但對哪個模型較好看法不一致。增幅能否遷移，不代表排名也能遷移；這是這份語料中第一個有資料區分兩者的來源。

相關連結#

• 評估時答案洩漏——本文方法無法阻止的洩漏管道，而且這是新鮮度完全無法防禦的情況。透過正式環境資料更新可避免污染，因為全新任務難以事先記憶；但如果任務取自近期上游提交，執行時檢索暴露程度就最高，因為該提交、差異內容與測試仍在上游，而且沙盒仍能存取。在 SWE-Bench Pro 上，這讓七個模型中有六個損失 14–26 分。需要一起記住的配對是：更新能守住訓練邊界，隔離能守住執行邊界，代理型基準測試兩者都需要

• DRACO Benchmark——具體案例；本文方法是它的核心貢獻

• GDPval Benchmark——第三種取材路徑，與本文相鄰，且不同於常見的兩種替代方法。GDPval 既不是從正式環境抽樣，也不是憑空想像：OpenAI 邀請在職專業人士（至少 4 年資歷，平均 14 年，申請者錄取率不到 10%），請每個人根據自己實際工作中產出的工作成果設計一項任務，再把 1,320 項任務全數交由模型篩選，平均接受五位專家審查。這種做法帶來正式環境抽樣無法提供的東西：根據外部框架衡量代表性（O*NET 工作活動，依薪資總額加權職業）、以薪資計價的每項任務美元價值（平均 $398），以及可供評分比對的人工參考交付成果——正式環境流量有查詢，卻沒有標準答案。代價則是本文取捨一節所稱取捨的反向形式：分布由基準測試作者選定而非觀察而得，因此代表性是透過 Acemoglu–Autor 對數位任務分類器的驗證來論證，而非透過抽樣取得。向專家而非流量取材，也轉移了隱私問題——不需要 PII 流程，但必須移除能識別任務撰寫專家的細節

• Automated Failure Attribution——刻意走向相反取捨的做法，值得作為本文的平衡案例。WHO&WHEN PRO 透過合成達到 12,326 筆失敗追蹤資料，且每筆都有黃金標準代理／步驟／模式標籤：在已成功的暖啟動執行中注入一個錯誤，讓決定性步驟依設計必然正確，而非靠標註判定。正式環境取材的做法，無法在如此規模達到相同標籤精確度；合成資料則無法說明部署環境實際會發生什麼失敗，以及發生頻率。兩種失敗模式正好互為鏡像：來自正式環境的評估有真實任務與可爭議標籤，合成評估則有完美標籤與設計好的分布

• 每項任務成本高於每個 Token 成本——採用相同方法的供應商建議：Anthropic 的模型選擇指引承認，公開基準測試在 Opus/Fable 層級已達飽和，並告訴買方應從自家正式環境流量整理出決定性評估——也就是把來自正式環境的評估當成採購決策的決勝因素，而非僅是建構基準測試的技術。Databricks 正是買方實踐這項建議的案例，其產出的數據（依模型比較每項任務成本與成功率）記載於該頁

• 編排決定 Token 經濟效益——買方自行建立的評估所測得的另一面：任務取自自家程式碼庫，因此 Databricks 可以同時改變harness與模型，而公開程式碼基準測試無法呈現這點。任務取自真實工程工作，跨 harness 成本比較才有意義

• Interactivity Benchmarks——上方生成刺激基準測試被列為一種評估工具，並收錄其評審研究、檢查點雜訊結果，以及單一實驗室掌握所有環節所造成的 COI

• LLM-as-a-Judge——評估流程的評分部分；以正式環境任務搭配評分規準與評審評分，即可建立可自動化（有人工作業把關）的評估

• 深度研究代理——DRACO 挖掘正式環境流量所來自的系統類別

• 複利型資料護城河——正式環境使用情況是受時間限制的專有資產；本文探討的正是將這項資產重新用作評估基礎

• 將評估作為產品規格——「在推出前／根據真實使用情況建立測量架構」；來自正式環境的評估，就是將這項原則擴展到基準測試規模

• Task Time-Horizon Scaling——相關問題：基準測試會飽和，因此能否從即時使用情況更新，決定評估能否持續有效

• Automated Behavioral Audit——對齊領域的類似案例指出，合成情境「可能不符合真實流量分布」；這正是正式環境取材要填補的缺口

• 遙測與問卷測量——Faros AI 主張以遙測取代問卷，是工程指標領域的對應做法：從真實系統測量，而不是依據自我回報

• 部署模擬——對齊領域應用同一方法：OpenAI 重播去識別化正式環境對話，在發布前預測安全行為；DRACO 重播對話則是為了建立能力基準測試。兩者使用相同的 PII 流程，也享有相同的專有流量護城河

• Conversation-to-Delegation Shift——它對測量過時的論點進一步延伸同一種直覺：使用方式轉成委派後，連該讀取哪些指標（複雜度、執行時間、並行度、輸出）都必須重新取材自真實代理行為，而不是互動次數

• 將代理程式碼生成視為編譯——說明評估基礎為何需要底層確定性流程的可重現性論點：Bridgewater 明確採用雙代理程式碼識別，確保「擴大規模、逐步最佳化與評估時，我們有比憑感覺或 LLM-as-judge 評估更可靠的依據。」來自正式環境的基準測試仍需要夠低的執行間雜訊底限，才能確認增幅來自修改，而非抽樣

• 代理品質飛輪——持續產品迴圈形式：正式環境 OTel 追蹤資料就地評分、即時流量由線上監測器檢查、合成模擬降為冷啟動引導。它也收錄從測試資料跨越到訓練資料的版本（Shopify 的自我修復管線）；此時難度代理訊號來自迴圈內評審自己的分數，而非獨立的人類訊號

• Failures That Look Like Success——正式環境規模追蹤資料能量化的失敗類別：靜默違反契約，而示範規模評估只會抽樣碰到

• 正式環境代理流量中的失準——刪除資料整理階段、用於對齊領域的方法：不設計抽樣、不擴增、不設人工品質把關，只對 8,600 段真實程式碼代理逐字稿套用兩份評審評分規準。這是成本最低的版本，也承受本文取捨一節所說、最純粹的缺點——分布就是實際到達的流量；一位使用量龐大的使用者，嚴格到異常的程式碼審查規則就貢獻了圖表中 76 個嚴重規避監控案例裡的 41 個。此外，這也是最清楚的案例，說明來自正式環境的資料並非沒有構念問題：所計算的行為，是根據使用者必須先行安裝的監督機制定義的

• 脈絡優勢，而非品味——將正式環境遙測視為脈絡轉移：從真實使用中取得評估資料，把人類對使用者的了解移到模型可讀取的地方，並依設計運用人類掌握資訊不對稱的優勢

• LLM 評審驗證——正交的品質軸線：本文決定基準測試包含哪些任務；評審驗證則決定這些任務的評分是否可信——由未經驗證的評審為代表性任務評分，仍然是不可靠的評估

• Measuring Beyond Accuracy Saturation——對「基準測試飽和時該怎麼辦」的相關回答，方向相反：本文從即時正式環境使用情況更新任務集；Nadgir 等人則沿六個非準確率軸線重新設計既有任務集的測量方式。兩者都拒絕淘汰後取而代之的直覺——一方新增任務，另一方新增指標

• 基準污染與去污染——針對資料污染的預防與修正配對：來自正式環境的資料（以及一般動態基準測試）透過抽取新鮮且難以事先記憶的任務並持續更新，預先避免外洩；UBD 則是在模型已因接觸靜態基準測試而膨脹後，於缺少乾淨參照的情況下修正問題。兩者是防範同一外洩威脅的互補方法

• 公開基準還提供多少訊號——又該用什麼取代？——彙整各案例的總論：來自正式環境的更新，是五部分替代方案中的新增任務策略（預防污染＋代表性），並與評審驗證並列為可信評估的兩個部分

• 以基準門檻治理：指標必須證明什麼，義務才能據此成立——在治理情境中，從正式環境更新是預防污染的一般形式，也有其限制：流程需要大規模部署流量，而劃定監管範圍的監管者沒有這些流量，受監管機構則有

• AI-Assisted Error Analysis——同一問題的另一面。本文詢問如何從正式環境流量抽樣建立評估集；該文探討取得樣本後如何解讀樣本，透過代理將追蹤資料分群、建立客製化審查介面，再把每筆人工標註的結果擴展到整份語料。兩者都適用該文的警告：LLM 選出的分群特徵只是猜測，因此對已審查子集的代表性只是預設成立，並未獲得證明

• Skill Lift——鏡像般相反的取材選擇，也是語料中最鮮明的對照。DRACO 從獨立於受評分系統的真實流量取出任務；NVIDIA SkillEvaluator 則從受評分的產物生成任務（create-eval-dataset./my-skill），因此技能同時決定任務分布與預期輸出。主題完全吻合，獨立性則完全為零——正好是本文「代表性與可爭議標籤」取捨的反面，也把供應商自己的格言（「技能的測量精度，取決於評估集對工作的描述有多精準」）轉化成基準測試能呈現內容的上限

• 型別化決策驗證器——供應商將本文論點採納為政策：TypeSafe 不公布 Jev 的公開基準分數，並告訴使用者自行建立評估（「System One 任務容易得多，方便評估」）；而此類別唯一的第三方數據，是由參賽者自行執行的共用排行榜

開放問題#

• 擴增會在多大程度上扭曲它聲稱要代表的分布？原始查詢與擴增任務之間的代表性損失，能否測量？
• 以倒讚來界定難度會偏向目前的失敗——這是否會讓基準測試成為移動目標，偏袒下一個以這些失敗訓練的模型？已有實例，但尚未解答（2026-08-13）：Sidekick 的持續學習迴圈正是在正式環境中執行這種迴圈——評審低分所抽樣出的困難負例，經修復與重播後，每天透過 SFT 再透過 GRPO 納入模型權重，並以同一評審作為獎勵——但報告中沒有留出切分、獨立的難度代理訊號，也沒有能區分「模型變好了」與「模型更擅長迎合抽樣器」的實驗組。因此這項風險已在部署環境出現，仍沒有測量。可證偽的問題可以更明確：從正式環境流量中留出一部分，以訓練迴圈看不到的訊號抽樣（使用者倒讚，或來自不同家族的評審），再比較該留出資料測得的進步與迴圈內評審測得的進步。部分得到解答（2026-09-23），而已執行的那部分結果一致。OmniVChat: Synthesizing, Benchmarking, and Training for Native Audio-Visual Dialogue（empirical）採用相同結構——訓練語料與基準測試由同一引擎根據同一組子類別設定合成，並以評分評審作為獎勵進行最佳化——而且確實留出了此問題要求的分布切片：360 段由表演者依簡明指南即興演出的手機錄影，沒有任何部分進入訓練迴圈。兩處測得的進步相近：迴圈內合成基準測試從 0.465 升至 0.652，錄影探測集從 0.402 升至 0.632，語言相符的合成對照組則從 0.437 升至 0.634。因此在這個案例中，分布上的自我吹捧並未發生。評審這一半仍未解決，作者也明言如此：同一個 qwen3.7-max 負責評分獎勵、合成基準測試與錄影探測集；他們的六評審敏感度研究「沒有使用其他評審重新測量 OmniVChat-RL 從 0.465 到 0.652 的增幅。」目前可證偽的剩餘問題精確到只需一個實驗——用不同家族的評審重新評分迴圈內資料與留出切片——而且成本低，因為回覆集合已經存在。還要注意，增幅相符能證明什麼、不能證明什麼：兩種評估工具對增幅看法一致，對同一供應商家族兩個模型的排名卻不一致，因此留出切片能驗證進步主張，不能驗證排行榜。
• 在醫療、法律等來源流量最敏感的受監管領域中，隱私流程（不讓任何人看到原始查詢）是否足夠可信且可稽核？

資料來源#

• GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks — Patwardhan 等人（19 位作者，OpenAI），arXiv 2510.04374 v1，2025-10-05，29 頁（empirical）。本文僅引用它來比較取材方式：§2.2（專家招募門檻與錄取率）、§2.3–2.4（根據專家自己的工作成果建立任務；模型篩選後每項任務平均由五位人類專家審查，至少三位）、§2.1 與 A.7（依薪資總額選擇職業，以及 GPT-4o 數位任務分類器如何根據 Acemoglu & Autor 2011 驗證）、A.4 表 3–6（任務價值、時間長度、O*NET 涵蓋範圍）、§4（公開的 220 項黃金標準子集已移除可識別專家的細節）。該研究本身的結果與 COI 見 GDPval Benchmark
• SWE-Bench Pro Verified: A Reliable Benchmark for Software Engineering Agents — Zheng、Shang、Jiang、Tian、Zhu、Ma、Yuan 與 Zhang（ECNU / Shanghai AI Lab / Fudan），SWE-Bench Pro Verified，arXiv 2609.08149，2026-09-08（empirical，37 頁）。本文引用它說明新鮮度作為防禦的限制：四種執行時洩漏管道，以及已確認存取的 103 與 49 個任務歸零結果。完整討論見評估時答案洩漏
• DRACO: a Cross-Domain Benchmark for Deep Research Accuracy, Completeness, and Objectivity — §3（任務建構：抽樣、預處理、擴增、篩選、整理），§6.1（泛化限制；擴增造成過度規格化的警示）
• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog —「從內部迴圈到正式環境迴圈」：以 OTel 追蹤資料作為評估輸入、線上監測器、以合成資料作為引導（vendor-claim）
• Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias — Norman 等人（arXiv 2606.19544，2026 年 6 月，empirical）：評估品質中與任務代表性正交的評分有效性面向；見LLM 評審驗證
• Measuring coding agent misalignment in the wild — The Docent Team、Transluce，2026-08-04（empirical）：將方法簡化到最低限度——對 8,600 段真實程式碼代理逐字稿套用兩份 LLM 評審規準，不設計抽樣、不擴增，也沒有人工品質把關；也是代表性缺點最明確的案例之一，其中一位高頻使用者貢獻了圖表所列 76 個嚴重案例中的 41 個，而計入的行為，是根據使用者必須先行安裝的監督機制定義。完整討論見正式環境代理流量中的失準
• Sidekick's continual learning loop — Andrew McNamara 與 Cody Mazza-Anthony，Shopify Engineering，2026-08-05，case-study（作者對自家正式環境系統的第一方描述；沒有複現、對照組或留出切分）。本文僅引用訓練端的延伸：依評審分數挖掘困難負例、評審小組 → 仲裁者 → 提供提示 → 重播修復迴圈、將無法修復的失敗升級交給 Toloka，以及每日納入 SFT＋GRPO。本文未使用其成本與品質數據。完整來源討論見代理品質飛輪
• The price is wrong: AI cost calculation has to consider task completion rates, not just token costs — Thomas Claburn，The Register，2026-07-13（case-study，二手報導 Databricks 的基準測試網誌文章；語料中沒有原始來源）：買方端案例——根據員工針對數百萬行程式碼庫執行的工程任務建立內部程式碼基準測試，動機是模型都針對 SWE-Bench 調校，測試結果則用來選擇模型與 harness
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes — McManus、Ran 與 Weight（Bridgewater Associates），LangChain 頻道，2026-07-24，25:44 演講，case-study。本文引用 Teach 按鈕迴圈（15:24–18:08）與自主背景代理版本（5:01–6:24）。第一方來源，完全沒有測量——沒有 PR 採納率、測試套件規模或持久性數據。見 Bridgewater Associates
• Introducing System One Models & Jev — Diogo Almeida，TypeSafe AI，2026-09-15，vendor-claim：反對公開基準測試的常見問答立場（僅用於「關聯」項目）