揭开RAG重排序（Rerankers）和两阶段检索（Two-Stage Retrieval）的神秘面纱

一、为什么需要重排序？

检索增强生成（Retrieval Augmented Generation，RAG）技术看似充满无限可能，但在实际应用中，许多人发现构建的RAG系统结果并不尽如人意。

尽管RAG相对容易入门，但要真正掌握其精髓却相当困难。实际上，建立一个有效的RAG系统远不止将文档存入向量数据库并叠加一个大语言模型那么简单。虽然这种方法有时会有效，但并非总能保证成功。

我们知道，RAG 通过在大量文本文档中进行语义搜索来工作，这些文档的数量可能达到数十亿。为了实现大规模搜索的快速响应，我们通常采用向量搜索技术。具体而言，就是将文本转化为向量后，放入一个向量空间内，再通过余弦相似度等度量标准来比较它们与查询向量的相似度。

向量搜索的前提是需要向量，这些向量通常将文本背后的意义压缩成768或1536维的形式，这一过程不可避免地会丢失一些信息。因此，我们常常会发现，即使是排名前三的文档，也可能遗漏了一些关键信息。

在此，我们关注的指标是召回率，即“我们检索到的相关文档的比例”。需要注意的是，召回率不考虑检索到的文档总数。

因此，理论上通过返回所有文档可以实现完美的召回率。然而，这在实际操作中是不可行的，因为大语言模型对可处理的文本量有限制，这个限制称为上下文窗口。

如果较低位置的文档包含了有助于大语言模型更好地形成回答的相关信息，该怎么办？一个简单的方法是增加返回的文档数量（即增加top_k值），并将它们全部传递给大语言模型。但是这样做有一定的条件：

第一，这样做的一个劣势，就是需要消耗更多的token，意味着成本的增加。

第二，尽管大模型拥有高达100K Token的巨大上下文窗口，理论上可以包含大量文档，但我们仍然不能返回所有文档并填满上下文窗口来提高召回率。

第三，当我们在上下文窗口中填充过多内容时，会降低大语言模型在该窗口中检索信息的能力。研究表明，当上下文窗口被过多Token填满时，大语言模型的回忆能力会受到影响。此外，过度填充上下文窗口还会使模型较难按指令执行，因此，这种做法是不可取的。

为了解决这一问题，我们可以通过检索尽可能多的文档来最大化检索召回率，然后通过尽量减少最终传递给大语言模型的文档数量。为此，我们重新排序检索到的文档，并只保留最相关的文档。

二、什么是重排序算法？

重排序模型（也称为Cross-Encoder）是一种能够针对查询和文档对输出相似度分数的模型。通过利用这些分数，我们可以根据文档与查询的相关性对它们进行重新排序。

一个包含两个阶段的检索系统通常在向量数据库（vector DB）阶段采用双编码器（bi-encoder，Bi-Encoder）或稀疏嵌入模型。搜索工程师长期以来在这种两阶段检索系统中使用重排序模型。第一阶段的模型（嵌入模型或检索器）负责从大数据集中提取一组相关文档。随后，第二阶段的模型（重排序器）对提取出的文档进行重新排序。

采用两阶段策略的原因在于，从大数据集中快速检索少量文档的速度远快于对大量文档进行重排序。简而言之，重排序器处理较慢，而检索器速度较快。我们将在后面详细解释其原因。

三、为何选择使用重排序器？

关键在于，重排序器的精确度远超过嵌入模型。

双编码器（bi-encoder）精度较低的根本原因在于，它必须将文档的所有潜在含义压缩成一个向量——这无疑导致了信息的丢失。此外，由于查询是在收到后才知道的，双编码器对查询的上下文一无所知（我们是在用户提出查询之前就已经创建了嵌入）。

而重排序器能够在大型Transformer中直接处理原始信息，这大大减少了信息丢失。由于重排序器是在用户提出查询时才运行，这让我们能够针对具体查询分析文档的含义，而非仅生成一个泛化的、平均化的含义。

重排序器避免了双编码器的信息丢失问题——但它也有代价，那就是时间。

双编码器模型将文档或查询的含义压缩成单一向量。值得注意的是，无论处理的是文档还是查询，双编码器的处理方式相同，都是在用户查询时进行。

使用双编码器和向量搜索时，所有繁重的Transformer计算都在创建初始向量时完成。这意味着，一旦用户发起查询，我们已经准备好了向量，接下来需要做的只是：

运行一个Transformer计算生成查询向量。

使用余弦相似度（或其他轻量度量）将查询向量与文档向量进行比较。

而对于重排序器，我们不进行任何预计算。相反，我们将查询和某个文档直接输入到Transformer中，进行完整的推理步骤，最终生成一个相似度分数。

重排序器通过一个完整的Transformer推理步骤，针对查询和单一文档生成一个相似度分数。请注意，这里的文档A实际上等同于我们的查询。

假设我们的系统有4000万条记录，使用像BERT这样的小型重排序模型在V100 GPU上运行，我们可能需要超过50小时来返回一个查询结果。而采用编码器模型和向量搜索，相同的查询结果可以在不到100毫秒的时间内完成。

四、重排序代码实现

现在我们了解了使用重新排序器进行两阶段检索背后的想法和原因，让我们看看如何实现它，首先，我们将设置我们的必备库：

!pip install -qU \datasets==2.14.5 \openai==0.28.1 \pinecone-client==2.2.4 \cohere==4.27

在设置检索管道之前，我们需要检索数据！我们将使用 Hugging Face Datasets 中的 jamescalam/ai-arxiv-chunked 数据集。该数据集包含 400 多篇关于 ML、NLP 和 LLMs 的 ArXiv 论文，包括 Llama 2、GPTQ 和 GPT-4 论文。

关键代码如下：

from datasets import load_dataset
data = load_dataset("jamescalam/ai-arxiv-chunked", split="train")data

import time
index_name = "rerankers"existing_indexes = [index_info["name"] for index_info in pc.list_indexes()]
# check if index already exists (it shouldn't if this is first time)if index_name not in existing_indexes:# if does not exist, create indexpc.create_index(index_name,dimension=1536,# dimensionality of ada 002metric='dotproduct',spec=spec)# wait for index to be initializedwhile not pc.describe_index(index_name).status['ready']:time.sleep(1)
# connect to indexindex = pc.Index(index_name)time.sleep(1)# view index statsindex.describe_index_stats()

def compare(query: str, top_k: int, top_n: int):# first get vec search resultsdocs = get_docs(query, top_k=top_k)i2doc = {docs[doc]: doc for doc in docs.keys()}# rerankrerank_docs = co.rerank(query=query, documents=docs.keys(), top_n=top_n, model="rerank-english-v2.0")original_docs = []reranked_docs = []# compare order changefor i, doc in enumerate(rerank_docs):rerank_i = docs[doc.document["text"]]print(str(i)+"\t->\t"+str(rerank_i))if i != rerank_i:reranked_docs.append(f"[{rerank_i}]\n"+doc.document["text"])original_docs.append(f"[{i}]\n"+i2doc[i])for orig, rerank in zip(original_docs, reranked_docs):print("ORIGINAL:\n"+orig+"\n\nRERANKED:\n"+rerank+"\n\n---\n")