RAG 项目里的召回排序链路如何设计，Embedding 召回、粗排、重排和答案生成各自承担什么职责？｜高频面试题解析

60 秒回答模板

我会把 RAG 召回排序链路分成六步。第一步是离线侧建索引：对文档做清洗、切分、去重、元数据标注、权限标记和向量化，同时保留关键词索引，保证后面既能语义召回也能精确匹配。第二步是在线 query 理解：识别用户问题的意图、实体、时间范围、权限、是否需要多跳查询，必要时做 query rewrite 或拆成子问题。第三步是召回，Embedding 召回负责高召回地找到语义相关片段，BM25、关键词、结构化过滤或规则召回补足专名、数字、代码、时间等向量模型不稳定的部分，通常会做 hybrid retrieval。第四步是粗排，用较便宜的特征快速筛掉明显不合适的候选，比如向量相似度、关键词覆盖、文档质量、时效、权限、点击/使用反馈、去重和多样性，让候选从几百条降到几十条。第五步是重排，用更贵但更准的 cross-encoder、LLM reranker 或领域排序模型判断 query 和片段的细粒度相关性，并考虑证据完整性、冲突、冗余和上下文预算。第六步是答案生成，把 top 证据按结构拼进 prompt，要求模型基于证据回答、标注不确定性、拒绝无依据内容，并在生成后做引用、事实一致性和安全校验。Embedding 召回的职责是召全，粗排的职责是低成本过滤和控制候选质量，重排的职责是精排相关性和证据可用性，生成的职责是把证据组织成可读答案。上线后要用检索指标、答案指标、延迟成本和 badcase 回流一起迭代。

考点 召回重在覆盖

难度 真实面经题

回答目标 让候选人能把 RAG 讲成可上线的检索增强系统，清楚区分召回、粗排、重排和生成的职责，并能补充工程取舍、评测指标和常见失败模式。

深入解析

离线索引决定召回上限

RAG 的效果很大程度由离线数据处理决定。文档要先清洗噪声、去重、保留标题层级、来源、时间、作者、权限、业务标签等元数据，再根据问答粒度切 chunk。chunk 太长会稀释语义并浪费上下文，太短会缺少完整证据；常见做法是按段落或语义边界切分，并保留父文档标题和相邻上下文。索引侧通常同时建向量索引和关键词索引，因为向量适合语义近似，关键词适合专名、数字、缩写、代码和精确术语。

在线查询先做意图和约束理解

用户问题进入召回前，不应直接丢给向量库。系统要识别查询意图、关键实体、时间条件、领域、权限和是否需要多跳推理；口语化问题可以做 query rewrite，把代词、缩写和上下文补全；复杂问题可以拆成多个子查询分别召回。对企业知识库或内部工具来说，权限过滤必须前置或贯穿全链路，避免召回到用户不该看到的内容。

Embedding 召回负责语义召全

Embedding 召回的核心职责是从大规模候选中快速找出语义相关片段，优点是能处理同义表达、自然语言问题和非精确匹配。它的难点在于召回结果会受 embedding 模型、chunk 粒度、向量归一化、索引参数、领域词表和冷门实体影响。为了提高召回率，常配合多路召回：原始 query 向量、改写 query 向量、标题向量、问题向量、相邻 chunk 扩展，以及 BM25 或规则召回。

粗排用便宜特征控制候选质量

召回阶段通常宁可多召一些候选，粗排负责用低成本信号把几百或上千个候选压到可重排规模。粗排可以使用向量相似度、关键词匹配、标题命中、文档质量、时效、来源可靠性、权限、业务标签、历史点击、反馈分、去重和多样性特征。它不追求像重排一样精细理解文本，而是避免明显无关、重复、过旧或低质量内容进入后续昂贵环节。

重排判断细粒度相关性和证据价值

重排阶段候选数量少，可以使用 cross-encoder、领域排序模型或 LLM reranker 对 query 和 chunk 做更细的匹配判断。它要区分“词相似但不能回答”和“文字不完全相同但能提供证据”，还要考虑证据完整性、是否包含定义/步骤/结论、与其他证据是否冲突、是否冗余，以及放入上下文后的覆盖范围。好的重排不仅选最相似的片段，还选最能支撑最终答案的证据集合。

生成阶段要受证据和评测约束

答案生成不是自由发挥，而是把重排后的证据组织成可读、可追溯、可拒答的输出。Prompt 要说明只能基于给定证据回答、证据不足时说明不足、冲突时列出冲突来源、不要编造引用。上线后要分层评测：检索看 recall@k、MRR、nDCG、命中率和权限正确性；生成看事实一致性、引用正确率、完整性、拒答质量、人工满意度、延迟和 token 成本。badcase 要回流到数据、召回、排序、prompt 和评测集。

易错点

把 RAG 简化成“向量数据库加大模型”，不讲数据清洗、chunk、混合召回、排序和评测。
认为 Embedding 召回越相似越好，忽略召回阶段应优先保证覆盖率和权限/时效过滤。
直接把召回结果全部塞给大模型，不做粗排、重排、去重和上下文预算控制。
只评测最终答案好不好，不拆检索命中、排序质量、事实一致性、引用正确率和延迟成本。
忽略无答案、证据冲突和权限受限场景，导致模型在证据不足时硬编答案。
只针对一个 badcase 调 prompt，不判断问题根因是在数据、召回、排序、上下文拼装还是生成。

面试官追问

为什么不能只用向量召回？

向量召回擅长语义相似，但对专有名词、数字、代码、缩写、精确时间和低频实体不一定稳定。实际 RAG 常用 hybrid retrieval，把向量召回和 BM25、关键词、元数据过滤、规则召回结合起来，提高召回覆盖和可控性。

chunk 大小怎么选？

要围绕答案所需证据粒度选。chunk 太小会丢上下文，太大相似度被稀释且浪费 token。可以按语义段落切分，保留标题和父文档信息，再用相邻 chunk 扩展或 parent-child retrieval 补完整上下文，最终用评测集比较命中率和答案质量。

重排模型和粗排模型的区别是什么？

粗排处理候选多，强调低成本和吞吐，常用简单特征、轻量模型或启发式规则；重排处理候选少，可以用 cross-encoder 或 LLM 进行 query-document 联合理解，强调细粒度相关性和证据可回答性。

RAG 如何降低幻觉？

先提高证据召回和重排质量，再在 prompt 中要求基于证据回答、证据不足时拒答或说明不确定；生成后可以做引用校验、事实一致性检查和答案-证据对齐。还要用无答案样本和冲突样本评测拒答能力。

如何优化 RAG 延迟？

可以减少多路召回的无效分支，调 ANN 索引参数，缓存热门 query 或 embedding，控制候选数和 rerank topK，使用轻量 reranker，压缩上下文，并把离线预处理和在线过滤边界设计清楚。优化时不能只压延迟，还要看召回和答案质量是否下降。