怎么考「RAG 的召回率怎么评估？测试集从哪来？」

我要答我要考
Q2-15RAG 评测中高频

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

开场怎么问

你说优化后效果变好了，怎么衡量的？

换个问法

  • 你们的评测集有多少条？怎么标的？
  • 召回率、准确率这些指标你们看哪个？

五层追问链

左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。

LLM 生成的评测集靠谱吗？

期望
可以用来扩量但不能全信——LLM 基于 chunk 反向生成问题，天然和该 chunk 高度匹配，会让指标虚高（问题里往往复用了原文措辞，检索当然容易命中）。所以：生成后必须人工筛，且要刻意改写成口语化问法；核心评测集仍应以真实用户 query 为主。
信号
这题是很好的探针——能说出「反向生成会让指标虚高」的，是真跑过这个流程。

k 取多少？recall@5 还是 recall@20？

期望
分两处看——recall@候选数（如 recall@50/100）衡量第一阶段召回是否漏，用来决定 rerank 的候选数；recall@最终条数（如 recall@5）衡量端到端。两个 k 服务不同决策，不能混为一谈。
信号
只报一个 k 且说不出用途的，评测体系不完整。

没有标注答案的情况下能评吗？

期望
能，但换指标——用 LLM-as-Judge 的 reference-free 指标（faithfulness、answer relevancy，见 Q2-16）；或用线上信号（点踩率、追问率、人工转接率）做代理指标。但 context recall 这类指标必须有标准答案或 gold chunk 才能算准，这是没法绕过的。
信号
能区分「哪些指标免参考、哪些必须有标注」的，说明真用过评测框架。

线上怎么持续发现问题？

期望
badcase 闭环——点踩、客服反馈、抽样人工审 → 归因分类（分块/召回/排序/生成/知识库缺失）→ 按量级排优先级 → 针对性改一个变量 → 加进回归集。回归集只增不减，是防止「修 A 打坏 B」的唯一保障。
信号
能说出「badcase 要沉淀进回归集」的，有工程闭环意识。

你们评测集上 recall@5 有 0.85，但用户还是投诉搜不到，怎么解释？

期望
几种可能都要能想到——① 评测集覆盖不了真实分布（用户真实问法比评测集更口语、更长尾）；② 分桶后某一类特别差，被总平均掩盖；③ 问题出在评测集没覆盖的环节（生成不忠实、上下文组装丢了材料、权限过滤误杀）；④ 知识库本身就没有这个答案。排查动作是：把投诉 case 逐条加进评测集重跑，看是不是评测集失真。
信号
第一反应是「那就再提高 recall」的，没意识到问题可能出在评测集本身。

危险信号

听到这些话，基本可以判定是背题而不是做过。

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

评分卡

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

考察意图

这是整章隐含的「资格题」——前面所有优化类回答（调 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。

攒够了去组卷页一键生成可打印的面试题单