RAG 評估要分層：先定位錯誤，再決定換哪一段

單一「答案準確率」無法告訴你該修哪裡

回答不正確，可能是文件沒有進索引、相關段落沒有被找回、上下文組裝錯誤，或模型沒有依據證據回答。若只看最後一個分數，換 Embedding、改 chunk 或調 Prompt 都像是在猜。

先把評估問題寫成可追查的案例，而不是只收集一批「看起來合理」的問句。

建立可重跑的案例集

每一筆至少記錄：

測試用 tenant 與資料集版本。
使用者問題與問題類型，例如精確名稱、同義改寫、跨段落問題或不可回答問題。
預期相關文件／段落，或明確標記「現有資料不足」。
回答必須包含的事實、不可臆測的部分，以及預期行為（回答、澄清或轉人工）。

案例集要保留實際失敗的查詢，也要涵蓋高風險的 tenant 隔離；修改索引或提示後，重跑同一版本，才有可比較的基準。租戶隔離是安全性不變條件，不應被平均檢索分數掩蓋。

分層指標與診斷

層次	檢查方式	失敗通常要先查什麼
索引	預期文件是否成功解析、切分並存在於正確 tenant 的索引	匯入失敗、解析／OCR、metadata 與 tenant 標記
檢索	Recall@k：已標註的相關證據是否出現在前 k 筆	查詢改寫、精確詞、過濾條件、向量或詞彙檢索設定
上下文	Context precision：送進生成的段落中，相關段落所占比例；另核對必要證據是否完整	排序、去重、截斷、上下文長度與組裝順序
回答	逐項核對關鍵事實與引用；檢查無證據時是否拒答或轉接	指令遵循、引用對應、答案門檻與 fallback

這些指標不是彼此替代：Recall@k 高不代表答案正確；Faithfulness 高也可能只是忠實重述了不完整的上下文。不可回答題還要另外檢查「該拒答卻回答」與「明明有證據卻轉接」兩種錯誤。

混合檢索是一個待驗證的假設

向量檢索與 BM25 / 全文檢索可能各自補足不同失敗類型。要判斷融合是否值得，應在同一批標註案例、相同 tenant filter 與候選數下分別執行 Vector Search、BM25 與 Fusion，再依精確名稱、政策關鍵字及語意改寫等類別比較 Recall@k、Context precision、延遲與錯誤案例。

融合可能提高證據覆蓋，也可能引入更多雜訊、增加延遲，或因 tenant filter 實作不一致造成資料隔離問題。只有當分層結果顯示改善了目標失敗類型，且沒有讓其他重要指標退化，才有理由保留它。

用 trace 把分數連回單一失敗案例

每次評估至少保留 query、tenant、查詢改寫結果、候選文件與排序、實際送入模型的上下文、回答與引用，以及 pipeline 版本。遇到失敗時沿著一筆 trace 往回看：證據不在索引、檢索沒撈到、排序或截斷丟掉證據，還是生成沒有使用證據？定位後一次只調整一個主要變因，再跑完整回歸集。

不用沒有數據支撐的調參結論

Chunk 大小、重疊量、Embedding、查詢改寫與融合權重都可能影響結果，影響方向也會隨文件型態與查詢分布改變。沒有固定案例集、基線和可重跑結果前，不能說「chunk 一定比換模型重要」或宣稱混合檢索已提升準確率。

本文整理的是可操作的評估方法，不是該民宿客服系統的 benchmark 報告；目前沒有在這裡呈現量化結果，因此不對準確率或召回率作數字宣稱。