从《红楼梦》的视角看大模型知识库 RAG 服务的 Rerank 调优

背景介绍

在之前的文章 有道 QAnything 源码解读 中介绍了有道 RAG 的一个主要亮点在于对 Rerank 机制的重视。

从目前来看，Rerank 确实逐渐成为 RAG 的一个重要模块，在这篇文章中就希望能讲清楚为什么 RAG 服务需要 Rerank 机制，以及如何选择最合适的 Rerank 模型。最终以完整的《红楼梦》知识库进行实践。

至于为什么要用红楼梦，答案就是作为读了很多遍《红楼梦》的忠实粉丝，问题的答案是不是靠谱一眼就能判断，问题相关的片段也能快速定位，就像定位 bug 一样快。

Rerank 是什么

以有道 QAnything 的架构来看 Rerank 在 RAG 服务中所处的环节

可以看到有道 QAnything 中的 Rerank 被称为为 2nd Retrieval, 主要作用是将向量检索的内容进行重新排序，将更精准的文章排序在前面。通过向大模型提供更精准的文档，从而提升 RAG 的效果。

在目前的 2 阶段检索（Embedding + Rerank）设计下，Embedding 模型只需要保证召回率，从海量的文档中获取到备选文档列表，不需要保证顺序的绝对准确。而 Rerank 模型负责对少量的备选文档列表的顺序进行精调，优中选优确定最终传递给大模型的文档。

打个简单的比方，目前的 Embedding 检索类似学校教育筛选中的实验班，从大量的学生中捞出有潜质的优秀学生进行培养。而 Rerank 则从实验班中对学生进一步精细排序，选出少数能上清北的重点培养。

为什么不能一步到位

Embedding 检索时会获得问题与文本之间的相似分，以往的 RAG 服务直接基于相似分进行排序，但是事实上向量检索的相似分是不够准确的。

原因是 Embedding 过程是将文档的所有可能含义压缩到一个向量中，方便使用向量进行检索。但是文本压缩为向量必然会损失信息，从而导致最终 Embedding 检索的相似分不够准确。参考 Pipecone 对应的图示如下所示:

可以看到 Embedding 过程包含两步：

1. 运行单个 Transformer 计算以创建查询向量。
2. 将查询向量与具有余弦相似性的文档向量进行比较，获取相似文档。

而 Rerank 阶段不会向量化，而是将查询与匹配的单个文档 1 对 1 的计算相似分，没有向量化带来的信息损失，必然会得到更好的效果，对应的过程如下所示：