[Day 11] RAG Evaluation：如何知道 AI 助理回答得好不好

今天為什麼要做這件事

在前幾天的實作中，我們逐步完成了 RAG 系統的核心流程

目前系統已經可以從文件中找出相關內容，並交給 LLM 產生回答

但接下來會遇到一個更重要的問題：

我們怎麼知道 AI 助理產生的回答真的好

如果只看到回答內容通順、語氣自然，就認為系統運作良好，可能會忽略以下問題：

• 檢索到的文件是否真的相關
• 回答是否有根據提供的文件
• 回答是否完整處理使用者問題
• AI 是否自行補充文件中不存在的資訊

因此，今天要開始建立 RAG Evaluation，從主觀觀察轉向可記錄、可比較、可重複的評估流程

今天要解決什麼問題

今天的目標包括：

1. 了解 RAG Evaluation 的基本概念
2. 評估檢索內容與使用者問題的相關性
3. 評估 AI 回答是否符合使用者需求
4. 確認回答是否有文件依據
5. 避免只憑個人感覺判斷系統品質。

什麼是 RAG Evaluation

RAG Evaluation 是針對 Retrieval-Augmented Generation 系統進行品質評估

它不只評估 LLM 的回答，也會同時檢查：

• 檢索階段是否找到正確文件
• 生成階段是否根據文件回答
• 最終回答是否符合使用者問題
• 整體系統是否穩定

因為 RAG 的錯誤可能發生在不同位置

不能只看最後的回答結果，就認定問題一定出在 LLM

不同研究與評估框架對指標的定義可能略有差異，因此實作時必須先定義自己的評分規則

Context Relevance：檢索內容是否相關

什麼是 Context Relevance

Context Relevance 用來評估：

系統檢索出來的文件，是否與使用者的問題有關

• 文件 A：高度相關
• 文件 B：可能相關
• 文件 C：與問題關聯較低

如果 Top-5 中有大量不相關文件，LLM 就可能受到雜訊影響

Context Precision 與 Context Recall

除了單純評估相關性，也可以觀察：

Context Precision

檢索結果中，相關文件所占的比例

Context Recall

所有必要參考文件中，有多少被成功檢索出來

兩者的差異：

• Precision：找到的內容是否大多相關
• Recall：必要的內容是否有被找出來

這也說明為什麼不能只看搜尋結果數量

Answer Relevance：回答是否符合問題

什麼是 Answer Relevance

Answer Relevance 用來評估：

AI 產生的回答，是否真正回應使用者提出的問題

雖然內容可能來自文件，但沒有直接回答「安裝完成後需要做什麼」

因此，回答是否有文件依據，與回答是否符合問題，是兩個不同的評估面向

Answer Relevance 評分

如果文件只提供這項資訊，這個回答可能具備良好的相關性
但不代表它涵蓋所有可能的安裝注意事項

因此，評估時應根據問題的具體範圍判斷完整程度

Faithfulness 與 Groundedness 的差異

這兩個概念經常一起出現，但實際定義可能因評估框架而有所不同。

Faithfulness：回答是否忠於 Context

Faithfulness 主要關注：

回答中的內容，是否能由提供的 Context 支持

這個回答可以由 Context 直接支持

但如果 Context 沒有提到，因此回答包含未被提供內容支持的資訊

這可能是 幻覺 或無依據延伸

Groundedness：回答是否建立在證據上

Groundedness 通常用來描述：

回答是否有足夠的外部證據或提供內容作為依據

在 RAG 系統中，證據通常包括：

• 檢索到的文件
• 文件 Metadata
• 知識庫內容
• 可追蹤的引用來源

兩者如何區分

在不同工具中，Faithfulness 與 Groundedness 可能被視為相近指標，甚至使用不同名稱的概念

因此，建立評估流程時，應該明確記錄定義，而不是只依賴指標名稱

建立 RAG 評估資料集

為什麼需要評估資料集

如果每次修改程式後，都只手動輸入幾個問題測試，會遇到：

• 測試案例不一致
• 每次評估標準不同
• 無法比較修改前後的差異
• 容易忽略以前出現過的問題

因此，可以建立固定的評估資料集，讓系統每次更新後都執行相同測試

評估資料集的基本結構

自然語言可能存在多種合理表達方式，因此應將參考答案視為評估輔助，而不是完全固定的字串

Step 1：建立基本答案評估函式

def keyword_coverage(answer, expected_keywords):
    if not expected_keywords:
        return 1.0

    matched_count = sum(
        1
        for keyword in expected_keywords
        if keyword.lower() in answer.lower()
    )

    return matched_count / len(expected_keywords)

這個方法的用途

它可以快速確認回答是否包含指定關鍵字

但它有明顯限制：

• 出現關鍵字不代表語意正確
• 可能出現錯誤的句子
• 無法判斷回答是否有文件依據
• 不適合單獨作為完整的 RAG 評估指標

因此，這只是初步的自動化檢查

Step 2：建立 Context Relevance 評估

實務上如何建立標註

可以由開發者或領域專家針對每個問題與 Chunk 進行標註

建議記錄：

• 問題 ID
• Chunk ID
• 相關性分數
• 標註理由
• 標註人員
• 評估日期

這些資訊可以協助後續分析檢索錯誤

Step 3：評估 Faithfulness

Faithfulness 需要判斷回答中的敘述，是否能被 Context 支持

重要限制

實際系統需要先正確拆分回答中的敘述，並判斷文件是否真的支持該敘述

單純使用關鍵字比對，可能無法處理：

• 否定句
• 數字變化
• 同義詞
• 複合句
• 因果關係
• 文件內容的隱含條件

