昨天我們替 Grounded Generation 加上三道閘門。但系統改完後，怎麼知道它真的變好了？
最常見的做法，是挑幾個問題跑 Demo，再看 Dashboard：Faithfulness 0.62、Answer Relevance 0.81。
新版高了 0.03，大家便準備發布。可是 0.62 究竟代表什麼？
回到 ORA-12541 的例子。原始文件有正確答案，Retriever 也在 Top-K 找到新版 Release Note，但 Context Builder 為了 Token Budget，將它裁掉，只留下數份語意相似的舊手冊。模型最後忠實地根據錯誤 Context 回答。
只看最終答案，我們可能繼續調 Prompt；只看 Retrieval Recall，又會以為證據已經找到。真正壞掉的是中間那一層。
好的 Evaluation 不是回答「系統有幾分」，而是回答「哪一層、在哪一類問題、以什麼代價失敗」。
RAG 的最終回答是多個元件共同作用的結果。答案錯了，可能是：
所以 RAG Evaluation 至少要分成 Retrieval、Context、Generation、Answerability、Task 與 Production 六層，各自指向不同 Owner。
加入 Agent 後，還要檢查 Tool、參數、授權、Recovery，以及外部世界是否到達預期狀態。
Evaluation 的目的不是替系統頒發成績單，而是建立一套能把失敗送回正確責任層的導航系統。
若測試資料只有 Question 與 Expected Answer，很快會遇到問題：同一題可以有多種正確表達；文字接近標準答案，也可能漏掉重要條件。
RAG 的 Golden Case 更適合保存：
case_id: ora-12541-001
query: "升級到 3.2.1 後出現 ORA-12541，要怎麼恢復？"
answerability: partial
required_facets:
- claim: "確認 Listener 是否啟動"
evidence: [doc-12#span-8]
- claim: "依 3.2.1 的變更決定恢復方式"
evidence: [doc-21#span-3]
expected_action: partial_answer
slice_tags: [exact_error_code, version_sensitive, troubleshooting]
source_snapshot: corpus-2026-08-24
重點不是 Golden Answer，而是 Required Facets、Evidence Span、Answerability 與 Expected Action。
Evidence-backed Facet 可以成為整條 Pipeline 共用的標註單位：Retrieval 檢查有沒有找到支持這個 Facet 的證據；Context 檢查它是否真的被保留；Generation 檢查回答是否涵蓋 Facet；Citation 則檢查對應 Evidence 是否真的支持 Claim。
Golden Set 也不能只有簡單且可回答的題目，還要包含：
真實 Query 需要去識別與人工標註；Synthetic Question 能擴充長尾，卻只能當候選題。RAGEval 研究情境化合成資料；mtRAG 則顯示多輪追問與不可回答問題無法由單輪 QA 代表。
先定義哪些行為算成功、哪些錯誤不可接受，再選擇 Metric 與工具；
不能先打開 Dashboard，才決定分數代表什麼。
Recall@K、MRR 與 nDCG@K 是常見起點，但 Hit Rate 只表示至少命中一筆，MRR 也不能描述多段 Evidence 的完整性。
RAG 還可以增加：
這些指標需要 Gold Evidence 或 Qrels。LLM Judge 可以估計 Relevance，卻不是 Retrieval Ground Truth。
Retriever 的輸出是候選排行榜；模型看到的則是經過 Reranking、去重、Compression、排序與 Token Budget 後的 Evidence Packet。兩者必須分開保存與評估。
這一層最值得加入的指標是：
Evidence Survival Rate：Retriever 已經找到的必要 Evidence，
最後有多少仍存在於模型實際看到的 Context？
此外還要觀察 Context Coverage、Duplicate／Distractor Rate、Conflict Detection 與 Provenance Integrity。
因此同一個錯答案可以被精確歸因：
| Retrieval | 最終 Context | 回答 | 主要問題 |
|---|---|---|---|
| 沒找到 | 沒有 | 答錯 | Retrieval |
| 找到了 | 被裁掉 | 答錯 | Context Assembly |
| 找到了 | 已保留 | 沒使用 | Generation |
| 找到了 | 已使用 | 擅自加料 | Grounding |
| 證據不足 | 證據不足 | 仍回答 | Answerability |
這一層承接 Day 9，需要分開衡量 Faithfulness、Answer Correctness、Required Facet Completeness、Citation Validity、Citation Correctness 與 Citation Completeness。
Faithfulness 高不代表 Reference 正確；
Answer Relevance 高，也可能只是流暢地回答錯誤內容。
金額、權限或版本等關鍵錯誤不能被平均分掩蓋。
測試集若全是 Answerable，永遠回答的模型就會被錯誤獎勵。
需要分別觀察 False Answer、Over-abstention、Partial Answer Coverage、Conflict Disclosure，以及不同 Threshold 下的 Risk–Coverage Curve。
最終指標應回到真實任務，例如是否找到條款、排除故障或正確路由工單。
Exact Match 適合封閉任務；
開放答案則使用 Required Facets、Executable Check 或 Blind Pairwise Comparison。
離線分數看不到流量尖峰、Timeout、Cache Stale 與跨 Tenant 風險。
Production 還需追蹤 Tail Latency、Fallback、成功任務成本、Stale Answer、ACL Leakage 與 Human Overturn。
AWS Bedrock 已將 RAG Evaluation 分成 Retrieve only 與 Retrieve and generate，Microsoft Foundry 也區分 Process Evaluation 與 System Evaluation。重點不是採用哪一家，而是主流實務已不再把 RAG 壓成單一最終分數。AWS Bedrock RAG Evaluation、Microsoft Foundry RAG Evaluators
自然語言答案很難只靠 Exact Match 評估，因此 LLM-as-a-Judge 幾乎不可避免：
| 方法 | 適合 | 主要風險 |
|---|---|---|
| Pointwise | 對單一答案給 Pass／Fail 或 Likert Score | 寬鬆程度與刻度漂移 |
| Pairwise | 比較 Candidate 與 Baseline | Position、Length 與 Style Bias |
| Reference-based | 對照 Gold Facts 或 Evidence | Reference 可能不完整或過期 |
Judge 會受到 Rubric、順序、Evidence 長度、模型版本與回答風格影響。Generator 與 Judge 使用同一家族時，也可能共享盲點。
因此 Judge 本身也要接受 Evaluation：
Google Vertex AI 的官方流程同樣要求使用 Human Ratings 評估 Judge，並提供 Confusion Matrix、Balanced Accuracy 與 F1，而不是只相信 Judge 產生的平均分。Google Cloud：Evaluate a judge model
RAG 的主要輸出是 Context 與 Answer；Agent 則會呼叫 Tool、改變狀態，甚至代表使用者執行外部動作。這使 Evaluation 從「回答是否正確」擴大成「世界是否真的被正確改變」。
假設 Agent 回答：「Listener 已重新啟動，服務恢復正常。」它可能同時：
因此，Agent Evaluation 至少有三種粒度：
| 粒度 | 真正要驗證的事 |
|---|---|
| Final State | 外部環境是否真的達到預期狀態？ |
| Milestone／Invariant | 必要確認與條件是否完成，禁忌是否未發生？ |
| Trajectory | Tool、參數、順序、Recovery 與 Stop 是否合理？ |
Anthropic 將 Transcript 與 Outcome 明確分開：Agent 說「訂票完成」不算完成，資料庫裡是否真的存在 Reservation 才是 Outcome。Anthropic：Demystifying evals for AI agents
Final Answer 是 Agent 對自己做了什麼的描述；Final State 才是外部世界真正發生了什麼。
付款或權限流程可能有固定順序，但研究、除錯與客服通常有多條合理路徑。只保存一串標準 Tool Calls，會把有效的新路徑判錯。
Agent Case 應定義：
task: "診斷 ORA-12541，但不要修改正式環境"
final_state:
diagnosis: listener_not_running
mandatory_milestones:
- identify_environment
- inspect_listener_status
- present_evidence
forbidden_actions:
- modify_production_configuration
- restart_service_without_confirmation
allowed_tools: [knowledge_search, monitoring_read]
budgets:
max_tool_calls: 6
max_retries_per_tool: 2
評估可以採 Exact、In-order、Any-order 或 Partial-order。開放任務較適合 Milestones、Forbidden Set 與少量順序限制；只有封閉 SOP 才要求完整路徑一致。AWS AgentCore Ground Truth Evaluation、LangSmith Trajectory Evaluation 都提供不同嚴格度的匹配方式。
Agent 選到正確 Tool，不代表行動正確。Tool Evaluation 至少要拆成：
Microsoft Foundry 也將 Tool Selection、Tool Input Accuracy、Tool Output Utilization 與 Tool Call Success 分成不同 Evaluator。這些維度不能只用「Function Name Match」概括。Microsoft Foundry Agent Evaluators
Offline Test 還應注入 Timeout、Stale Result、惡意 Tool Result 與 Partial Failure，觀察 Agent 是否：
效率不是步數越少越好。應先確認安全 Milestones，再衡量重複呼叫、Token、Latency 與成功任務成本。
如果 Agent 完成退款，但把另一位客戶的資料放進回覆，不能用 90 分 Task Success 抵銷。越權、資料洩漏、跳過確認與 Forbidden Action 必須直接阻擋發布或執行。
安全測試至少涵蓋未授權行動、跨 Tenant、敏感資料洩漏、Prompt Injection、惡意 Tool Result、確認繞過與防禦過度。
Deterministic Grader 應優先檢查真實 State、Tool Schema、Argument Range、Authorization、Forbidden Action 與 Business Invariant。LLM Judge 只處理語氣、互動品質與開放路徑是否合理等語意灰區；Borderline 與高風險案例保留 Human Adjudication。
可以用程式直接驗證的真相，不應先交給另一個 LLM 猜測。
新版 Pipeline 如果使用更強模型、五倍 Retrieval、三倍 Context 與額外三次 Judge Call，回答改善不一定來自新方法本身。
比較 Candidate 與 Baseline 時，應固定或揭露：
EMNLP 2025 的 Stronger Baselines for RAG with Long-Context LMs 也提醒，複雜 RAG 應在 Matched Token Budget 下和簡單但強的 Baseline 比較，避免把更多資源帶來的改善歸功於新 Pipeline。
Agent 具有隨機性，同一 Case 還要跑多次 Trial，報告成功率、Variance、Cost 與 Latency 分布，不能挑最好的一次 Demo。
Offline Evaluation 應在固定 Corpus 與隔離、可重置的環境中執行。每次 Parser、Chunker、Retriever、Context Policy、Prompt、Model、Tool Schema 或 Judge 更新，都需要重跑 Component Metrics 與 End-to-end Regression。
Release Gate 不應只有「平均分不能下降」：
上線後再用 Shadow、Canary 或 A/B 觀察真實 Task Outcome、Human Escalation、Undo、Correction、Latency 與 Cost。線上按讚或 Citation Click 只是行為訊號，不是 Correctness Ground Truth。
最重要的閉環是 Incident Replay：Production 發生錯誤後，由 SME 判定 Failure Layer、補上 Evidence／State／Expected Action，加入永久 Regression Suite。如此 Evaluation 才會隨真實失敗變得更完整。
但 Metric Library 不會產生企業 Ground Truth，Trace 不等於 Correctness，Test Runner 也不是 Dataset Strategy。即使兩套工具都叫 Faithfulness，只要 Judge、Rubric 與輸入不同，分數就不能直接比較。
把今天的設計整理成一條開發循環：
RAG 評估的是證據如何成為答案；Agent 評估的則是模型如何透過一連串決策、工具與狀態改變完成任務。兩者共同的原則是：不能只相信系統最後說了什麼，還要保留每一層真正看見、選擇與改變了什麼。
成熟的 Evaluation 不會只說新版從 0.81 進步到 0.84；
它會告訴我們改善發生在哪一類 Case、犧牲了多少成本與延遲、哪些關鍵風險仍然存在，
以及這個版本是否有資格被發布。
下一步，當 Evaluation 已經能指出問題在哪一層，就需要進一步討論 Production Observability：如何把 Query、Retrieval、Context、Tool Calls、Model、Verifier、Latency、Cost 與使用者結果串成一條可以重建的 Trace。
iThome鐵人賽
看影片追技術