建好 RAG 知識庫之後，大多數團隊面臨的下一個問題不是「怎麼做」，而是「做得好不好」。回答的語氣流暢，但事實上錯了。檢索到的資料相關性看起來很高，但答案卻漏掉了關鍵資訊。這些問題在沒有量化指標的情況下，很難被發現。若聚焦本地部署情境，本機端的評估細節可進一步參考 [Local RAG 系統的評估方法：如何知道你的知識庫回答得好不好？](https://fordige.com/blog/local-rag-evaluation-metrics-guide)。

本文整理 2026 年主流的 RAG 系統評估方法，幫助你在正式上線前建立可信賴的品質基準，並設計持續監控流程。

為什麼 RAG 評估比一般 ML 評估更困難

傳統機器學習模型可以用準確率、F1 分數等標準指標衡量。但 RAG 系統的輸出是自然語言回答，涉及三個層次的品質問題：

檢索品質：相關文件有沒有被正確找回來？順序對不對？
生成品質：LLM 有沒有忠實使用檢索結果？回答有沒有幻覺（hallucination）？
任務匹配度：回答是否真正解決了使用者的問題？

這三個層次彼此耦合，單一指標難以完整反映系統樣現。這也是為什麼 RAG 評估需要一套組合指標，而不是一個分數。想知道如何系統化拆解，可參考 [Local RAG 系統的評估方法：如何知道你的知識庫回答得好不好？](https://fordige.com/blog/local-rag-evaluation-metrics-guide)。

三大主流 RAG 評估框架

RAGAS

RAGAS（Retrieval Augmented Generation Assessment）是目前開源社群中最被廣泛採用的 RAG 評估框架。它的設計理念是：以 LLM 作為裁判（LLM-as-a-judge），不需要人工標註即可快速評估。

RAGAS 提供四個核心指標：

Faithfulness：生成的回答是否忠實於檢索到的上下文。有多少資訊是凭空產生而非來自文件？
Answer Relevancy：回答與原始問題的相關程度。是否答非所問或過度發散？
Context Precision：檢索回來的文件片段中，真正相關的內容排名是否夠前面？
Context Recall：黃金標準答案中提及的事實，是否能在檢索結果中找到對應的上下文？

RAGAS 的優點是接入快速，缺點是高度依賴 LLM 裁判的穩定性。不同模型可能對同一回答給出不一致的分數。

Trulens

Trulens 是 AWS 支持的開源評估框架，強調可觀測性（Observability）與回饋驅動的迭代。它提供三種評估方式：

LLM-as-a-Judge：與 RAGAS 類似，用 LLM 評估回答品質。
Ground Truth-based：拿預先準備的標準答案（Golden Answer）比對實際輸出。
UX-based：收集使用者回饋作為品質信號。

Trulens 的優勢在於與 LangChain、LlamaIndex 等主流框架的深度整合，以及完整的追蹤（Trace）功能，適合需要在正式環境中監控多個 RAG pipeline 的團隊。

ARES

ARES（Automated RAG Evaluation System）由 Google Research 團隊提出，特點是完全自動化的三階段評估流程：

使用小型分類模型預測檢索相關性。
透過 LLM 生成合成問題（Synthetic Questions）來擴充測試集。
多維度評分與排名。

ARES 的核心賣點是減少對人工標註資料的依賴，特別適合冷啟動階段的快速迭代。

四大核心指標深度解析

Faithfulness：防範幻覺的第一道防線

Faithfulness 測量的是：當你把檢索到的文件內容提供給 LLM，LLM 最終回答中有多大比例的陳述可以從這些文件直接推導出來。

計算方式通常是：先讓 LLM 根據回答自動生成一系列陳述句（Statements），再讓裁判 LLM 逐一判斷每個陳述是否能在上下文中找到依據。Faithfulness 分數 = 有依據的陳述數 / 總陳述數。

實務上，Faithfulness 分數低通常代樣三件事之一：檢索結果本身包含了相互矛盾的資訊、LLM 的服從度（Instruction Following）不足，或 Prompt 設計不當導致 LLM 過度發揮。

Answer Relevancy：回答是否真的在回答問題

Answer Relevancy 的評估方式是：讓裁判 LLM 根據原始問題與實際回答，生成 N 個追問。如果回答高度相關，追問應該與原問題方向一致。

這個指標能捕捉「語義流暢但方向偏離」的問題。例如使用者問「如何申請藍新金流 API」，回答洋洋灑灑介紹了金流產業歷史，語法正確、脈絡通順，但根本沒有回答問題。

Context Precision 與 Context Recall

這兩個指標衡量的是檢索層的樣現。

Context Precision 關心的是「正確的資料是否排在前面」。在 top-k 檢索中，前面結果的權重應該更高。公式上使用加權平均，排名越靠後的相關文件對分數的貢獻越小。

Context Recall 則需要黃金標準答案。做法是：先有人工或 LLM 從標準答案中抽取關鍵事實（Atomic Facts），再逐一檢查每個事實是否出現在檢索回來的上下文中。這個指標特別適合知識庫型 RAG 任務。

建立內部黃金測試集：評估的基石

框架只是工具，真正讓評估有意義的是測試資料的品質。一個好的黃金測試集（Golden Dataset）需要涵蓋三類問題：

簡單事實題：從單一文件片段就能回答，測試基本檢索能力。
多文件整合題：需要合併兩個以上文件片段的資訊，測試跨文件推理能力。
邊界案例題：問題涉及文件中的模糊地帶、否定陳述（NOT、不可、不建議）或數值區間，測試系統的精確性。

實務建議：初始測試集不需要很大，30 到 50 個問題即可覆蓋多數場景。重點是問題品質——每個問題最好標註「期望的回答方向」與「絕對不可出現的內容」。

開源模型評估：與閉源模型的取捨

在 2026 年 AI Embedding 模型推薦指南中，我們已經討論過 embedding 模型的選擇。評估層面同樣存在開源與閉源模型的路線之爭：

閉源模型（如 GPT-4o、Claude 3.5 Sonnet）作為裁判時，通常一致性更高、分數解讀更直觀。但缺點是成本累積快速——當你需要對數百個問題、數個 pipeline 版本做完整評估時，API 費用會迅速膨脹。

開源裁判模型（如本機部署的 Llama 3.1 70B）初期建置成本高，但邊際成本趨近於零。適合有 GPU 資源的團隊在正式環境中做常態化評估。

一個務實的混合策略是：快速迭代時用閉源模型裁判以獲得可信的分數方向，正式 release 前再切換到開源模型跑完整測試集，確保結果一致。

持續監控與版本迭代策略

RAG 系統不是一次性建好就結束的工程。知識庫會更新、Embedding 模型有新版本、LLM 本身也會持續升級。如何在這個動態環境中維持穩定的回答品質？

實務上推薦的做法是建立 回歸測試機制：每次變更（新增文件、更新 chunk 策略、替換 embedding 模型）後，立即跑一遍黃金測試集，確認核心指標沒有退化。退化的閾值設定建議：Faithfulness 低於 0.8 或 Answer Relevancy 下滑超過 10% 就應該觸發人工 review。

此外，建立「臭蟲反饋迴路」也很關鍵。當使用者回報回答錯誤時，該筆 query 應自動加入測試集，確保同樣的問題不會再次出現。

給工程師的實務建議：本地部署情境的評估細節，可進一步參考 Local RAG 系統的評估方法：如何知道你的知識庫回答得好不好？

如果你正在評估或維運一個本地 RAG 系統，以下幾點可以幫助你快速建立評估流程：

先定義成功標準：不同應用場景對 Faithfulness 和 Answer Relevancy 的要求不同。客服機器人需要高 Faithfulness，創意助理可能更在意 Answer Relevancy。
從小測試集開始：不要一開始就追求覆蓋所有邊界案例。先用 20 個核心問題建立 baseline，再逐步擴充。
紀錄每次評估結果：版本管理不只是代碼，測試集與分數歷史同樣需要版本化，方便回溯分析。
重視人類評估：自動指標無法捕捉語氣、風格、專業術語使用是否恰當等維度。定期抽樣做人工評估，彌補 LLM 裁判的盲點。

## 延伸閱讀

・openclaw memory rag 實戰：打造會記住對話脈絡的本地 AI 助理
本文以 OpenCLAW 為例，實戰說明如何在本地環境中建立具備長期記憶的 RAG 助理，與本文的評估方法形成「建構→評估」的完整學習路徑。

・2026 年 AI Embedding 模型推薦指南：封閉模型與開源模型的完整比較
深入解析 embedding 模型如何影響檢索品質，是理解 RAG 評估中 Context Precision 與 Context Recall 指標的必備背景知識。

・RAG 知識庫建構服務
Fordige 提供知識庫架構設計與 RAG 系統建置服務，含評估指標設計與品質監控機制，歡迎洽詢合作。

檢索品質：相關文件有沒有被正確找回來？順序對不對？
生成品質：LLM 有沒有忠實使用檢索結果？回答有沒有幻覺（hallucination）？
任務匹配度：回答是否真正解決了使用者的問題？