从 v0.8 版本开始,RAGFlow 正式迈入 Agentic 时代,后端提供了一套完备的、基于图的任务编排框架,前端则提供了无代码工作流编辑器。为什么要引入 Agentic?这一功能与现有的工作流编排系统有何不同?
要回答这些问题,我们必须先审视 RAG 和 Agent 之间的关系。如果没有 RAG,大语言模型(LLM)只能通过长上下文有限地访问私有数据,这使得 Agent 难以服务于企业场景。客户服务、营销推荐、合规检查和库存优化等,需要的不仅仅是长上下文 LLM 和工作流组装。以单轮对话为代表的朴素 RAG 系统,是支持工作流中 Agent 编排的关键算子。反过来看,RAG 是一种使 LLM 能够访问企业私有数据的架构模式。因此,一个先进的 RAG 系统应该提供远不止于此的功能。当用户查询意图明确时,它应能处理需要跨文档推理和查询分解的多跳问答;对于查询意图模糊的情况,它应能与 Agent 协同工作,采用动态的 Agent 编排来“评判”/评估检索结果、相应地重写查询,并为这些复杂的问答任务进行“多跳”推理。本质上,Agent 和 RAG 是互补的技术,在企业应用中,两者相辅相成,互相增强对方的能力。
RAGFlow 自开源以来,在不到三个月的时间里便在 GitHub 上获得了 10000 颗星。现在是我们反思 RAGFlow 的成功并展望其未来变革的时候了。
上图展示了一个典型的 RAG 工作流程。这种基于语义相似性的方法多年来一直保持一致,可分为四个阶段:文档分块、索引、检索和生成。这个过程实现起来相当直接,但搜索结果往往不尽如人意,因为这种朴素的基于语义相似性的搜索系统有几个局限性:
- 作为一种 chunk 级别的操作,embedding 过程很难区分哪些 token 需要增加权重,比如实体、关系或事件。这导致生成的 embedding 中有效信息密度低,召回率差。
- Embedding 不足以进行精确检索。例如,用户查询公司 2024 年 3 月财务计划中的投资组合,可能会收到不同时间段的投资组合、同一时期的营销或运营计划,甚至是其他类型的数据。
- 其检索结果高度依赖于所选的 embedding 模型;通用模型在特定领域的表现可能不佳。
- 其检索结果对数据分块方法很敏感。然而,这种基于 LLMOps 的系统在文档分块方面天生简单粗糙,导致数据语义和结构的丢失。
- 缺乏用户意图识别能力,仅改进相似性搜索方法无法有效提升对模糊用户查询的回答质量。
- 无法处理复杂查询,例如需要从异构信息源进行多步推理的多跳问答。
因此,这种以 LLMOps 为中心的系统可被视为 RAG 1.0。它具有编排和生态系统的特点,但在效果上有所欠缺。尽管开发者可以用 RAG 1.0 快速构建一个原型系统,但在解决真实企业场景中的问题时,他们常常会陷入困境。因此,RAG 必须随着 LLM 继续发展,以促进在各种专业领域的搜索。基于这些考虑,我们为 RAG 2.0 提出了以下关键特性和组件:
- RAG 2.0 是一个端到端的搜索系统,分为以下几个阶段:信息提取、文档预处理、索引和检索。
- RAG 2.0 无法通过复用为 RAG 1.0 设计的 LLMOps 工具进行编排,因为这些阶段是耦合的,缺乏统一的 API 和数据格式,并且存在循环依赖。例如,对于多跳问答和用户意图识别至关重要的查询重写,就涉及到迭代式的检索和重写。
- 为了解决 RAG 1.0 中召回率低的问题,需要一个更全面、更强大的支持混合搜索的数据库。除了向量搜索,它还应包括全文搜索和稀疏向量搜索,甚至应该实现支持像 ColBERT 这样的后期交互机制的张量搜索。
- 数据库在 RAG 2.0 中只涵盖了查询和检索。从全局来看,优化 RAG 流程的每个阶段都至关重要。这包括:
- 需要一个独立的数据提取和清洗模块来对用户数据进行分块。它依赖一系列识别模型,来识别各种复杂的文档结构,包括表格和图文混排,并根据检索到的搜索结果迭代调整其分块大小。
- 在发送到数据库进行索引之前,提取的数据可能会经过多个预处理程序,包括知识图谱构建、文档聚类和领域特定 embedding。这些程序通过多种方式对提取的数据进行预处理,确保检索结果包含必要的答案。这对于解决复杂查询问题(如多跳问答、用户意图模糊和领域特定查询)至关重要。
- 检索阶段涉及粗排和精排。精排通常在数据库之外进行,因为它需要不同的重排模型。此外,用户查询将根据 AI 模型识别出的用户意图,经历一个持续重写的循环。这个过程会一直持续,直到检索到的答案令用户满意为止。
总的来说,RAG 2.0 中的每个阶段基本上都是围绕 AI 模型构建的。它们与数据库协同工作,以确保最终答案的有效性。
当前开源版本的 RAGFlow 主要解决了流程的第一个阶段,即使用深度文档理解模型来确保数据的“高质量输入,高质量输出”。此外,它在第三个阶段(索引)采用了双路检索(dual-retrieval),将关键词全文搜索与向量搜索相结合。这些特性使其区别于其他 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 在企业场景中“流动”起来。如果您认同这一愿景,请在 GitHub 上关注并为我们的项目点赞。