提高 RAG 应用准确度，时下流行的 Reranker 了解一下？

提高 RAG 应用准确度，时下流行的 Reranker 了解一下？

检索增强生成（RAG）是一种新兴的AI技术栈，通过为大型语言模型（LLM）提供额外的"最新知识"来增强其能力。在基础的RAG架构中，通过Embedding模型、向量数据库、提示词工程和大语言模型等组件，可以有效解决LLM产生"幻觉"、生成内容不可靠的问题。然而，为了进一步提高上下文相关性和问答准确度，许多企业开始在RAG应用中集成Reranker。

什么是Reranker？

Reranker是信息检索（IR）生态系统中的一个重要组成部分，用于评估搜索结果并进行重新排序，从而提升查询结果的相关性。在RAG应用中，Reranker主要在向量查询（ANN）的结果后使用，能够更有效地确定文档和查询之间的语义相关性，更精细地对结果重排，最终提高搜索质量。

目前，Reranker主要有两种类型：

• 基于统计的Reranker：汇总多个来源的候选结果列表，使用多路召回的加权得分或倒数排名融合（RRF）算法来为所有结果重新算分，统一将候选结果重排。这种类型的Reranker的优势是计算不复杂，效率高，因此广泛用于对延迟较敏感的传统搜索系统中。

• 基于深度学习模型的Reranker（Cross-encoder Reranker）：由于深度学习的特性，一些经过特殊训练的神经网络可以非常好地分析问题和文档之间的相关性。这类Reranker可以为问题和文档之间的语义相似度进行打分。因为打分一般只取决于问题和文档的文本内容，不取决于文档在召回结果中的打分或者相对位置，这种Reranker既适用于单路召回也适用于多路召回。

Reranker在RAG中的作用

将Reranker整合到RAG应用中可以显著提高生成答案的精确度，因为Reranker能够在单路或多路的召回结果中挑选出和问题最接近的文档。此外，扩大检索结果的丰富度（例如多路召回）配合精细化筛选最相关结果（Reranker）还能进一步提升最终结果质量。使用Reranker可以排除掉第一层召回中和问题关系不大的内容，将输入给大模型的上下文范围进一步缩小到最相关的一小部分文档中。通过缩短上下文，LLM能够更"关注"上下文中的所有内容，避免忽略重点内容，还能节省推理成本。

上图展示了增加了Reranker的RAG应用架构。可以看出，这个检索系统包含两个阶段：

• 在向量数据库中检索出Top-K相关文档，同时也可以配合Sparse embedding（稀疏向量模型）覆盖全文检索能力。
• Reranker根据这些检索出来的文档与查询的相关性进行打分和重排。重排后挑选最靠前的结果作为Prompt中的Context传入LLM，最终生成质量更高、相关性更强的答案。

使用Reranker的成本

在使用Reranker提升检索相关性的同时需要着重关注它的成本。这个成本包括两方面：增加延迟对业务的影响、增加计算量对服务成本的增加。我们建议根据自己的业务需求，在检索质量、搜索延迟、使用成本之间进行权衡，合理评估是否需要使用Reranker。

• Reranker会显著增加搜索延迟：未使用Reranker的情况下，RAG应用只需执行低延迟的向量近似最近邻(ANN)搜索，从而获取Top-K相关文档。例如Milvus向量数据库实现了HNSW等高效的向量索引，可实现毫秒级的搜索延迟。如果使用Zilliz Cloud，还能借助更强大的Cardinal索引进一步提升搜索性能。但如果增加了Reranker，尤其是Cross-encoder Reranker后，RAG应用需要通过深度学习模型处理所有向量检索返回的文档，这会导致延时显著增加。相比于向量检索的毫秒级延迟，取决于模型大小和硬件性能，延迟可能提高到几百毫秒甚至到几秒！

• Reranker会大幅度提高计算成本：在基础架构的RAG中，向量检索虽然需要预先使用深度学习模型处理文档，但这一较为复杂的计算被巧妙设计在离线状态下进行。通过离线索引（Embedding模型推理），每次在线查询过程只需要付出极低计算成本的向量检索即可。与之相反，使用Reranker会大大增加每次在线查询的计算成本。这是因为重排过程需要对每个候选文档进行高成本的模型推理，不同于前者可以每次查询都复用离线索引的结果，使用Reranker需要每次在线查询都进行推理，结果无法复用，带来重复的开销。这对于网页搜索、电商搜索等高流量的信息检索系统非常不适用。

