RAG为何必须使用Rerank重排序机制

检索增强生成（RAG）与重排序（Rerank）的协同配合，是突破复杂问答任务性能瓶颈的关键策略。今天这篇文章，就来深度拆解这套组合拳的真正价值。

先抛出几个核心判断：RAG在实际落地时，理想效果与现实表现之间往往存在明显差距。很多人搭建完一个RAG流程后，最常问的问题是：“为什么效果没有预期好？”答案其实很简单——RAG看似简单，但真正精通的门槛并不低。把文档存入向量数据库，再叠加一个LLM，有时确实能跑通，但更多时候，你得到的只是“勉强能用”的结果。

所以，当现有RAG效果不佳时，最直接、见效最快的优化方案是什么？重排序 Rerank。咱们就从这里说起。

召回率与上下文窗口

先聊聊单纯RAG存在的问题。使用RAG时，需要对海量文本文档进行语义搜索——文档数量可能从几万到几百亿不等。为了确保大规模搜索的速度，向量搜索是标准配置。文本被转换成向量，存入向量空间，再通过余弦相似度等方法，比较它们与查询向量的距离。

但这里有一个关键点：向量本质上是将文本“含义”压缩成768维或1024维的向量。压缩必然导致信息丢失。所以你经常会发现，向量搜索返回的前三篇文档，可能恰好遗漏了最关键的信息。那条真正有用的内容，往往落在你设定的top_k阈值之外。

怎么办？最直观的方法是：增加返回的文档数量（提高top_k值），然后一股脑儿全塞给LLM。这里衡量的指标叫召回率——也就是“我们检索到了多少相关文档”。召回率不考虑检索到的文档总数，理论上你可以通过返回所有文档来获得“完美”的召回率。

可惜的是，这条路行不通。LLM对输入文本量有限制，这个限制称为上下文窗口。虽然Claude这类模型有100K Token的窗口，能塞下几十页文本，但问题在于：你不能用“塞满窗口”的方式来提高召回率。

为什么？因为上下文填充会严重损害LLM的召回性能。注意，这里的召回率是LLM自己的召回能力，和检索阶段的召回率是两码事。研究表明，随着上下文窗口中填入更多Token，LLM的召回率会明显下降。而且，当窗口被塞满时，LLM遵循指令的能力也会大打折扣。所以，上下文填充绝对不是好主意。

这就形成了一个矛盾：增加检索文档数量能提升检索召回率，但把这些文档全塞给LLM，又会损害LLM的召回率。怎么破局？

答案很清晰：通过检索大量文档来最大化检索召回率，再通过最小化传给LLM的文档数量来最大化LLM召回率。要实现这一点，就需要对检索到的文档进行重新排序，只保留对LLM最有用的那些内容。而这个操作，就是Rerank。

Rerank的强大之处

重排序模型，也叫交叉编码器——给定一个查询和文档对，它会输出一个相似度分数。我们利用这个分数，根据文档与查询的相关性重新排序。

搜索工程师们在两阶段检索系统中使用Rerank，已经有很长时间了。第一阶段，嵌入模型（检索器）从大数据集中检索出一组相关文档；第二阶段，Rerank对这些文档进行重新排序。之所以采用两阶段设计，是因为从大数据集中检索出一小部分文档，比直接对海量文档进行重排序要快得多。简单说：Rerank运行慢，而检索器速度飞快。

为什么要用Rerank？

既然Rerank这么慢，为什么还要用它？答案是：Rerank比嵌入模型准确得多。

双编码器（嵌入模型）准确性较差的原因在于：它必须将一个文档所有可能的含义压缩成一个单一向量，信息丢失是必然的。而且，双编码器在查询方面没有上下文信息——因为用户在查询之前，模型根本不知道查询内容（嵌入是在查询前就创建好的）。

而Rerank则不同。它可以将原始信息直接输入模型计算，信息丢失更少。更重要的是，Rerank是实时运行在用户查询上的，所以它能根据用户查询的具体语境，分析文档的特定含义，而不是试图生成一个笼统的、平均的含义。

当然，这种准确性是有代价的——时间。假设你有4000万条记录，用BERT这样的小型重排序模型在V100 GPU上跑，为了返回一个查询结果，可能要等50多个小时。而用编码器模型加向量搜索，同样的操作在100毫秒以内就能完成。

但话说回来，Rerank正是那个让RAG从“勉强能用”升级到“真正可靠”的关键拼图。两阶段协同，各取所长，才是高性能问答系统的正确打开方式。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：RAG为何必须使用Rerank重排序机制要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题