超越向量检索！混合检索 + 重排序改善 RAG 应用

2024-02-27资讯

【导读】随着时间推移，RAG 技术已经迅速成为在实际应用中部署大型语言模型（LLMs）的首选方式。本文旨在介绍混合检索和重排序技术的基本原理，解释其对提升 RAG 系统文档召回效果的作用，并讨论构建生产级 RAG 应用的复杂性。通过对实验数据评估和测试结果的分析，本文还突出了混合检索 + 重排序在不同场景下的显著优势。

本文精选自【 007：大模型时代的开发者】，【新程序员 007】聚焦开发者成长，其间既有图灵奖得主 Joseph Sifakis、前 OpenAI 科学家 Joel Lehman 等高瞻远瞩，又有对于开发者们至关重要的成长路径、工程实践及趟坑经验等，欢迎大家。

作者 | 何文斯张路宇

责编 | 王启隆

出品 | 【新程序员】编辑部

我相信在当下这个时间点，每一个大模型应用开发者对 RAG（ Retrieval Augmented Generation，检索增强生成）的技术概念都已经不再陌生。在着手写这篇文章之前，我观察到仍有不少技术文章将 RAG 简单归纳为基于 Embedding 的向量检索技术与大模型生成技术的结合。

但实际上，各行各业的开发者们在 RAG 应用方向上经过近一年的探索和实验后，普遍意识到一个问题： 在打算将应用部署到生产环境时，仅仅依靠向量检索技术构建 RAG 应用是远远不够的。

9 月份，Microsoft Azure AI 在官方博客上发布了一篇题为【Azure 认知搜索：通过混合检索和排序能力超越向量搜索】 [1] 的文章。该文对在 RAG 架构的生成式 AI 应用中引入混合检索和重排序技术进行了全面的实验数据评估，量化了该技术组合对改善文档召回率和准确性方面的显著效果。

在查阅了与这项技术相关的中英文资料后，我发现中文互联网对这项技术的讨论尚少。

本文作为一篇关于混合检索和重排序技术入门的文章，一方面将介绍这两项技术的基本原理，解释其为何能够改善 RAG 系统的召回效果。另一方面，也将讨论构建生产级 RAG 应用的复杂性。为了便于理解，我先用通俗的语言快速解释一下 RAG 系统是什么。

RAG 概念解释

2024 年，以向量检索为核心的 RAG 架构成为解决大模型获取最新外部知识、同时解决生成幻觉问题的主流技术框架，并已在相当多的应用场景中得到实际应用。

开发者可以 利用该技术以较低成本构建 AI 智能客服、企业智能知识库、AI 搜索引擎等 ，通过自然语言输入与各类知识组织形式进行对话。以一个有代表性的 RAG 应用为例（见图 1）：

图 1 RAG 应用示意图

在图 1 中，当用户提问「美国总统是谁？」时，系统并非直接将问题提交给大模型来回答，而是首先在知识库中（如图 1 中的维基百科）进行向量搜索，通过语义相似度匹配的方式查询相关内容（例如，拜登是美国现任第 46 届总统… ），然后再将用户问题和搜索到的相关知识提供给大模型，以使大模型获得足够完备的知识来回答问题，从而获得更可靠的问答结果。

为什么需要这样做呢？

我们可以将大模型比作超级专家，他熟悉人类各个领域的知识，但也有自己的局限性。例如，他不了解你个人的一些状况，因为这些信息是私人的，不会在互联网上公开，所以他没有提前学习的机会。

当你想雇佣这个超级专家充当你的家庭财务顾问时，需要允许他在接受你的提问时先查看一下你的投资理财记录、家庭消费支出等数据。这样他才能根据你个人的实际情况提供专业的建议。

这就是 RAG 系统所做的事情：帮助大模型临时性地获取他所不具备的外部知识，允许他在回答问题之前先找答案。

根据上面这个例子，我们很容易发现 RAG 系统中最核心的是外部知识的检索环节。超级专家能否向你提供专业的家庭财务建议，取决于他能否精确找到需要的信息；如果他找到的不是投资理财记录，而是家庭减肥计划，那么再厉害的专家都会无能为力。

为什么需要混合检索？

上文提到，RAG 检索环节中的主流方法是向量检索，即语义相关度匹配的方式。技术原理是通过将外部知识库的文档先拆分为语义完整的段落或句子，并将其转换（ Embedding ）为计算机能够理解的一串数字表达（多维向量），同时对用户问题进行同样的转换操作。

计算机能够发现用户问题与句子之间细微的语义相关性，比如「猫追逐老鼠」和「小猫捕猎老鼠」的语义相关度会高于「猫追逐老鼠」和「我喜欢吃火腿」之间的相关度。在查找到相关度最高的文本内容后，RAG 系统会将其作为用户问题的上下文一起提供给大模型，帮助大模型回答问题。

除了能够实现复杂语义的文本查找，向量检索还具有其他的优势：

相近语义理解（如老鼠/捕鼠器/奶酪、谷歌/必应/搜索引擎）

多语言理解（跨语言理解，如输入中文匹配英文）

多模态理解（支持文本、图像、音视频等的相似匹配）

