深入理解 AI Agent 03｜RAG评估体系：量化检索增强效果，精准定位系统短板

RAG 系统最危险的失败模式不是报错，而是「看起来对」。检索召回了不相关的文档，LLM 一本正经地编造了上下文里不存在的内容——输出流畅、格式漂亮，但事实全部是错的。研究表明，约 35% 的 RAG 失败案例涉及生成与源材料矛盾的信息。没有评估体系的 RAG 系统，就像没有仪表盘的汽车——你感觉在跑，但不知道什么时候会爆缸。本文系统拆解 RAG 评估的核心指标、工具链与生产级评估管线的工程实践。

---

一、为什么 RAG 评估不能靠「肉眼看」

大多数 RAG 团队的发布流程是这样的：开发阶段精心写了 20 个测试问题，跑一遍，回答看起来挺合理，就推到线上了。但这 20 个问题覆盖了多少真实场景？如果你的知识库有 200 篇文档、50 种问题类型，20 个测试只覆盖了不到 1% 的表面积。

「手工评估」的三个结构性缺陷：

① 覆盖率不达标。 人工写的测试用例天然偏向简单事实查询，很少覆盖推理链、多文档综合、边界假设等复杂场景。知识库 99.6% 的面积处于未测试状态。

② 测试用例会腐化。 知识库在持续更新——新文档入库、旧文档修改、分块策略调整。但手工测试集没人维护。两个月后，测试全绿不代表系统正常，只是测试已经过时了。

③ 无法定位故障域。 一个回答不好，你很难判断是检索没找到对的文档（检索问题），还是找到了但 LLM 没用好（生成问题）。没有分解的评估指标，就像没有故障码的发动机报警——你知道有问题，但不知道修哪里。

架构师法则： 如果你的评估报告给出一个综合分数 0.82，但团队里没人能说清楚当它跌到 0.74 时该先查哪里，那你建的是遥测系统，不是评估系统。

---

二、评估的两个维度：检索质量 vs 生成质量

RAG 管线的评估必须拆成两个独立维度，每个维度有各自的失败模式和优化方向。混在一起打分是掩耳盗铃。

维度	评估什么	核心问题
检索质量	向量库是否找到了正确的文档块	找到了吗？找全了吗？排序对吗？
生成质量	LLM 是否正确使用检索到的上下文	忠于上下文吗？回答了问题吗？

下面按维度逐一拆解核心指标。

2.1 检索质量指标

Context Precision（上下文精确率）： 检索到的文档中，真正有用的占比。精确率低 = 噪声多，LLM 被无关信息干扰。生产环境通常要求 ≥ 0.75。

数学原理：

Context Precision = Σ(k=1 to K) [Precision@k × rel(k)] / 总相关文档数

其中：
- K = 检索返回的文档数（top_k）
- rel(k) = 第 k 个文档是否相关（1 或 0）
- Precision@k = 前 k 个结果中相关文档的占比

Context Recall（上下文召回率）： 回答问题所需的全部相关信息中，有多少被检索到了。召回率低 = 关键信息缺失，回答不完整。低于 0.6 意味着 40% 以上的查询漏掉了关键文档。需要 ground truth 标注。

数学原理：

Context Recall = |检索到的相关文档| / |ground truth 中标注的所有相关文档|

Recall@K / Precision@K： 经典 IR 指标。Recall@K 关注"找全了没有"，Precision@K 关注"找准了没有"。K 的选择是精度-召回的经典权衡——K 大了召回好但噪声多，K 小了精确高但可能漏掉关键信息。

MRR（Mean Reciprocal Rank）： 第一个相关结果出现在第几位。如果第一个相关文档排在第 3 位，MRR 就是 1/3。对于 RAG 场景，排在顶部的文档对 LLM 影响最大——MRR 直接衡量"第一眼看到的是不是对的"。

MRR = (1/|Q|) × Σ(i=1 to |Q|) 1/rank_i

其中 rank_i 是第 i 个问题的第一个相关结果的排名位置

NDCG（Normalized Discounted Cumulative Gain）： 考虑了排序质量的综合指标——相关文档排得越靠前，分数越高。完美排序得 1.0，随机排序接近 0。适合需要严格排序的场景。

DCG@K = Σ(k=1 to K) rel(k) / log2(k+1)
NDCG@K = DCG@K / IDCG@K

其中 IDCG@K 是理想排序下的 DCG（所有相关文档排在最前面）

2.2 生成质量指标

