搜索技术仍然是计算机科学中的主要挑战之一，很少有商业产品能够有效地进行搜索。在大型语言模型（LLMs）兴起之前，强大的搜索能力并不被认为是必不可少的，因为它们并没有直接提升用户体验。然而，随着LLMs开始流行，为了将LLMs应用于企业环境，需要一个强大的内置检索系统。这也被称为检索增强生成（RAG）——在将内容输入LLM以生成最终答案之前，搜索内部知识库以找到与用户查询最相关的内容。
想象一个场景，其中LLM回答用户查询。没有RAG，它仅依赖其训练数据；有了RAG，LLM可以在教科书中搜索可能包含答案的段落，就像进行开卷考试一样。现代LLM已经发展到可以处理更长的用户查询，上下文窗口可达数百万个标记。这就提出了一个问题：如果LLM的上下文窗口可以容纳整本教科书，为什么还需要在教科书内进行单独的搜索？事实上，对于具有大上下文窗口的LLM来说，单独的搜索仍然至关重要，原因如下：
- 企业文档通常有多个版本，将它们全部提供给LLM以生成答案可能会导致答案冲突。
- 大多数企业场景需要对输入到上下文窗口的内容进行严格的访问控制。
- LLMs 往往会被语义相关但不相关的内容分散注意力。
- 即使使用强大的LLMs，处理数百万个不相关的令牌也是昂贵且耗时的。
RAG的迅速流行可以归功于各种LLMOps工具，这些工具迅速集成了以下组件以创建一个功能系统。
这种基于语义相似性的方法已经保持多年不变：文档被分块（例如按段落），通过嵌入模型转换为嵌入，并存储在向量数据库中。在检索过程中，查询也被转换为嵌入，数据库找到最相关的块，理论上这些块包含语义上最相关的信息。在这个过程中，LLMOps工具通常处理诸如以下任务：
- 解析文档并将其分割成固定大小的块。
- 编排任务：将块发送到嵌入模型（本地或SaaS）；将生成的嵌入与相应的块一起转发到向量数据库；使用提示模板从向量数据库中组装查询结果。
- 集成业务逻辑，包括生成和返回用户对话内容，将对话与业务系统（如客服平台）连接等。
这个过程实现起来很简单，但搜索结果往往不尽如人意，因为这个基于朴素语义相似性的搜索系统有几个局限性：
- 作为一个块级操作，嵌入过程使得难以区分需要增加权重的Tokens，例如实体、关系或事件。这导致生成的嵌入中有效信息的密度低，召回率差。
- 嵌入对于精确检索是不够的。例如，用户询问其公司2024年3月财务计划中的投资组合时，可能会收到来自不同时间段的投资组合、同一时间段的市场或运营计划，甚至其他类型的数据。
- 其检索结果高度依赖于所选的嵌入模型；通用模型在特定领域可能表现不佳。
- 其检索结果对数据分块方法敏感。然而，这个基于LLMOps的系统在文档分块方面天生简单且粗糙，导致数据语义和结构的丢失。
- 缺乏用户意图识别，仅改进相似性搜索方法无法有效增强对模糊用户查询的答案。
- 无法处理复杂查询，例如多跳问答，这需要从异构信息源进行多步推理。
因此，这个以LLMOps为中心的系统可以被视为RAG 1.0。它具有编排和生态系统的特点，但在有效性方面有所不足。尽管开发者可以快速使用RAG 1.0构建原型系统，但在处理实际企业环境中的问题时，他们常常发现自己陷入困境。因此，RAG必须继续与LLMs一起发展，以促进各种专业领域的搜索。最终，搜索系统的目标是找到答案，而不仅仅是检索最相似的结果。基于这些考虑，我们为RAG 2.0提出了以下关键特性和组件：
-
RAG 2.0 是一个端到端的搜索系统，分为以下几个阶段：信息提取、文档预处理、索引和检索。它不能通过重用为 RAG 1.0 设计的 LLMOps 工具来编排，因为这些阶段是耦合的，缺乏统一的 API 和数据格式，并且存在循环依赖。例如，查询重写对于多跳问答和用户意图识别至关重要，涉及迭代检索和重写。在这里引入编排不仅没有必要，还可能干扰搜索和排名优化。这部分解释了最近对 AI 编排框架 LangChain 的批评。
-
需要一个更全面和强大的数据库来支持混合搜索，以解决RAG 1.0中的低召回率问题。除了向量搜索，它还应包括全文搜索和稀疏向量搜索。它甚至应该实现张量搜索，支持像ColBERT这样的后期交互机制。
-
全文搜索对于精确检索是不可或缺的，因为当发现预期的文档没有在具有明确意图的查询中返回时，可能会相当令人沮丧。此外，通过显示匹配的关键词，全文搜索有助于理解检索背后的原因，这也增加了排名结果的可解释性。因此，在大多数情况下，不建议从RAG的检索选项中删除全文搜索。尽管全文搜索已经存在多年，但仍然不容易实现。除了需要处理大量数据外，它还必须提供基于Top-K联合语义的搜索选项，因为RAG查询通常是完整的句子，而不是几个关键词的组合。不幸的是，市场上声称支持BM25和全文搜索的数据库在这两方面都表现不足。它们既不支持高性能的大规模数据搜索，也不提供有效的检索，因此不适合企业级检索。
-
IBM研究的最新发现表明，结合全文搜索、稀疏向量搜索和密集向量搜索在多个问答数据集上实现了最先进的结果。这表明，原生支持这种三向检索能力的数据库有着光明的未来。
-
张量搜索是一种新颖的检索方法，专门为像ColBERT这样的后期交互机制设计。简而言之，交叉编码器能够捕捉查询和文档之间的复杂交互，产生比普通向量搜索更精确的排名结果。然而，由于它需要同时处理查询和文档段落的编码任务，交叉编码器在排名任务中通常非常慢，仅适用于最终结果的重新排名。像ColBERT这样的排名模型比普通向量搜索具有更高的检索准确性，且信息损失更少。这是因为它使用多个嵌入或张量来表示文档，并计算文档中每个标记的相似性。它也比交叉编码器表现更好，因为文档编码在索引阶段离线执行。这使得它在检索阶段的排名成为一个实际的选择。因此，对于为RAG 2.0设计的数据库，结合张量搜索和全文搜索的混合搜索能力将是有益的。
-
张量搜索是一种新颖的检索方法，专门为像ColBERT这样的后期交互机制设计。简而言之，交叉编码器能够捕捉查询和文档之间的复杂交互，产生比普通向量搜索更精确的排名结果。然而，由于它需要同时处理查询和文档段落的编码任务，交叉编码器在排名任务中通常非常慢，仅适用于最终结果的重新排名。像ColBERT这样的排名模型比普通向量搜索具有更高的检索准确性，且信息损失更少。这是因为它使用多个嵌入或张量来表示文档，并计算文档中每个标记的相似性。它也比交叉编码器表现更好，因为文档编码在索引阶段离线执行。这使得它在检索阶段的排名成为一个实际的选择。因此，对于为RAG 2.0设计的数据库，结合张量搜索和全文搜索的混合搜索能力将是有益的。
-
数据库仅涵盖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