Eval 就是 Spec
Eval 就是 Spec 的核心主張是：在 AI 產品裡，真正定義系統行為的不是 PRD，而是 eval 資料集。aihao-blog 的文章用這個觀點把 AI 產品設計從「寫需求」拉到「定義可測量的行為分布」。
核心意思
- PRD 對傳統軟體有效，但對 LLM / AI Agent 不夠。
- 品質不是單一分數，而是整個分布。
- 要塑造 Agent 行為，得靠足夠多、足夠貼近真實場景的 eval。
- 每一條 eval 都是在把系統往預期行為方向推。
2026-02-17 的 AIHAO 文章補上一個反例：通用 AI 指標（helpfulness、coherence、toxicity、ROUGE、BERTScore）只能粗略描述 foundation model 能力，不能保證特定產品任務成功。Application eval 要從 domain expert 標註真實失敗案例開始，把「功能正確、符合業務限制、符合使用者期待」拆成產品自己的 criteria；因此 test-time-compute-evaluation 或 benchmark 只能做模型初篩，不能替代產品級 eval。
這也讓 agent-trace-observability 更重要：trace 裡的真實錯誤、使用者回報與邊界案例，才是把 generic metric 轉成 application-specific eval 的材料。沒有這一層，prompt 調整容易變成追求漂亮分數，而不是修正真正的產品行為。
Google Research 的 2026-03-31 文章補上 benchmark 標註設計問題：若任務本身帶有主觀性或文化差異，只用 1–5 位 rater 取多數決，可能把 human disagreement 壓成假裝穩定的單一 ground truth。它用 virtual expert tribes 模擬 item 數（N）與每題 rater 數（K）的取捨，指出想捕捉意見分布時，增加每題 rater 通常比只增加題目更有用；因此 eval dataset 不只要有案例，還要記錄標註者分歧與可重現性假設。
Google Research 的 ConvApparel 文章再補上「測試互動對象是否可信」：LLM-based user simulator 若過度有耐心、知識太完整或語氣太規整，會讓 conversational agent 在 synthetic users 上看似成功、但真實使用者體驗變差。它用 user-simulator-evaluation 的 dual-agent data collection、human-likeness score 與 counterfactual validation 測量 realism gap，提醒 eval 不只要測答案，也要測情境、互動分布與 out-of-distribution 反應。
SensorFM 的 Personal Health Agent 實驗再提供一個 domain-specific eval 例子：把 SensorFM predictions、ground-truth measurements 與 baseline 分成三種 grounding 條件，由臨床專家以 context、relevance、justifiability、personalization、potential for harm 五項 rubric 評分。這提醒產品級 eval 必須把可辯護性、個人化與傷害風險寫進 spec，而不只比較模型的任務分數。
SymptomAI：從合成 vignette 走向真實使用者與延遲 ground truth
Google Research 的 SymptomAI 提供另一個高風險 conversational agent 的 in-situ eval 案例：13,917 名同意參與者被隨機分派到五種 Gemini Flash 2.0 SymptomAI agent，描述自己的症狀並接受主動追問；兩週後再回報醫療提供者的診斷。評估同時包含三位 board-certified clinicians 對完整對話的盲評與 DDx 排名，以及把 AI 的 top-5 differential diagnosis 對照後續自報診斷，形成「即時互動 → 延遲外部結果 → 專家比較」的 ground-truth 路徑。
這個案例對 eval spec 的可重用補充有三點：第一，真實使用者的資訊完整度、醫療識讀與自然敘述不能用 curated case study 代替；第二，agent 是否主動追問本身就是可評估的 policy，來源報告五種 prompting arms 中 agent-driven follow-up 優於完全 user-driven 的 Base 條件；第三，高風險任務要把時間延遲、外部結果、專家分歧與失敗邊界寫進評測，而不是只看一次回答的 correctness。文章也把 Fitbit biosignals 與症狀對話連結起來，但這是 observational evidence，不是臨床驗證。
SymptomAI 的限制同樣是 spec 的一部分：臨床專家只能審查靜態 transcript，不能自行追問；診斷可能隨時間改變，且對話可能缺少身體語言、影像與病歷。所有診斷與疾病標籤都只是研究分析用途，不能當成確認診斷或正式醫療評估；這提醒 agent-trace-observability 與 user-simulator-evaluation 之外，產品還要保留專業審查、風險分級與明確的人類責任邊界。
AMIE (Video)：把多模態、延遲與安全一起寫進 eval
Google Research 的 AMIE (Video) 把高風險 conversational agent 的 eval 從文字診斷推進到同步 audio-visual consultation。系統用非同步三 agent 分工：Talker 維持低延遲對話，Planner 在背景更新鑑別診斷與管理計畫，Perception 持續讀取聲音與影像中的非語言線索；這是把 model-interface-agent-orchestration 的分工直接接到臨床 latency、感知與推理指標，而不是單純增加模型規模。
它的驗證分兩層：先從醫學文獻建立 telehealth audio-visual competency taxonomy，以 targeted single-turn perception／reasoning tests 和 multi-turn simulated audio consultation 快速找出 failure modes；再用 randomized OSCE 覆蓋 100 個情境、300 次標準化諮詢，設置 AMIE (Video)、AMIE (Text) 與 PCP (Video) 三臂，由 20 位資深 primary care physicians 依一般臨床能力與 case-specific rubric 評估。來源報告 AMIE (Video) 在整體臨床能力、診斷正確性與溝通品質上與 PCP 相當，在 eliciting physical signs／引導檢查上更高，且 patient actors 偏好 video；這些是 Google 研究結果，不是獨立重現或臨床核准。
可重用的 eval spec 不只寫「答案對不對」，還要分開測 modality contribution、response latency、非語言線索、檢查引導、patient experience、failure recovery 與 harm boundary。這延伸 user-simulator-evaluation 的 simulated participant 驗證與 agent-experience 的可理解互動，但限制也必須同時入 spec：研究全由 professional patient actors 在模擬場景完成，存在偶發感知／推理錯誤與技術中斷，仍需真實病人、不可表演的臨床狀況與安全框架驗證。
從 ALE 看長時程 agent eval
AIHAO 對 Berkeley RDI Agents’ Last Exam（ALE） 的整理，把 eval 的對象從問答答案推到真實專業軟體中的工作完成度。來源報導的設計包含產業專家出題、跨子產業任務、rolling 題庫、可驗證 outcome、agent trace，以及 Near-term／Full-Spectrum／Last-Exam／ALE-CLI 的難度分層；它同時保留 pass rate 與 partial-credit score，避免長任務在最難區域全部變成零分。來源也把模型、harness、推論成本與分數放在同一張表中，但 leaderboard 數字與「規模最大」等描述仍應視為來源報導，正式選型前需回查 ALE 原站與評測定義。
這個案例把產品級 spec 再往前推：若產品宣稱 agent 能「上工」，eval 至少要固定任務分布、外部軟體環境、可驗證 outcome、長時程恢復能力、partial credit、成本與 harness；單一短任務 pass rate 或單一模型排名不足以支撐部署結論。它也直接連到 agent-trace-observability：trace 不只是除錯資料，而是分析 agent 在專業工具中卡住、恢復或完成的證據。
LLM-as-Judge：把模糊品質拆成可驗證規格
AIHAO 2026-07-22 整理兩條獨立研究線的共同做法：不要讓 judge 直接把多維度品質壓成 1–5 分，而是把需求拆成互相獨立、自包含的 Yes／No criteria，再按權重聚合。這樣既能降低位置、冗長、自我增強與 ceiling bias，也能把某一條 fail 直接轉成 prompt、workflow 或產品規格的 debug 訊號；criteria 應針對任務甚至單一案例設計，並由專家參考答案或人工審查校準，而不是把通用 rubric 或純合成清單直接當真值。
拆解不是無條件的自動正確：來源同時整理了自動 checklist 在直接評分、pairwise、不同 judge 模型與逐條／batch 執行方式上的取捨。高風險流程應保留人工審查、保守的 false-pass gate 與成本／一致性比較；在 AI Ark 的最小實作中，可先把一條模糊品質要求拆成可獨立驗證的條目，再將 fail 條目回寫成 eval case，而不是先追求一個漂亮的總分。
文件解析也要是 eval spec
AIHAO 2026-07-26 導讀《Beyond RAG》補上資料層的 eval 分布：文件解析不能只用文字重疊率判斷，至少要分開測表格的列欄結構、圖表數值、文字完整性、標題／清單等結構，以及元素能否 grounding 回頁碼或 bounding box。這把 document-parsing-first-rag 的上游 failure 轉成可驗收的規格，而不是把所有錯誤推給模型或 embedding。
同一來源也提醒，parser、index、prompt、schema 與來源版本要能重播；parser 改版後應以長尾題庫、faithfulness、relevancy、recall、成本與延遲做 regression gate。vendor benchmark 可用來找候選，但不能取代自己的 corpus、權限與任務分布。
Eval 也會折舊：用 ablation 找到真正需要保留的規則
BusinessNext 2026-07-30 整理 Claude Code 團隊以 ablation 檢查 system prompt：先整段刪除，再逐行加回，觀察哪些規則真的改變任務結果。來源同時轉述一個重要限制：eval 集可能只活一到三個模型世代，能力進步後分數會飽和，測試集需要重做；因此 eval 是 spec，卻不是永久不變的規格檔。
可重用的最小迴圈是：固定目前任務分布與失敗案例 → 刪除一段 prompt／skill／scaffold → 正常跑任務 → 檢查品質、成本與安全是否退化 → 只回填能修正重複失敗的規則。這讓 model-harness-fit 與 loop-engineering 接回 eval 的版本化維護，也提醒 agentic-ai-cost-management：刪掉無效規則可能降低 context 與 retry 成本，但不能用「分數飽和」當成刪掉高風險測試的理由。
Chain-of-Evidence：研究 agent 的 integrity eval
Google Research 的 Science One Framework 把 eval 直接綁到研究 artifact 的 evidence chain。CoE Audit 將「可信」拆成四個可驗收 criteria：獨立重跑分數、是否違反任務規格、引用是否真實，以及論文方法是否和 code 對齊；這些 criteria 可以把幻覺引用、不可重現分數與 method-code drift 轉成明確的 fail case，而不是只給一個模糊的 paper quality 分數。這補強 chain-of-evidence-autonomous-research：eval 不只是最後評分，也是每個 claim 與其證據之間的契約。
生成式媒體指南把 application eval 落到視覺與品牌產物：先由 Gemini 依品牌準則與原始提示詞做守門，再用 Gecko 類問答拆解、動態查核問題與視覺比對評估構圖、文字與場景條件；不合格時重寫提示並重試，超過上限才交人工複核。這補充 generative-media-agent-workflow 的評估層：高產量媒體不能靠單一審美總分，應把角色一致性、音畫同步、品牌規範、內容安全與可重現性拆成可驗證 criteria。Gecko 的具體能力與效果仍是 Google／文章歸屬，不視為獨立 benchmark。
資料 agent：把真實分析失敗寫進 eval
AIHAO 整理 Hex 的做法，補上資料 agent 的 application-specific eval：不要只問「英文能否轉成 SQL」，而要從半完成 notebook、使用者指出「這數字很奇怪」與多層資料 bug 出發，測 agent 是否能在中間結果中找到被前一個錯誤遮住的後續錯誤。來源特別描述 fan-out 讓所有業務看似達成 900% 配額的題目；模型幾乎不會主動懷疑數字，直到人先給出「這看起來不太對」的訊號。
可重用的 eval 規則是：題目要小到負責人記得每個失敗陷阱，重複執行來觀察變異，而不是用數百個同一陷阱的題目製造假精度；同時保留日常 regression set 與專門量測目前全模型都做不好的 target set。Metric City 再把 eval 延伸到 90 回合的資料環境，測 agent 是否會主動記錄並取回 context；這是 trajectory／長時程學習能力的測試，不應被單次 pass rate 取代。
Eval smell：把可驗證性做進產品 UX
AIHAO 2026-08-05 整理 Hamel Husain 的「It’s Hard to Eval」：團隊若說輸出很難 eval，往往不是缺少更強的 judge，而是產品把驗證責任推回使用者。這把 agent-experience 接到 eval spec：產品應先問使用者實際要檢查什麼、手上有哪些可信對照、專家依哪些訊號判斷，以及輸出能否拆成可個別接受、編輯或拒絕的小單位。
資料分析 agent 的 chat + notebook、課程計畫的 retrieval + diff、醫療報告的 fact-first research assistant 都採同一方向：保留 provenance、逐步揭露假設與來源，把整體答案改成可核對的證據單位。可重用的判準是同時縮短「發現錯誤」與「標註／評估」的成本；降低模型錯誤率仍重要，但不能用一個總分掩蓋使用者無法校準信任的 UX 缺口。這也連到 ai-cognitive-offloading-and-agency：可驗證介面讓人保留判斷責任，而不是把「看起來合理」當成接受理由。
架構分層與錯誤分析：兩種 Agent Eval 路線
AIHAO 2026-08-02 的 draft 把 Braintrust 的架構分層與 howtoeval 的 production error analysis 放在一起比較。兩者都反對一次性 benchmark、都把真實失敗回收成 eval case，也都把評估單位從答案推到完整 trace；差異在於前者先按 agent 架構與 harness 元件補測試層，後者先按流量與真實錯誤安排最小工作流。
可重用的組合方式是：產品早期先讀 log、重現高成本錯誤並維持少量高訊號 case；當系統加入 workflow graph、記憶、sandbox、skills、工具探索或權限審批，再逐層補 smoke、離線、模擬、replay／shadow 與線上 gate。eval suite 要同時避免「測不夠」與「大到團隊忽略失敗」兩種風險，保留仍在保護重要行為的案例，定期修剪失去訊號的案例。
PhotoScan：多模態健康模型的驗證規格
Google Research 的 PhotoScan 提供另一個 domain-specific eval 例子：系統先從 smartphone imagery 估計 BF%、A/G 與 V/S，再比較 demographics、tape measurements、smartwatch BIA、PhotoScan 與 DXA 五種 feature set 對 insulin resistance 的預測。可重用的 spec 不是單一 AUROC，而是同時固定 5-fold fine-tuning、independent cohort、unseen data、BMI／標籤平衡、leak-free split、body-composition MAE 與 AUROC／NRI，並把 gold-standard DXA 當對照。
來源在其 cohort 上報告 demographics baseline AUROC 0.692、加 PhotoScan 後 0.760、加 DXA 後 0.773；這些結果仍是研究來源 attribution，不能直接推導臨床等價、普遍族群效能或醫療建議。高風險 multimodal agent 若要把這類中間指標交給 personal-general-ai-assistant，還應把 consent、privacy、bias、外部 validation、專業覆核與 potential for harm 明確寫入 eval contract；這也延伸 wearable-health-foundation-models 對「representation → tool output → agent grounding」的分層。
在 AI Ark 的用法
Knowledge Profiling / WikiProfile 提供一個 fact-level eval spec 範例：同一個 fact 要拆成 encoding、direct recall、thinking recovery 與 recognition，而不是只記一個 QA accuracy。這讓 eval 能回答「該補資料、改 retrieval、增加 thinking，還是修正生成／驗證流程」，也和 knowledge-profiling-factuality、test-time-compute-evaluation 相連。
Judge 偏好與溝通評測的校準
BusinessNext 2026-08-06 整理《Moral Mazes in the Era of LLMs》的 HR Simulator，補上一個不能忽略的 eval caveat：LLM judge 的分數同時量到任務表現與 judge 自己的溝通偏好。研究把信件拆成同理、正式與 tact，並以 10 個不同模型當 judge；來源報導指出，大、小模型之間的分歧多半落在「得體」而不是單純禮貌，且第 2、5 關未能由 tact 同樣解釋。這些結果是預印本的特定任務與 rubric 下的觀察，不是人類溝通能力的通用排名。
可重用的 eval 規則是：先記錄 judge model／版本、rubric、受眾與不可妥協的內容，再比較 judge 分數、跨 judge 分歧與真實收件者 outcome。人類先決定溝通策略、AI 再調整語氣的混合流程可能提升通關率，但若只追逐單一 judge 的高分，系統可能學會迎合模型品味而不是改善真實溝通；這應和 emergent-tact、anti-sycophancy-prompting 及 ai-cognitive-offloading-and-agency 一起驗收。
這個概念可以直接接到 prompt-debugging-eval-checklist：先定義測試案例，再修提示詞與輸出契約。 它也補強 test-time-compute-evaluation：比較系統時，不只看分數，還要看預算與行為曲線。 放進 loop-engineering / aiark-loop-engineering 時，就是把 eval 當成 watch → ingest → verify 的共同語言。
Evals 自動化的邊界：人定義、AI 規模化
AIHAO 2026-08-24 整理 Shreya Shankar 的 Analyze／Measure／Improve 框架，補上一條自動化紅線：真正的瓶頸是產品知識，不是算力。人要先從資料中發現並命名 failure mode、決定什麼算好與哪些最壞情況不可接受；AI 適合把既有判斷套用到更多 trace、量測頻率並協助改善，而不是從空白 trace 自動產生完整 eval 規格。
來源示範的 error-discovery skill 把流程拆成理解資料、設計 review surface、分群取樣、互動標註與反覆掃描；中間產出的 failure-mode 定義、標註、judge 與可見度都要留下，否則每次換資料都會重新猜一次。新標註觸發回掃已看過與未看過的資料，讓 criteria drift 變成可校準的 outer／inner loop；這可接到 agent-trace-observability 與 loop-engineering，但 agent 找例子仍不完整，不能取代人的判斷。
可重用的 adoption gate 是 人負責注意與分類，agent 負責整理與套用：先用 agent-skills 封裝方法，再以 app-specific worst-case 推導查證、重疊比對、隱私與 guardrail eval。這也提醒 agent-experience，互動式 review UI 不只是輸出，若把標註寫入可監看的 append-only 事件，UI 就能成為人引導 agent 的輸入通道；來源中的 skill 與 benchmark 數字仍屬演講／作者 attribution，需用自身產品資料驗證。