RAG 项目怎么评测?
面试官问:RAG 项目怎么评测?这道题如果只会说准确率、召回率,那基本就凉了。因为面试官真正想听的不是背了几个指标,而是能不能把一个 RAG 系统的问题拆开定位。
记住这句开场:
"RAG 评测不能只看最终答案对不对,因为它有两个可能出错的地方:第一,检索可能没拿到对的资料;第二,资料拿对了,模型也可能乱编。所以我一般会把评测拆成三层:检索评测、生成评测、端到端业务评测。"
这一句话说出来,面试官基本就知道你不是在背八股了。
评测全景图
第一层:检索质量评测
RAG 的第一步是把相关资料找出来。如果这一步错了,后面大模型再强也没用。
这里重点看两个指标:
Context Precision(上下文精确率)
它关心的是:召回的这些 chunk 里面到底有多少是真有用的?
比如用户问:"退款多久到账?"结果召回了一堆"发票规则"、"会员权益"、"优惠券说明"——这些内容虽然都来自知识库,但对当前问题没帮助,这就是精确率低。
精确率 = 1/4 = 25%。4 个 chunk 里只有 1 个真正有用。
Context Recall(上下文召回率)
它关心的是:回答这个问题必须用到的信息有没有都找回来?
比如一个问题要同时依赖"退款条件"和"到账时间"两段内容,只召回了到账时间,没召回退款条件,模型就很容易答得不完整。
召回率 = 1/2 = 50%。必须的 2 段内容只召回了 1 段。
检索阶段的核心
不是"有没有召回",而是两个字:准不准、全不全。
第二层:生成质量评测
检索对了不代表答案就一定对,因为大模型可能拿着正确资料最后生成一个错误答案。
Faithfulness(忠实度)
它看的是:模型的回答是不是完全基于召回上下文,有没有自己脑补。
比如文档里只写了"退款一般 3-7 个工作日到账",模型回答成"最快当天到账",这就是典型的不忠实——也就是幻觉。
Answer Relevancy(答案相关性)
它看的是:答案有没有真正回答用户问题。
有些答案看起来事实都对,但用户问的是"怎么申请退款",模型却解释了一大段"退款规则是什么",这就叫答非所问。
生成阶段的核心
用指标反推问题(加分项)
真正加分的地方,是你要会用指标反推问题。
这才是面试官最想听的:不是"我会看指标",而是"我能根据指标定位系统问题"。
第三层:评测方法
RAG 评测不能靠拍脑袋,一定要有一套黄金数据集(Golden Dataset)。
Golden Dataset 的结构
一般可以先人工整理几十到一百条测试样本,每条样本至少包含三样东西:
评测流程
常用工具
| 工具 | 特点 | 适用场景 |
|---|---|---|
| RAGAS | 轻量级 | 快速跑 RAG 四件套(Precision、Recall、Faithfulness、Relevancy) |
| DeepEval | 与 pytest/CI 集成好 | 工程化流程、持续集成 |
| TruLens | 偏线上观测 | 链路分析、生产环境监控 |
没有测试集怎么办?
如果项目初期没有测试集,也可以让 LLM 基于文档生成一些合成问题。
但这里一定要强调一句:
合成数据必须人工抽检。 因为大模型很容易生成那种看起来很合理但原文根本没有依据的假问题。
完整的 RAG 评测三层体系
| 层级 | 评测内容 | 典型指标 |
|---|---|---|
| 组件级 | 单独比较 embedding、reranker、chunk 策略 | Hit Rate、MRR、NDCG |
| 端到端 | 整个 RAG 链路表现 | Context Precision、Context Recall、Faithfulness、Answer Relevancy |
| 业务级 | 最终用户体验 | 用户满意度、人工抽检通过率、badcase 率、转人工率、追问率 |
指标再漂亮,业务方觉得"不好用",那这个 RAG 系统就是没做好。