Faithfulness（忠实度）： 生成的回答中，有多少内容可以从检索到的上下文中推导出来。这是最关键的指标——它检测的是幻觉。RAGAS 的计算方式是把回答拆解为原子化陈述，逐一检查是否能被上下文支撑。分数 1.0 表示所有陈述都有据可查，0.4 表示 60% 的内容是编造的。不需要 ground truth，只需对比回答和检索上下文，可以在生产环境实时计算。

数学原理：

Faithfulness = |可从上下文推导的原子陈述数| / |回答中的原子陈述总数|

步骤：
1. LLM 将回答拆解为原子陈述：{"巴黎人口210万", "拥有埃菲尔铁塔"}
2. 对每条陈述检查：能否从上下文推导？
3. 计算比例

Answer Relevance（答案相关性）： 生成的回答是否真正回答了用户的问题。一个技术上正确但答非所问的回答，相关性很低。RAGAS 用了一个巧妙的「反向生成」技巧：让 LLM 基于生成的回答反向生成 3-5 个问题，然后计算这些问题与原始问题的语义相似度。不需要 ground truth，也可以在生产环境实时运行。

数学原理：

Answer Relevance = (1/N) × Σ(i=1 to N) cos_sim(embed(生成的问题ᵢ), embed(原始问题))

步骤：
1. LLM 基于回答反向生成 N 个问题（通常 N=3-5）
2. 计算每个生成问题与原始问题的 embedding 余弦相似度
3. 取平均值

Answer Correctness（答案正确性）： 综合评估生成回答与 ground truth 的语义匹配度。结合了语义相似度（Embedding 余弦距离）和事实重叠度（F1 Score）。需要 ground truth 标注，适合离线评估集。

Answer Correctness = 0.5 × F1_Score + 0.5 × Semantic_Similarity

其中：
- F1_Score：基于答案和 ground truth 的 token 重叠
- Semantic_Similarity：Embedding 向量的余弦相似度

---

三、指标交叉诊断：四个分数讲的故事

单个指标只能告诉你"这里有问题"。但把检索和生成的指标交叉起来看，就能精确定位问题出在管线的哪一段。这是评估体系真正的价值所在。

分数组合	说明什么	该改什么
Context Recall 高 + Faithfulness 低	正确文档都检索到了，但 LLM 在胡说	收紧 System Prompt、换更强的指令遵循模型
Context Recall 低 + Faithfulness 高	LLM 很忠实地基于少量信息回答，但关键信息没找到	增大 top_k、换 embedding 模型、优化分块策略
Context Precision 低	检索结果噪声太多，无关文档混进来了	提高相似度阈值、加 Reranker、优化 embedding
Answer Relevance 低	回答跑题了或只回答了部分问题	在 Prompt 中强调用户问题、做 Query Rewriting

最危险的组合是「Context Recall 高 + Faithfulness 低」——正确的文档已经摆在 LLM 面前了，但它还是编造了内容。这是纯粹的生成问题，不是检索问题。通常意味着模型过于自信或 Prompt 约束不够严格。

案例：某金融问答系统的诊断过程

某金融 RAG 系统上线一周后，用户投诉"回答不准确"。团队查看评估数据：

初始指标：
- Context Precision: 0.82 ✓
- Context Recall: 0.88 ✓
- Faithfulness: 0.58 ✗
- Answer Relevance: 0.76 ✗

从交叉诊断表可以看出：

• Recall 高 + Faithfulness 低 → 检索没问题，生成有幻觉
• Relevance 偏低 → 回答没有完全切中问题

优化动作：

1. 在 System Prompt 中加入："仅基于提供的上下文回答，如果上下文中没有答案，请明确说'根据现有资料无法回答'"
2. 在 Prompt 开头重复用户原始问题，强化回答的针对性

优化后指标：

- Faithfulness: 0.92 (+0.34)
- Answer Relevance: 0.89 (+0.13)

---

四、RAGAS：RAG 评估的事实标准

RAGAS（Retrieval Augmented Generation Assessment）是专门为 RAG 系统设计的评估框架。它把上面讨论的指标全部工程化实现，并采用 LLM-as-Judge 模式——用一个评估模型（如 GPT-4、Gemini）来给你的 RAG 输出打分。

相比 BLEU、ROUGE 这些传统指标，RAGAS 的优势很明显：传统指标靠文本表面匹配打分，无法检测"语义正确但措辞不同"或"措辞相似但事实错误"的情况。RAGAS 用 LLM 做语义级判断，能捕捉传统指标完全遗漏的问题。据实践报告，RAGAS 能比关键词匹配多发现约 60% 的准确性问题。

