文章目录
- 一、引言
- 二、召回的核心目标
- 三、范式一：稀疏检索（Sparse Retrieval）
- 3.1 思想：关键词匹配
- 3.2 BM25 公式
- 3.3 BM25 的优点
- 3.4 BM25 的致命缺陷
- 四、范式二：稠密检索（Dense Retrieval）
- 4.1 思想：语义匹配
- 4.2 稠密检索的优点
- 4.3 稠密检索的致命缺陷
- 五、范式三：混合检索（Hybrid Retrieval）
- 5.1 为什么必须混合？
- 5.2 混合检索的两种融合方式
- 方式 A：分数加权融合
- 方式 B：RRF（Reciprocal Rank Fusion）——工业首选
- 5.3 混合检索的标准架构
- 六、实战：客服场景的混合检索
- 6.1 客服场景的"召回痛点"画像
- 6.2 智能路由：让该赢的赢
- 6.3 一段 LangChain 的混合检索代码
- 七、召回的"再加工"：让结果更可用
- 7.1 去重
- 7.2 多样性（MMR）
- 7.3 上下文窗口预算分配
- 八、召回的评估指标
- 九、常见踩坑清单
- 十、本文小结
- 十一、给下一篇文章的铺垫
本系列为《RAG 做智能客服》第 6 篇
前置条件：已阅读第 4、5 篇，了解分片与索引
一、引言
前面两篇我们搞定了分片和索引——文档已经被切成小块，存进了向量数据库。
现在到了"用武之地"：召回（Retrieval）——用户问一个问题，系统怎么从几十万、上百万个分片里，又快又准地捞出最相关的 K 个？
直觉上想：用户问题 → 转向量 → 算相似度 → 排序 → Top-K。听起来简单，但一上生产就翻车。
为什么？因为纯向量检索不是万能的。这一篇我们拆解三大召回范式：稀疏检索、稠密检索、混合检索，并给出生产级的实战方案。
二、召回的核心目标
召回阶段要同时满足三个互相矛盾的目标：
| 目标 | 含义 | 难度 |
|---|---|---|
| 召回率（Recall） | 真正相关的分片都召回了 | 召得全 |
| 精确率（Precisi |
