總覽：怎麼知道 RAG 有沒有變好？
換了切塊、Top-k、prompt 之後，若沒有可重複的評測，就只是在賭運氣——本篇專講評估面，不重複 pipeline 與切塊細節。
在 RAG 架構綜合手冊 與 Chunking 與檢索策略 裡，我們把「怎麼建、怎麼撈」講清楚了。下一步後端最容易忽略的是：怎麼證明這次改動真的變好。感覺答案比較順、偶發 demo 過關，都不足以當上線依據——你需要把品質拆成檢索面與生成面，再用離線評測集與線上觀測閉環。
評估不是另一套產品，而是掛在 pipeline 旁的量測層：離線用標註集驗證「改動方向」，線上用回饋與抽樣盯「真實分布」。本篇與切塊／hybrid 篇互補——那些調旋鈕，這裡告訴你旋鈕轉完有沒有變好。
| 量測面 | 回答的問題 | 主要指標 | 壞掉時的徵狀 |
|---|---|---|---|
| 檢索面 | 該進 Context 的證據有沒有被撈到、排得夠不夠前 | Recall@k、Precision@k、MRR／nDCG@k | 引用空或引用一堆卻答偏 |
| 生成面 | 答案有沒有忠於證據、有沒有回答到問題 | Faithfulness、Answer Relevance | 證據齊全卻加油添醋，或正確但答非所問 |
| 離線評測 | 這次改動的方向對不對（可重複、可比較） | 固定 golden set 上的前兩列指標 | 分數上升但線上沒感覺 |
| 線上觀測 | 真實分布下實際發生了什麼 | 引用點擊、負回饋率、拒答率、抽樣人工複核 | Golden set 過關卻上線翻車 |
四列由上到下是「量測什麼」到「在哪裡量」：前兩列切開品質的兩個面，後兩列切開量測的兩個場域——四格都要有人負責，缺一格就會出現「分數好看但使用者不買單」。
檢索面：召回率與 Precision
先回答「該進 Context 的證據有沒有被撈到」——生成再漂亮，缺金標 chunk 也救不回。
檢索評估假設你有一組查詢與金標相關文件／chunk（可人工標，或從已驗證引用反推）。常用指標都建立在「Top-k 命中集合」上：
同一個查詢撈回 10 筆候選（已依分數排序）。點任一格可把它標成／取消金標（★）；再用下面三個旋鈕改 k、改「完全沒進 Top-10 的金標數」、改 rerank 強度。四個指標與它們的分子分母即時重算。
排名尺：左到右是 rank 1…10，藍色右邊界就是 Top-k 的切線，切線右邊的候選不進 Context。rerank 只會讓 ★ 往左移，不會憑空生出金標——所以它救得了排序指標，救不了召回。
每根柱是該名次的折扣權重 1/log2(i+1)：rank 1 拿滿 1.000、rank 2 只剩 0.631、rank 10 只剩 0.289。填色的柱才真的有金標、才計入 DCG——這就是「排越前面越值錢」的量化樣子。
把 k 拉到 50，Recall 幾乎總能上升，但 Prompt 塞滿弱相關噪音，生成忠實度與延遲一起變差。實務應同時報 Precision@k（或命中後的「可用 Context 比例」），並固定評測用的 k 與過濾條件。
| 情境 | 檢索訊號 | 常見根因 |
|---|---|---|
| 答案錯但引用空 | Recall 低 | 切塊邊界、embedding、metadata 過濾過嚴 |
| 引用一堆卻答偏 | Precision 低／排序差 | 缺 rerank、多主題塊稀釋、查詢改寫弱 |
| 金標在 Top-10 但不在 Top-3 | Recall@10 高、MRR 低 | 候選池夠，排序／rerank 不足 |
先用檢索指標定位「撈沒撈到」，再決定要不要動切塊、hybrid 或 rerank——不要一開始就怪 LLM。
生成面：忠實度、幻覺與答案相關性
Context 對了，答案仍可能「加油添醋」或答非所問——生成面量的是「有沒有忠於證據」與「有沒有回答問題」。
- 答案中的可驗證主張，是否都能被檢索到的 Context 支持。
- 低忠實度 ≈ 幻覺／捏造數字、期限、例外條款。
- 可用人工勾選，或 LLM-as-judge 逐句對照 Context。本篇文末的互動 demo 會把這個逐句拆解程序完整跑一遍。
- 答案是否針對使用者問題，而非堆砌相關但無用的段落。
- 高忠實、低相關：正確複述了別的主題。
- 常與「拒答／不足以回答」策略一起設計。
檢索 Recall 高 + 生成忠實度低 → 多半是 prompt／模型／拒答策略問題。檢索 Recall 低 + 答案卻「很完整」→ 高度可疑的無據生成。面試時用這張診斷矩陣，比背指標名字更有說服力。
離線評測 vs 線上觀測
離線告訴你「這次 diff 方向對不對」；線上告訴你「真實流量下還站不站得住」——缺一不可。
- 固定問題集＋金標 chunk／參考答案／評分 rubric。
- 每次改切塊、embedding、prompt 先跑回歸，擋明顯回退。
- 可重複、可 CI；但分布可能過時、長尾覆蓋不足。
- 使用者回饋（👍／👎）、重問率、人工抽樣複核。
- 延遲、空檢索率、拒答率、權限過濾命中等系統指標。
- 反映真實分布；噪音大、標註成本高、要控隱私與偏差。
閉環：線上翻車案例定期回填離線集，避免「離線全綠、線上長尾全滅」。
| 維度 | 離線 | 線上 |
|---|---|---|
| 目的 | 驗證改動、回歸防護 | 監視真實品質與漂移 |
| 標註 | 高品質、可複用 | 稀疏、有選擇偏差 |
| 風險 | 過擬合金標集 | 噪音、延遲發現問題 |
| 最低配備 | 50–200 題含邊界案例 | 抽樣複核 + 👎 工單 |
LLM-as-Judge：用法與陷阱
用強模型當評審，能把 Faithfulness／Relevance 規模化——但評審本身也有偏差，必須當「加速器」而非唯一真相。
典型用法：把「問題 + Context + 答案」餵給評審模型，要求依 rubric 打分（例如忠實度 1–5、是否有無據主張）。適合大量回歸與粗篩；關鍵發布仍應抽樣人工複核。
| 作法 | 優點 | 陷阱 |
|---|---|---|
| 逐句對照 Context | 忠實度可解釋 | 漏給關鍵 Context → 誤判幻覺 |
| 與參考答案比對 | 實作簡單 | 開放域一題多解，字面不一致≠錯 |
| 單一分數 | 好排序、好畫趨勢 | 掩蓋「檢索差 vs 生成差」 |
| 與被評模型同家族 | 成本低、風格接近 | 自我偏好／長度偏差（喜歡長答案） |
（1）固定 rubric 與輸出 JSON schema，避免散文式評語無法聚合；（2）定期用人工標註集測 Judge 與人的一致率；（3）分軸打分（檢索相關／忠實／答案相關），不要只留一個「整體分」；（4）對安全與合規題，人工優先於自動分數。
互動 · 把一個答案拆成 claims 對照 Context
Faithfulness 不是一個感覺分數，而是一套可以手算的程序：切 claims → 逐一比對 Context → 過門檻的算被支撐 → 相除。這裡把四層全攤開。
第一層：答案依切分規則被切成幾個 claim。切得越細，分母越大、同一段答案的分數就越嚴——所以「Faithfulness = 0.75」這種數字，離開切分規則是沒有意義的。
第二層：每一格是支撐度＝該 claim 的 gram 有多少比例出現在該 context（containment，對應忠實度那一節寫的 CLAIM ⊆ CONTEXT——方向不對稱，問的是「claim 被蓋住了嗎」），綠框代表過了門檻。把門檻從 0.50 降到 0.35 試試：「電子票券也可以退」對上「電子票券與客製化商品不適用本退貨條款」會翻成「被支撐」，分數衝到 1.000——但語意完全相反。字面公式讀不出否定，這正是忠實度最後需要 LLM-as-Judge 或人工複核的原因，也是本篇談 Judge 那一節要處理的難題。
面試折衷與實務清單
能畫出「檢索×生成」診斷矩陣，並說清離線／線上閉環，就比只報一個滿意度分數更像有生產經驗。
| 決策點 | 一端做法 | 另一端做法 | 留意 |
|---|---|---|---|
| 優化目標 | 拉高 Recall@k | 顧 Precision／Context 品質 | 兩者要一起報，固定 k |
| 評分方式 | 人工精標 | LLM-as-judge 粗評 | Judge 要測人機一致率 |
| 發佈門檻 | 只看離線金標 | 只看線上 👍 率 | 雙軌＋回填，避免過擬合 |
| 除錯順序 | 先怪模型 | 先看命中 chunk | 無引用／低 Recall 先修檢索 |
（1）含「邊界切斷／例外條款／無權限文件」的回歸題；（2）每題金標 chunk id，而不只參考答案散文；（3）分軸分數：Recall@k、Precision@k、Faithfulness、Answer Relevance；（4）線上 👎 與空檢索率儀表，並有回填金標的節奏。有這四樣，調切塊或 hybrid 才有科學依據。