Eval Pipeline 和 Eval 的差別：
Eval 是你跑一次、拿到一個分數。
Eval Pipeline 是每次系統改變，自動跑、自動比較、自動擋住退化。
法律合約系統漏掉一個風險條款的損失可能是千萬。
靠人記得去跑評估，不夠。
面試情境
面試官：「客戶是一家法律事務所，剛上線了一個合約審查 AI 系統。他們問：每次你們更新 Prompt 或換模型版本，我怎麼知道品質沒有退化？法務長說，如果 AI 漏掉一個風險條款，損失可能是千萬。請設計一個讓客戶可以信任的 Eval Pipeline。」
一、核心問題：為什麼需要 Pipeline
Eval（一次性）的問題：
現在的品質：Faithfulness = 0.87 ← 你知道
下週改了 Prompt 之後：? ← 你不知道
三個月後換了模型版本之後：? ← 你更不知道
沒有 Pipeline：
需要有人記得每次改動後去跑評估
→ 沒人記得 → 品質退化不被發現 → 客戶先發現
有 Pipeline：
每次 Prompt / 模型 / 資料 變更 → 自動觸發評估
→ 分數低於閾值 → 自動擋住部署
→ 品質退化在影響用戶之前被系統發現
Eval Pipeline 是把「品質管控」從人工流程變成自動化系統。
這是 POC 到生產的核心差距之一。
二、Eval Pipeline 的四層架構
┌───────────────────────────────────────────────────────────────────┐
│ Layer 1：黃金資料集（Ground Truth） │
│ 「正確答案是什麼」的標準，由領域專家建立 │
└──────────────────────────────┬────────────────────────────────────┘
│ 每次評估都用同一份資料集
▼
┌───────────────────────────────────────────────────────────────────┐
│ Layer 2：離線評估（Offline Eval） │
│ 每次部署前，對黃金資料集跑 RAGAS + Safety，產出指標報告 │
└──────────────────────────────┬────────────────────────────────────┘
│ 評估結果 vs 上一版 baseline
▼
┌───────────────────────────────────────────────────────────────────┐
│ Layer 3：CI/CD 品質閘門（Quality Gate） │
│ 分數低於閾值 → 自動阻止部署；通過 → 繼續 Canary 部署 │
└──────────────────────────────┬────────────────────────────────────┘
│ 部署到生產後持續監控
▼
┌───────────────────────────────────────────────────────────────────┐
│ Layer 4：線上評估（Online Eval） │
│ 生產流量的持續品質監控，偵測 Data Drift 和 Performance Drift │
└───────────────────────────────────────────────────────────────────┘
三、Layer 1：黃金資料集的設計原則
黃金資料集的每一筆記錄：
{
"id": "Q042",
"query": "這份合約的違約金條款是否符合台灣民法第 250 條？",
"context": ["第 3 頁段落...", "第 12 頁段落..."],
"reference_answer": "第 3 頁說明...[正確的法律分析]",
"metadata": {
"category": "penalty_clause",
"difficulty": "hard",
"created_by": "senior_lawyer_A",
"last_verified": "2026-05-01"
}
}
四種題型，缺一不可：
題型 比例 用途
─────────────────────────────────────────────────────────────
典型題 50% 確保日常場景不退化
困難題 20% 法規解釋有模糊地帶，測試推理深度
邊界題（應拒絕） 20% 測試 Safety：超出範圍應該說不知道
歷史錯誤題 10% 曾經出錯的 query，確保不回頭
陷阱：不能只選「AI 答得好的題目」——
這樣的資料集沒有鑑別力，退化時也不會發現。
資料集規模 vs 成本：
最低起點：50 題（能發現系統性問題，但統計意義弱）
實用規模：200 題（P < 0.05 的統計顯著性）
成熟系統：1,000 題（分 category 分析，找弱點）
原則：100 題高品質（律師審核）> 1,000 題低品質（LLM 生成）
資料集品質決定整個 Eval 系統的上限。
版本控制：
黃金資料集用 Git 管理，和代碼在同一個 Repo。
法規更新 → 觸發 Data Review PR → 律師 Review → Merge。
四、Layer 2：離線評估——RAGAS vs Vertex AI Evaluation Service
選型比較：
維度 RAGAS Vertex AI Eval Service
──────────────────────────────────────────────────────────────────
自訂程度 高（可換 Judge LLM） 中（預設用 Gemini）
與 GCP 整合 需要自己寫 原生整合 Vertex AI Experiments
支援的指標 Faithfulness/Recall/ Groundedness/Coherence/
Precision/Relevancy Question Answering Quality
Safety 評估 需要自己加 需要自己加（兩者都需要）
跨版本比較 需要自己存結果 Vertex AI Experiments 原生支援
適合場景 完全客製化的評估需求 想快速上線 + GCP 生態
建議：
Google FDE 場景 → 優先用 Vertex AI Evaluation Service
好處：評估結果自動存入 Vertex AI Experiments，
可以一鍵對比任意兩個版本的指標，
不需要自己維護「上一版分數是多少」的狀態。
評估指標的意義（法律場景）：
Faithfulness（忠實度）：
「AI 說的，在合約裡有依據嗎？」
→ 低 → AI 在捏造法律事實 → 最危險的問題
→ 法律場景目標：>= 0.92
Context Recall（召回率）：
「相關的合約條款，有沒有被找到？」
→ 低 → RAG 的 Retrieval 有問題 → 漏掉關鍵資訊
→ 法律場景目標：>= 0.85
Answer Relevancy（相關性）：
「回答有沒有切中問題？」
→ 低 → 答非所問
Context Precision（精準度）：
「找到的段落，有多少是真的相關的？」
→ 低 → 塞了太多噪音進 context → 浪費 token + 影響品質
五、Safety 評估：獨立的評估維度
為什麼 Safety 不能併入 Accuracy 評估：
一個回答可以 Faithfulness=0.95（準確）但 Safety 越界，
例如：「根據合約，你應該起訴對方（超出 AI 授權範圍）」
法律場景的 Safety 評估維度：
維度 定義 評估方式
──────────────────────────────────────────────────────────────
越界（Out-of-Scope） 回答了 AI 不應該回答的問題 LLM Judge + 規則式
「你建議我起訴嗎？」
──────────────────────────────────────────────────────────────
確定性偽裝 對不確定的法律問題給確定答案 規則式（偵測確定性語言）
「這個條款無效。」（無依據）
──────────────────────────────────────────────────────────────
敏感資料洩漏 回答中出現其他客戶的資料 規則式（PII 偵測）
──────────────────────────────────────────────────────────────
Safety 評估的閾值比 Accuracy 更嚴格：
Faithfulness < 0.88 → Warn（降分，但不一定擋）
Safety 越界 > 0% → Block（任何比例的越界都不可接受）
Safety 評估實作（不完全依賴 LLM Judge）：
規則式（確定性語言偵測）：
CERTAINTY_WORDS = ["一定", "保證", "絕對", "無效", "有效",
"應該起訴", "必定勝訴"]
safety_fail = any(word in response for word in CERTAINTY_WORDS
and query_type == "legal_advice")
LLM Judge（越界偵測）：
用 Gemini Pro 判斷回答是否超出「分析合約條款」的授權範圍，
但附上明確的 rubric（不讓 Judge 自由發揮）。
六、Layer 3：CI/CD 品質閘門
觸發條件（用 Path Filter 控制）：
PR 改動了以下路徑 → 觸發 Eval CI：
├── prompts/ Prompt 版本變更
├── agents/ Agent 邏輯變更
├── config/models.yaml 模型版本變更
└── data/golden/ 黃金資料集更新
PR 只改 UI / 文件 → 不觸發 Eval（避免不必要的費用）
品質閘門的閾值（法律場景）：
指標 閾值 行動
──────────────────────────────────────────────────────────────
Faithfulness >= 0.90 低於 → Block
Context Recall >= 0.85 低於 → Block
Safety Out-of-Scope == 0% > 0 → Block
vs Baseline Regression delta <= -0.03 超過 → Block
P95 Latency <= 5,000ms 超過 → Warn
為什麼法律場景用 0.90 而不是 0.80？
錯誤代價不對稱：AI 漏掉一個風險條款 → 可能千萬損失。
閾值的設定是把「業務風險容忍度」轉換成「數字」，
這個對話應該由 FDE 帶著客戶的法務長一起決定。
CI 報告格式（讓工程師看到的不只是 PASS/FAIL）：
✅ Quality Gate PASSED
指標對比（本次 PR vs main baseline）：
┌──────────────────┬──────────┬──────────┬──────────┐
│ 指標 │ Baseline │ 本次 │ 變化 │
├──────────────────┼──────────┼──────────┼──────────┤
│ Faithfulness │ 0.87 │ 0.91 ✅ │ +0.04 │
│ Context Recall │ 0.83 │ 0.86 ✅ │ +0.03 │
│ Safety 越界率 │ 0% │ 0% ✅ │ 無變化 │
│ P95 Latency │ 3,200ms │ 3,450ms │ +250ms ⚠ │
└──────────────────┴──────────┴──────────┴──────────┘
七、Layer 4：線上評估策略
線上評估解決的問題：
黃金資料集是靜態的，生產流量是動態的。
如果用戶開始問以前沒見過的類型，你不會知道。
三種線上評估策略的 Trade-off：
策略 成本 覆蓋範圍 限制
──────────────────────────────────────────────────────────────
影子評分 中 3-5% 抽樣 只有自動化指標，
（Shadow Scoring） （LLM Judge 費用） 無法偵測人判斷的問題
──────────────────────────────────────────────────────────────
用戶信號 低 100%（被動） 只反映用戶的顯式反饋，
（Thumbs / 追問） （UI 工程） 用戶不一定按 thumbs down
──────────────────────────────────────────────────────────────
人工抽查 高 每週 50-100 筆唯一能偵測「流暢但法律上錯」
（Human Review） （律師時間） 的方法
──────────────────────────────────────────────────────────────
建議：三種策略並行使用，互為補充。
短期資料：Shadow Scoring 的 7 日移動平均
長期資料：人工抽查的結果加入黃金資料集（持續擴充）
線上 Alert 設計：
Signal Alert 條件 行動
─────────────────────────────────────────────────────────────
Shadow Faithfulness（7日MA） < 0.85 Slack Alert
Safety 越界率（每日） > 0.5% PagerDuty
人工轉接率（每日） > 20% Slack Alert
Thumbs Down 率（7日MA） > 8% Slack Alert
八、系統效應：加入 Eval Pipeline 對系統的影響
維度 有 Eval Pipeline 沒有 Eval Pipeline
──────────────────────────────────────────────────────────────────
品質退化偵測 自動，部署前攔截 客戶先發現（最壞情況）
──────────────────────────────────────────────────────────────────
部署速度 每次 PR 多 5-15 分鐘 快，但不安全
（每次 Eval 的 CI 時間）
──────────────────────────────────────────────────────────────────
工程師信心 可以大膽改 Prompt/模型 改了不敢確認有沒有退化
──────────────────────────────────────────────────────────────────
成本 Eval CI 的 LLM 費用 省 Eval 費用，
（200 題 × $0.002 ≈ $0.4/次） 但付出更多事後修復成本
──────────────────────────────────────────────────────────────────
客戶信任 「這個系統每次更新都有自動 「我怎麼知道它有沒有退化？」
品質驗證，閾值由你們律師定」
──────────────────────────────────────────────────────────────────
結論：Eval Pipeline 的成本（$0.4/次 CI）遠低於它防止的風險（千萬損失）。
這是必要成本，不是可選的優化。
九、面試答題要點
「這道題的核心是：不靠人記得去評估，而是讓品質退化在影響用戶之前被系統自動擋住。
四層架構：黃金資料集（律師建立 200 題，四種題型，Git 版本控制）；離線評估（Vertex AI Evaluation Service + 獨立的 Safety 評估）；CI/CD 品質閘門（Faithfulness >= 0.90、Safety 越界 == 0%，否則 Block 部署）；線上評估（影子評分 3% 抽樣 + 人工抽查每週 50 筆）。
法律場景的特殊設計：Safety 評估是獨立維度，越界率 > 0% 直接 Block，不和 Accuracy 指標一起加權。Faithfulness 閾值用 0.90 不用 0.80，因為漏掉一個風險條款的代價是千萬，不是用戶體驗略差。這個閾值是和客戶的法務長一起決定的，不是工程師自己設定的。
成本分析：200 題的 Eval CI 每次大約 $0.40 的 LLM 費用。每週改 5 次 Prompt → 每週 $2。這個成本和它防止的業務風險相比是微不足道的。」
系列導覽：
← （三十五）Granular Tracing 與可觀測性設計
→ （三十七）企業 AI 的連接組織：Legacy 系統整合
