面经策

什么是 RAG 中的 Rerank？具体需要怎么做？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

Rerank（重排序）是在粗召回之后，用一个更精细但更贵的模型对 Top-N 候选文档重新打分排序，把最相关的几篇顶到前面再喂给大模型。

为什么要做：向量检索是"宽召回"，追求快和覆盖率，往往把语义相近但答非所问的内容也捞回来；业务上直接表现为——用户问退换货政策，系统引用了物流条款。Rerank 用 Cross-Encoder 逐对精算 query 和文档的相关度，精度显著高于向量点积，把有限的上、下文窗口留给真正有价值的内容，直接提升回答准确率、降低幻觉。

怎么做：召回阶段用向量+关键词混合检索取 Top 50~100，再用 BGE-Reranker、Cohere Rerank 这类模型精排到 Top 3~5 进入生成。

投入产出判断：Rerank 会增加一次模型调用，延迟多 100~300ms、成本小幅上升。我的经验是：知识库问答这类对准确率敏感、对延迟不敏感的场景（客服、内部知识库）必上；而高频低价值的场景（如埋点式的语义匹配）先用"提高召回数量+调阈值"顶住，等业务验证了价值再上 Rerank，避免过度设计。

🏗 系统架构师 ​

核心结论：Rerank 是在粗排（ANN 召回 Top 50~100）之后，用更重的交叉编码器对候选做精排，把最相关的 3~5 条送进 LLM。它解决的是"召回率与上下文预算"的矛盾。

为什么要做：向量检索是双塔结构，query 和文档独立编码，精度有限；Cross-Encoder 把 query+doc 拼接后 jointly 编码，精度显著更高但计算量是 N 倍，没法对全库跑。所以工程上必然是两段式：ANN 粗排保召回，Rerank 精排保精度——这和搜索、推荐系统的漏斗架构完全同构。

怎么做：

  • 召回 Top 50~100（混合检索：向量 + BM25）；
  • 用 Rerank 模型打分，取 Top 3~5 进 Prompt；
  • 模型选型：BGE-reranker、Cohere Rerank、Qwen3-Reranker，也可以用 LLM-as-Reranker 但延迟和成本要评估。

量级数字：Rerank 一次 50 条通常增加 100~300ms 延迟，但能省下 LLM 端的 token 成本（进上下文的 chunk 更少更准）。我的经验是 rerank 后 top-3 的命中质量普遍好于不 rerank 的 top-10，属于性价比最高的一档优化。

💻 全栈开发专家 ​

Rerank 是检索的第二阶段精排：第一阶段用向量检索粗排召回 top 50~100，第二阶段用 Cross-Encoder 对 query 和文档逐对联合编码打分，只取 top 3~5 进 Prompt。它解决的是双塔 Embedding「各自编码、交互太浅」导致的排序不准。

落地做法（我项目里的标准链路）：

python
from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import CrossEncoderReranker
from langchain_community.cross_encoders import HuggingFaceCrossEncoder

model = HuggingFaceCrossEncoder(model_name="BGE reranker base")  # bge-reranker-v2-m3
compressor = CrossEncoderReranker(model=model, top_n=5)
retriever = ContextualCompressionRetriever(
    base_compressor=compressor, base_retriever=vectorstore.as_retriever(search_kwargs={"k": 50}))

踩过的坑：一是 rerank 不能贪多，50 条以内延迟可控（本地 GPU 上几十毫秒），上到几百条接口 P99 明显劣化；二是中文场景一定选 bge-reranker-v2-m3 或 Cohere Rerank 这类多语种模型，用英文模型排序中文基本没增益。加了 rerank 后我们召回命中率（recall@5）从 0.68 提到 0.85，是 RAG 调优里性价比最高的一步。