1. 背景：为什么 RAG 系统评估重要
随着大语言模型在企业知识库、智能客服、法律咨询、医疗问答、代码助手等场景中的广泛应用，RAG 已经成为构建企业级 AI 应用的重要技术方案。
相比直接让大模型依赖自身参数回答问题，RAG 通过"检索外部知识 + 基于上下文生成答案"的方式，让模型能够利用企业内部文档、实时业务数据、政策法规、产品手册等外部知识，从而提升答案的准确性、时效性和可追溯性。
但是，RAG 系统并不是简单地把文档切成 chunk、存进向量数据库，再接一个大模型就能稳定工作的。
在真实生产环境中，一个 RAG 系统可能会遇到很多问题：
- 正确文档没有被检索到；
- 正确文档被检索到了，但排序靠后；
- chunk 切分不合理，导致上下文不完整；
- 检索结果中混入大量无关内容，干扰模型判断；
- 答案看似合理，但并没有被检索内容支持；
- 引用来源不准确；
- 文档已经过期，导致答案不符合最新业务规则。
这些问题都会直接影响最终回答质量。
因此，RAG 评估的核心价值不只是判断"答案对不对"，需要判断：
- 系统是否找到了正确知识，是否正确使用了知识，是否生成了可信、可追溯的答案。
尤其是在法律、医疗、金融、政务等高风险场景中，一个错误答案可能带来严重后果。此时，单纯依赖人工抽查或问答准确率，已经无法满足生产级系统对稳定性、可解释性和可持续优化的要求。
2. 传统 RAG 评估方法及其问题
2.1 人工抽查
早期评估 RAG 系统时，最常见的方法是人工抽查。
开发者或业务人员准备一批问题，让 RAG 系统回答，然后人工判断答案是否可以接受。例如：
jsx
问题：员工如何申请年假？
答案：员工需要在系统中提交年假申请，并经过直属主管审批。
人工判断：正确。这种方法的优点是简单、直观，适合 demo 阶段或系统早期验证。但它的问题也很明显：
- 评估成本高；
- 主观性强；
- 不同评估人员标准不一致；
- 覆盖问题数量有限；
- 很难持续回归测试；
- 无法定位错误发生在哪个环节。
人工抽查可以告诉我们"这个答案看起来对不对"，但很难告诉我们"为什么错、应该改哪里"。
同时，我们也采用人工审查的方式去查看引用是否正确，因为RAG会检索相关内容并结合内容进行回答，那么检索内容是否正确与否非常重要，但是人工校验引用内容是否正确依然存在上述介绍的问题。
2.2 问答准确率
另一种常见方法是构造一个问题集，然后统计系统答对了多少。例如：
总共 100 个问题，系统答对 78 个，那么准确率就是 78%。
这种方法比人工抽查更量化，但对于 RAG 系统来说仍然过于粗糙。
因为 RAG 系统不是一个单纯的问答模型，而是由检索、重排、上下文组装和生成多个环节组成。最终答案错误，可能并不是大模型生成能力不够，而是前面的检索阶段根本没有拿到正确上下文。例如，用户问：
"Skilled Worker visa 是否可以携带配偶？"
如果系统检索到的是 Student visa dependant 页面，而不是 Skilled Worker dependant 页面，那么最终答案即使写得再流畅，也很可能是错的。
所以，仅看最终准确率无法区分：
- 是检索失败；
- 还是排序失败；
- 是上下文组装失败；
- 还是生成阶段幻觉。
3. 现代 RAG 评估的核心思想：分层评估
在生产级 RAG 系统中，评估不应该只停留在"最终答案是否正确"这一层，而应该从完整链路出发，至少评估三个层面：检索层、生成层和系统层。
| 评估层级 | 核心问题 | 主要关注点 |
|---|---|---|
| 检索层评估 | 系统有没有找到正确资料？ | 召回率、排序质量、检索相关性 |
| 生成层评估 | 模型有没有基于资料正确回答？ | 正确性、忠实度、相关性、引用准确性 |
| 系统层评估 | 系统是否能稳定服务真实用户？ | 延迟、成本、稳定性、用户反馈、知识更新 |
3.1 检索层评估
检索层评估关注的是：系统是否找到了正确资料。
如果检索阶段没有召回正确文档，那么后续生成模型再强，也很难给出可靠答案。因此，检索层评估主要关注正确文档是否被召回、是否排在靠前位置，以及检索结果中是否混入大量无关内容。
常见指标包括 Recall@K、Hit Rate@K、Precision@K、MRR 和 NDCG。
| 指标 | 含义 | 主要作用 | 示例 |
|---|---|---|---|
| Recall@K | 前 K 个检索结果中，是否包含应被召回的相关文档 | 衡量系统有没有把正确资料找出来 | Recall@5 = 0.8 表示前 5 个结果覆盖了 80% 的相关资料 |
| MRR | Mean Reciprocal Rank，平均倒数排名，关注第一个正确结果排在第几位 | 衡量正确结果是否排得足够靠前 | 第一个正确结果排第 1，得分 1；排第 5，得分 1/5 |
| Precision@K | 前 K 个结果中，有多少比例是真正相关的 | 衡量检索结果的"纯度"，避免无关内容太多 | 前 5 个结果中有 4 个相关，Precision@5 = 0.8 |
| Hit Rate@K | 前 K 个结果中是否至少命中一个正确文档 | 判断系统是否"至少找到了一个可用证据" | Hit Rate@5 = 1 表示前 5 个结果中至少有一个相关文档 |
| NDCG | Normalized Discounted Cumulative Gain，考虑相关性等级和排序位置的综合指标 | 衡量整体排序质量，适合多个相关文档的场景 | 高相关文档排在前面时，NDCG 更高 |
| Context Recall | 检索到的上下文是否覆盖回答问题所需的关键信息 | 判断最终上下文是否足够回答问题 | 标准答案需要 5 个要点，上下文覆盖 4 个，Context Recall = 0.8 |
| Context Precision | 检索到的上下文中有多少内容是真正有用的 | 判断上下文中噪声是否过多 | 传给模型的 10 个 chunk 中只有 6 个相关，Context Precision = 0.6 |
在实际 RAG 系统中，Recall@K 和 MRR 通常最重要。
如果 Recall@K 很低，说明正确资料根本没有被找出来。这时应该优化
jsx
文档入库
chunk 切分
embedding 模型
BM25 检索
混合检索
query rewrite
metadata filter如果 Recall@K 不低，但 MRR 很低，说明正确资料虽然被召回了，但排得太靠后。这时应该重排，具体优化方案如下：
jsx
reranker
RRF 融合排序
source 权重
时间新鲜度权重
标题和 metadata 加权如果 Precision@K 很低，说明检索结果中混入了太多无关内容。这会导致模型被噪声干扰，生成错误答案。这时应该优化：
jsx
相似度阈值过滤
metadata 过滤
去重策略
reranker
query intent 分类检索层评估的核心结论是：
如果检索层失败，生成层基本没有机会稳定答对。
所以当 RAG 答案错误时，第一步不要急着改 prompt，而应该先检查检索结果。
3.2 生成层评估
生成层评估关注的是：模型是否基于检索到的资料生成了正确答案。
在 RAG 系统中，一个答案语言流畅，并不代表它可靠。真正重要的是：
jsx
答案是否回答了用户问题？
答案是否忠实于检索上下文？
答案是否覆盖了关键条件和例外？
答案中的引用是否真的支持结论？
资料不足时，模型是否能够拒答？常见指标包括
| 指标 | 含义 | 主要作用 | 示例 |
|---|---|---|---|
| Faithfulness / Groundedness | 答案是否忠实于检索上下文 | 判断模型是否基于资料回答，是否产生幻觉 | 上下文没有提到"自动获批"，答案却写"自动获批" |
| Answer Correctness | 答案结论是否正确 | 判断最终答案是否符合事实或标准答案 | 标准答案说"需要满足条件"，模型回答"无条件允许"，则不正确 |
| Answer Relevance | 答案是否真正回答了用户问题 | 判断答案是否跑题 | 用户问"能否携带配偶"，模型却主要回答"签证费用" |
| Completeness | 答案是否覆盖关键条件、限制和例外 | 判断答案是否完整 | 只回答"可以携带配偶"，但漏掉"需要满足 dependant 条件" |
| Citation Accuracy | 引用是否真的支持答案中的结论 | 判断引用是否准确、可追溯 | 答案说费用，引用却指向 eligibility 页面 |
| Citation Coverage | 关键结论是否都有引用 | 判断答案是否充分可溯源 | 答案有 3 个关键结论，但只有 1 个有引用 |
| Refusal Accuracy | 当资料不足时，系统是否正确拒答 | 判断系统是否避免无依据回答 | 用户问"我的申请一定会通过吗"，系统应避免给确定结论 |
| Hallucination Rate | 答案中有多少内容无法被上下文支持 | 衡量模型编造信息的比例 | 答案 5 个事实中有 2 个无依据，幻觉率为 40% |
| Fluency | 答案表达是否自然、清晰、连贯 | 衡量语言质量 | 答案事实正确，但表达混乱，也会影响用户体验 |
其中，Faithfulness 是非常关键的指标，Faithfulness 关注的是：答案中的每一个关键事实，是否都能在检索上下文中找到依据？一般可以这样评估：
1. 将答案拆成多个原子事实 claim；
2. 判断每个 claim 是否能被上下文支持；
3. 计算被支持的 claim 占比。
例如答案是：
Skilled Worker visa 持有人可以携带配偶和子女，配偶需要满足 dependant partner 的资格要求，并且一定会自动获批。| Claim | 是否被上下文支持 |
|---|---|
| Skilled Worker visa 持有人可以携带配偶和子女 | 支持 |
| 配偶需要满足 dependant partner 的资格要求 | 支持 |
| 配偶一定会自动获批 | 不支持 |
如果 3 个 claim 中只有 2 个被支持，那么 Faithfulness 就不是满分。
生层层常见的问题有
| 问题 | 表现 | 可能原因 | 优化方向 |
|---|---|---|---|
| 答案跑题 | 没有直接回答用户问题 | prompt 不清晰、上下文噪声太多 | 优化 prompt、提高 context precision |
| 答案幻觉 | 编造上下文中没有的信息 | 生成约束不足 | 加 faithfulness check、要求基于上下文回答 |
| 答案不完整 | 漏掉关键条件或例外 | 上下文不足、模型总结不完整 | parent-child chunk、答案结构化 |
| 引用错误 | 引用不能支持对应结论 | citation 颗粒度太粗 | claim-level citation、引用校验 |
| 过度确定 | 把"可能""需要满足条件"说成"一定" | 缺少风险控制 | 增加不确定性表达和拒答策略 |
| 应该拒答但没有拒答 | 资料不足仍然强行回答 | 没有 answerability 判断 | 加 no-answer gate |
3.3 系统层评估
系统层评估关注的是：整个 RAG 系统是否能够在生产环境中稳定运行。
除了答案质量，一个生产级 RAG 系统还需要关注响应延迟、调用成本、知识库更新频率、空检索率、拒答率、用户反馈和回归测试稳定性。
常见指标包括 Latency、Cost per Query、Empty Retrieval Rate、No-answer Rate、User Feedback 和 Index Freshness等。
| 指标 | 含义 | 主要作用 | 示例 |
|---|---|---|---|
| Latency | 单次请求的响应时间 | 判断用户等待时间是否可接受 | 平均响应 2 秒和 20 秒，用户体验完全不同 |
| Cost per Query | 每次请求的平均成本 | 判断系统是否具备规模化运行能力 | 包括 embedding、rerank、LLM token 成本 |
| No-answer Rate | 系统拒答的比例 | 判断系统是否经常无法回答 | 拒答率过高可能说明知识库覆盖不足 |
| User Feedback | 用户点赞、点踩、人工纠错 | 衡量真实用户满意度 | 高频点踩问题应进入评估集 |
| Regression Stability | 系统更新后旧问题是否仍然答对 | 判断优化是否引入退化 | 换 embedding 后，旧测试集准确率是否下降 |
| Error Rate | 系统运行错误比例 | 判断系统稳定性 | API 超时、检索失败、LLM 调用失败 |
系统层评估的意义在于，帮助我们判断这个 RAG 系统是否不仅"能答对"，而且能够长期、稳定、低成本地服务真实用户。
4. LLM-as-a-Judge 与 RAGAS
在早期阶段，这些判断通常依赖人工评审。但随着大语言模型能力提升，越来越多的 RAG 评估开始引入自动化评估方法，其中最常见的就是 LLM-as-a-Judge ，以及基于这种思想构建的评估框架，例如 RAGAS。
4.1 LLM as a Judge
LLM-as-a-Judge的基本思想是：使用一个能力更强或更稳定的大模型作为评估器，让它根据预设评分标准，对 RAG 系统的输出进行打分和解释。
在 RAG 场景中，我们通常会把以下信息一起输入给 Judge LLM：
Question：用户问题
Retrieved Context：检索到的上下文
Generated Answer：RAG 系统生成的答案
Reference Answer：标准答案，可选
Citation：答案中的引用，可选然后让 Judge LLM 判断：
答案是否回答了用户问题？
答案是否基于检索上下文？
答案中是否存在上下文没有支持的事实？
答案是否遗漏了关键条件？
引用是否真的支持答案中的结论？
资料不足时，系统是否应该拒答？相比传统的字符串匹配或人工粗略打分，LLM-as-a-Judge 的优势在于它可以理解语义关系。例如，标准答案是：
Skilled Worker visa 持有人通常可以携带符合条件的 partner 和 children。模型回答是：
一般情况下，Skilled Worker 签证持有人可以让配偶或子女作为 dependant 一起申请，但他们需要满足相应条件。这两个答案在字面上不完全相同，但语义上基本一致。传统字符串匹配很难准确判断，而 LLM-as-a-Judge 可以更好地识别这种语义等价关系。它适合评估答案相关性、忠实度、完整性、引用准确性等传统指标难以覆盖的维度。但它也不是绝对可靠的。Judge LLM 也可能存在偏差、误判、打分不稳定等问题。因此，在生产环境中，通常需要结合人工抽样、明确 rubric、多模型交叉评估和回归测试来提升可靠性。
一个judge prompt设计案例如下
jsx
你是一个 RAG 系统评估员。
请根据用户问题、检索上下文和模型答案，评估该答案是否可靠。
你需要判断以下维度：
1. Answer Relevance：答案是否直接回答了用户问题？
2. Faithfulness：答案中的事实是否都能被上下文支持？
3. Completeness：答案是否覆盖了问题所需的关键要点？
4. Citation Accuracy：引用是否支持答案中的关键结论？
5. Refusal Accuracy：如果上下文不足，模型是否正确拒答？
评分规则：
- 1 分：完全满足
- 0.5 分：部分满足
- 0 分：不满足
请输出 JSON 格式：
{
"answer_relevance": 0-1,
"faithfulness": 0-1,
"completeness": 0-1,
"citation_accuracy": 0-1,
"refusal_accuracy": 0-1,
"reason": "简要说明评分原因"
}4.2 RAGAs
如果说 LLM-as-a-Judge 是一种评估思想，那么 RAGAS 就是一个把这种思想落地到 RAG 场景中的评估框架。
RAGAS，全称是 Retrieval Augmented Generation Assessment。它的目标不是只评估最终答案，而是分别评估 RAG 系统中的检索质量、上下文质量和生成质量。RAGAS 论文将其描述为一个面向 RAG pipeline 的 reference-free evaluation 框架，也就是在很多场景下不需要依赖人工标注的标准答案，就可以对 RAG 系统进行评估
一个典型的 RAGAS 评估样本通常包含以下字段：
| 字段 | 含义 | 是否必须 |
|---|---|---|
| question | 用户问题 | 必须 |
| answer / response | RAG 系统生成的答案 | 必须 |
| contexts / retrieved_contexts | 检索到的上下文 | 必须 |
| ground_truth / reference | 标准答案 | 部分指标需要 |
| reference_contexts | 标准上下文 | 部分指标需要 |
RAGAS 官方文档列出了多个面向 RAG 的指标，包括 Context Precision、Context Recall、Response Relevancy、Faithfulness、Noise Sensitivity 等。在实际测试中，我们可以选用我们需要的指标进行评估。
| 指标 | 对应层级 | 评估问题 | 解释 |
|---|---|---|---|
| Context Precision | 检索层 | 检索结果是否把相关内容排在前面？ | 衡量相关 chunk 是否排在无关 chunk 前面 |
| Context Recall | 检索层 | 检索结果是否覆盖了回答所需的信息？ | 衡量重要信息是否被成功检索出来 |
| Faithfulness | 生成层 | 答案是否忠实于上下文？ | 判断答案中的 claim 是否能被检索上下文支持 |
| Response Relevancy / Answer Relevance | 生成层 | 答案是否回答了用户问题？ | 判断答案是否切题，是否包含无关内容 |
当然，RAGAS也不是万能的，RAGAS 更适合作为自动化评估的一部分，而不是唯一标准。在实际环境中，我们可能还需要考虑人工复核，用户反馈等等其他补充方式，综合考虑从而提升RAG系统的效果。
5. 如何构建一套 RAG 评估流程
我们已经介绍了评估指标以及评估方法，现在介绍具体如何开展并构建完整的评估管道。
5.1 构建评估数据集
RAG 评估的第一步是构建评估数据集。很多人一开始会直接拿几个问题测试系统效果，但这种方式很难反映真实业务场景。
一个好的评估集应该覆盖不同类型的问题，而不是只包含简单事实问答。
| 问题类型 | 示例 |
|---|---|
| 简单事实问题 | Skilled Worker visa 可以携带配偶吗？ |
| 条件判断问题 | 未婚伴侣是否可以作为 dependant？ |
| 多文档问题 | dependant 申请需要满足哪些条件以及费用是多少？ |
| 时间敏感问题 | 当前 IHS surcharge 是多少？ |
| 概念混淆问题 | Spouse visa 和 Skilled Worker dependant 有什么区别？ |
| 不可回答问题 | 我的签证申请一定会通过吗？ |
| 多轮上下文问题 | 那我的孩子呢？ |
每条样本可以包含：
jsx
{
"question": "Skilled Worker visa 可以携带配偶吗？",
"gold_answer": "通常可以，但配偶需要满足 dependant partner 的资格要求。",
"gold_sources": [
"GOV.UK Skilled Worker visa: your partner and children"
],
"answerable": true,
"category": "skilled_worker_dependant",
"difficulty": "medium",
"freshness_required": true
}5.2 运行 RAG Pipeline 并保存 Trace
在评估 RAG 系统时，只保存最终答案是不够的。因为最终答案错误时，我们需要知道错误发生在哪个环节。
因此，在每次评估运行时，都应该保存完整 trace。
jsx
{
"question": "Skilled Worker visa 可以携带配偶吗？",
"rewritten_query": "Can a Skilled Worker visa holder bring their spouse as a dependant?",
"retrieved_chunks": [
"chunk_001",
"chunk_002"
],
"reranked_chunks": [
"chunk_002",
"chunk_001"
],
"final_context": [
"Skilled Worker visa holders may be able to bring their partner and children..."
],
"generated_answer": "可以。Skilled Worker visa 持有人通常可以携带符合条件的配偶作为 dependant。",
"citations": [
"GOV.UK Skilled Worker visa: your partner and children"
],
"latency": 2.8,
"cost": 0.01
}5.3 分层计算评估指标
拿到评估结果后，可以按照检索层、生成层和系统层分别计算指标。
其中，检索层指标更适合用标注好的 gold_sources 计算；生成层指标可以使用 LLM-as-a-Judge 或 RAGAS 辅助评估；系统层指标则通常来自日志和监控系统。
5.4 进行错误归因
当一个问题回答错误时，我们需要判断它属于哪种错误类型。
| 错误类型 | 表现 | 优化方向 |
|---|---|---|
| Indexing Failure | 正确文档没有入库 | 检查数据源、爬虫、解析流程 |
| Chunking Failure | 文档有答案，但 chunk 切分破坏语义 | 优化 chunk size、标题继承、parent-child chunk |
| Retrieval Failure | 正确 chunk 没有被召回 | 混合检索、query rewrite、多查询检索 |
| Ranking Failure | 正确 chunk 被召回但排名靠后 | reranker、RRF、metadata 加权 |
| Context Failure | 正确 chunk 没有进入最终上下文 | context packing、去重、topK 调整 |
| Generation Failure | 上下文有答案，但模型回答错 | prompt、faithfulness check、答案结构化 |
| Citation Failure | 引用不支持答案 | claim-level citation、引用校验 |
| Freshness Failure | 使用了过期文档 | 文档版本管理、更新时间过滤 |
5.5 建立回归测试机制
RAG 系统上线后仍然会持续变化。文档会更新，用户问题会变化，embedding 模型、reranker 和 prompt 也可能迭代。
因此，评估不能只做一次，而应该成为持续回归测试的一部分。
| 版本 | Recall@5 | Faithfulness | Citation Accuracy | Latency |
|---|---|---|---|---|
| V1 baseline | 0.72 | 0.81 | 0.76 | 2.1s |
| V2 hybrid retrieval | 0.84 | 0.83 | 0.78 | 2.5s |
| V3 hybrid + reranker | 0.86 | 0.89 | 0.85 | 3.4s |
通过这样的版本对比，我们可以判断一次优化到底带来了什么影响。比如加入 reranker 后，Faithfulness 和 Citation Accuracy 提升了，但 Latency 也上升了，那么就需要在效果和成本之间做权衡。
6. 如何根据评估结果优化 RAG 系统
不同错误对应不同优化方法：
| 错误类型 | 优化方向 |
|---|---|
| 检索不到 | 加 BM25、混合检索、query rewrite、多查询检索 |
| 排名靠后 | 加 reranker、RRF、权威来源加权 |
| 上下文不完整 | parent-child chunk、section expansion |
| 噪声太多 | metadata filter、阈值过滤、去重 |
| 答案幻觉 | 加 faithfulness 检查、引用约束 |
| 引用错误 | claim-citation 对齐检查 |
| 文档过期 | metadata freshness、版本管理 |
具体介绍优化方法我将在后续文章进行总结。
Reference/ 参考资料
RAGAs: Automated Evaluation of Retrieval Augmented Generation (Es et al., EACL 2024)