让我们简单算一笔账，看看使用Reranker的成本。根据VectorDBBench的数据，一个能负担每秒钟200次查询请求的向量数据库使用成本仅为每月100美元，平摊下来相当于每次查询成本仅为0.0000002美元。如果使用Reranker，假设第一阶段向量检索返回top-100个文档，重排这些文档的成本高达0.001美元。也就是增加Reranker比单独执行向量搜索的成本高出了5000倍。虽然很多实际情况中可能只针对少量结果进行重排（例如10到20个），但是使用Cross-encoder reranker的费用仍然远高于单纯执行向量搜索的费用。

从另一个角度来看，使用Reranker相当于在查询时负担相当于离线索引的高昂成本，也就是模型推理的计算量。推理成本与输入大小（文本的Token数）和模型本身的大小有关。一般Embedding和Reranker模型大小在几百MB到几个GB不等。我们假设两种模型尺寸接近，因为查询的文档一般远大于查询的问题，对问题进行推理成本忽略不计，如果每次查询需要重排top-10个文档，这就相当于10倍对于单个文档离线计算Embedding的成本。如果在高查询负载的情况下，计算和使用成本可能是无法承受的。对于低负载的场景，例如企业内部高价值低频率的知识库问答，这一成本则可能完全可以接受。

成本比较：向量检索 v.s. Cross-encoder Reranker v.s. 大模型生成

虽然Reranker的使用成本远高于单纯使用向量检索的成本，但它仍然比使用LLM为同等数量文档生成答案的成本要低。在RAG架构中，Reranker可以筛选向量搜索的初步结果，丢弃掉与查询相关性低的文档，从而有效防止LLM处理无关信息，相比于将向量搜索返回的结果全部送进LLM可大大减少生成部分的耗时和成本。

举一个贴近实际的例子：第一阶段检索中，向量搜索引擎可以在数百万个向量中快速筛选出语义近似度最高的20个文档，但这些文档的相对顺序还可以使用Reranker进一步优化。虽然会产生一定的成本，但Reranker可以在top-20个结果进一步挑出最好的top-5个结果。那么，相对更加昂贵的LLM只需要分析这top-5个结果即可，免去了处理20个文档带来的更高成本和注意力"涣散"的问题。这样一来，我们就可以通过这种复合方案平衡延迟、回答质量和使用成本。

哪种情况适合在RAG应用中使用Reranker？

追求回答高精度和高相关性的场景中特别适合使用Reranker，例如专业知识库或者客服系统等应用。因为这些应用中的查询都具有很高的商业价值，提升回答准确性的优先级远高于系统性能和控制成本。使用Reranker能够生成更准确的答案，有效提升用户体验。

但是在网页搜索、电商搜索这类场景中，响应速度和成本至关重要，因此不太适合使用代价高昂的Cross-Encoder Reranker。此类应用场景更适合选用向量检索搭配更轻量的Score-based Reranker，从而确保响应速度，在提升搜索质量的同时降低开销。

总结

相比于单独使用向量检索，搭配Reranker可以通过对第一层检索结果的进一步精细化排序提高检索增强生成（RAG）和搜索系统中答案的准确性和相关性。但是使用Reranker会增加延时和提高使用成本，因此不适合高频高并发的应用。考虑是否使用Reranker时，需要在回答准确性、响应速度、使用成本间做出权衡。

如果需要在RAG应用中使用Reranker，可以采用最新推出的pymilvus模型库组件调用Reranker模型配合Milvus的向量检索。同时Zilliz Cloud不仅提供向量数据库这一关键组件，还推出了Pipelines功能，通过调用API服务一站式完成文本向量化、检索、重排序，简化了RAG应用的后端架构和降低维护成本。有兴趣的读者可以访问链接(https://docs.zilliz.com/reference/python/Model)或者浏览（https://milvus.io/docs）了解在Zilliz Cloud Pipelines或者Milvus使用Reranker的详情。