RAGFlow 进入 Agentic（智能体）时代

自 v0.8 版本起，RAGFlow 正式进入 Agentic（智能体）时代，在后端提供了全面的基于图的任务编排框架，并在前端提供了无代码工作流编辑器。为什么选择智能体？这项功能与现有的工作流编排系统有何不同？

为了解答这些问题，我们首先必须审视 RAG 与智能体之间的关系。如果没有 RAG，大型语言模型（LLM）只能通过长上下文有限地访问私有数据，这使得智能体难以服务于企业场景。客户服务、营销推荐、合规检查和库存优化不仅需要长上下文大型语言模型和工作流组装。以单轮对话为代表的朴素 RAG 系统是支持工作流中智能体编排的关键操作符。反之，RAG 是一种架构模式，使大型语言模型能够访问企业内部数据。因此，一个先进的 RAG 系统应该提供更多功能。当用户查询意图明确时，它应该能够处理多跳问答，这需要跨文档推理和查询分解；当查询意图模糊时，它应该能够与智能体协同工作，采用动态智能体编排来“批判”/评估检索结果，相应地重写查询，并对这些复杂的问答任务进行“多跳”推理。实质上，智能体和 RAG 是互补的技术，在企业应用中相互增强能力。

RAGFlow 自开源发布以来，在不到三个月的时间里获得了 10,000 个 GitHub 星标。现在是时候反思 RAGFlow 的成功，并展望其未来的变革了。

上图展示了 RAG 的典型工作流。这种基于语义相似性的方法多年来一直保持一致，可以分为四个阶段：文档分块、索引、检索和生成。这个过程实现起来相当直接，但搜索结果往往不尽如人意，因为这种朴素的基于语义相似性的搜索系统存在一些局限性：

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

因此，这种以 LLMOps 为中心的系统可以视为 RAG 1.0。它具有编排和生态系统，但在有效性方面存在不足。尽管开发者可以利用 RAG 1.0 快速构建原型系统，但在处理实际企业场景中的问题时常常会陷入困境。因此，RAG 必须与大型语言模型一起不断发展，以促进在各种专业领域的搜索。基于这些考虑，我们为 RAG 2.0 提出了以下关键特性和组件：

1. RAG 2.0 是一个端到端的搜索系统，分为以下几个阶段：信息提取、文档预处理、索引和检索。
2. RAG 2.0 不能通过重用为 RAG 1.0 设计的 LLMOps 工具来编排，因为这些阶段相互耦合，缺乏统一的 API 和数据格式，并且存在循环依赖。例如，查询重写对于多跳问答和用户意图识别至关重要，它涉及迭代的检索和重写过程。
3. 需要一个更全面、更强大的支持混合搜索的数据库来解决 RAG 1.0 中的低召回率问题。除了向量搜索，它还应该包括全文搜索和稀疏向量搜索。它甚至应该实现支持 ColBERT 等后期交互机制的 Tensor 搜索。
4. 数据库在 RAG 2.0 中仅涵盖查询和检索。从全局角度来看，优化 RAG 流水线的每个阶段至关重要。这包括：
   1. 需要一个单独的数据提取和清洗模块来对用户数据进行分块。它依靠一系列识别模型，能够识别各种复杂的文档结构，包括表格和图文混排的文本，并根据检索到的搜索结果迭代调整其分块大小。
   2. 在发送到数据库进行索引之前，提取的数据可能会经历一些预处理程序，包括知识图谱构建、文档聚类和领域特定嵌入。这些程序通过以多种方式预处理提取的数据，确保检索结果包含所需的答案。这对于解决多跳问答、模糊用户意图和领域特定查询等复杂问题至关重要。
   3. 检索阶段涉及粗排和精排。精排通常发生在数据库之外，因为它需要不同的重排模型。此外，用户查询会根据人工智能模型识别的用户意图，持续经历重写循环。这个过程一直持续到检索到的答案令用户满意为止。

总的来说，RAG 2.0 中的每个阶段基本上都围绕着人工智能模型构建。它们与数据库协同工作，以确保最终答案的有效性。

当前 RAGFlow 的开源版本主要解决了流水线的第一个阶段，使用深度文档理解模型来确保数据的“高质量输入，高质量输出”。此外，在第三阶段的索引过程中，它采用了双向检索（dual-retrieval），结合了关键词全文搜索和向量搜索。这些特性使其区别于其他 RAG 产品，表明 RAGFlow 已经迈向了 RAG 2.0 之路。

RAGFlow v0.8 实现了智能体，以便更好地支持 RAG 2.0 流水线中的后续阶段。例如，为了改进对话中模糊查询的处理，RAGFlow 引入了一种类似 Self-RAG 的机制，用于对检索结果进行评分和重写用户查询。这种机制需要使用智能体来实现一个具有反思能力的 Agentic RAG 系统，该系统以循环图而非传统工作流（DAG：有向无环图）的方式运行。请参见下图：

这种循环图编排系统为智能体引入了反思机制。反思使智能体能够探索用户意图，动态适应上下文，引导对话，并最终提供高质量的回复。反思能力奠定了智能体智能的基础。

Agentic RAG 和工作流的引入自然促进了 RAG 2.0 集成到企业检索场景中。为了支持这一点，RAGFlow 提供了一种无代码工作流编辑方法，适用于 Agentic RAG 和工作流业务系统。下面的截图展示了 RAGFlow 无代码工作流编排系统中当前可供用户入门使用的几个内置模板，包括客户服务和人力资源呼叫助手模板。此模板列表正在不断扩展，以涵盖更多场景。

下面的截图展示了一个 Self-RAG 工作流示例。一个名为“Relevant”（相关性）的操作符评估检索结果是否与用户查询相关。如果认为不相关，则重写查询。此过程重复进行，直到“Relevant”操作符确定结果令人满意为止。

下图展示了一个人力资源候选人管理系统，示例说明了多轮对话场景。紧随这个无代码编排模板之后提供了相应的对话示例。

以下是可以在无代码模式下编排的工作流操作符。分隔线上方是与 RAG 和对话密切相关的功能操作符，这些是 RAGFlow 与其他 RAG 系统的区别所在。分隔线下方是一些工具。许多现有的工作流智能体系统已经集成了许多此类工具。RAGFlow 尚处于早期阶段，未来将添加更多此类工具。

现在，让我们来回答最初的问题：RAGFlow 的无代码编排与市场上的类似 RAG 项目有何不同。首先，RAGFlow 是以 RAG 为中心而非以 LLM 为中心，因此强调 RAG 如何在企业级场景中支持特定领域的业务。其次，它解决了 RAG 2.0 的核心需求，并编排了与搜索相关的技术，例如查询意图识别、查询重写和数据预处理，以提供更精确的对话，同时还兼顾了以工作流编排为特征的业务系统。

RAGFlow 的未来愿景是一个 Agentic RAG 2.0 平台，我们的终极目标是让 RAG 在企业场景中“流动”起来。如果您也认同这一愿景，请在 GitHub 上关注并星标我们的项目。