在 RAG 系统的检索环节，一个始终绕不开的工程权衡就是：如何在“尽可能找回所有相关内容”和“尽快返回结果”之间找到最佳平衡点。这就是召回率与检索速度之间的典型矛盾。
为什么两者天然对立
- 召回率（Recall） 衡量的是“所有真正相关的文档中，有多少被检索出来了”。追求高召回往往意味着放宽匹配条件、检索更多候选、执行更复杂的排序甚至重排序，这些操作会线性甚至超线性地增加计算开销。
- 检索速度 直接关系到用户体验和系统吞吐量。在对话式应用中，用户期望得到即时反馈，数百毫秒的额外延迟就可能让交互感大打折扣。
理想情况下当然希望“又快又准”，但在实际系统中，提升一方通常要以牺牲另一方为代价。
权衡的具体抓手
- 索引结构的选择
- 精确最近邻检索（如 KD‑Tree 等）：在维度较低时能兼顾召回和速度，但面对高维向量（数百维以上）常出现“维度灾难”，速度骤降。
- 近似最近邻检索（ANN，如 HNSW、IVF、PQ 等）：通过牺牲少量精度换取极大的速度提升，是当前 RAG 系统的标配。不同 ANN 算法的内存占用、构建时间和查询速度差异很大，根据场景选型就是在精度与速度之间做第一次取舍。
- 检索参数的直接调节
- Top‑K 值：增大 K 会返回更多候选片段，有利于提高召回率，但会往 LLM 的上下文窗口塞入更多内容，不仅增加生成耗时和费用，还可能引入噪声。减小 K 则速度更快，但可能漏掉关键信息。实践中通常在 3~10 之间实验，找到业务可以接受的下限。
- 相似度阈值：设置一个分数底线，低于该值的片段直接丢弃。阈值设得高，速度快但召回低；设得低，召回高但会混入弱相关内容，拖慢后续的生成和判断。
- 多阶段检索（粗筛 + 精排）
不把所有计算压力全压在向量检索这一步。采用“召回‑重排序”架构：第一阶段用轻量级 ANN 快速召回一个稍大的候选集（如 50~100 个片段），第二阶段借助更精准但更慢的模型（如交叉编码器 Cross‑Encoder）对候选集重排序，最终截取 Top‑K 送入生成。这个策略用较小的速度代价换取了明显更高的精准度，是平衡二者的经典手段。
- 硬件与库层面的优化
向量数据库的底层实现、是否启用 GPU 加速、数据是否全在内存等，都直接影响检索速度。有时在同一算法下，换一个更成熟的向量数据库或开启合适的索引参数（如 HNSW 的 efSearch），就能在几乎不损失召回的情况下让速度快一个数量级。
实用的平衡思路
没有绝对正确的参数，只有匹配业务的取舍。建议的做法是：
- 先定延迟预算：根据场景决定用户能接受的最大等待时间（如 200 ms、500 ms）。
- 在预算内尽量提升召回率：尝试不同 ANN 算法和 Top‑K、阈值组合，用一批真实问题构建测试集，量化延迟与召回率关系，找到预算内的最优配置。
- 引入业务兜底：对于高精准要求的场景，宁可让检索返回空结果并触发“未找到信息”的明确回复，也不要为了追求高召回而塞入弱相关内容造成幻觉。
召回率与检索速度的权衡不是一次性配置就能解决的事，它会随着数据量增长、用户行为变化而漂移。把它当作一项持续观测和调优的指标，才能长期保持 RAG 系统又快又准的有效运行。