RAG没Rerank，等于开车没带方向盘

推荐语

RAG技术中Rerank的重要性和优势，提升问答系统性能的关键。

核心内容：
1. RAG技术中向量搜索的局限性和问题
2. Rerank作为交叉编码器的优势和原理
3. Rerank如何协调召回率和精度，提升RAG性能

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

RAG没Rerank，等于开车没方向盘。

相信好多人搭完知识库，RAG一跑，效果都是全是幻觉，一片稀碎。

而且资料内容越多，幻觉就是越大，准确性也随之直线下降。

原因很简单。

传统的RAG就是一个“检索+生成”的过程 ：从海量文档里捞出相关内容，喂给LLM，让它吐出答案。

第一步靠向量搜索，文本变嵌入（embeddings），用余弦相似度一比，出结果；

第二步LLM接手，生成答案。

但问题来了，向量搜索快是快，可靠性拉胯。文本转成768维或1024维的嵌入，信息压缩得太狠，细节丢了一堆。

举个例子。

问“量子计算的核心原理是啥”，向量搜索可能给排在前面的是一篇“量子力学入门”，而真正硬核的“量子计算算法”被挤到top_k之外，比如第15位。

这时候LLM拿到一堆半吊子资料，能答好才怪！

那把top_k调大点，多捞点文档总行了吧？想法不错，但LLM的上下文窗口（context window）不是无限的。

拿Claude举例，100K Token听着还行，可是塞满窗口后，LLM的召回能力直线下降，中段信息基本“失忆”，指令都不听。喂多了，喂出个“老年痴呆”助手。

所以Rerank就来了。

Rerank是个交叉编码器（cross-encoder），通俗来说：

拿到查询和文档一对一PK，算出相似度分数，再重新排序。跟向量搜索的双编码器（bi-encoder）比，Rerank不靠预计算的嵌入，而是实时分析，信息丢失少得可怜。

举个栗子：向量搜索给你捞了50篇文档，Rerank一出手，分析完直接把最相关的5篇挑出来。

原本排第20的“量子计算算法”可能直接跳到第1，LLM拿到手的上下文全部都有了打开。直接把回答质量拉上天。

为啥Rerank这么强？

之前的双编码器的问题是提前把文档压缩成单一向量，查询来了才匹配，上下文全靠猜。而Rerank根据具体查询深度挖掘文档含义，精度甩双编码器几条街。

向量搜索靠预先算好的嵌入，查询来了才临时匹配，难免有点“盲人摸象”。Rerank不一样，它是实时分析，能根据你的具体问题，深度挖掘文档的含义。

这里得提两个硬核指标：召回率（recall）和精度（precision）。

召回率看你捞到多少相关文档，精度看这些文档里多少真有用。

向量搜索可以把top_k调到50、100，召回率拉满，但LLM吃不消，上下文窗口一塞满，性能就崩。

直接砍top_k到5吧，召回率又不够，漏掉关键信息。

Rerank的牛逼之处就在于，它完美实现了两者的协调。

第一步，向量搜索捞一大堆（比如top_k=50），保证召回率；

第二步，Rerank精挑细选（比如top_5），确保精度。

结果是：检索阶段不漏网，LLM阶段不超载。数据支持这点，根据Pinecone的分析，两阶段检索加Rerank能让RAG的搜索质量提升20%-30%，问答任务尤其明显。

当然，Rerank也不是没槽点。最大的问题是慢！

向量搜索100毫秒搞定的事儿，Rerank可能得几秒甚至几分钟。假设你有4000万条记录，用个小型BERT跑Rerank，在V100 GPU上可能得50小时起步。相比之下，双编码器加向量搜索，基本是“秒杀级”速度。

但慢有慢的道理。

Rerank的高精度来源于它不偷懒，实时计算避免了双编码器的信息丢失。尤其在企业场景，比如法律检索、医疗问答，这种慢工出细活的“龟速”能换来极致效果。

而且，随着硬件升级和模型优化（比如DistilBERT），Rerank的延迟也在逐步缩小。

没Rerank，初始检索不靠谱，LLM拿到的资料质量参差不齐，回答要么跑偏，要么“幻觉”满天飞。

Rerank就像个“质量把关员”，确保每份资料都够格。

能不能优化嵌入模型跳过Rerank？

理论上行，比如用更强的Sentence-BERT，但实际中，大规模数据集和复杂查询下，嵌入模型还是容易翻车。

Medium上有篇文章提到，即便是最先进的嵌入模型，面对多样化文档时，top_k的排序依然不稳定。Rerank目前是最快、最实用的“补丁”，尤其在追求极致效果时，基本没得选。

在Cherry Studio中使用重排

获取密钥

https://cloud.siliconflow.cn/i/eGafyivT

选择模型类型

界面设置

在知识库中使用Rerank