4.1 RAGAS 的四大核心指标计算流程

Faithfulness 计算（两步 LLM 调用）：

第一步，LLM 将回答拆解为原子化陈述（atomic statements）。例如"巴黎人口 210 万，拥有埃菲尔铁塔"拆成两条独立陈述。

第二步，对每条陈述检查是否能从检索上下文中推导出来。最终分数 = 可推导陈述数 / 总陈述数。

示例：回答被拆解为 5 条原子陈述
其中 4 条可从上下文中推导
Faithfulness = 4 / 5 = 0.80

Answer Relevance 计算（反向生成技巧）：

LLM 基于生成的回答，反向生成 N 个（通常 3-5 个）"这个回答可能是在回答什么问题"。然后将这些候选问题与原始问题分别计算 embedding 余弦相似度，取平均值。

Answer Relevance = (1/N) × Σ cos_sim(embed(生成的问题ᵢ), embed(原始问题))

Context Precision 和 Context Recall 则需要 ground truth 标注。前者检查检索结果中有用的文档是否排在前面，后者检查所有必要的信息是否都被检索到了。

4.2 代码实战：用 RAGAS 评估你的 RAG 管线

以下是一个完整的最小可用示例，展示如何将 RAGAS 集成到你的评估流程中：

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)
from datasets import Dataset

# 1. 准备评估数据集
# question: 用户问题
# answer:   RAG 系统生成的回答
# contexts: 检索到的文档块列表
# ground_truth: 人工标注的标准答案
eval_data = {
    "question": [
        "如何申请7天无理由退货？",
        "会员积分的有效期是多久？",
    ],
    "answer": [
        rag_pipeline.answer("如何申请7天无理由退货？"),
        rag_pipeline.answer("会员积分的有效期是多久？"),
    ],
    "contexts": [
        rag_pipeline.retrieve("如何申请7天无理由退货？"),
        rag_pipeline.retrieve("会员积分的有效期是多久？"),
    ],
    "ground_truth": [
        "支持7天无理由退货，需保持商品完好并附购物凭证，"
        "申请路径：个人中心-售后-退货申请。",
        "会员积分自获得之日起12个月内有效，逾期自动清零。",
    ],
}

# 2. 运行评估
result = evaluate(
    Dataset.from_dict(eval_data),
    metrics=[faithfulness, answer_relevancy,
             context_precision, context_recall],
)

# 3. 查看结果
print(result)
# faithfulness: 0.91 | answer_relevancy: 0.87
# context_recall: 0.83 | context_precision: 0.78

注意版本陷阱： RAGAS v0.4 做了重大 breaking change——移除了 LangchainLLMWrapper、AspectCritic 等 API，metrics 现在返回 MetricResult 对象（包含分数和推理过程），而不是原始浮点数。网上大量 v0.1-v0.3 的代码示例在 v0.4.x 上跑不起来，需要迁移到 llm_factory() 新接口。建议固定使用 RAGAS 0.4.3+。

4.3 配置自定义 Judge 模型

RAGAS 默认使用 GPT-3.5 作为 Judge 模型，但你可以根据成本和质量需求切换：

from ragas.llms import llm_factory
from langchain_openai import ChatOpenAI

# 方式 1：使用 llm_factory（推荐，v0.4+）
judge_llm = llm_factory(
    provider="openai",
    model="gpt-4o-mini",  # 平衡成本和质量
    temperature=0,
)

# 方式 2：使用 Langchain 集成
from ragas.llms import LangchainLLMWrapper
judge_llm = LangchainLLMWrapper(
    ChatOpenAI(model="gpt-4o", temperature=0)
)

# 在评估时指定
result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy],
    llm=judge_llm,
)

成本对比（以 1000 条评估为例）：

Judge 模型	单条评估成本	1000 条总成本	质量
gpt-4o	~$0.015	~$15	最高
gpt-4o-mini	~$0.003	~$3	中等
gpt-3.5-turbo	~$0.001	~$1	基线
DeepSeek-V3	~$0.0005	~$0.5	可接受

建议： 开发阶段用 gpt-4o 建立高质量基线，生产监控用 gpt-4o-mini 或 DeepSeek 控制成本。

---

五、构建生产级评估管线

单次评估只能告诉你"现在怎么样"，生产级评估需要回答"什么时候变差了"。这需要一套分层评估架构。

5.1 三层评估架构

