完整题目
在检索增强生成（RAG）系统中，如何评估并提升从知识库中召回文档的相关性与准确性？请从检索模型、数据质量、重排序策略等方面进行阐述。
本文目录
答案要点
- 能清晰区分检索阶段与生成阶段的评估差异
- 掌握常用检索评估指标（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等轻量方案：平衡效率与效果
- 多任务学习：结合点击日志训练排序模型
四、数据质量治理
| 问题类型 | 解决方案 |
|---|---|
| 文档过长 | 语义切分（按主题/段落），控制chunk 300-500 tokens |
| 信息密度低 | 清洗HTML标签、广告，提取核心内容 |
| 多跳关联 | 构建知识图谱，显式链接相关文档 |
| 时效性 | 时间戳过滤，新文档加权 |
五、快速验证方法
- 构建黄金测试集：100-500条人工标注的(query, 相关doc)对
- 错误分析：按bad case类型（漏召回、误召回、排序错）分类优化
换一种问法，检查是否真正理解
场景切入
假设你在做电商客服RAG，用户问“订单怎么还没到”，系统得从知识库召回物流规则。你怎么评估召回来的文档是不是真的相关？如果召回结果不准，你会从哪些方面去提升？
层层追问
在RAG系统里，你怎么保证召回文档的相关性？……指标用什么？……如果召回率低，你会先优化检索模型还是数据？……重排序怎么加进去？
直球架构
请系统性地讲一下RAG中召回文档相关性和准确性的评估与提升方法，包括检索模型选择、数据质量治理和重排序策略，具体怎么落地？
练习口述回答 · 约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。我更倾向于混合检索加领域微调这个组合，因为它在大多数业务场景里性价比最高。