考察点
这道题出自字节跳动 AI 岗一面，考的是评测意识——这是区分「做过 RAG」和「真的把 RAG 做上线了」的关键问题。面试官想听你讲清楚两件事：一是 RAG 要分层评测，不能只看端到端；二是任何孤立指标都没有意义，0.81 好不好取决于基线、业务要求和评测集本身。追问常往「评测集怎么构造」「生成质量怎么自动评」「线上怎么监控」走。
参考答案
先拆层：检索和生成分开评
RAG 出问题有两种完全不同的死法：检索没召回对（巧妇难为无米之炊），和检索召回了但模型没用好（幻觉、答非所问）。混在一起评端到端准确率，出了问题你根本不知道改哪边。所以我的评测体系是分层的。
检索层指标：
- Recall@K：标准答案所依据的文档片段，是否出现在检索结果的 top-K 里。这是最核心的指标，直接决定生成质量的上限。
- MRR / nDCG：不只看有没有，还看排得多靠前。正确文档排在第 1 位和第 5 位，对生成的影响差别很大。
- 如果链路里有 rerank，还要单独看 rerank 前后的对比，确认 rerank 真在起作用。
生成层指标：
- 忠实度（faithfulness）：答案的每个论断是否能被检索到的上下文支持。这是幻觉的直接度量。
- 答案相关性：答案是否真正回应了用户问题，而不是复述了一堆相关但不解答的内容。
- 自动化手段主要是 LLM-as-judge：用强模型按打分标准评， Ragas 这类框架也是这个思路。自动评测前要先用一批人工标注样本验证 judge 模型和人工判断的一致率，一致率不行就先调 judge 的 prompt。
端到端指标：带标准答案的评测集上算答案正确率（人工评或 judge 评），这是最终交付质量的度量。
Recall@5 = 0.81，是好是坏？
孤立的 0.81 没法下结论，我会从四个角度去定位它：
- 对比基线。如果切分策略或 embedding 模型换一版之前是 0.72，那 0.81 是实打实的进步；如果竞品方案或简单调参（比如 top-5 改 top-10）就能到 0.90，那 0.81 说明还有明显的坑没填。指标只有放在对比里才有意义。
- 看业务容忍度。Recall@5 = 0.81 意味着五分之一的问题，正确文档根本不在上下文里——这部分请求注定答错或幻觉。客服场景答错五分之一可能直接不可用；内部知识库助手里，配合拒答机制（检索分数低就说不知道）也许可以接受。关键问题是：漏掉的 19% 是均匀地漏，还是集中在某类问题上？
- 拆开看分布。总量指标会掩盖结构性问题。按问题类型、文档类别、query 长度分桶看 recall，常见的情况是某些桶只有 0.5——比如表格类、多跳类问题集中漏召。这比总召回率更有指导意义。
- 检查评测集本身。0.81 还可能反映评测集的问题：标准答案标注错了（答案其实在文档里但标错了片段）、评测集和线上真实 query 分布不一致。指标异常时先怀疑尺子，再怀疑系统。
基于 0.81 往上提的常规手段：调 chunk 大小和重叠、换 embedding 模型（比如中文场景试 bge-m3）、加 BM25 混合召回、加 rerank、做 query 改写。每改一步在同一个评测集上重测，这才是指标存在的意义——让迭代有方向。
线上持续验证
离线评测集代表不了全部，上线后还要有线上闭环：埋点收集用户的点赞点踩、追问率、转人工率；定期抽样人工 review；线上 query 聚类后把高频 badcase 回灌进离线评测集，评测集跟着业务一起长。
可能的追问
- 评测集怎么构造、要多大规模？ 答：从真实历史 query 抽样 + 人工按业务场景补边界 case，每条标注答案和依据的文档片段；起步阶段 100-300 条就能跑起来，关键是覆盖分布、持续扩充，而不是一次凑几千条。
- LLM-as-judge 可靠吗？ 答：不完全可靠，必须用人工标注校准过一致率（比如 85% 以上）才能用于回归测试；它适合看趋势和做 A/B 对比，不适合当绝对真理。
- Recall@5 和 Recall@10 怎么选 K？ 答：K 要和线上真实配置一致——线上 top-5 进上下文就评 Recall@5，否则指标反映不了线上行为；另外 K 越大 recall 天然越高，报数字必须带 K。