搜尋意圖： 如果你在找「增強生成評估 是什麼」或「增強生成評估 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 評估 RAG 系統輸出品質的方法論，量化模型在檢索增強場景下的忠實性、相關性和答案完整性。
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
評估 RAG 系統輸出品質的方法論，量化模型在檢索增強場景下的忠實性、相關性和答案完整性。
隨著 RAG 架構在企業 AI 應用中的普及，如何系統性地評估 RAG 系統的輸出品質成為一個獨立的研究課題。傳統 NLP 評估指標（如 BLEU、ROUGE）只衡量文字相似度，無法捕捉 RAG 場景的特殊失敗模式，如模型「幻覺性引用」（聲稱引用了某段文字，但實際上在捏造或歪曲）或「檢索成功但生成失敗」（檢索到相關文件，但最終回答沒有正確利用這些資訊）。增強生成評估（AGE）框架因此需要針對 RAG 管線的每個環節單獨評估。
主流的 AGE 框架（如 RAGAS、TruLens、DeepEval）通常評估以下幾個維度。忠實性（Faithfulness）衡量模型回答是否完全基於提供的上下文：對回答中的每個聲明（Claim），檢查它是否能從檢索文件中找到支持依據，無支持的聲明被計為幻覺。這個指標直接對應企業最關心的「AI 會不會亂說話」問題。上下文精準率（Context Precision）衡量檢索到的文件中有多少比例是真正相關的：若搜尋「2024 年 AI 法規」，系統召回了 10 篇文件，其中 7 篇確實討論 AI 法規，精準率為 70%。上下文召回率（Context Recall）衡量問題所需的相關資訊是否都被召回：若正確回答需要 3 個不同的資訊點，系統只找到 2 個，召回率為 67%。答案相關性（Answer Relevance）衡量最終回答是否真的在回答問題，而非跑題或只是複述文件原文。
RAGAS（Retrieval-Augmented Generation Assessment System）是目前最廣泛使用的開源 AGE 框架，採用 LLM-as-Judge 的方法：利用一個獨立的語言模型（通常是 GPT-4 或更強的模型）來評判另一個模型的輸出是否忠實、是否相關，而不依賴人工標注或固定詞彙匹配。這種方法的優點是能理解語意等價（「北京是中國首都」和「China's capital is Beijing」視為相同資訊），缺點是評估本身依賴 LLM 的判斷，引入了 LLM 評估者自身的偏差和成本。
在實際 RAG 系統調優中，AGE 框架提供了具體的診斷方向。若忠實性低，問題在生成端：模型傾向脫離上下文發揮，應強化系統提示詞（「只使用提供的資料回答，若資料不足請說不知道」）或使用更小、受控更強的模型。若上下文精準率低，問題在檢索端的相關性排序：可能需要改進向量嵌入模型、調整混合搜尋（向量 + 關鍵詞）的權重，或引入重排序（Reranker）模型。若上下文召回率低，問題在文件切割或索引策略：重要資訊被切散在不同 chunk，或嵌入模型無法有效捕捉特定領域的語意。
在 AI 應用評估的更廣泛框架下，AGE 屬於「系統評估（System Evaluation）」層次，有別於「模型評估（Model Evaluation）」。一個通用 LLM 在標準基準測試（如 MMLU、HumanEval）上表現優異，不代表以它為核心的 RAG 系統在特定業務場景中表現良好。AI 應用規劃師在評估和監控生產 RAG 系統時，建立持續的 AGE 評估管線（Evaluation Pipeline）是確保系統品質的必要實踐，通常包括：離線評估（在標注好的測試集上定期評估）、在線評估（對生產流量的隨機樣本進行 LLM-as-Judge 評估）、人工評估抽查（對高置信度的 AI 評估結果進行週期性人工審核）。
建立 AGE 評估管線的投入雖然需要初期資源，但它能讓團隊在系統變更時有客觀指標作為依據，避免「感覺變好了」的主觀判斷造成品質退步未被發現。這是 RAG 系統從原型升級到生產可靠度的關鍵一步。
常見問題
RAGAS 的幾個評估指標之間有什麼關係，應該優先關注哪個？
RAGAS 的四個核心指標（忠實性、上下文精準率、上下文召回率、答案相關性）衡量 RAG 管線的不同環節，低分的指標指向不同的問題根源。忠實性低表示生成環節出現幻覺，是最嚴重的品質問題，直接影響系統的可信度，應優先改善。上下文精準率和召回率反映檢索品質，前者衡量精準度（有多少噪音），後者衡量完整性（有多少遺漏）。答案相關性反映最終回答是否切題，有時即使檢索和生成都正確，回答仍可能跑題。實務上建議按忠實性 → 上下文相關性（精準率和召回率）→ 答案相關性的優先順序改善，忠實性是 RAG 系統的底線品質要求。
LLM-as-Judge 評估方法有什麼局限性？
LLM-as-Judge 使用大型語言模型來評判另一個模型的輸出，優點是能理解語意、不需要大量人工標注、可自動化運作。但有幾個重要局限：自我偏愛（Self-preference Bias）是指評估用的 LLM 傾向給與自己風格相近的輸出更高分；位置偏差（Position Bias）指評估者傾向偏好出現在特定位置（如第一個）的選項；詳細度偏差（Verbosity Bias）指評估者傾向認為較長的回答更好。這些偏差使得評估結果不完全客觀。緩解方法包括：多評估者投票（使用多個不同的 LLM 評估者）、設計明確的評分標準（Rubric）避免主觀判斷、定期與人工評估對比校準。完全依賴 LLM-as-Judge 而不做任何人工審核是有風險的。
如何在有限資源下快速建立 RAG 系統的評估機制？
有限資源下建立 RAG 評估機制的務實路徑是從小但關鍵的測試集開始。第一步，整理 50-100 個代表性的問題-答案-來源三元組（Golden Dataset），這些應涵蓋系統預期處理的核心使用場景；第二步，選擇一個輕量的評估框架（如 RAGAS），它能以 API 呼叫的方式自動計算忠實性等指標，不需要自行實作複雜邏輯；第三步，優先手動評估忠實性（10-20 筆，人工逐筆確認），因為這個指標最關鍵且最直觀；第四步，每次對系統做重要改動（換檢索模型、改 chunk 大小、換生成模型）後都在測試集上跑一次評估，追蹤指標變化趨勢。這個輕量流程能在不大量增加成本的前提下，確保系統品質有基本的監控保障。