前言

我們都知道LLM會有幻覺現象，RAG的其中一作用就是要避免LLM胡說八道。但你怎麼知道你的RAG真的沒有在胡說八道呢?因此就像所有AI模型一樣，評估指標 是不可或缺的一步。
RAG在回答使用者問題時，同時包含了 檢索（Retrieval） 與 生成（Generation） 兩個功能，因此需要針對兩個面向分別進行測試，確保系統能檢索到相關資訊，並生成正確、可信的答案，下面我們就來仔細了解一下各項指標吧!

🔎 檢索（Retrieval）評估指標

檢索階段的目標是找到最相關的文件，並提供給生成模型。常見的指標如下：

1. Precision@k

• 公式：

• 解釋： 衡量前 k 個檢索結果中，有多少比例是相關文件。
• 使用情境： 適合強調「使用者最先看到的結果是否正確」。

2. Recall@k

• 公式：
  
• 解釋： 衡量前 k 個檢索結果，覆蓋了多少比例的相關文件。
• 使用情境： 側重檢查系統是否「漏掉重要資訊」。

3. Mean Reciprocal Rank (MRR)

• 公式：
  
  其中 (rank_i) 為第 i 個查詢的第一個正確答案出現的排名。
• 解釋： 觀察正確答案出現在前幾名，排名越前，分數越高。
• 使用情境： 適合希望正確答案盡早出現在檢索結果的任務。

4. nDCG（Normalized Discounted Cumulative Gain）

• 公式：
  
  其中 (rel_i) 表示文件的相關性標籤，IDCG 是理想排序下的 DCG。
• 解釋： 同時考慮相關性與排序位置，越相關且排名越前的文件貢獻越大。
• 使用情境： 適合需要多級相關性評估的檢索（例如：高度相關、中度相關、無關）。

✍️ 生成（Generation）評估指標

在生成階段，LLM 根據檢索內容回覆答案。這部分需要衡量生成結果是否正確、相關且流暢。

1. Faithfulness（忠實度）

• 定義： 測量生成的答案是否忠實於檢索到的文件，避免幻覺（hallucination）。
• 方法： 可透過 Ragas 或 LLM-based 評估器，檢查答案是否基於檢索來源。

2. Correctness（正確性）

• 定義： 衡量生成的答案是否事實正確，與黃金標準答案一致。
• 常用指標：
  • F1 Score：同時考慮 precision 與 recall。
  • Exact Match (EM)：完全符合標準答案。

3. Relevance（相關性）

• 定義： 測量生成答案是否與查詢需求相關。
• 方法：
  • 人工標註（人工判斷相關程度）。
  • 自動化指標（例如 Ragas 的 Answer Relevancy）。

4. Semantic Similarity（語義相似度）

• 定義： 衡量生成答案與標準答案在語義上的接近程度。
• 常用方法：
  • Cosine Similarity：將答案轉為 embedding，計算向量相似度。
  • BERTScore：基於 Transformer 的語意相似度評估。

5. 文本品質（Fluency & Readability）

• 定義： 檢查生成文本是否自然、流暢、易讀。
• 常用指標：
  • ROUGE：常用於摘要任務。
  • BLEU：常用於翻譯任務。
  • Perplexity：衡量模型生成文本的可預測性。

🔧 補充: Ragas 評估框架

Ragas 是一個專門為 RAG 系統設計的開源評估工具。
它能夠基於「問題、生成答案、檢索上下文」來自動化計算多種指標，包括：

• Faithfulness（忠實度）：答案是否來自檢索到的上下文。
• Answer Relevancy（相關性）：答案是否回答了使用者的問題。
• Semantic Similarity（語義相似度）：答案是否在語義上接近黃金答案。

使用 Ragas 可以快速建立一個 自動化測試流程，避免完全依賴人工評估，也適合持續追蹤系統效能。

🛠️ 最佳實踐（Best Practices）

在進行 RAG 系統評估時，除了建立指標外，搭配一套完整的流程來確保結果可靠也是非常重要的。參考一些資料後，整理以下是幾個Best Practices做參考：

1. 建立測試框架

   • 使用像 Ragas 這類的工具，建立一個可重複、自動化的測試流程。
   • 在每次系統迭代後自動執行，確保效能變化能被追蹤。

2. 黃金參考資料集 (Golden Reference Dataset)

   • 收集一組已知正確的「問題-答案對」來做為基準。(非常重要)
   • 在檢索與生成階段分別驗證，提升評估的精確性。

3. 一次只改變一個變數

   • 當測試不同的Chunking size、embedding model或檢索演算法時，務必一個一個調整一個一個驗證，不要一次條好幾個地方。
   • 這樣能確保指標變化的原因明確可解釋，也才知道是為何影響。

4. 合成數據 (Synthetic Data)

   • 當缺乏真實使用者查詢時，可以透過 LLM 自動生成測試問題與對應答案。(這邊其實很需要仔細檢查，LLM產出的pair還是有錯誤的風險)
   • 特別適合在專案早期快速驗證檢索與生成效果。

5. 根因分析 (Root Cause Analysis)

   • 當系統結果不佳時，分開檢驗 檢索 與 生成 的表現。
   • 例如：檢索結果相關但生成答案錯誤 → 問題在生成；檢索不到相關內容 → 問題在檢索。

6. 人為評估 (Human Evaluation)

   • 雖然自動化指標（MRR、nDCG、Ragas 等）可以有個客觀的分數，但無法完全捕抓到使用者的感覺。
   • 引入人工標註能幫助發現「技術指標分數高，但使用者體驗差」的情況。

📌 小結

RAG 系統的評估不能僅依靠單一指標，而是需要同時關注 檢索（Retrieval） 和 生成（Generation） 的整體表現：

• 在 檢索端，Precision@k、Recall@k、MRR、nDCG 可以幫助我們判斷檢索是否抓到足夠且相關的上下文。
• 在 生成端，Faithfulness、Correctness、Semantic Similarity、Relevance 等指標能衡量模型是否基於檢索結果，並產生準確、連貫且有幫助的答案。
• Ragas 等工具讓我們能自動化這些流程，快速驗證迭代效果。

除此外，評估不是單次工作，而是持續性的過程。結合自動化測試、人為評估與根因分析，才能確保 RAG 系統有達到 高品質、穩定性與可解釋性。

參考資料

Optimizing RAG retrieval: Test, tune, succeed
RAG Evaluation
Best Practices in RAG Evaluation: A Comprehensive Guide
Evaluation of Retrieval-Augmented Generation: A Survey