RAG 的召回率怎么评估?测试集从哪来?

Q2-15RAG 评测高频召回率recall评测集分桶MRRNDCG

谁在问:二面必问;「你怎么知道优化有效」是所有优化类回答的必然追问

口语化问法

  • 你说优化后效果变好了,怎么衡量的?
  • 你们的评测集有多少条?怎么标的?
  • 召回率、准确率这些指标你们看哪个?

考察意图

这是整章隐含的「资格题」——前面所有优化类回答(调 chunk、加 rerank、上混合检索)的可信度都取决于这一题。面试官想确认:① 你有没有评测集,还是全凭感觉;② 标注对象是不是 chunk 级别(很多人答成「问答对」,暴露没做过检索评测);③ 有没有分桶意识——只看总平均会掩盖局部劣化

参考答案

图 2 · 60 分与 90 分差在哪:代价、演进、怎么验证

60

60 分答案(及格线)

检索侧主要看 Recall@k(正确文档有没有进候选)、Precision@k(候选里相关的比例)、MRR(第一个正确结果排第几)、NDCG@k(整体排序质量)。优先级是先保 Recall——没进候选,后面全白搭;漏召回是不可逆的,排序错还有 rerank 能救。

测试集来源:优先从真实用户提问日志里抽;没上线就自己写,或让 LLM 基于文档生成候选问题再人工筛。人工标注每个问题对应的正确 chunk。

90

90 分答案(有生产经验的回答)

补四层:

规模不必大,100–200 条起步就够用。很多团队因为「凑不齐一千条」迟迟不建评测集,结果所有优化都是玄学。先有一个小而准的集合,远胜于没有。

必须分桶——按问题类型标注:事实型 / 多跳型 / 专有名词型 / 口语型 / 知识库里没有答案的。理由是:某个改动可能提升总分却打坏某一类。比如加了 BM25 之后总平均涨了,但语义类 query 那一桶掉了——总平均会把这件事藏起来。分桶评测是发现局部劣化的唯一方法。

必须有一类是「知识库里没有答案」的问题,用来测系统会不会老老实实说不知道。这类样本几乎所有人都会漏掉,但它对应的是生产中最危险的失败模式——一本正经地胡编。

标注对象是 chunk 级别,不是文档级别。因为你要评估的是「正确的那一块有没有被召回」,文档级别的标注太粗,一份 200 页文档里对的和错的都算命中,指标就失真了。

再补一个方法论:一次只改一个变量。同时换了 embedding 又改了 chunk 大小,效果变了也不知道是谁的功劳。改动跑全量回归,防止修 A 打坏 B。

追问链

图 1 · 五层追问树:面试官会往哪儿挖
整章的资格题:前面所有「优化后变好了」都靠这一题兜底

  1. LLM 生成的评测集靠谱吗?

    期望扩量不能全信:基于 chunk 反向生成的问题天然与该 chunk 高度匹配、还复用了原文措辞,指标虚高;生成后必须人工筛、刻意改写成口语化问法,核心集仍以真实用户 query 为主
    信号说得出「反向生成会让指标虚高」→ 真跑过这个流程,这题是很好的探针
  2. k 取多少?recall@5 还是 recall@20

    期望分两处看:recall@候选数(如 recall@50 / recall@100)衡量第一阶段漏没漏、用来定 rerank 的候选数;recall@最终条数(如 recall@5)衡量端到端。两个 k 服务不同决策,不能混为一谈
    信号只报一个 k、说不出它服务哪个决策 → 评测体系不完整
  3. 没有标注答案的情况下能评吗?

    期望能但要换指标:LLM-as-Judge 的 reference-free 指标(faithfulnessanswer relevancy)+ 线上代理指标(点踩率、追问率、人工转接率);但 context recall 这类必须有标准答案或 gold chunk 才算得准
    信号能分清「哪些指标免参考、哪些必须有标注」→ 真用过评测框架
  4. 线上怎么持续发现问题?

    期望badcase 闭环:点踩 / 客服反馈 / 抽样人工审 → 归因分类(分块 / 召回 / 排序 / 生成 / 知识库缺失)→ 按量级排优先级 → 针对性改一个变量 → 加进回归集。回归集只增不减,是防「修 A 打坏 B」的唯一保障
    信号说得出「badcase 要沉淀进回归集」→ 有工程闭环意识
  5. 评测集上 recall@5 有 0.85,用户还是投诉搜不到,怎么解释?

    期望四种可能逐个排:① 评测集覆盖不了真实分布(真实问法更口语更长尾);② 分桶后某一类特别差,被总平均掩盖;③ 病在评测集没覆盖的环节(生成不忠实、上下文组装丢了材料、权限过滤误杀);④ 知识库本身就没这个答案 → 动作是把投诉 case 逐条加进评测集重跑,先看是不是评测集失真
    信号第一反应是「那就再把 recall 提上去」→ 没想到问题可能出在评测集本身
中间三层只考手艺,真正的筛子是第 1 层和第 5 层:一个探你知不知道「反向生成会让指标虚高」,一个探你敢不敢怀疑自己的评测集。

评分要点

  1. 能列出 Recall@k / Precision@k / MRR / NDCG 并说明各自用途
  2. 明确「先保 Recall」的优先级及理由(漏召回不可逆)
  3. 评测集来源优先真实日志
  4. 标注对象是 chunk 级别
  5. 有分桶意识,知道总平均会掩盖局部劣化
  6. 加分:包含「知识库里没有答案」这一类样本
  7. 加分:知道 LLM 生成评测集会让指标虚高
  8. 加分:一次只改一个变量 + 回归集

常见错误

「靠人工看效果」——没有评测集,前面所有优化的可信度归零。
标注到文档级别而非 chunk 级别。
只看总平均,没有分桶。
用 LLM 生成评测集且完全不做人工筛,指标虚高而不自知。
说不出 k 的取值依据。
badcase 修完就完了,不沉淀进回归集。

关联学习