對應原題（Common ‧ Evaluation and Observability）
- Design the regression gate that decides whether a prompt or model change ships. — Asked at: Anthropic
- Design online evaluation: what do you log, what do you sample, and what do you A/B? — Asked at: Perplexity
- How do you manage prompt versioning and rollbacks in production?
🎯 什麼情境該想到我
當你「改了 prompt，不知道該不該上線」的時候。
★ 核心主張：prompt 改動必須被當成程式碼改動對待——版本控制、code review、CI gate、可回退。
把 prompt 當成「隨時可以在後台改一改的設定」，是 LLM 產品事故最大的來源。
⚙️ Part 1：上線閘門（Regression Gate）
五層閘門（由快到慢、由便宜到貴）
| 層 | 檢查什麼 | 耗時 | 何時跑 |
|---|---|---|---|
| 1. 靜態檢查 | prompt 模板的變數都有綁定、必要區段存在、token 數在預算內、無硬編碼密鑰 | 秒 | 每次 commit |
| 2. 斷言測試 | 可程式驗證的性質：格式合法、該拒答有拒答、無 PII 洩漏、引用 span 有效 | 秒–分 | 每次 commit |
| 3. 回歸集評估 | 固定 100–300 題的核心指標 | 分 | 每次 PR |
| 4. Pairwise 對照 | 舊版 vs 新版，裁判做 A/B（見 LLM-as-Judge） | 分–時 | 合併前 |
| 5. 金絲雀 / 線上 A/B | 真實流量 | 時–天 | 發布時 |
第 1、2 層應該像 lint 一樣快、一樣自動。 大多數團隊直接跳到第 3 層，結果 CI 太慢就沒人跑。
★ 通過條件怎麼定（關鍵設計）
絕對不能只看「平均分數有沒有變高」。 要分三類指標：
| 類別 | 例子 | 通過條件 |
|---|---|---|
| ① 硬性護欄（不得退步） | 安全拒答率、PII 洩漏、格式合法率、引用有效性、contradiction rate | ★ 任何退步都擋，不看統計顯著性 |
| ② 目標指標 | 答案正確率、groundedness、使用者任務完成率 | 改善要有統計顯著性 |
| ③ 成本與延遲 | p95 TTFT、每請求 token 數、每請求成本 | 不得超過預算 X% |
★ 兩個最容易做錯的地方
1. 被雜訊騙
同一個 prompt 跑兩次，分數就會不同（見 取樣與解碼策略：
temperature=0也不保證可重現）。→ 每個版本要跑多次（3–5 次）取平均，並算信賴區間。
「新版 82.3% vs 舊版 81.7%」很可能只是雜訊。沒有信賴區間的 gate 會讓你不斷部署隨機漫步。
2. ★ 只看總體，掩蓋子群崩壞
總體 +2%，但「中文查詢」-15%、「長文件」-20%——總體分數會蓋住它。
→ Gate 必須分子群評估：每個查詢類型、每個語言、每個資料源、每個使用者層級。
任一子群顯著退步就要人工判斷，不能自動放行。
Gate 的輸出要可讀
不要只給一個分數。要列出哪些案例從對變錯（逐案 diff）。
「這 7 個案例退步了」比「分數 -0.4%」有用一百倍——前者能直接除錯，後者只能猜。
⚙️ Part 2：Prompt 版本管理與回退
Prompt 存哪裡
| 程式碼庫 | 外部 prompt 平台 | |
|---|---|---|
| 可 review / diff | ✅ | ⚠️ |
| 與程式碼版本綁定 | ✅ | ❌ |
| 可走 CI gate | ✅ | ⚠️ |
| 熱更新 | ❌ 要部署 | ✅ |
事故時能 git revert | ✅ | ⚠️ |
★ 建議：程式碼庫是真相來源。
需要熱更新時，用 feature flag 切換「哪個已提交的版本生效」，
而不是讓人直接在後台編輯 prompt 文字。
兩者的差別是：前者所有可能生效的內容都經過 review 與 gate，後者沒有。
一個「版本」是什麼
★ prompt、模型、參數、工具 schema 是一組，不能分開版控：
version: v2026.09.20-3
prompt_hash: sha256:a3f1...
model: claude-sonnet-5
params: {temperature: 0.2, top_p: 0.9, max_tokens: 2048}
tools_schema: sha256:9c2e... # ★ 改工具定義也會改變行為
retrieval_cfg: {top_k: 50, reranker: bge-v2}
eval_results: {...} # 這個版本通過 gate 時的分數回退必須整組回退。 只回退 prompt 而留著新模型，是一個沒有被測試過的組合。
★ 每個線上回應都要記錄它用的是哪個版本
沒有這一欄，事故時無法回答「壞掉的那些請求是哪個版本產生的」——整個歸因鏈斷掉。
⚙️ Part 3：線上評估
★ 前提：離線分數好，線上未必好
常見原因（見 Benchmark 污染與分數失真）：真實查詢分布與評估集不同、真實輸入更髒、使用者行為與評估假設不同、長尾佔比被低估。
記什麼（Log）
| 類別 | 內容 |
|---|---|
| 請求層 | trace_id、使用者/租戶（雜湊）、版本、時間 |
| 內容 | 完整輸入、輸出、system prompt 的 hash |
| 檢索 | 命中的 doc ID + 版本 + 分數 + 是否命中快取 |
| 工具 | 每次呼叫的名稱、參數、回傳、耗時、成敗 |
| 效能 | TTFT、TPOT、總延遲、排隊時間（見 Prefill 與 Decode） |
| 成本 | input / output / cache-read / cache-write token 數 |
| ★ 隱式回饋 | 追問、複製、重新提問、放棄、停留時間、有沒有捲到底 |
| 顯式回饋 | 讚/倒讚、回報、編輯後採用 |
抽樣什麼（Sample）
全量記 metadata（便宜），抽樣記完整內容（貴）。
| 抽樣策略 | 用途 |
|---|---|
| 隨機抽樣（如 1%） | ★ 無偏的基準，用來估算整體品質 |
| ★ 分層過取樣 | 負回饋、低信心、高價值使用者、新版本、異常延遲、觸發護欄 這些要大比例抽 |
| 全量記錄的例外 | 安全事件、工具執行失敗、contradiction 告警 —— 100% 留存 |
★ 只做分層過取樣而沒有隨機基準，會讓你的品質估計嚴重偏悲觀（因為你只看了壞的）。兩者都要。
A/B 什麼
| 指標類型 | 例子 |
|---|---|
| ★ 主要指標＝使用者行為 | 任務完成率、追問率（越低越好）、複製率、留存、轉換 |
| 代理指標 | groundedness、裁判勝率 —— 快，但不是真相 |
| ★ 護欄指標 | p95 延遲、每請求成本、錯誤率、安全事件數、拒答率 —— 任一惡化就停 |
三個實驗設計要點：
- ★ 分流單位是「使用者」不是「請求」 —— 同一個人在兩版之間跳，體驗不一致、指標也被污染
- 要跑夠久 —— 至少一個完整週期（週內效應），並避開新奇效應
- 同時跑多個實驗要注意互動 —— prompt 改動與檢索改動同時上，結果無法歸因
⚠️ Part 4：注意 / 什麼時候不適用
- ★ Gate 太嚴會讓人繞過它。如果每個小改動都要跑 2 小時的評估，團隊會開始「直接在後台改」。分層設計就是為了讓快的路徑真的快。
- Gate 太鬆等於沒有。至少硬性護欄那一組不能妥協。
- 評估集會被過擬合。調 prompt 調久了就是在對著回歸集調——要有不用來調參的 holdout（見 沒有標註時怎麼建評估集）。
- 裁判換版本，歷史分數作廢。裁判模型升級要重跑一次基準線。
- ★ 日誌是 PII 的匯聚點。完整輸入輸出含使用者資料，保存期限、存取控制、去識別化都要設計（見 PII、紅隊與公平性稽核）。
- A/B 需要足夠流量。小產品可能永遠跑不出顯著性——那就靠人工複核與逐案檢視，不要假裝有統計結論。
- 不要在事故中做 A/B。線上出問題就直接回退，事後再分析。
🧪 我實際套用的紀錄
- 2026-09-20：從面試題庫展開。待辦：把 prompt 移進程式碼庫，並加上第 1、2 層的秒級 gate。
🔗 相關
- 沒有標註時怎麼建評估集 —— gate 所需的回歸集
- LLM-as-Judge —— 第 4 層的實作與偏誤
- 幻覺偵測 —— 硬性護欄的指標
- Benchmark 污染與分數失真 —— 為什麼離線好線上壞
- LLM 可觀測性 —— log 的基礎設施
- Agent 評估 —— agent 的 gate 更複雜
- 工具-AI改動的AB對照評測、工具-部署管線與持續交付 —— 決策層
- 工具-agent的測試金字塔 —— agent 專屬的補充：軌跡比對、依評估器類型設門檻、題數與標準誤、CI 裡的非同步等待