跳转到主内容

从 RAG 1.0 到 RAG 2.0，万变不离其宗

阅读时长 8 分钟

搜索技术一直是计算机科学的主要挑战之一，市面上鲜有能够实现高效搜索的商业产品。在大语言模型（LLMs）兴起之前，强大的搜索能力并未被视为刚需，因为它们并不直接影响用户体验。然而，随着 LLM 的普及，将 LLM 应用于企业环境需要强大的内置检索系统。这也就是所谓的检索增强生成（RAG）——在将内容提供给 LLM 生成最终答案之前，先在内部知识库中搜索与用户查询最相关的内容。<!--truncate-->

想象一个 LLM 回答用户查询的场景。如果没有 RAG，它完全依赖其训练数据；有了 RAG，LLM 可以在教科书中搜索可能包含答案的段落，就像进行开卷考试一样。现代 LLM 已经进化到可以处理更长的用户查询，上下文窗口（Context Window）可达数百万个 token。这就提出了一个问题：如果 LLM 的上下文窗口可以容纳整本教科书，为什么还需要在教科书内部进行单独搜索？事实上，对于拥有大上下文窗口的 LLM 来说，单独的搜索仍然至关重要，原因如下：

  • 企业文档通常有多个版本，将所有版本都提供给 LLM 生成答案可能会导致矛盾的回答。
  • 大多数企业场景要求对输入到上下文窗口的内容进行严格的访问控制。
  • LLM 容易被语义相关但实际上无关的内容干扰。
  • 即使使用强大的 LLM，处理数百万个无关 token 的成本也很高且耗时。

RAG 的迅速普及可以归功于各种 LLMOps 工具，它们通过快速整合以下组件来创建一个功能系统：

这种基于语义相似度的方法多年来保持一致：文档被切片（例如按段落），通过嵌入模型转换为向量（Embeddings），并存储在向量数据库中。在检索过程中，查询也被转换为向量，数据库寻找最相关的切片，理论上这些切片包含最相关的语义信息。在此过程中，LLMOps 工具通常处理以下任务：

  • 解析文档并将其拆分为固定大小的切片。
  • 编排任务：将切片发送到嵌入模型（本地或 SaaS）；将生成的向量与对应的切片转发到向量数据库；使用提示词模板组装来自向量数据库的查询结果。
  • 集成业务逻辑：包括生成并返回用户对话内容、将对话与客服平台等业务系统连接等。

这个过程实现起来非常直接，但搜索结果往往不尽如人意，因为这种朴素的基于语义相似度的搜索系统存在若干局限：

  • 作为切片级的操作，向量化过程很难区分需要增加权重的 Token，例如实体、关系或事件。这导致生成的向量中有效信息密度低，召回率差。
  • 向量对于精确检索是不够的。例如，用户询问其公司 2024 年 3 月财务计划中的投资组合，可能会收到来自不同时期的投资组合，或者同期的营销/运营计划，甚至其他类型的数据。
  • 其检索结果高度依赖于所选的嵌入模型；通用模型在特定领域的表现可能欠佳。
  • 其检索结果对数据切片方法非常敏感。然而，这种基于 LLMOps 的系统在文档切片方面天生简单粗暴，导致数据语义和结构的丢失。
  • 缺乏用户意图识别，仅仅改进相似度搜索方法无法有效增强对模糊用户查询的回答。
  • 无法处理复杂查询，如多跳问答，这需要从异构信息源进行多步推理。

