RAG系列之——Rerank到底解决了什么问题？
项目中使用 RAG 时，不知道大家有没有遇到过这样的问题：
检索环节召回了很多“看起来相关”的片段，但真正有用的却排在后面。把这些初筛之后的片段喂给大模型，由于内容太多，大模型返回的结果往往效果很差。
Rerank 就是专门用来解决这类问题的。
一．RAG 链路中，Rerank 在哪个环节？
大家来看以下流程图：
通过 BM25 + 向量检索进行初步召回后，我们在后续环节加入 Rerank，进行初步筛选之后的精排。
比如，我们通过 BM25 + 向量检索召回20个结果，而这20个结果又太多，我们想进一步筛选之后，再给到大模型。这个时候，使用 Rerank，可以将这20个结果再排个序，最终根据我们的要求，从中再次筛选出 Top-K 个结果。
这很像考研，先通过笔试，把各科成绩超过国家线的学生筛选出来（BM25 + 向量检索），再通过面试，详细聊一聊这个学生跟该专业的匹配程度，给每个同学打分后，根据录取名额，按最终分数从高到低，录取 Top-K 个学生。
二. Rerank 到底在判断什么？
前面文章我们讲过，向量检索原理是将 query 向量和 chunk 向量求余弦相似度，看的是两个向量在语义空间中的距离。
而 Rerank 更像是把 query 和 chunk 一起输入模型，由模型来判断，这个 chunk 对回答 query 帮助有多大？
Rerank 判断的不是相似，而是“可回答性”和“证据价值”。
举个例子，用户提问：
“公司报销往返车票，需要提交哪些材料？”
候选片段 A:
“往返车票包含机票、高铁票，以及打车费用。”
候选片段 B:
“员工报销往返车票时，需要提供行程单、发票和付款凭证。”
如果只用向量检索，两个片段都会被召回，并且没有先后顺序，但使用 Rerank 之后，片段 B 就能被排在片段 A 前面，因为 A 能够回答问题。
三．常见 Rerank 方法
- Cross-Encoder Rerank
这种方法就是我们上面讲的，把 query 和 chunk 拼在一起输入到 Rerank模型中，计算相关性分数，再根据分数进行排序。
这种方法优点是效果好，根据分数进行排序，结果一目了然，可解释性强；缺点也很明显，query 需要跟每个 chunk 计算相关性分数，速度会比较慢。这种方法适合对初筛结果进行二次排序。
Rerank 常见模型有
BGE-Reranker，这是目前国内使用最多的开源 Reranker，它的最大优势是可以本地部署，免费使用，另外它在中文下效果非常好，缺点是速度慢。
Cohere Rerank，目前仅支持付费 API 调用，效果非常好，属于第一梯队，对多语言支持很好，唯一缺点就是贵。
Jina Reranker，近两年热度非常高，速度快，适合 Agent、Code Search 和大型知识库，缺点是商业化场景需要许可证。
Voyage Rerank，对于英文支持非常好，但是中文环境不如 BGE，比较适合海外产品。
2.LLM Rerank
顾名思义，也就是直接让大模型判断哪些片段最相关。
这种方法更加灵活，但是消耗 token，更贵，也更慢，另外稳定性不一定好。这种一般适合问题比较复杂的场景，当你初筛得到的结果比较少，或者需要详细解释排序理由的时候，可以采用这种方式。
当然，你可能会问，反正 RAG 检索出来的结果，最终还是要丢给大模型，那为什么在最终调用大模型之前，再多调一次大模型进行 Rerank 呢？直接在最后环节把这个过程包含进去不就行了？
好问题，可以这么做，并且很多轻量化的 RAG demo 就是这么干的。但是生产环境不建议这么做，主要是以下几个原因：
首先，两个阶段目标不一样，Rerank 阶段主要是根据候选 chunk 对于回答问题的证据价值进行排序，而最终回答阶段，是让大模型基于上下文回答用户问题。如果把两件事情混在一块，大模型容易“边看边答”，效果反而不好。
其次，Rerank 阶段通常是在 Top-20、Top-50 甚至 Top-100 中筛选出 Top-5 或者 Top-10，如果一股脑把还未筛选的大量 chunk 硬塞给大模型，容易导致 prompt 膨胀，无关 chunk 会稀释模型注意力，干扰大模型做出正确回答。
另外，生产场景使用大模型，评测是不可忽视的关键环节，如果把 Rerank 和最终回答环节放在一起，如果最终效果不好，那到底是 Rerank 出了问题，还是回答环节效果不行？这个时候你就会发现，只有把两者拆开，结果才更加可控，更可评估。
最后一点，如果将两者分开，Rerank 可以使用更小、更便宜的模型，因为 Rerank 对于模型的要求没有最终回答环节那么高，模型参数量小一点不会对结果产生很大影响，但是节省下来的可是非常可观的一笔费用。
四．如何评估 Rerank 有没有用？
真实业务场景下，我们一般先构建评测集，为每个问题标注正确的参考文档或者 chunk，评测集大小可以根据业务复杂度和构建成本进行选择。之后对比“有 Rerank”和“无 Rerank”时，以下几个指标有没有改善：
Recall@K，在前 K 个检索结果中，有没有包含正确文档或者 chunk，包含取1，不包含取0，最后取平均，它不关心排第几，只关心前 K 中有没有。
MRR（Mean Reciprocal Rank，平均倒数排名），它关心的是第一个正确结果排在第几位，计算公式：
MRR = 1 / 第一个正确结果的排名它回答了正确结果是不是排的足够靠前，而这正是 Rerank 的核心作用
NDCG（Normalized Discounted Cumulative Gain，归一化折损累计增益），它比前两个指标更细，它既考虑结果是否相关，也考虑越靠前的正确结果，价值是否越高，是对整体排序质量的评估。
当然，以上是检索/排序环节的指标，我们也可以根据最终回答环节的效果，比如加入 Rerank 后，大模型回答质量是否有所提高来判断 Rerank是否有用。
五．什么时候用 Rerank?
讲到这里，想必大家对于什么时候需要使用 Rerank 已经有比较深入的认识了。当你想提升上下文质量，减少无关 chunk 干扰，想在召回环节多一点，最终喂给 LLM 少一点时，就可以使用 Rerank，把有限的上下文窗口留给最有证据价值的内容。
六、Rerank 的代价和坑
当然，Rerank 也不是无脑就能加，我们也要考虑成本。
候选 chunk 越多，Rerank 就会越慢，从而延长模型最终回答问题的耗时。
不管使用 API Rerank 还是 LLM Rerank，系统整体成本都会增加。
如果召回阶段没有找到有价值的 chunk，那 Rerank 效果再好，对于最终回答质量，也毫无帮助。
Rerank 是精排不是魔法，它依赖召回阶段给它一批“至少有希望”的候选项。
七．一个推荐的实践配置
结合我的经验，给你一个工程建议：
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～