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