因此，正式評估可以使用 LLM Judge、NLI 模型或人工審查，但仍需要設計驗證機制

Step 4：使用 LLM Judge 進行評估

除了關鍵字規則，也可以讓另一個模型協助判斷回答品質

例如建立評估 Prompt：

def build_evaluation_prompt(
    question,
    context,
    answer
):
    return f"""
你是一個 RAG 評估員。

請根據以下內容評估 AI 回答。

【使用者問題】
{question}

【參考文件】
{context}

【AI 回答】
{answer}

請評估以下項目：

1. Context Relevance：
文件是否與問題相關？

2. Answer Relevance：
回答是否有回應問題？

3. Faithfulness：
回答是否能由參考文件支持？

請針對每個項目給出 0 到 2 分，
並說明評分理由。

請使用以下格式：

Context Relevance: 分數
Answer Relevance: 分數
Faithfulness: 分數
Reason: 評分理由
"""

LLM Judge 的優點

• 能處理較複雜的自然語言
• 可以判斷同義表達
• 能提供評分理由
• 適合進行大量初步評估

LLM Judge 的限制

• 模型本身也可能判斷錯誤
• 不同模型的評分標準可能不同
• Prompt 改變後，結果可能產生差異
• 可能受到回答語氣或格式影響
• 需要搭配人工抽查

因此，LLM Judge 應視為評估工具，而不是絕對正確的裁判

如何避免只憑主觀感覺判斷

建立固定測試案例

每次修改以下項目後，都執行相同測試：

• Chunk Size
• Embedding Model
• Top-K
• Hybrid Search 權重
• Reranking Model
• Prompt
• LLM Model

這樣才能比較修改前後的差異

同時記錄品質與效能

不能只追求回答正確率，也需要記錄系統成本與速度

這類記錄可以幫助我們了解系統變更帶來的影響

不過，評估指標之間可能存在取捨：

• 更大的候選集合可能提升 Recall，但增加延遲
• 更複雜的 Reranker 可能改善排序，但提高推論成本
• 更長的 Context 可能包含更多資訊，但也可能增加雜訊

因此，應根據實際應用需求決定評估重點

實驗設計：比較不同 RAG 設定

實驗時要注意

不要因為某一個測試案例結果變好，就直接認定整體系統改善。

至少應該：

1. 使用多個不同類型的問題
2. 包含可回答與不可回答的問題
3. 包含精確關鍵字與自然語言查詢
4. 記錄失敗案例
5. 比較平均結果與個別案例

常見評估問題

問題一：回答很流暢，是否代表品質很好

不一定

LLM 可以產生語句通順的回答，但內容可能：

• 沒有回答問題
• 缺乏文件依據
• 加入文件中不存在的資訊
• 忽略重要條件

因此，語言流暢度不能取代正確性與依據評估

問題二：關鍵字全部出現，是否代表回答正確

不一定

即使回答包含 Ubuntu 24.04，也可能與文件內容相反

因此，關鍵字覆蓋率只能作為初步檢查，不能單獨判斷答案正確性

問題三：Faithfulness 很高，是否代表回答完整

不一定

回答可能完全根據文件，但只回答局部問題

問題四：評估分數越高，系統就一定越好嗎

需要看評估指標與實際需求。

例如：

• 提高 Recall，可能增加不相關文件
• 提高 Faithfulness，可能讓回答變得過於保守
• 降低回應時間，可能犧牲部分排序品質
• 提高關鍵字覆蓋率，可能無法反映語意正確性

因此，評估分數應搭配實際案例、錯誤分析與效能指標一起解讀

今天學到什麼

今天開始建立 RAG Evaluation 的基本觀念，將系統品質從主觀感受轉換成可測量的指標

RAG 評估不只看最後答案

Context Relevance 與 Answer Relevance 不同

• Context Relevance：文件是否與問題相關
• Answer Relevance：回答是否回應使用者問題
  即使文件相關，回答仍可能偏離問題

Faithfulness 與 Groundedness 用來檢查回答依據

回答需要建立在檢索到的文件上，而不是由模型自行捏造內容

不同評估工具可能對兩者採用不同定義，因此需要明確記錄評估標準

4. 自動化資料集能提高測試一致性

固定的問題、參考答案與評估規則，可以協助我們比較不同版本的系統表現

5. 評估結果需要搭配錯誤分析

數字可以告訴我們系統表現的變化，但還需要進一步分析：

• 哪些問題回答錯誤
• 錯誤發生在檢索還是生成
• 哪些文件沒有被找到
• 哪些回答缺乏證據
• 哪些設定造成品質下降

目前系統進度

目前的系統已經從單純的問答流程，逐步建立完整的檢索與評估架構

接下來不只是讓 AI 助理「能夠回答」，而是要確認它的回答：

• 是否有依據
• 是否符合問題
• 是否具備穩定品質
• 是否能透過測試持續改善

明天要做什麼

今天我們建立了 RAG Evaluation 的基本指標與測試資料集

但目前的評估仍以簡單規則與概念示範為主，接下來需要進一步將評估流程整合到實際系統中

明天可以探討：

• 如何建立完整的 RAG Evaluation Pipeline
• 如何將評估結果儲存成 JSON 或 CSV
• 如何比較不同模型與參數
• 如何分析失敗案例
• 如何建立自動化回歸測試
• 如何讓 RAG 系統具備持續改善能力

Day 12：建立自動化 RAG Evaluation Pipeline 讓每次修改都有依據

從今天的「確認回答品質」，進一步走向「透過自動化測試，持續追蹤與改善 AI 助理的表現」