RAG 向量检索怎么高效召回?

回答与解析

核心检索流程

1. 查询预处理

• 查询改写：扩展同义词、纠错、补全上下文（如HyDE生成假设文档）
• 意图识别：区分事实查询/摘要/对比类问题，路由到不同检索策略

2. 向量检索执行

• 索引结构：HNSW（高召回+速度平衡）、IVF-PQ（超大规模）、DiskANN（内存受限）
• 参数调优：ef_search（搜索深度）、M（图连通度）与延迟的trade-off

3. 多路召回融合

向量召回（语义相似） + 稀疏检索（BM25，关键词匹配） + 倒排索引（结构化过滤）
→ 线性加权或Learned Sparse Retrieval（如SPLADE）融合

关键影响因素

实践调优要点

• 动态检索：小模型预判所需token数，自适应调整top-k
• 结果重排：Cross-Encoder精排，或ColBERT轻量级交互
• 反馈闭环：用户点击数据回流，训练领域Embedding

学习建议

建议系统学习该知识点

口语版讲法(约4分钟)

• 本质是语义匹配加工程取舍
• 混合检索：向量加关键词，各管一摊
• 分块策略：粒度与上下文的平衡
• 落地风险：数据漂移和索引更新
• 收尾：重排与反馈闭环

这道题其实是在问，怎么在语义理解、检索效率和工程复杂度之间找到平衡。我理解RAG的检索模块本质上是一个语义匹配问题，但落地时不能只靠向量检索一条腿走路。

具体说一下我的做法。首先是混合检索。纯向量检索对关键词、数字、实体匹配很弱，比如用户搜“订单号12345退款”，向量可能把“12345”当成语义噪声，但BM25能精准命中。所以我会把 向量召回和BM25结合起来，做一个Hybrid Search。向量负责语义相似，BM25负责精确匹配，两个分数线性加权或者用学习排序融合。这里有个坑：权重怎么设？我一般先看业务，比如客服场景退款问题语义更重要，BM25权重低一点；而搜政策条款时关键词更重要，权重调高。上线我会特别关注融合后的召回率，如果发现向量拉回一堆不相关但语义近的，就适当压低向量分数。

再一个是分块策略，这是很多人忽略的。Chunk大小直接影响检索粒度。块太大，比如一整个合同段落，语义完整但噪声多；块太小，比如一句话，容易上下文断裂。我偏向用 语义分块加滑动窗口，比如先用Embedding检测主题边界，再在边界附近做重叠切分，确保每个块有上下文。举个例子，企业SOP文档里“退货流程”和“退款流程”是相邻的，如果硬切就把“退货需先退款”这个完整动作截断了。分块时我会预留前后各一两句的上下文，保证召回时信息完整。前提是你的Embedding模型能准确感知语义边界，否则切出来更乱。

检索执行层面，索引结构我常用HNSW，它平衡了速度和召回。参数ef search和M要调，一般M设16-32，ef search设200-500，具体看延迟容忍度。如果向量库上亿，我会考虑IVF-PQ做量化压缩，但召回会掉一点，得看业务能不能接受。

落地最大的风险其实是 数据分布漂移。比如客服系统，用户query随时间变化，新政策发布后语义空间变了，但索引还是旧的，召回质量会逐渐下降。所以我会建一个反馈闭环：用户点击结果后，把正负样本回流，定期增量训练Embedding模型。索引更新也有讲究，全量重建太慢，我会用双缓冲影子索引，新索引构建完后原子切换，切换前用固定query回放，对比Recall@K和延迟，不通过就回滚。

说到反馈闭环，其实还有一个方向是Self-RAG，让模型在生成时自己判断是否需要检索，以及检索结果的可靠性。这能解决很多不必要的检索开销和幻觉问题，但需要更多训练数据和控制。

最后收一下：我会把检索模块看成 一个系统工程，不是单一算法能解决的。混合检索、分块策略、索引更新、反馈闭环，这几个环节环环相扣。我更倾向先用简单方案跑通，比如BM25加向量，再逐步加重排和反馈，避免一开始就搞复杂导致维护成本失控。

关键一句:Self-RAG让模型自己判断是否需要检索，减少无效检索和幻觉。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你的RAG系统要支撑电商客服，用户问‘这个手机拍照怎么样’，你从向量库召回相关文档。如果直接拿这句话去检索，和实际匹配的文本块之间经常有语义偏差，你怎么处理？

2. 问法 2 · 层层追问

   RAG的检索模块你一般怎么设计？……那如果用户查询很短，比如‘退货’，你怎么保证召回率？……除了向量检索，你还会考虑别的召回方式吗？……你觉得哪些因素最影响召回效果？

3. 问法 3 · 直球架构

   设计RAG系统的检索模块，从用户查询到高效召回相关文本块，你会考虑哪些关键步骤？影响召回效果的核心因素有哪些？请从表示、索引、检索、系统几个层面分别说说。