很多人在回答“RAG系统怎么评估”时，只会说一句“看最终答案准不准”。 这其实只答到了最表层。真正成熟的回答，必须把 测试集、检索层、生成层、线上闭环 拆开讲清楚。因为 RAG 不是一个单模型，而是一整条链路：测试集质量不行，指标会失真；检索捞不到证据，生成再强也答不对；生成阶段乱总结，检索再好也会翻车。
1. 这道题为什么高频：面试官到底在考什么
1.1 这题考的不是“你会不会背几个指标名”
很多人以为，面试官问 RAG 评估，就是想听 ROC、AUC、准确率这一类通用指标。其实不是。RAG 的关键问题，是“系统有没有把正确证据找出来，并基于这些证据给出可信、完整、贴题的回答”。所以它考的是你是否具备“系统拆解能力”，而不是“指标名背诵能力”。
1.2 为什么不能只看最终答案
如果你只看最终答案，有两个典型问题会被埋掉。第一，答案错了，但你不知道是检索没捞到，还是模型自己编了。第二，答案看起来差不多，但其实引用的证据不对、排序不对、漏掉了关键限制条件。真正成熟的 RAG 评估，一定是分层评估。
1.3 高分回答的核心框架
最稳妥的回答方式，是先说明：我会把 RAG 评估拆成四部分——测试集构建、检索层评估、生成层评估、线上闭环。然后再逐层展开。这样的回答结构一出来，面试官基本就能判断你不是停留在概念层。
2. 测试集怎么构建：这是 RAG 评估的地基
2.1 测试集不是“问题清单”，而是“完整样本”
一个真正能用来评估 RAG 的样本，至少要包含这些字段：query、reference_answer、supporting evidence、retrieval ground truth、问题标签。换句话说，它不仅要告诉你“用户问了什么”，还要告诉你“标准答案应该是什么”“哪些证据能支撑答案”“哪些文档或 Chunk 算相关”，以及“这是什么类型、什么难度、是不是应该拒答的问题”。
从官方评估工具的设计也能看出这点。Vertex AI 的评估数据集文档明确把 prompt、response、reference 作为常见输入字段，并说明实际评估集通常会有 100 条以上的数据点；Azure Foundry 的 RAG 检索评估还要求 retrieval_ground_truth 和 retrieved_documents 这类字段，说明检索层单独做金标，是很多平台的共识。
2.2 样本最好从哪里来
优先级最高的一定是真实用户问题和真实业务日志，因为它最接近线上；FAQ、制度文档、 知识库 问答可以补充高频事实型问题；历史工单、复杂聊天记录可以补充长尾问题；合成数据可以用来补盲区，但不建议整套测试集都靠模型自己生成。否则很容易出现“模型出题、模型作答、模型给自己打高分”的假繁荣。
2.3 样本一定要分层
如果测试集全是“单文档、单事实、短问题”，你的系统哪怕很一般，也能拿到一个不错的分数。真正能拉开系统差距的，是复杂样本：跨段抽取、多文档对比、多跳问题、时效性问题、证据不足必须拒答的问题。
一个实用的做法，是把测试集按任务类型和难度拆成小桶：事实 问答 、汇总总结、比较归纳、多跳问题、时效问题、拒答问题；每类里再分简单、中等、困难。最后不要只看一个总分，而是看每一桶分别表现如何。
2.4 检索金标怎么做
这是很多人最容易漏掉的一步。你如果只写“问题 + 标准答案”，只能评估生成层；你评不了检索层。要评估检索，最好给每个 query 标注相关文档或相关 Chunk，并且最好给出分级相关度标签。
Elasticsearch 的 ranking evaluation 文档就把检索评估的三件事讲得很清楚：要有文档集合、典型查询，以及针对查询的文档相关性评级。有了这套东西，你才可以算 MRR、precision、discounted cumulative gain 这些指标。也正因为如此，RAG 里如果要认真做检索评估，几乎绕不开人工相关度标注。
3. 检索层怎么评估：别只会说 Recall
3.1 HitRate@K / Top-N 准确率
这个指标最适合先做冒烟检查。它看的不是“前 K 个结果有多干净”，而是“前 K 个结果里，至少有没有一个正确证据”。如果连这个都做不到，说明系统在最基础的召回上就已经有问题了。
3.2 Recall@K：看有没有漏证据
Recall@K 关注的是“该捞回来的证据，你实际捞回来了多少”。对多跳问题、跨文档问题，它尤其重要。因为这类问题往往不是找到 1 条证据就够，而是要找到多条证据才能把答案拼完整。
3.3 Precision@K：看前排干不干净
Precision@K 关注的是“前 K 个结果里，有多少是真的相关”。这个指标很适合帮助你判断检索结果是不是太脏。如果 Recall 很高，但 Precision 很低，说明系统虽然捞到了答案，但同时也塞进去了很多噪声，后面的生成模型很容易被带偏。
3.4 MRR：看第 1 条相关结果够不够靠前
MRR 的价值在于判断“用户最先看到的检索结果，是不是就很靠谱”。如果第一个相关 Chunk 总是排得很靠后，虽然 Recall 可能不低，但实际生成时模型未必会优先使用到关键证据。
3.5 nDCG：看排序整体是不是合理
如果你的相关度不是简单二元标签，而是分了 0、1、2、3、4 这样的等级，那么 nDCG 会比单纯的 Recall 或 MRR 更适合。它衡量的是“你的排序结果和理想排序有多接近”，因此非常适合评估有分级相关度标签的企业知识库场景。
Ragas 的 Context Precision 文档强调，context precision 会看相关块是不是排在更前面；Context Recall 文档则强调不要漏掉重要结果。Azure Foundry 的 document_retrieval 评估器又进一步把 NDCG、Fidelity、XDCG、Max Relevance 等组合在一起，说明成熟平台已经普遍不再满足于只看单个检索指标。
3.6 检索层最常见的误区
只看 Recall，不看 Precision，结果把一堆噪声也喂给了模型。
只看 HitRate，不看排序，结果“捞到了，但排得太靠后”。
只标文档，不标 Chunk，最后无法判断切分策略到底有没有提升。
把所有问题混在一起做一个总分，看不见多跳问题和拒答问题的真实表现。
4. 生成层怎么评估：别把“像对”当成“真对”
4.1 Groundedness / Faithfulness：有没有胡说
这是 RAG 最核心的生成指标之一。它问的不是“回答听起来像不像标准答案”，而是“这段回答是不是能被当前检索出来的上下文严格支撑”。Azure AI Content Safety 的 groundedness 检测，核心就是识别回答是否偏离了提供的源材料；Azure Foundry 的 RAG evaluators 也把 groundedness 单列出来，强调它关注的是回答的“精确约束”——不能说出上下文之外的东西。
4.2 Relevance：有没有答到点上
有些回答几乎没胡说，但就是不回答问题，或者回答了一堆正确废话。这时候 Groundedness 可能不低，但 Relevance 会很一般。它看的重点，是回答和问题之间是否真正对齐。
4.3 Correctness：关键事实对不对
Correctness 一般需要 reference answer，也就是标准答案。它是“回答与标准答案的一致性”问题。LangSmith 的 RAG 教程就把 answer correctness 和 answer vs reference answer 放在核心评估项里，这也是为什么前面我一直强调测试集必须要有标准答案。
4.4 Completeness：有没有漏掉关键点
企业知识库场景里，最常见的问题不是胡说，而是漏答。比如制度条款里有“适用条件”和“例外条件”，模型只说了主规则，没说限制条件。这个时候 Correctness 看起来不一定差，但 Completeness 会很危险。Azure Architecture 的 RAG 评估文档就专门把 completeness 单列出来，并提醒不同指标服务不同目标，不要只盯着一个指标。
4.5 拒答准确率：该闭嘴的时候会不会闭嘴
RAG 系统在证据不足、知识库无答案、问题越权时，最理想的行为不是硬答，而是拒答或引导用户补充信息。所以在很多高风险业务里，拒答准确率实际上比普通问答准确率更重要。这个指标常常单独成组来测。
4.6 生成层最常见的误区
Groundedness 高，就误以为答案一定高质量。其实它只说明“没乱编”，不代表“答完整了”。
Correctness 高，就误以为检索没问题。其实有时候标准答案太宽松，会掩盖检索排序不佳。
只看一个总分，不做原因分析，最后无法知道是偏题、漏答还是幻觉。
5. 指标一旦异常，应该怎么定位
真正区分熟手和新手的，不是会不会念指标名，而是能不能根据指标组合定位问题。
5.1 如果 Recall@K 低，MRR 也低
大概率是检索基础能力有问题。优先查这几件事：chunk 切分是否太碎或太长； embedding 模型是否不适合当前语料；query 是否需要改写；top_k 是否太小；有没有少了一路关键召回，比如关键词召回、结构化过滤、重排前粗召回。
5.2 如果 Recall 高，但 Precision 低
说明系统捞得多，但前排太脏。这个时候重点不是继续加召回，而是做更好的排序和过滤，比如引入 rerank、元数据过滤、query 意图识别和更稳的召回融合。
5.3 如果检索指标高，但 Groundedness 低
说明证据其实到了，但生成阶段在乱总结。这个时候要看 提示词 是不是太开放、上下文拼接是不是太乱、模型温度是不是偏高、是否缺少引用约束和答案格式约束。
5.4 如果 Groundedness 高，但 Correctness 或 Completeness 低
这种情况最容易让人误判。它往往说明：模型确实基于上下文在回答，但上下文本身不完整，或者模型没有把多条证据融合好。此时应该反查测试集证据标注是不是充分，以及当前检索是否支持多跳证据的完整召回。
6. 离线评估之外，还要看什么
6.1 离线评估解决的是“可回归”
离线测试集最大的价值，是让你可以做版本对比、参数 sweep、回归检查。LangSmith 的官方 RAG 评估流程就是：先建 数据集 ，再跑应用，再用评估器测表现；Azure Foundry 也强调可以用 document_retrieval 去对比不同 search algorithm、top_k、chunk size 的表现。
6.2 线上监控解决的是“真实用户体验”
线上要看的，往往不是单一学术指标，而是空检率、引用覆盖率、用户追问率、人工转接率、回答延迟、单次成本、投诉率等。这些指标不一定优雅，但很真实。
6.3 人工抽检和 A/B 解决的是“指标和体验是否一致”
再漂亮的分数，也可能和真实体验不完全一致。所以最稳的做法，是离线分层评估 + 线上监控 + 人工抽检一起看。特别是高价值场景，最好再加上版本 A/B，对比用户真实反馈。
7. 面试时到底怎么答，最加分
7.1 60 秒版本
我会把 RAG 评估拆成三层。第一，先构建高质量测试集，至少包含 query、标准答案、支持证据和检索金标；第二，检索层看 HitRate/Recall@K、Precision@K、MRR、nDCG，判断有没有召回、前排纯不纯、排序好不好；第三，生成层看 Groundedness、Relevance、Correctness、Completeness，必要时补拒答准确率。最后再用线上监控和人工抽检做闭环。如果检索分高而生成分低，我就优先查提示词和生成链路；如果检索分低，就重点查切分、召回和重排。
7.2 3 分钟扩展版
如果面试官继续追问，我会进一步补一句：测试集必须分层，至少要覆盖事实问答、汇总、比较、多跳、时效和拒答场景；并且不要只看一个总分，而要看分桶表现。真正成熟的评估，不是只告诉你“系统好不好”，而是能告诉你“哪一层出了问题、下一步该改哪里”。
8. 总结：把这题答完整，其实就一句话
RAG 评估的本质，不是看一个“大而全”的总分，而是把 测试集、检索、生成、线上反馈 串成闭环。
你如果只会说“看最终答案对不对”，这道题只能答到及格线；你如果能讲清楚测试集怎么建、检索指标怎么拆、生成指标怎么拆、指标异常时怎么定位，再补上线上闭环，基本就是高分回答。
面试里最有力量的一句，不是“我们用过某某框架”，而是“我知道每个指标在评什么，也知道指标一旦异常该去查哪一层”。
