完整题目
在RAG系统中，为什么通常采用两阶段检索（召回+重排序）而不是直接使用重排序模型进行检索？这样的架构设计有什么优缺点？
本文目录
答案要点
- 理解召回阶段的核心作用是快速缩小候选集（从百万级到千级）
- 明确重排序模型计算成本高，无法直接作用于大规模语料
- 能对比单阶段vs两阶段在延迟、精度、成本上的权衡
- 提到实际工业中的常见配置（如向量召回+Cross-Encoder重排）
核心原因：计算成本与精度的权衡
为什么必须分两阶段？
| 阶段 | 处理规模 | 模型特点 | 核心目标 |
|---|---|---|---|
| 召回（Retrieval） | 百万~亿级文档 | 轻量、快速（如向量相似度、BM25） | 快速筛选，从海量中捞出Top-K候选 |
| 重排序（Rerank） | 百~千级候选 | 重型、精准（如Cross-Encoder） | 精细排序，用复杂交互计算最终相关性 |
重排序模型（如BERT-based Cross-Encoder）需要query和document拼接后过Transformer，计算复杂度O(n)，无法承受直接扫描百万级文档的延迟和成本。
架构优缺点
优点
- 效率可控：召回阶段毫秒级响应，重排阶段只处理小候选集
- 精度可扩展：重排序能捕捉细粒度语义交互（如query词与doc的精确匹配）
- 灵活解耦：可独立优化召回策略（换embedding模型）或重排策略（换reranker）
缺点
- 误差累积：召回漏掉的优质文档，重排阶段无法挽回（recall天花板）
- 系统复杂：需维护两套索引和模型，增加运维成本
- 延迟叠加：两阶段串行，总延迟 = 召回延迟 + 重排延迟
工业界典型配置
Query → 向量检索（HNSW索引，Top-1000）→ Cross-Encoder重排（Top-10）→ LLM生成若对延迟极敏感，也可用双塔模型做召回 + 轻量交互模型（如ColBERT）做重排，在效率和精度间再取平衡。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服的RAG系统，用户问“这个手机多少钱”，你从商品库检索后回答。现在用户又追问“那拍照怎么样”，你肯定要结合前文。但问题是，你的检索库可能有上百万个商品，如果每个都拿去做深度匹配，延迟根本扛不住。你怎么设计这个检索流程？
层层追问
RAG系统里，query来了之后，你怎么从海量文档里找到相关的？……直接用最精准的模型去全文搜一遍行不行？……为什么实际工业界都分成召回和重排两步？这样设计有什么好处和坏处？
直球架构
RAG里为什么通常采用召回+重排序的两阶段架构，而不是直接用一个重排序模型检索？请分析这种设计的优缺点，包括效率、精度、系统复杂度等方面。
练习口述回答 · 约4分钟
- 本质是计算成本与精度的权衡
- 召回阶段快速筛出候选集
- 重排阶段精细排序
- 优缺点与落地风险
- 收尾：工程师取舍与给出可延伸点
这道题问的是为什么[[RAG]]里要分召回和[[重排序]]两步走，而不是让重排序一步到位。其实本质就是在问计算成本和精度之间的权衡。如果直接用 [[Cross-Encoder]] 这种重型模型去扫百万级文档，计算量会大到没法接受，延迟和成本都扛不住，所以必须拆成两阶段，先快速捞一把，再精细排一遍。
具体说一下。召回阶段，比如用 [[BM25]] 或者 向量检索，目标是快，从海量文档里筛出几百上千个候选，这个阶段模型很轻量，延迟能控制在毫秒级。重排序阶段，候选集已经很小了，就可以上 Cross-Encoder 这种精细模型，让 query 和文档做深度的交互计算，把最相关的排到前面。召回是保召回率，重排是提精度，缺一不可。
举个例子，在客服退款场景里，用户问“为什么我的退款还没到账”，召回阶段可能从百万条知识库里捞出几百条跟退款流程相关的文档，重排阶段再根据用户的具体描述，比如“已提交三天”，把最匹配的那几条排到最前面，这样 LLM 才能给出准确回复。如果只用召回，可能排在前面的都是泛泛的退款政策，不精准；如果只用重排，那延迟就爆炸了，用户等不了。
这个架构的好处很明显：效率可控，召回快，重排只处理小量数据；精度能提上去，因为重排模型能捕捉细粒度语义；而且召回和重排可以独立优化，比如换个更好的 [[Embedding]] 模型或者换一个重排器。但缺点也得心里有数。最核心的风险是误差累积，如果召回阶段把重要文档漏掉了，重排阶段再怎么排也找不回来，这就是召回率天花板。另外系统复杂度上去了，要维护两套索引和两个模型，运维成本高；而且两阶段串行，总延迟是叠加的，对实时性要求特别高的场景需要注意。
所以实际落地时，我会特别关注召回阶段的质量，比如用 [[Hybrid Search]] 把 [[稀疏检索]] 和 [[稠密检索]] 结合起来，降低漏召回的风险。如果对延迟特别敏感，可以换成 [[ColBERT]] 这种轻量交互模型做重排，或者把召回阶段做得更激进一点，比如只保留 Top-100。上线前我会用一批线上真实 query 做 A/B 测试，看召回率和最终回答质量有没有掉，如果掉就调召回策略。
另外还有一个有意思的点，就是召回和重排的边界其实可以灵活调整。比如在 [[Agentic RAG]] 里，[[Agent]] 可以动态决定是继续召回还是直接重排，甚至多次迭代。这个方向其实挺值得深入聊的。
所以整体上，两阶段架构是个很务实的工程选择，核心就是在成本和精度之间找到平衡点。我更倾向把它看作一个可调节的 pipeline，而不是固定的套路，根据业务场景去调召回量和重排模型，才能落地得稳。