
为什么 RAG 一定需要 Rerank? 原创
今天想和大家深入探讨一下检索增强生成(RAG)中的一个重要环节——重排序(Rerank)。
RAG 技术一直以来都备受关注,尤其是当它与大模型(LLM)结合后,人们都满怀期待地认为:这下终于可以轻松解决那些复杂的问答任务了!然而,现实往往并不如人意。很多开发者在完成一个 RAG 流程后,都会感到困惑:为什么它的效果并没有达到预期呢?
其实,和大多数工具一样,RAG 的使用虽然简单,但想要真正精通却并非易事。事实上,RAG 并不仅仅是将文档存储到向量数据库中,然后在其上简单地添加一个 LLM。虽然这种方式在某些情况下可能会奏效,但并不总是有效。
因此,今天我们就来聊聊当现有的 RAG 流程无法达到理想效果时,我们该怎么办。如果你经常遇到 RAG 表现欠佳的情况,这里有一个最容易且最快实施的解决方案——重排序(Rerank)。
1、召回率与上下文窗口
在深入探讨解决方案之前,我们先来剖析一下传统 RAG(检索增强生成)流程中存在的问题。在 RAG 的应用中,我们常常需要对海量的文本文档进行语义搜索,这些文档的数量可能从几万篇到几百亿篇不等。
为了在大规模搜索中保证足够的速度,我们通常会采用向量搜索技术。具体来说,就是将文本转换为向量形式,将它们放置在同一个向量空间中,然后利用余弦相似度等相似性度量方法,来比较这些向量与查询向量之间的接近程度。
向量搜索的关键在于向量本身。这些向量本质上是将文本背后的“含义”压缩成一个低维向量(通常是 768 维或 1024 维)。然而,这种压缩过程不可避免地会导致部分信息的丢失。
由于信息丢失,我们常常会遇到这样的情况:向量搜索返回的前几篇文档中,可能遗漏了重要的相关信息。而这些相关信息,可能出现在我们设置的 top_k 阈值之外。
那么,如果这些位置靠后的相关信息能够帮助我们的 LLM(大型语言模型)生成更好的回答,我们该怎么办呢?最直接的方法就是增加返回的文档数量(提高 top_k 值),并将这些文档全部传递给 LLM。
这里涉及到的衡量指标是**召回率**,它表示的是“我们检索到了多少相关文档”。召回率并不考虑检索到的文档总数,因此我们可以通过返回所有文档来“操纵”这个指标,从而得到完美的召回率。
然而,我们并不能返回所有文档。LLM 对于能够接收的文本量是有限制的,这个限制被称为**上下文窗口**。例如,Anthropic 的 Claude 这样的 LLM,其上下文窗口可以达到 100K 个 Token,这意味着我们可以放入几十页的文本。
那么,我们是否可以通过返回大量文档(尽管不能是全部),并“填满”上下文窗口来提高召回率呢?
答案是否定的。我们不能使用上下文填充的方法,因为这会降低 LLM 的**召回性能**。这里所说的 LLM 的召回率,与我们之前讨论的检索召回率是不同的概念。
研究表明,随着我们在上下文窗口中放入更多的标记,LLM 的召回率会逐渐降低。当我们填满上下文窗口时,LLM 也不太可能遵循指令,因此上下文填充并不是一个好的解决方案。
这就引出了一个问题:我们可以通过增加向量数据库返回的文档数量来提高检索召回率,但如果把这些文档全部传递给 LLM,就会损害 LLM 的召回率。那么,我们该怎么办呢?
解决这个问题的方法是,通过检索大量文档来最大化检索召回率,然后通过**最小化**传递给 LLM 的文档数量来最大化 LLM 的召回率。要做到这一点,我们需要对检索到的文档进行重新排序,只保留对 LLM 最相关的文档。而实现这一操作的关键,就是**重排序(Rerank)**。
2、Rerank 的强大之处
重排序模型,也被称为交叉编码器,是一种特殊的模型。它接收一个查询和文档对作为输入,并输出一个表示相似度的分数。我们利用这个分数,根据文档与查询的相关性对文档进行重新排序。
在现代检索系统中,通常采用两阶段检索的策略。在第一阶段,通常会使用一个双编码器或稀疏嵌入模型来从大规模数据集中快速检索出一组相关文档。这些模型能够在海量数据中高效地筛选出初步的候选文档集合。
然后,在第二阶段,重排序模型(Rerank)登场。它的任务是对第一阶段检索到的文档进行更细致的重新排序。Rerank 模型通过更复杂的计算,对文档的相关性进行更精准的评估,从而提升最终返回结果的质量。
搜索工程师们在两阶段检索系统中使用 Rerank 已经有很长时间了。这种策略的核心在于,从大数据集中检索出一小部分文档的速度,远远快于对大量文档进行重新排序的速度。简单来说,Rerank 的运行速度相对较慢,而检索器的运行速度非常快。
为什么采用两阶段检索?
采用两阶段检索的原因主要有以下几点:
第一、效率与精度的平衡
第一阶段(检索阶段):使用双编码器或稀疏嵌入模型,能够在大规模数据集中快速检索出一组相关文档。这些模型的设计目标是高效地筛选出初步的候选文档集合,虽然它们的精度可能有限,但速度非常快。
第二阶段(重排序阶段):Rerank 模型对第一阶段检索到的文档进行重新排序。虽然 Rerank 的运行速度较慢,但它能够更精准地评估文档的相关性,从而提升最终返回结果的质量。
第二、资源优化
如果直接对大规模数据集进行重新排序,计算成本会非常高昂,且效率低下。通过两阶段检索,第一阶段快速筛选出一小部分文档,第二阶段再对这些文档进行精细排序,这样可以显著降低计算资源的消耗。
第三、灵活性与扩展性
两阶段检索系统允许在不同阶段使用不同的模型和技术。例如,第一阶段可以使用高效的向量检索模型,第二阶段可以使用更复杂的交叉编码器模型。这种分阶段的策略使得系统更加灵活,可以根据具体需求进行优化和扩展。
重排序模型的作用
重排序模型(Rerank)在两阶段检索系统中扮演着至关重要的角色。它通过对第一阶段检索到的文档进行重新排序,确保最终返回的文档不仅数量适中,而且相关性更高。具体来说,Rerank 的作用包括:
提升相关性:通过更复杂的计算,Rerank 能够更精准地评估文档与查询的相关性,从而提升最终返回结果的质量。
优化上下文窗口:由于 LLM 的上下文窗口有限,Rerank 可以帮助我们在有限的上下文窗口中选择最相关的文档,从而最大化 LLM 的性能。
减少噪声:Rerank 可以去除那些虽然在第一阶段被检索到,但实际相关性较低的文档,从而减少噪声,提高系统的整体性能。
3、为什么要用 Rerank?
如果 Rerank 的速度这么慢,那为什么我们还要使用它呢?答案很简单:Rerank 比嵌入模型要准确得多。
第一、双编码器的局限性
双编码器模型的准确性较低,主要有两个原因:
- 信息压缩导致的丢失
双编码器需要将一个文档的所有可能含义压缩成一个单一的向量。这种压缩过程不可避免地会导致信息丢失。因为向量的维度是固定的,而文档的含义可能是多维度的。
例如,一个文档可能包含多种主题和细节,但双编码器只能将其压缩成一个固定维度的向量,这就导致了部分信息的丢失。
- 缺乏查询上下文
双编码器在处理文档时,没有查询的上下文信息。因为在用户查询之前,我们已经创建了文档的嵌入向量。这意味着双编码器无法根据具体的查询来调整文档的表示。
例如,同一个文档在不同的查询下可能有不同的相关性,但双编码器无法动态地调整文档的向量以适应不同的查询。
第二、Rerank 的优势
相比之下,Rerank 模型具有显著的优势:
- 直接处理原始信息
Rerank 模型可以直接处理原始的文档和查询信息,而不是依赖于压缩后的向量。这意味着信息丢失更少,能够更准确地评估文档与查询的相关性。
例如,Rerank 模型可以分析文档中的具体句子和段落,而不是仅仅依赖于一个固定的向量表示。
- 动态分析文档含义
因为 Rerank 是在用户查询时运行的,所以可以根据具体的查询来分析文档的特定含义,而不是试图生成一个通用的、平均的含义。
例如,对于一个包含多种主题的文档,Rerank 可以根据用户的查询,动态地提取与查询最相关的部分,从而提高相关性评估的准确性。
第三、Rerank 的代价
尽管 Rerank 模型在准确性上有显著优势,但它也有一个明显的代价——时间。
- 双编码器模型
双编码器模型将文档或查询的含义压缩成一个单一向量。在用户查询时,双编码器以与处理文档相同的方式处理查询。
例如,假设你有 4000 万条记录,使用编码器模型和向量搜索,同样的操作可以在不到 100 毫秒内完成。
- Rerank 模型
Rerank 模型需要直接处理原始文档和查询,计算复杂度更高,因此速度较慢。
例如,使用像 BERT 这样的小型重排序模型,在 V100 GPU 上,为了返回一个查询结果,可能需要等待 50 多个小时。
4、总结
尽管 Rerank 模型的运行速度较慢,但其在准确性上的优势使其在许多场景中不可或缺。通过两阶段检索系统,我们可以在第一阶段快速筛选出候选文档,然后在第二阶段通过 Rerank 模型进行精细排序,从而在保证效率的同时,显著提升检索结果的质量。这种策略在处理复杂的问答任务和生成任务时尤为重要,因为它能够确保最终返回的文档不仅数量适中,而且相关性更高。
本文转载自公众号玄姐聊AGI 作者:玄姐
