RAG約 1 分鐘
只看答案準確率，看不出 RAG 哪裡壞掉
精確名稱找不到、租戶資料混掉、證據不足還硬答。這三種失敗要分開量，才知道該修哪一段。
Contents
問題
一個準確率數字，把三種失敗混在一起：對的段落根本沒被索引、索引了但沒被撈到、撈到了但生成時被忽略。
做民宿客服時，最常見的其實是第二種：房型名稱、政策名稱這種專有名詞，只靠向量搜尋不一定抓得準。
設計目標
每一段各有自己的指標，回歸時能指出是哪一段壞掉。
指標
階段 | 指標 | 回答的問題 |
|---|---|---|
檢索 | recall@k | 證據有沒有在前 k 筆裡？ |
上下文 | context precision | 拿到的上下文有多少是有用的？ |
生成 | faithfulness | 回答有沒有守住上下文？ |
混合檢索補的是哪一段
向量搜尋對語意好，對精確字詞弱。BM25 相反。兩邊各取前 N，用 Weighted RRF 合併。這不是讓流程看起來更複雜，而是補 recall@k 在專有名詞上的洞。
使用者問題 ──▶ Query Rewrite ──┬──▶ Vector Search ──┐
└──▶ BM25 ───────────┴──▶ Weighted RRF ──▶ Grounded Context沒有證據時的行為也要量
檢索結果不足時，系統應該轉人工，而不是生成一段看似確定的文字。這件事也可以量：「證據不足卻回答了」的比例，比準確率更能反映客服的風險。
心得
- Chunk 大小對 recall 的影響，比換 Embedding 模型還大。先量檢索，再調生成。
- 租戶混掉是另一類失敗，指標抓不到，要靠 Tenant Context 沿路由傳到底來防。