【RAG】召回（Retrieval）与重排（Rerank）核心技术要点汇总
RAG 召回（Retrieval）与重排（Rerank）核心技术要点汇总
一、 核心概念
在检索增强生成（RAG）架构中，召回与重排处于不同的阶段，承担不同的职责：
- 召回阶段（初筛 - Retrieval）
- 核心任务：从全量海量知识库（百万级文本块）中，快速、低延迟地筛选出可能相关的候选文本集合（通常为 Top 50）。
- 关注指标：查全率（Recall）。核心目标是“宁滥勿缺”，确保正确答案包含在候选集中。
- 重排阶段（精排 - Rerank）
- 核心任务：对召回阶段产生的有限候选集（Top 10 ~ 50）进行深度的语义相似度重新评估与排序，筛选出质量最高、最精准的文本块（通常为 Top 3 ~ 5）喂给大语言模型（LLM）。
- 关注指标：查准率（Precision）。核心目标是“去伪存真”，将真正高价值的上下文推到最前面。
二、 底层原理与技术要点
1. 召回阶段：双塔模型（Bi-Encoder）
- 架构机制：Query（用户问题）与 Document（文档块）在编码阶段各自独立进行向量化，二者在计算相似度前互不知道对方的存在。
- 计算逻辑：离线状态下将全量文档转化为高维向量并存入向量数据库（如 Milvus）；在线推理时仅需将 Query 向量化，通过计算余弦相似度等指标进行极速检索。
- 优缺点：
- 优点：计算复杂度低，支持大规模向量索引，响应时间在毫秒级。
- 缺点：无法捕捉 Query 与 Document 之间微观、细腻的词级互动，容易被字面相似但逻辑不相关的硬负样本（Hard Negatives）欺骗。
2. 重排阶段：交叉编码器（Cross-Encoder）
- 架构机制：打破双塔屏障，将
Query与Document拼接成一条连续的输入序列，格式通常为：[CLS] + Query + [SEP] + Document + [SEP]
整体输入到同一个 Transformer 网络中。 - 计算逻辑：在网络内部，利用全注意力机制（Full Attention），让 Query 中的每一个 Token 与 Document 中的每一个 Token 进行深度的微观交互。最终通过
[CLS]位置的输出向量进行线性映射，输出一个 0 到 1 之间的相关性得分。 - 优缺点：
- 优点：语义理解极度精准，对否定句、因果逻辑、条件转折等微观语义极其敏锐。
- 缺点：计算复杂度随输入长度呈平方级（O(N^2)）暴增，无法用于全量知识库检索。
3. 企业级落地部署方案
在工业级高并发场景中，禁止在业务代码中直接同步加载模型推理，主流做法分为两类：
- 方案 A：独立微服务化部署（私有化首选）
- 技术栈：利用基于 Rust 编写的TEI (Text Embeddings Inference)框架或 Triton、vLLM 进行模型托管。
- 核心优化：利用框架集成的Flash Attention 2以及动态批处理（Dynamic Batching）技术，将重排时延压缩至毫秒级，实现高吞吐。
- 方案 B：商业化 API 服务（免运维首选）
- 代表厂商：智谱 AI Rerank API、Cohere Rerank、阿里云百炼等。
- 集成方式：通过标准 HTTP/gRPC 协议调用。例如智谱 AI 接口，通过
Authorization: Bearer <API_KEY>鉴权，传入query和documents数组，直接返回排序后的index和relevance_score。
三、 总结与注意事项
1. 经典漏斗形 RAG 架构
标准生产环境的检索链路应当遵循**“多级漏斗”**设计：
- 第一级（多路混合检索召回）：全量知识库 -> 向量检索 + BM25 关键词检索 -> 融合产生 Top 50 候选集。
- 第二级（专用 Rerank 模型精排）：Top 50 候选集 -> 经由
bge-reranker或智谱 Rerank API -> 精简为 Top 5 核心上下文。 - 第三级（大模型生成）：Top 5 上下文 + 原始 Prompt -> 最终喂给大语言模型（LLM）生成回答。
2. 生产落地注意事项
- Top_N 截断机制：在调用 Rerank 模型或 API 时，务必显式指定
top_n参数（如 3 或 5）。利用服务端内部排序截断，避免将大量无效文本传输回业务后端，不仅节省带宽，还能大幅减少最终喂给 LLM 的 Context Token 消耗。 - 超时与降级策略：重排由于计算量大且通常涉及网络 I/O，必须设置严格的超时控制（建议 2 ~ 3 秒）。在系统偶发超时或服务不可用时，应引入降级机制：跳过重排步骤，直接截取向量检索原始的前 5 个结果送给 LLM，确保核心业务的可用性与高容错。
- 安全合规：若涉及极度敏感、涉密的企业核心资产或用户隐私数据，应避免使用云端公有云 Rerank API，须采用自建显卡服务器通过 Docker 本地化部署开源重排模型。