召回是 RAG 系统中最先接触用户意图的环节，它的质量直接决定了后续生成的天花板。如果检索到的片段与问题无关，再强的生成模型也无法给出正确答案。因此，优化召回是提升整体回答质量最有效的着力点之一。本节从几个经实战验证的方向展开，不追求面面俱到，只讲常用的、好用的方法。
14.3.1 提升基础向量检索质量
向量检索是目前 RAG 系统的默认选择，它的效果受多个因素影响：
- 嵌入模型的选择
不同嵌入模型对不同类型文本的语义捕捉能力差异很大。例如，通用英文模型处理中文时效果会明显下降；轻量模型速度快但可能损失细微语义。实践中建议根据业务语言和知识库内容，选择在该领域表现均衡的嵌入模型，并在自有数据上做简单对比测试（如评测召回命中率）。
- 分块策略的精细化
检索的颗粒度由分块大小决定。块太大，语义混杂，召回的相关性会降低；块太小，上下文缺失，模型生成的答案可能不完整。常用的优化包括：
- 根据文档类型动态调整块大小，比如 FAQ 短文本用小块，技术手册用中等块。
- 重叠切分，让相邻块之间有部分共享内容，减少信息割裂。
- 保留元数据（标题、章节号），可在检索后进行过滤或加权。
- 查询优化
用户提问往往口语化、省略关键信息。在检索前对问题进行简单改写，可以显著提升召回。比如将“上次说的那个产品，价格变了吗？”补充上下文变为“X 产品最新价格是多少”。工程上可以通过小模型或模板实现，成本很低。
14.3.2 混合检索：关键词 + 向量
纯向量检索擅长捕捉语义近似，但对专有名词、编号、缩写等精确匹配场景常常表现不佳。例如用户搜索“HR-2024-003 号文件”，向量可能召回一堆关于“人力资源政策”的片段，却漏掉了这个精确编号。
混合检索同时利用稀疏检索（如 BM25） 和向量检索，并对结果进行融合排序：
- BM25 等传统算法基于词频和逆文档频率，对精确字符串匹配天然敏感。
- 向量检索提供语义泛化能力，能召回相近表达的段落。
融合策略常用的有倒数排序融合（RRF） 或直接对分数加权求和。实施时可以从简单的线性加权开始，根据业务侧重（精确匹配 vs. 语义泛化）调整系数。
14.3.3 重排序：让精准的结果排在前面
初始检索通常用近似最近邻（ANN）快速召回一批候选（如 top‑100），但排序的精度受限于嵌入模型的语义表达能力。重排序（Re‑ranking） 是在召回集合上，用更强但更慢的模型进行二次排序，最终将最相关的几个片段送入生成阶段。
常用方法：
- 交叉编码器模型：将查询和每个候选片段拼接后，输出一个相关性分数。这种模型精度远高于独立嵌入，但计算量随候选数量线性增长，因此通常只对 top‑k（如 20‑50 个）进行重排序。
- 轻量级专用重排序模型：如 Cohere Rerank、BGE‑Reranker 等，专门优化了推理速度，可以在准确性和延迟之间取得较好平衡。
实施时，建议先测量引入重排序后的延迟和成本增长，再决定候选池的大小和模型选择。对于很多业务，对 top‑50 做重排序，取前 5 送入生成，已是性价比很高的方案。
14.3.4 多路召回与结果融合
当知识库包含异构内容时，单一检索策略很难面面俱到。比如既要检索严谨的技术文档，又要匹配 FAQ 中的类似问题，这时可以采用多路召回：
- 一路：针对长文档正文，使用向量检索。
- 一路：针对问答对库，直接匹配用户问题。
- 一路：针对题录、摘要等结构化信息，用精确搜索。
每条路径独立返回结果集，最后通过统一的融合层合并排序，消除重复后送入重排序。多路召回能有效提升覆盖面，尤其适合知识来源复杂的场景。
14.3.5 评测驱动的迭代
召回优化最容易犯的错误是“凭感觉调参”。建立一套轻量但可靠的离线评测流程，能让优化更有方向：
- 构建标准问答对：从真实用户日志或业务专家那里收集一批问题及对应的理想文档片段。
- 量化指标：关注命中率（Hit Rate）和平均倒数排名（MRR），它们直接反映检索能否把正确答案递到模型眼前。
- A/B 测试：在线上小流量验证新的召回策略，观察最终回答准确率和用户反馈。
每次调整（换嵌入模型、改分块大小、引入重排序）之后，都在同一套评测集上跑一遍，保存结果，形成优化记录。这样即使短期没有提升，也能知道改动没有引发退化。
14.3.6 一些容易被忽视的实用技巧
- 利用文档结构：如果原始文档有层级标题，可将标题信息附加到每个分块中（如“## 第三章 退款规定”），检索时这些元信息能提供极强的上下文信号。
- 时效性加权：对于注重时效的信息，可以在检索时根据文档创建或更新时间进行加权，让新内容更优先被召回。
- 负反馈机制：收集用户对回答的负向反馈，反向标记被引用的片段，持续优化索引和排序。
召回优化不是一蹴而就的，它是一个随着业务理解深入而不断打磨的过程。在多数真实项目中，把基础向量检索做到 80 分，再搭配混合检索和重排序，就足以支撑一个稳定可用的 RAG 系统。后续章节将讨论如何进一步在生成环节提升答案的可用性。