跳转到主内容

RAGFlow 迈入智能体时代

阅读时间 8 分钟

自 v0.8 版本起，RAGFlow 正式进入 Agentic 时代，在后端提供了一套完备的基于图的任务编排框架，在前端则提供了无代码的工作流编辑器。为什么要转向 Agentic？这一特性与现有的工作流编排系统有何不同？<!--truncate-->

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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