6.4 端到端 RAG 評估框架

分開量檢索與生成有助於找原因，但使用者接觸到的是整套系統。端到端評估要把兩邊接起來，而且流程必須可以重複執行，否則每次改版都只能憑印象比較。

RAG 三角

一個常見的整理方式，叫做 RAG 三角（RAG triad），是 TruLens 這個工具提出的概念。它把 RAG 裡的三樣東西——問題、檢索到的資料、答案——兩兩之間的關係，各自檢查一次：

關係	問的問題	對應
① 問題 ↔ 資料	檢索到的資料和問題相關嗎？	檢索品質（6.2）
② 資料 ↔ 答案	答案有根據資料嗎？有沒有亂編？	忠實度（6.3）
③ 問題 ↔ 答案	答案有回答到問題嗎？	答案相關性（6.3）

三個都好，系統才算好。哪一邊低，就知道問題在哪裡：

• ① 低：檢索有問題，回去看第 2、3 章。
• ② 低：模型沒照資料回答，檢查提示詞（第 4 章）。
• ③ 低：答非所問，可能是檢索偏題，或是提示詞沒有講清楚。

評估的流程

一個基本的端到端評估，步驟是：

1. 準備測試集：問題，加上正確資料所在位置、參考答案（6.1）。
2. 跑系統：對每個問題，執行完整的流程，記錄檢索到的資料、提示詞、答案。
3. 計算指標：
   • 檢索：Hit@k、MRR。
   • 生成：忠實度、相關性、引用檢查、拒答。
4. 看結果：不只看平均，還要看哪些題目錯了，分析原因。
5. 改進：針對問題改動一個地方。
6. 重跑：同一份測試集再跑一次，比較前後。

這個流程要能用一個指令重複執行，才不會因為麻煩就不做了。

需要記錄什麼

每一次評估，建議存下：

項目	為什麼
系統設定（嵌入模型、分塊大小、k、門檻、提示詞版本、模型版本）	之後才知道這個分數是哪個設定得到的
每題的檢索結果（含排名和分數）	分析檢索錯在哪
送給模型的完整提示詞	分析生成錯在哪
模型的答案	比對和打分
各項指標	比較
延遲和 token 用量	看速度和成本

不只是準確度

端到端評估還要看這些：

• 延遲：從提問到收到答案要多久？使用者等得了嗎？
• 成本：每次問答花多少錢？提示詞越長、模型越大，成本越高。
• 穩定性：同一個問題多問幾次，答案一致嗎？
• 安全與權限：有沒有把使用者不該看到的資料找出來？有沒有被提示詞注入攻擊騙到？

避免改壞

每次改動一個地方（例如換了嵌入模型），可能讓某些題目變好，同時讓另一些題目變差。所以：

• 每次都跑完整的測試集，不是只看你想改的那幾題。
• 保留歷史結果，才能比較。
• 這種「改完確認沒有壞掉別的東西」的測試，叫做回歸測試（regression test）。

上線之後

真實使用者的問題，會和你預想的不一樣。上線之後可以：

• 記錄真實的提問，定期抽樣檢查。
• 收集回饋：「這個答案有幫助嗎？」的按鈕。
• 把失敗的案例加進測試集，讓測試集越來越貼近真實。
• 定期重新評估：資料更新了、模型換版了，結果可能就變了。

從小開始

評估不需要一開始就很完整。一個可行的起點：

1. 先整理 20 到 50 題真實的問題，標好正確資料的位置。
2. 寫一個腳本，算 Hit@k 和 MRR。
3. 再慢慢加入生成的檢查。

有一個簡單、每次都會跑的評估，比一個複雜但從來沒跑過的評估有用得多。