RAG 召回准确性：三大失败场景

30 秒回答

1. 能清晰区分检索阶段与生成阶段的评估差异
2. 掌握常用检索评估指标（Recall@K、MRR、NDCG）
3. 理解稠密检索与稀疏检索的优缺点及混合策略
4. 知道重排序模型的作用与典型实现

回答与解析

答案要点

• 能清晰区分检索阶段与生成阶段的评估差异
• 掌握常用检索评估指标（Recall@K、MRR、NDCG）
• 理解稠密检索与稀疏检索的优缺点及混合策略
• 知道重排序模型的作用与典型实现
• 能提出具体可落地的数据优化方案

一、评估维度与指标

检索阶段 vs 生成阶段

• 检索评估：关注"找得准不准"，用Recall@K（答案是否在TopK）、MRR（首个相关文档排名）、NDCG（考虑相关度分级）
• 端到端评估：用Answer Accuracy或RAGAS框架（context precision/recall, answer relevance等）

二、检索模型优化

双路召回策略

• 稀疏检索（BM25）：关键词匹配，对专有名词、ID类查询效果好，可解释性强
• 稠密检索（Embedding）：语义理解能力强，需选合适模型（bge、m3e等），注意领域适配
• 混合检索：BM25 + 向量分数加权融合，或RRF（Reciprocal Rank Fusion）合并结果

Embedding优化

• 领域微调：用业务数据对比学习训练
• 查询改写：HyDE（生成伪文档再检索）、Query2Doc扩展

三、重排序（Rerank）策略

• 交叉编码器（Cross-Encoder）：精度高但慢，适合精排Top100→Top10
• ColBERT等轻量方案：平衡效率与效果
• 多任务学习：结合点击日志训练排序模型

四、数据质量治理

五、快速验证方法

• 构建黄金测试集：100-500条人工标注的(query, 相关doc)对
• 错误分析：按bad case类型（漏召回、误召回、排序错）分类优化

口语版讲法(约4分钟)

• 一句话定位：RAG召回评估与提升的本质是匹配问题
• 评估指标：Recall@K和MRR的适用边界
• 检索模型：混合检索的落地取舍
• 重排序：Cross-Encoder的精度与成本
• 数据质量：切分与清洗的坑
• 收尾与可延伸点：GraphRAG的适用场景

这道题其实是在问，怎么让RAG系统从知识库里精准捞出有用的信息，本质是个匹配问题。我主要从评估、检索模型、重排和数据质量几个角度来说。

先说评估。检索阶段和生成阶段的关注点不一样，检索阶段我只看召回率，就是正确答案在不在TopK里，用 Recall@K 来衡量。如果场景对顺序敏感，比如客服系统里必须把最相关的退款政策排第一，那我还会看 MRR，也就是第一个正确答案的排名。但端到端评估像RAGAS那种，是测最终答案好不好，这跟检索评估是两码事，我一般分开看。

然后说检索模型优化。这里有个很实际的选择：用关键词还是向量。关键词检索像 BM25，对专有名词、订单号这类精确匹配特别稳，可解释性强，但语义理解弱。向量检索 Embedding 语义能力强，但领域不匹配时效果会崩。真正落地我倾向 混合检索，把 BM25 和向量分数加权融合，或者用 RRF 合并排名。举个例子，在企业SOP合规文档场景，员工问“报销流程”，关键词可能漏掉“费用申请”这种同义词，向量能补上；但如果搜“合同编号123”，关键词更准。所以两条腿走路更稳。

这里有个前提，就是向量模型要领域适配。直接用通用模型，比如中文场景用开源的bge，如果不微调，对业务术语的理解可能不准。常见失败场景是，把“满减”和“优惠券”当成不相关的向量，导致漏召回。所以我会用业务数据做对比学习微调，或者用 HyDE 先生成伪文档再检索，能缓解一点。

再一个就是重排序策略。检索阶段拿回Top100，但精度不够，需要精排。我一般用 Cross-Encoder 模型，它把查询和文档同时输入做交互，精度高，但慢，所以只对Top100做重排，取Top10。另一个方案是 ColBERT，用后期交互平衡效率和效果，适合在线场景。但重排不是万能的，如果检索阶段Top100里就没有正确答案，重排也救不了。所以我会先保证检索召回率，再靠重排提升排序质量。

数据质量这块，最容易被忽视。文档切分是个大坑，固定按500字切，可能把完整逻辑切碎。我倾向语义切分，按段落或主题分，控制chunk在300到500 tokens。另外，信息密度低的内容，比如网页里的广告、无关注释，要清洗掉。还有个坑：多跳关联的文档，比如一个政策引用了另一个政策，如果没显式链接，检索会漏。我有时会用 知识图谱 来显式关联，但成本高，只有关键场景才做。

最后提一句，如果知识库有强关联结构，比如法律合同引用了多个条款，我会考虑用 GraphRAG 来增强召回，但它的工程复杂度很高，不是所有场景都值得。

所以总结一下，我会把召回优化看成一条链路：先保证数据质量，再选合适的检索模型，用重排兜底，评估时关注Recall@K和MRR。我更倾向于混合检索加领域微调这个组合，因为它在大多数业务场景里性价比最高。

关键一句:GraphRAG适合强关联结构的知识库，但工程复杂度高

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做电商客服RAG，用户问“订单怎么还没到”，系统得从知识库召回物流规则。你怎么评估召回来的文档是不是真的相关？如果召回结果不准，你会从哪些方面去提升？

2. 问法 2 · 层层追问

   在RAG系统里，你怎么保证召回文档的相关性？……指标用什么？……如果召回率低，你会先优化检索模型还是数据？……重排序怎么加进去？

3. 问法 3 · 直球架构

   请系统性地讲一下RAG中召回文档相关性和准确性的评估与提升方法，包括检索模型选择、数据质量治理和重排序策略，具体怎么落地？