层级	工具	职责	触发时机
Layer 1	RAGAS	在静态评估集上计算四大核心指标，作为基线分数	每次 PR / 模型变更
Layer 2	DeepEval	Pytest 风格的测试框架，50+ 指标，集成 CI/CD	CI 流水线自动化
Layer 3	自建监控	生产流量采样评估，趋势监控，漂移告警	持续运行

5.2 DeepEval：CI/CD 集成利器

DeepEval 的核心优势是与 pytest 无缝集成，可以直接在 CI 流水线中运行评估：

# test_rag_evaluation.py
import pytest
from deepeval import assert_test
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase

def test_rag_faithfulness():
    """测试 RAG 系统的忠实度"""
    test_case = LLMTestCase(
        input="如何申请7天无理由退货？",
        actual_output=rag_pipeline.answer("如何申请7天无理由退货？"),
        retrieval_context=rag_pipeline.retrieve("如何申请7天无理由退货？"),
    )
    
    metric = FaithfulnessMetric(threshold=0.7)
    assert_test(test_case, [metric])

def test_rag_relevancy():
    """测试 RAG 系统的答案相关性"""
    test_case = LLMTestCase(
        input="会员积分的有效期是多久？",
        actual_output=rag_pipeline.answer("会员积分的有效期是多久？"),
        retrieval_context=rag_pipeline.retrieve("会员积分的有效期是多久？"),
    )
    
    metric = AnswerRelevancyMetric(threshold=0.7)
    assert_test(test_case, [metric])

在 CI 中运行：

# 直接运行 pytest
pytest test_rag_evaluation.py

# 或者用 deepeval 命令，带更多输出
deepeval test run test_rag_evaluation.py

DeepEval 的 50+ 指标分类：

类别	代表指标	说明
RAG 核心	Faithfulness, Answer Relevancy	RAG 系统必备
hallucination	HallucinationMetric	检测幻觉内容
Toxicity	ToxicityMetric	检测有害内容
Bias	BiasMetric	检测偏见
Summarization	SummarizationMetric	评估摘要质量
Question Answering	CorrectnessMetric	问答正确性

5.3 评估数据集：黄金标准

评估数据集的质量直接决定评估的可信度。一个合格的「黄金数据集」应包含 100-200 个多样化的查询，覆盖预期的所有使用场景。构建方法：

① 人工标注（精准但昂贵）： 领域专家针对每个查询标注 ground truth 答案和相关文档。适合核心场景，但规模有限。

② 合成数据生成（规模化方案）： 用 LLM 从知识库文档自动生成测试用例。DeepEval 的 Synthesizer 可以从 55 篇文档自动生成 330+ 测试用例，覆盖推理、多文档综合、假设分析等多种复杂度。

from deepeval.synthesizer import Synthesizer

synthesizer = Synthesizer()

# 从文档生成测试用例
synthesizer.generate_from_docs(
    docs=["doc1.pdf", "doc2.pdf"],
    num_test_cases=50,
    max_contextual_length=2000,
)

# 导出为 CSV
synthesizer.export_to_csv("eval_dataset.csv")

③ 混合策略（推荐）： 核心场景人工标注（确保关键路径的质量），边缘场景合成生成（扩大覆盖面）。评估数据集需要版本管理，与代码一起纳入 Git。

5.4 生产环境持续监控

在生产环境中，不可能对 100% 的流量做评估（LLM 调用成本太高）。推荐策略：

① 采样评估： 随机抽取 5% 的生产查询进行评估。成本可控，同时能捕捉到质量退化。

import random

def should_evaluate():
    """5% 采样率"""
    return random.random() < 0.05

def evaluate_production_query(query, answer, contexts):
    if not should_evaluate():
        return
    
    # 异步评估，不阻塞主请求
    asyncio.create_task(
        evaluate_async(query, answer, contexts)
    )

② 优先监控 reference-free 指标： Faithfulness 和 Answer Relevance 不需要 ground truth，可以在生产环境实时计算。设置滚动窗口均值告警，当指标跌破阈值时触发告警。

# 伪代码：生产监控
from datetime import datetime, timedelta

def check_metric_drift():
    """检查指标是否漂移"""
    window = timedelta(hours=1)
    
    recent_faithfulness = get_recent_metrics(
        metric="faithfulness",
        time_range=window,
    )
    
    baseline = 0.85  # 基线分数
    current_mean = sum(recent_faithfulness) / len(recent_faithfulness)
    
    if current_mean < baseline - 0.05:  # 下降超过 5%
        send_alert(
            f"Faithfulness 漂移告警: {current_mean:.2f} "
            f"(基线: {baseline:.2f})"
        )