因此，这种以 LLMOps 为中心的系统可以被视为 RAG 1.0。它虽然具备编排和生态，但在有效性上有所欠缺。虽然开发者可以使用 RAG 1.0 快速构建原型系统，但在处理真实企业环境中的问题时，往往会陷入困境。因此，RAG 必须随着 LLM 的发展而继续进化，以促进各个专业领域的搜索。归根结底，搜索系统的目标是找到答案，而不仅仅是检索最相似的结果。基于这些考虑，我们提出了 RAG 2.0 的以下核心特征和组件：

  1. RAG 2.0 是一个端到端的搜索系统，分为信息提取、文档预处理、索引和检索几个阶段。它不能通过复用为 RAG 1.0 设计的 LLMOps 工具来编排，因为这些阶段是耦合的，缺乏统一的 API 和数据格式，并且存在循环依赖。例如，查询重写对于多跳问答和用户意图识别至关重要，涉及迭代检索和重写。在此引入编排不仅没有必要，还可能干扰搜索和排序优化。这在一定程度上解释了最近对 AI 编排框架 LangChain 的批评。

  2. 为了解决 RAG 1.0 中召回率低的问题，需要一个更全面、更强大的支持混合搜索的数据库。除了向量搜索外，它还应包括全文搜索和稀疏向量搜索。它甚至应该实现张量（Tensor）搜索，以支持像 ColBERT 这样的延迟交互机制。

    • 全文搜索对于精确检索是不可或缺的，因为当针对意图明确的查询却没能返回预期的文档时，会让人非常沮丧。此外，通过显示匹配的关键词，全文搜索有助于理解检索背后的原因，这也有助于排序结果的可解释性。因此，在大多数情况下，不建议从 RAG 的检索选项中去掉全文搜索。尽管全文搜索已经存在多年，但实现起来依然不易。除了需要处理海量数据外，它还必须提供基于 Top-K 并集（Union）语义的搜索选项，因为 RAG 查询通常是完整的句子，而不是几个关键词的组合。不幸的是，市场上声称支持 BM25 和全文搜索的数据库在这两方面都表现不足。它们既不支持高性能的海量数据搜索，也无法提供有效的检索，因此无法直接用于企业级检索。
    • IBM Research 最近的发现表明，将全文搜索、稀疏向量搜索和稠密向量搜索相结合，在多个问答数据集上达到了最先进（SOTA）的结果。这表明原生支持这种“三路检索”能力的数据库具有广阔的前景。
    • 张量搜索是专门为 ColBERT 等延迟交互机制设计的一种新型检索方法。简而言之，交叉编码器（Cross-encoder）能够捕捉查询与文档之间的复杂交互，产生比普通向量搜索更精确的排序结果。然而，由于它需要同时处理查询和文档段落的编码任务，交叉编码器在排序任务中通常非常缓慢，只适合对最终结果进行重排。像 ColBERT 这样的排序模型在信息损失更少的情况下，比普通向量搜索实现了更高的检索精度。这是因为它使用多个向量或一个张量来表示一个文档，并计算文档中每个 Token 的相似度。它的表现也优于交叉编码器，因为文档编码是在索引阶段离线完成的。这使其成为检索阶段排序的务实选择。因此，对于为 RAG 2.0 设计的数据库，具备将张量搜索与全文搜索相结合的混合搜索能力将大有裨益。

  3. 在 RAG 2.0 中，数据库仅涵盖查询和检索。从全局视角看，优化 RAG 流水线的每一个阶段都至关重要。这包括：

    • 需要一个独立的数据提取和清洗模块来对用户数据进行分块。它依靠一系列识别模型，识别各种复杂的文档结构（包括表格和图文混排内容），并根据检索结果迭代调整其切片大小。数据提取和清洗过程可以类比为现代数据栈中的 ETL，但复杂得多。ETL 本质上是一个基于 SQL 的确定性系统，而这个过程是一个围绕文档结构识别模型构建的非标系统。
    • 在发送到数据库进行索引之前，提取的数据必须经过多个预处理程序，包括知识图谱构建、文档聚类和领域特定嵌入。这些程序通过以多种方式预处理提取的数据，确保检索结果中包含必要的答案。这对于解决多跳问答、模糊用户意图和领域特定查询等复杂查询问题至关重要。
    • 在发送到数据库进行索引之前，提取的数据必须经过多个预处理程序，包括知识图谱构建、文档聚类和领域特定嵌入。这些程序通过以多种方式预处理提取的数据，确保检索结果中包含必要的答案。这对于解决多跳问答、模糊用户意图和领域特定查询等复杂查询问题至关重要。

RAG 2.0 中的每个阶段本质上都是以模型为中心的。它们与数据库协同工作，以确保最终答案的有效性。

RAG 2.0 围绕数据库和 AI 模型构建，需要一个持续迭代的平台。这促使我们开发并开源了 RAGFlow。RAGFlow 没有复用现有的 RAG 1.0 组件，而是从流水线的视角解决了 LLM 检索系统中的根本挑战。自开源发布以来，它在不到三个月的时间内就获得了 10,000 个 GitHub 星标，标志着一个新的开始。然而，RAGFlow 仍处于早期阶段，其每个部分都需要进一步进化。

RAG 2.0 将显著影响企业场景中的 LLM 应用，我们对其作为 AI 驱动力的未来充满热情。如果您也感兴趣，欢迎关注我们的工作：https://github.com/infiniflow/ragflow

© . This site is unofficial and not affiliated with InfiniFlow.