EN
03 / 07第 6 章：RAG 系統的評估與改進 · 3 分鐘 · 2026-10-05

6.3 組件級別評估：生成

檢索找對了，模型有沒有照著資料回答、回答得切不切題。

RAG下一篇 →

假設檢索沒有問題，資料都找對了。接下來要問的是：模型有沒有把答案寫好？ 這一步的評估比檢索難，因為輸出是自由的文字。

要看哪些面向

面向 問的問題
忠實度（faithfulness，也叫 groundedness） 答案裡的每個說法，都有資料支撐嗎？有沒有編造？
答案相關性（answer relevance） 答案有回答到使用者問的問題嗎？有沒有離題、答非所問？
正確性（correctness） 和標準答案相比，資訊對不對？
完整性（completeness） 該講的重點有沒有漏掉？
來源標註（citation accuracy） 標的編號存在嗎？內容真的能支撐那句話嗎？
拒答的正確性 資料裡沒有答案時，有沒有誠實說沒有？反過來，有答案時有沒有誤拒答？

其中最重要的是忠實度，因為它直接對應 RAG 要解決的幻覺問題。

評估的方法

1. 人工評分

請人看「問題、資料、答案」，依標準打分數。最可靠，但最貴、最慢，也不能反覆執行。

比較實際的做法：抽樣。例如每次改版隨機抽 20 題，請人看，作為評估的基準，也用來檢驗自動方法準不準。

2. 程式規則檢查

有些項目可以用程式直接檢查，快又便宜：

  • 引用的編號是否存在（4.6 的 check_citations）。
  • 資料裡沒有答案的測試題，答案是不是包含「資料中沒有提到」。
  • 輸出格式是否符合要求（JSON 能不能解析）。
  • 答案裡的數字，是否出現在提供的資料中。

這類檢查範圍有限，但很適合放進每次的自動測試。

3. 和標準答案比對

如果有參考答案，可以用文字相似度（例如 ROUGE、BLEU）或嵌入向量的相似度來比較。

但要小心：同樣的意思有很多種寫法，文字重疊度低不代表答案錯。這類方法對自由文字的可靠性有限，通常只當輔助參考。

4. 用 LLM 當裁判（LLM-as-a-judge）

請另一個 LLM，根據明確的評分標準，判斷答案好不好。可以大量、自動、重複執行，是目前很常用的做法。

評分提示詞的大概樣子：

你是一個嚴格的評審。下面有「參考資料」和「答案」。
請判斷答案裡的每一個說法，是否都能從參考資料找到依據。

# 參考資料
{context}

# 答案
{answer}

請依下面格式輸出：
- 逐句列出答案中的說法，標註「有依據」或「沒有依據」，並簡短說明理由
- 最後給一個 1 到 5 的分數（5 = 全部有依據）

（這是示意用的提示詞，我沒有實際跑過。）

LLM 裁判的問題要知道：

  • 有偏見：有的傾向偏好比較長的答案，有的偏好排在前面的選項，也可能偏好自己家模型寫的文字。
  • 不穩定：同樣的輸入，分數可能不一樣。
  • 可能判錯：特別是需要專業知識的內容。

所以要用人工評分去校準：抽一批題目，同時請人和 LLM 打分，比對一致程度。一致程度夠高，才適合大量使用。

工具

有一些工具把這些評估包裝好，例如 RAGAS（提供忠實度 faithfulness、答案相關性 answer relevancy、context precision、context recall 等指標）、TruLens、DeepEval 等。它們的指標名稱和介面常常改版，使用前請看最新的官方文件。

用這些工具，也要懂指標背後在量什麼，否則只是看一堆不知道意義的數字。

檢索和生成要分開看

一個實用的診斷方式：

檢索結果 生成結果 結論
正確資料有找到 答案正確 正常
正確資料有找到 答案錯誤 生成的問題：提示詞、模型
正確資料沒找到 答案錯誤 檢索的問題：先修檢索
正確資料沒找到 答案正確 可能是模型靠自己的記憶蒙對的，要特別小心，這代表它沒有真的在用資料

最後一種很值得注意：答案對，不一定是 RAG 的功勞。

拒答的評估

一個好的 RAG 系統，在資料裡沒有答案時，應該說不知道。要評估這件事，測試集要包含一批沒有答案的問題，看系統有沒有：

  • 誠實拒答：說「資料中沒有提到」。
  • 亂編：硬寫一個答案。這是嚴重問題。

另一方面也要檢查過度拒答：資料裡明明有答案，卻說沒有。這常常是因為提示詞太嚴，或是檢索的門檻設得太緊。這兩種錯誤要一起看，不能只追求其中一邊。

← 全部文章