完整题目
请阐述可以用于优化RAG系统中召回链路的方法，包括检索器选择、索引结构、查询重写等方面的技术手段。
本文目录
一、检索器选择：多路召回
稠密检索（Dense）
- 基于Embedding：DPR、Contriever，适合语义匹配
- 优势：跨表述理解；劣势：对罕见实体、精确匹配弱
稀疏检索（Sparse）
- BM25、TF-IDF、SPLADE，适合关键词精确匹配
- 优势：零样本、可解释；劣势：语义鸿沟
实践策略：双路召回 + 线性加权或Learned Fusion（如RRF倒数排序融合）
二、索引结构优化
| 方法 | 核心思想 | 适用场景 |
|---|---|---|
| HNSW | 图索引，贪心导航 | 百万级，高召回要求 |
| IVF | 聚类分桶，减少搜索空间 | 亿级，内存受限 |
| PQ/OPQ | 向量量化压缩 | 极致内存优化 |
| DiskANN | 内存+磁盘混合 | 十亿级大规模 |
关键调参：efConstruction（建图质量）、M（邻居数）、nprobe（搜索桶数）
三、查询重写（Query Rewriting）
核心问题：用户原始query短、歧义、与文档表述不一致
| 技术 | 做法 |
|---|---|
| HyDE | 用LLM生成伪答案，再向量化检索 |
| Query2Doc | 生成伪文档扩展query |
| Step-back | 抽象出高层概念再检索 |
| 子查询分解 | 复杂query拆成多个子问题 |
| 历史上下文补全 | 多轮对话中补全指代消解 |
四、进阶优化
- 重排序（Rerank）：Cross-encoder精排，如ColBERT、BGE-Reranker
- 迭代检索：根据中间结果动态调整query（IRCOT）
- 元数据过滤：先结构化过滤，再向量检索，减少搜索空间
一句话总结：召回链路优化 = 多路召回扩覆盖 + 索引结构保效率 + 查询重写对齐语义 + 重排序保精准。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服的RAG系统，用户问“上次那个蓝色的充电宝还有吗”，但知识库里只有商品描述“BluePower 10000mAh”。你怎么让系统能把这俩对上？
层层追问
RAG系统的召回你是怎么做的？……如果只用向量检索，遇到长尾或精确匹配问题怎么办？……那索引结构上，亿级数据怎么保证延迟？……查询重写用过吗？比如用户问“它”这种指代？
直球架构
请完整阐述RAG召回链路的优化方案，包括检索器选择（多路召回）、索引结构（HNSW/IVF等）、查询重写（HyDE/Step-back等）以及进阶的rerank和迭代检索。
练习口述回答 · 约4分钟
- 一句话定位：召回链路优化本质是平衡覆盖、效率和精准
- 检索器选择：稠密与稀疏的双路融合
- 索引结构：HNSW vs IVF的取舍与调参
- 查询重写：HyDE与子查询分解的落地
- 风险与收尾：重排序、迭代检索及工程权衡
这道题问的是[[RAG]]系统里召回链路的优化，其实本质上是在问怎么在覆盖、效率和精准之间做平衡。我先说检索器选择。[[稠密检索]]比如 [[Embedding]] 模型，语义匹配强，但对罕见实体和精确匹配很弱；[[稀疏检索]]像 [[BM25]]，关键词匹配稳，可解释性强，但跨表述理解差。所以真正落地时，我倾向双路召回，把稠密和稀疏的结果用倒数排序融合或者学习权重合并，这样能互补。举个例子，客服退款场景里，用户问“怎么退运费”，BM25能精准匹配“运费”这个词，而稠密检索能理解“运费险”“退货运费”这种变体，两条路一起上，召回覆盖就上去了。
再一个，索引结构优化。[[HNSW]] 图索引在百万级数据下召回很高，但内存消耗大；[[IVF]] 聚类分桶适合亿级数据，内存受限时好用，但搜索精度会受桶数影响。我一般会按场景选：如果延迟要求苛刻，比如毫秒级，我会用 HNSW 并调 efConstruction 和 M 参数；如果数据量超大但内存有限，IVF 加 [[Product Quantization]] 向量量化是标配。这里有个坑：HNSW 在动态更新时删除很麻烦，不能原地删，否则图会乱，所以我会用软删除加异步重建。
然后是查询重写。用户 query 通常短、有歧义，跟文档表述不一致。HyDE 的思路是用大模型先生成一段伪答案，再拿伪答案去向量检索，效果不错，但前提是生成质量不能太差，否则引入噪声。另一个常用的是子查询分解，比如用户问“满减和优惠券能叠加吗”，我会拆成“满减规则”和“优惠券规则”两个子问题分别检索，再合并结果。这种策略对复杂查询很有效，但代价是增加了一次大模型调用和多次检索，延迟会上升。
说到延迟，我其实更关注一个容易被忽略的点：[[重排序]]阶段怎么避免成为瓶颈。[[Cross-Encoder]] 精排确实能提升精准度，但如果召回返回几百条，每条都跑一次大模型，延迟就炸了。所以我会严格控制重排序的候选集大小，比如只对 top 20 做重排，同时用 [[ColBERT]] 这种轻量级交互模型来平衡。另外，迭代检索比如 IRCOT，能根据中间结果动态调整 query，但需要设计好终止条件，否则会陷入循环。
所以整体上，我会把召回链路看成一套组合拳：双路检索扩覆盖，索引结构保效率，查询重写对齐语义，重排序保精准。但上线前我一定先看业务数据的分布，比如高频 query 是不是有长尾实体，索引更新频率怎么样，再决定具体方案。