RAG 怎么评测才不自欺？把“答得像”拆成四层证据

Demo 演示时，RAG 经常表现得像个好学生：问题熟、答案顺、引用也挂上了。上线后换一个版本号，或者问一句带权限的问题，系统立刻开始一本正经地胡说。

先给一个能复述的答案

RAG 评测至少拆成数据质量、检索质量、证据使用和最终回答四层。数据层看文档是否完整、去重、可追溯；检索层看正确证据是否进入 top-k；证据层看引用是否支持结论；生成层看答案是否准确、完整、拒答得当。每层都要有可回放样本和失败归因。

一、先建一套真实问题集

问题集不要全由工程师临时编。来源可以是客服工单、搜索日志、面试题、线上 bad case 和业务同学的自然问法。每个问题至少记录：标准答案、必要证据、允许的版本范围、是否应该拒答、可接受的表达差异。

二、四层指标分别回答什么

层级	核心问题	可观察指标
数据	知识是否进得来、找得到	覆盖率、重复率、过期率
检索	正确证据是否进入候选	Recall@k、MRR、nDCG
证据	引用是否真的支持结论	引用准确率、证据完整率
生成	最终回答是否有用且诚实	正确性、完整性、拒答率、延迟

只看最终答案，会把四类问题压成一个分数。一个回答错了，工程师就不知道该重切文档、换召回器、调 prompt，还是修权限过滤。

三、离线评测和线上观测要接起来

离线集适合做回归：模型、索引或分块策略一改，就自动重跑。线上观测适合发现新问题：用户追问、点击引用、手动点踩、答案被复制或重新提问，都能作为反馈信号。

但线上反馈不能直接当真值。用户没点击引用，可能是答案已经够用，也可能是引用坏了。反馈要和人工抽样、问题类型和版本信息一起看。

四、失败归因比总分更重要

每个 bad case 最少保留 query、改写 query、召回列表、重排列表、最终上下文、答案和引用。复盘时先判断：正确证据是否存在？如果存在，在哪一步掉了？如果不存在，知识库是否应该有它？这套证据链比“换个 prompt 试试”更能让系统变好。

60 秒面试回答

“我们把 RAG 评测拆成四层：数据质量、检索质量、证据使用和最终生成。用真实问题集回放，分别看覆盖率、Recall@k、MRR、引用准确率、答案正确性和拒答率；线上再采集追问、点击和人工抽样。每个 bad case 保留完整 trace，先定位掉链环节，再决定改数据、检索、重排还是生成。”

继续追问

• 没有标准答案时，如何做人工评测？
• LLM-as-a-judge 如何避免评委偏差？
• 如何把评测集接入 CI，防止索引更新后质量回退？