RAGFlow 迈入智能体时代

2024年7月11日阅读时长 8 分钟

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

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

RAGFlow 在开源后的不到三个月内便获得了 10,000 个 GitHub 星标。现在是我们反思 RAGFlow 的成功并展望其未来变革的时候了。

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

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

因此，这种以 LLMOps 为中心的系统可以被视为 RAG 1.0。它虽然具备编排能力和生态系统，但在有效性方面表现不足。尽管开发者可以使用 RAG 1.0 快速搭建原型系统，但在处理真实企业场景中的问题时，往往会陷入困境。因此，RAG 必须随着 LLM 的发展而持续演进，以促进各种专业领域的搜索。基于这些考虑，我们为 RAG 2.0 提出了以下关键特性和组件：

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

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

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

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

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

智能体 RAG 和工作流的引入，自然地促进了 RAG 2.0 向企业检索场景的集成。为了支持这一点，RAGFlow 提供了一种无代码工作流编辑方法，适用于智能体 RAG 和工作流业务系统。下面的截图展示了 RAGFlow 无代码工作流编排系统中目前可用的几个内置模板，供用户入门使用，包括客服和 HR 拨测助手模板。该模板列表正在不断扩展，以覆盖更多场景。

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

下图显示了一个 HR 候选人管理系统，这是一个多轮对话场景的范例。在该无代码编排模板之后，紧接着提供了一个相应的示例对话。

以下是可以在无代码中编排的工作流算子。分割线以上是与 RAG 和对话密切相关的功能算子，这使得 RAGFlow 有别于其他 RAG 系统。分割线以下是一些工具。许多现有的工作流智能体系统已经整合了许多此类工具。RAGFlow 仍处于早期阶段，未来将加入更多此类工具。

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

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