③ 建立阈值门控： 分数是数据，阈值是策略。典型的上线门槛：

指标	上线最低阈值	说明
Faithfulness	≥ 0.85	幻觉容忍度极低
Answer Relevance	≥ 0.80	回答必须切中问题
Context Precision	≥ 0.75	检索噪声要少
Context Recall	≥ 0.70	关键信息不能漏

每次模型变更、Prompt 调整、分块策略修改前，都必须通过评估门控。

---

六、工具链横评：RAGAS vs DeepEval vs TruLens

市面上三个主流 RAG 评估框架各有侧重，不是三选一的关系，而是分层配合。

维度	RAGAS	DeepEval	TruLens
定位	指标科学层	测试框架层	可观测性层
核心能力	四大核心指标的算法实现	50+ 指标 + Pytest 集成 + 合成数据生成	Trace 存储 + 实时反馈 + 自定义 Selector
Reference-free	Faithfulness + Answer Relevance	RAG Triad（含 Groundedness）	Context Relevance + Groundedness + Answer Relevance
CI/CD 集成	需自行封装	原生 pytest 集成	支持，侧重 trace 分析
适用层	Layer 1：基线评估	Layer 2：CI 自动化测试	Layer 3：生产监控
注意事项	v0.4 有 breaking change	支持自定义 Judge 模型（可用 DeepSeek 降本）	2.8.0+ 要求 Python ≥ 3.10

实战建议： 不要纠结选哪个，三个在不同层级各有所长。RAGAS 负责「指标科学」，DeepEval 负责「测试自动化」，TruLens 负责「生产可观测」。如果只能选一个起步，RAGAS 是最小可行方案。

---

七、LLM-as-Judge 的踩坑点

RAGAS 和 DeepEval 都依赖 LLM 作为评估裁判。这个设计有优势（语义级判断、可扩展），但也有坑。

坑一：Judge 模型的能力直接影响评估质量。 Faithfulness 的原子化陈述拆解步骤如果用了弱模型，可能把两个独立声明合并成一个，导致幻觉被漏检。建议 Judge 模型至少和生成模型同档次。

坑二：同名指标不等于同义指标。 RAGAS 的 Faithfulness 和 DeepEval 的 Faithfulness 虽然名字一样，但底层 Judge Prompt 不同，分数不可直接比较。切换框架时必须重新建立基线。

坑三：评估成本不可忽视。 每个样本的 Faithfulness 评估需要 2 次 LLM 调用（拆解 + 验证），Answer Relevance 需要 N+1 次（生成 N 个问题 + 计算相似度）。如果每天评估 1000 条生产查询，Judge 模型的 API 成本可能占到总成本的 15-20%。

坑四：Judge 模型版本必须锁定。 同一个指标，用 gpt-4o-mini 打分和用 claude-3-5-sonnet 打分，结果可能差 5-10 个百分点。评估管线中 Judge 模型必须作为配置项锁定，否则基线分数会随模型升级漂移。

坑五：评估结果存在随机性。 即使同一个 Judge 模型、同一个输入，多次评估的分数也可能有 ±0.05 的波动。建议：

• 建立基线时跑 3 次取平均
• 阈值设置留有余量（如基线 0.85，阈值设 0.80）
• 不要过度解读 0.02 以内的分数波动

---

八、评估驱动优化：一个真实案例

以一个电商客服 RAG 系统为例，展示评估如何驱动优化决策：

初始状态： 200 条评估集，人工标注 ground truth。

指标	优化前	优化动作	优化后
Context Recall	0.52	top_k 从 3 调到 8 + 混合检索（BM25 + 向量）	0.81
Context Precision	0.45	加入 Cohere Reranker，从 8 个候选中精选 4 个	0.83
Faithfulness	0.68	System Prompt 加入"仅基于上下文回答，不确定则说不知道"	0.92
Answer Relevance	0.71	Prompt 中显式嵌入用户原始问题 + Query Rewriting	0.88

优化细节拆解：

1. Context Recall 优化（0.52 → 0.81）

诊断：Context Recall 低说明关键信息没找到。查看失败案例发现，很多查询需要综合多个文档片段才能回答，但 top_k=3 只返回 3 个文档，经常漏掉关键信息。

优化动作：

# 1. 增大 top_k
retriever.top_k = 8

# 2. 加入 BM25 混合检索（关键词匹配兜底）
from langchain.retrievers import EnsembleRetriever

