RAG 召回又快又准靠什么?
检索效率、相关性提升与可扩展性策略详解
原题：请阐述可以用于优化RAG系统中召回链路的方法，包括检索效率、相关性提升和可扩展性等方面的策略。
向量检索 · 阿里真题
回答与解析
一、检索效率优化
索引结构层面
- HNSW图索引：平衡召回率与查询速度，适合中等规模；超大规模时采用IVF-PQ或ScaNN降低内存占用
- 量化压缩：FP32→FP16/INT8，或乘积量化（PQ），内存降4-8倍，精度损失可控
- 磁盘索引：FAISS的
IndexIVFPQ+ondisk模式，牺牲部分延迟换取容量
工程架构层面
- 分片（Sharding）+ 路由层，支持水平扩展
- 预过滤（metadata filter）减少候选集，避免全量扫描
二、相关性提升策略
多路召回
| 方式 | 适用场景 |
|---|---|
| 稠密向量（Dense） | 语义匹配、同义词、跨语言 |
| 稀疏向量（SPLADE/BM25） | 关键词精确匹配、长尾实体 |
| 图检索（KG） | 结构化关系推理 |
查询侧优化
- HyDE：用LLM生成假设文档，再用假设文档去检索
- 查询扩展：同义词扩展、伪相关反馈（PRF）
- 多查询生成：一个query变5个不同表述，聚合结果
结果精排
- 两阶段架构：向量召回Top-K → Cross-Encoder/BGE Rerank精排
- Rerank模型用轻量交互式（如ColBERT）或交叉注意力，精度显著高于双塔
三、可扩展性设计
- 增量索引：避免全量重建，支持实时数据流入（如Milvus的segment机制）
- 冷热分层：热数据放内存HNSW，温数据SSD，冷数据对象存储
- 服务化：检索服务独立部署，支持K8s弹性扩缩，与生成服务解耦
关键权衡：延迟vs召回率vs成本，需根据业务SLA选择组合策略。
学习建议
建议系统学习该知识点
口语版讲法(约4分钟)
- 定位：RAG召回本质是精度、速度、成本的三角博弈
- 检索效率：索引选择与量化压缩的工程权衡
- 相关性：混合检索与两阶段精排的落地组合
- 可扩展：增量更新与冷热分层的架构设计
- 收尾：工程师的取舍判断与延伸点
我觉得这道题其实是在问一个很本质的问题：当你面对一个RAG系统的时候，怎么在精度、速度和成本这三个维度上做取舍。说白了，召回链路没有银弹，每个策略都有它的适用边界和代价。
先说检索效率。很多人上来就推HNSW，但HNSW其实更适合中等规模、对延迟要求高的场景，比如在线客服。如果数据量到了千万级甚至亿级，我会更倾向用IVF-PQ或者ScaNN，因为HNSW的内存占用太大了。举个例子，一个电商客服系统，商品政策和退款规则大概几百万条，用HNSW能毫秒级召回，没问题。但如果是企业内部的SOP文档库，上亿条，HNSW可能把128G内存吃满，这时候IVF-PQ加量化压缩就香多了，把向量从FP32压到INT8，内存直接砍4倍，精度损失控制在2%以内，完全可以接受。这里有个前提：如果你的业务场景对精度极其敏感，比如医疗诊断，那量化压缩就要慎用，得先做A/B测试。
再一个，相关性提升。我见过很多团队只靠向量检索，结果关键词匹配一塌糊涂。实际上，真正落地的方案往往是混合检索，Dense Retrieval加Sparse Retrieval一起上。比如用户搜“退款”，向量能召回“退货”“赔付”这些语义相近的，但BM25能精准命中“退款流程”这个短语。所以我会把两条路的结果做加权融合，权重根据场景调。然后还有查询优化，比如用户问“订单异常怎么办”，我会先生成一个假设文档“当订单状态为异常时，用户应联系客服并提供订单号”，用这个去检索，效果比原始query好很多，这就是HyDE。
结果出来之后，别直接给LLM，一定要加一层精排。我通常用两阶段：先向量召回Top-200，再用Cross-Encoder或者ColBERT重排到Top-10。重排这一步能把召回率提升10到15个点，代价是多了几毫秒延迟，但值得。不过要注意，重排模型不能太大，否则延迟会崩，我一般用BGE-Reranker那种轻量级的。
可扩展性这块，我特别关注增量更新。很多向量数据库不支持实时插入，比如FAISS的HNSW，新增一条向量就得全量重建，这在知识库频繁更新的场景下就完蛋了。所以我会用支持segment机制的数据库，比如Milvus，新数据先写小segment，后台慢慢合并。或者用双缓冲策略：一个base索引只读，一个delta索引接受增量写入，查询时合并结果。另外冷热分层也很关键，热点数据放内存，冷数据放SSD，能省不少钱。
说到增量更新，其实还有一个坑很多人没意识到：删除操作。如果你直接在图索引上删向量，召回质量会急剧下降，因为图的邻居关系断了。我通常的做法是软删除，维护一个删除ID列表，查询时过滤掉，然后后台异步重建。这块如果深挖，会涉及到图索引的动态维护和一致性保证，挺有意思的。
所以整体上，我更倾向于把召回链路看成一套可组合的乐高积木，没有固定的最佳实践，只有针对业务场景的权衡。比如对延迟敏感的用HNSW加量化，对精度要求高的用混合检索加精排，对成本敏感的做冷热分层。关键是上线前一定要压测，用真实query回放，对比Recall@K和延迟，不达标就回滚。
关键一句:增量更新中删除操作的坑：软删除加异步重建，避免图索引质量下降
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做电商客服RAG，用户问‘我的订单怎么还没到’，你从知识库召回退换货政策。但有时候召回的结果不相关，比如用户其实想问物流延迟。你会怎么优化召回链路，让语义匹配更准、速度也快？
- 问法 2 · 层层追问
RAG系统的召回你怎么做的？……如果召回结果不准，你能想到哪些方向改进？……进一步，数据量涨到千万级，检索延迟怎么控制？还有增量数据怎么实时更新？
- 问法 3 · 直球架构
设计一个RAG召回系统，要优化检索效率、相关性、可扩展性。从索引结构、多路召回、精排到工程架构，你会怎么选型和组合？关键权衡在哪？