容错性（处理拼写错误、模糊的描述）

虽然向量检索在以上情景中具有明显优势，但在某些情况中效果不佳。比如：

搜索一个人或物体的名字（例如伊隆·马斯克、iPhone 15 ）

搜索缩写词或短语（例如 RAG、RLH F ）

搜索 ID（例如 gpt-3.5-turbo、titan-xlarge-v1.01 ）

而上述缺点正好是传统关键词搜索的优势所在。传统关键词搜索擅长：

精确匹配（如产品名称、姓名、产品编号）

少量字符的匹配（通过少量字符进行向量检索时效果非常不好，但很多用户恰恰习惯于只输入几个关键词）

倾向低频词汇的匹配（低频词汇往往承载了语言中的重要意义，比如「你想跟我去喝咖啡吗？」这句话中的分词，「喝」「咖啡」会比「你」「吗」在句子中承载更重要的含义）

对于大多数文本搜索的情境，首要的是确保潜在最相关的结果能够出现在候选结果中。向量检索和关键词检索在检索领域各有其优势。 混合检索 正是结合了这两种搜索技术的优点，同时弥补了两者的缺陷。

在混合检索中，我们需要在数据库内提前建立向量索引和关键词索引。在用户输入问题时，通过两种检索模式分别在文档中检索出最相关的内容（见图 2 ）。

图 2 混合检索流程

「混合检索」实际上并没有明确的定义，本文以向量检索和关键词检索的组合为例。如果我们使用其他搜索算法的组合，同样可以被称为「混合检索」。例如，我们可以将用于检索实体关系的知识图谱技术与向量检索技术结合。

不同的检索系统各自擅长寻找文本（段落、语句、词汇）之间不同的细微联系，包括精确关系、语义关系、主题关系、结构关系、实体关系、时间关系、事件关系等。可以说没有任何一种检索模式能够适用于全部情境。混合检索通过多个检索系统的组合，实现了多个检索技术之间的互补。

这里我想强调的是：选择何种检索技术，取决于开发者需要解决什么样的问题。RAG 系统的本质是基于自然语言的开放域问答系统。对于用户的开放性问题，要想获得高的事实召回率，就需要对应用情景进行概括和收敛，寻找合适的检索模式或组合。

在着手设计一个 RAG 系统之前，最好先考虑清楚自己的用户是谁，以及用户最可能提出什么样的问题。

为什么需要重排序？

混合检索能够结合不同检索技术的优势，以获得更好的召回结果。然而，在不同检索模式下的查询结果需要进行合并和归一化（将数据转换为统一的标准范围或分布，以便更好地进行比较、分析和处理），然后再一并提供给大模型。在这个过程中，我们需要引入一个评分系统：重排序模型（ Rerank Model ）。

重排序模型通过将候选文档列表与用户问题的语义匹配度进行重新排序，从而改进语义排序的结果（见图 3 ）。其原理是计算用户问题与给定的每个候选文档之间的相关性分数，并返回按相关性从高到低排序的文档列表。常见的 Rerank 模型如：Cohere rerank、bge-reranker 等。

图 3 混合检索 + 重排序

在大多数情况下，由于计算查询与数百万个文档之间的相关性得分将会非常低效，通常会在进行重排序之前进行一次前置检索。因此，重排序一般放在搜索流程的最后阶段，非常适合用于合并和排序来自不同检索系统的结果。

然而，重排序并不是只适用于不同检索系统的结果合并。 即使在单一检索模式下，引入重排序步骤也能有效帮助改进文档的召回效果，例如在关键词检索之后加入语义重排序。

在具体实践过程中，除了将多路查询结果进行归一化之外，我们会在将相关的文本分段交给大模型之前限制传递给大模型的分段个数（即 TopK，可以在重排序模型参数中设置）。这样做的原因是大模型的输入窗口存在大小限制（一般为 4K、16K、32K、128K 的 Token 数量），我们需要根据选用的模型输入窗口的大小限制，选择合适的分段策略和 TopK 值。

需要注意的是，即使模型上下文窗口足够大，过多的召回分段可能会引入相关度较低的内容，从而导致回答的质量降低。因此，重排序的 TopK 参数并不是越大越好。

重排序并不是搜索技术的替代品，而是一种用于增强现有检索系统的辅助工具。 它最大的优势在于，不仅提供了一种简单且低复杂度的方法来改善搜索结果，允许用户将语义相关性纳入现有的搜索系统中，还无需进行重大的基础设施修改。

以 Cohere Rerank 为例，我们只需要注册账户和申请 API，接入只需要两行代码。此外，Cohere Rerank 还提供了多语言模型，这意味着我们可以将不同语言的文本查询结果进行一次性排序。

Azure AI 实验数据评估

Azure AI 对 RAG 中几种常用的检索模式做了实验数据测试，包括关键词检索、向量检索、混合检索、混合检索 + 重排序。实验结果支持将混合检索 + 重排序视为改进文档召回相关性的有效方法，对于使用 RAG 架构的生成式 AI 场景尤其适用。

以下是针对不同数据集类型的测试结果，可以看到混合检索 + 重排序的组合在不同测试集下的召回质量上都有一定程度的提升（见图 4 ）。