完整题目
在构建多路召回系统时，如何全面评估不同召回策略所返回文档的质量？请系统阐述可用于衡量召回有效性的定量与定性评估指标、分析方法及其适用场景，并结合RAG系统的实际需求说明如何选择和组合这些评估手段以优化整体检索性能。
本文目录
一、定量评估指标
基础指标
- Recall@K：关键文档是否被召回，RAG场景优先关注（漏召回=无法生成）
- Precision@K：召回结果中相关文档占比，控制噪声干扰LLM
- F1-Score：平衡场景使用
排序质量指标
- MRR（平均倒数排名）：关注首个相关文档位置，适合单文档即可回答的场景
- NDCG@K：考虑文档相关性分级，适合需要综合多文档生成的复杂Query
- MAP（平均精度均值）：评估整体排序质量
多路召回特有指标
- 覆盖率（Coverage）：Query被至少一路召回的比例
- 互补性（Complementarity）：各路召回结果的重叠度，理想状态是低重叠高互补
二、定性评估方法
- 人工相关性标注：构建黄金测试集，定义"相关/部分相关/不相关"标准
- 错误案例分析：分类bad case（漏召、误召、排序差）归因到具体策略
- LLM辅助评估：用GPT-4等判断文档-Query相关性，降低标注成本
三、RAG场景的组合策略
分层评估体系
- 离线阶段：各路独立评估Recall/Precision，筛选候选策略
- 融合阶段：评估融合后的NDCG@K和覆盖率
- 端到端阶段：最终生成答案的准确性（Answer-level metrics），这是RAG的北极星指标
决策原则
- 优先保证高Recall（设阈值如>95%），再优化Precision和排序
- 不同Query类型（事实性/推理性/多跳）配置不同评估权重
- A/B测试验证：离线指标提升≠端到端效果提升，需线上验证
典型组合
稀疏召回（BM25）+ 稠密召回（向量）+ 重排序模型
评估：各路Recall → 融合后NDCG → 端到端Answer Accuracy学习建议
建议先掌握信息检索基础指标（如Precision、Recall、MRR），再结合RAG场景理解多路召回的特性，通过实际项目或开源数据集动手实践评估流程。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服RAG系统，用户问‘我的订单什么时候到？’你会从订单库、物流库、FAQ库等多个渠道召回文档。现在各路召回结果回来一堆，你怎么判断哪一路的质量更高？比如向量召回和BM25谁更靠谱？
层层追问
多路召回的效果你怎么评估？……先不看融合，单看每一路召回的质量，你会用什么指标？……那Recall和Precision在RAG场景下哪个更重要？……如果一路召回Recall很高但Precision很低，你敢不敢用？
直球架构
设计一套多路召回质量评估体系，要求覆盖定量指标和定性方法。定量方面除了Recall和Precision，还要考虑排序质量和多路之间的互补性。定性方面你怎么做人工评估或者用LLM辅助？最终怎么把这些评估手段组合起来指导RAG的检索优化？
练习口述回答 · 约4分钟
- 本质是评估召回能否支撑生成
- 定量指标要按场景选
- 定性分析不能省
- RAG落地要分层评估
- 取舍与风险
这道题其实问的是，当你有好几条召回策略时，怎么能科学地判断哪条好、怎么组合，最终要服务[[RAG]]的生成效果。我一般会从定量、定性、还有RAG特有的分层评估这几个角度来说，但核心思路是：指标只是工具，业务场景才是裁判。
先说定量指标。像Recall@K和Precision@K是基础，但怎么取舍要看场景。比如客服退款场景，用户说“我上个月买的鞋开胶了”，如果召回没把退款政策文档拿回来，LLM就编不出答案，所以Recall是底线，我通常会设个阈值比如95%，低于这个的直接淘汰。但Precision也重要，不然一堆不相关文档喂进去，LLM容易[[Hallucination]]。具体来说，NDCG@K适合那种需要综合多份文档的复杂Query，比如“对比这两款保险”，因为它能区分文档的不同相关程度；而MRR就适合单文档就能回答的事实性问题，比如“订单号123的状态”。还有一个多路召回特有的指标叫互补性，理想状态是各路召回结果重叠度低、互补性强，这样融合后覆盖率高。
定性评估很多人会忽略，但我觉得特别关键。人工标注黄金测试集是少不了的，定义好“相关”“部分相关”“不相关”，然后跑一遍bad case分析。比如漏召了，是[[BM25]]分词没对上，还是[[Embedding]]向量离得远？误召了，是关键词膨胀还是语义偏了？这种归因能直接指导策略优化。另外，用LLM辅助评估可以降成本，比如用GPT-4给文档-Query对打分，但要注意它本身有偏差，只能当参考。
到了RAG这个场景，我习惯搭一个分层评估体系。离线阶段先独立测每条路的Recall和Precision，比如[[稀疏检索]]的BM25和[[稠密检索]]的向量召回，各自跑一遍，筛掉明显不行的。融合阶段再看NDCG和覆盖率，比如用[[重排]]模型把结果混在一起排序。最后端到端阶段，直接看生成答案的准确率，这才是北极星指标。举个例子，企业SOP合规文档检索，用户问“离职流程是什么”，如果召回没抓到最新的离职政策文档，生成答案就错了，所以离线Recall再高，端到端答不对也是白搭。
这里有个坑：离线指标提升不一定等于端到端效果提升。比如Recall从90%提到95%，但引入的噪声让LLM答得更差了，那就不值得。所以上线前一定要A/B测试，用真实用户反馈验证。另外，不同Query类型要配不同权重，事实性Query重点看Recall，推理型Query重点看NDCG。
还有一个点值得注意，就是评估时怎么处理Query本身的歧义性。比如用户说“退货”，可能指“退货政策”也可能指“退货流程”，如果召回策略没做Query理解，直接搜关键词，容易偏。所以我现在倾向在评估时加入Query改写后的对比，看能不能提升召回质量。