ensemble_retriever = EnsembleRetriever(
    retrievers=[
        vector_retriever,  # 向量检索（语义相似）
        bm25_retriever,    # BM25（关键词匹配）
    ],
    weights=[0.6, 0.4],  # 向量权重更高
)

2. Context Precision 优化（0.45 → 0.83）

诊断：top_k 增大后，召回率上去了，但噪声也多了。很多无关文档排在前面，干扰 LLM。

优化动作：加入 Reranker 二次排序

from cohere import Client

client = Client(api_key="your-api-key")

def rerank(query, documents, top_n=4):
    response = client.rerank(
        model="rerank-multilingual-v2.0",
        query=query,
        documents=documents,
        top_n=top_n,
    )
    return [r.document["text"] for r in response.results]

# 在检索后、生成前加入重排序
contexts = ensemble_retriever.get_relevant_documents(query)
reranked_contexts = rerank(query, contexts, top_n=4)

3. Faithfulness 优化（0.68 → 0.92）

诊断：Recall 高 + Faithfulness 低 = 检索没问题，LLM 在编造。查看失败案例发现，LLM 在上下文不足时仍然强行回答，引入了自己的"知识"。

优化动作：

system_prompt = """你是一个专业的客服助手。请严格遵循以下规则：

1. 仅基于提供的上下文回答用户问题
2. 如果上下文中没有答案，请明确回复"根据现有资料，我暂时无法回答您的问题"
3. 不要使用上下文之外的知识
4. 不要编造或推测信息

上下文：
{context}
"""

4. Answer Relevance 优化（0.71 → 0.88）

诊断：Relevance 低说明回答跑题了。查看失败案例发现，LLM 有时候"答非所问"，或者只回答了问题的部分。

优化动作：

# 1. 在 Prompt 中显式嵌入用户原始问题
prompt = f"""用户问题：{user_query}

请针对上述问题，基于以下上下文给出回答：
{context}

回答要求：
- 直接回答用户问题
- 不要偏离主题
"""

# 2. 加入 Query Rewriting（查询改写）
def rewrite_query(original_query):
    """将用户问题改写得更明确"""
    rewrite_prompt = f"""请将以下问题改写为更明确、更具体的版本：
    
原问题：{original_query}

改写后的问题："""
    return llm.invoke(rewrite_prompt)

关键洞察：每个优化动作都对应一个低分指标。不是盲目调参，而是评估驱动——先看哪个指标低，诊断原因，定向优化，再跑评估验证效果。这就是评估体系的价值。

---

九、生产上线 Checklist

一份经过实战验证的 RAG 评估上线清单：

评估维度	必检项
评估数据集	100+ 条黄金测试集已构建，版本化管理，覆盖核心场景
基线建立	四大指标基线分数已记录，Judge 模型版本已锁定
CI 集成	评估脚本已集成到 CI 流水线，模型/Prompt/分块变更自动触发评估
阈值门控	每个指标设定了上线最低阈值，分数下降超过 5% 视为回归
生产监控	采样评估已部署，Faithfulness 和 Answer Relevance 设置滚动窗口告警
成本预算	Judge 模型的评估成本已纳入预算，采样率控制在可承受范围

---

十、总结

RAG 评估不是一个可以"以后再做"的事情。没有评估的 RAG 系统在生产中就是一颗定时炸弹——你不知道什么时候知识库更新导致检索失效，不知道哪次 Prompt 修改引入了幻觉，不知道换了一个 embedding 模型后召回率掉了多少。

核心要点回顾：

• 评估必须拆分检索质量和生成质量两个维度，否则无法定位故障域
• Faithfulness 和 Answer Relevance 是 production-ready 指标，不需要 ground truth，可以实时跑
• RAGAS 是指标科学层的事实标准，DeepEval 是测试自动化层，TruLens 是可观测层——三者分层配合
• 评估数据集需要版本化管理，和代码一样纳入 Git
• 评估的最终目的是驱动优化——每个低分指标都应该对应一个明确的优化动作

评估不是终点，而是持续改进的起点。建立评估体系的那一刻，才是 RAG 系统从 Demo 走向生产的真正开端。

---

下一篇将深入 Graph RAG——当文档之间存在复杂的引用、依赖、层级关系时，传统 RAG 的切片检索会丢失这些结构信息。Graph RAG 通过知识图谱把文档关系显式建模，让 Agent 能顺着关系链找到更完整的上下文。

— 深入理解 AI Agent 系列 · 第 3 篇 —

有问题评论区见，欢迎交流~

---