从 0.8 版本开始，RAGFlow 后端提供了完整的基于图的任务编排框架，并且在前端支持无代码方式编辑任务和工作流，正式步入Agentic 时代。为什么要实现这一功能，跟一些已有的工作流编排有什么不同？

要回答这些问题，首先需要来谈谈 RAG 和 Agent 之间的关系。假如没有 RAG，那么 LLM 只具备有限的访问私有化数据的能力（利用长上下文），很多企业级必备的功能，是无法组装成 Agent 服务具体场景的。例如客户服务问答，营销推荐，合规检查，库存优化，等等，这些系统，并不是依靠长上下文并组装工作流就可以完成的，可以说，以单轮简易对话为代表的 RAG，是支撑 Agent 服务垂类企业场景的工作流编排中不可或缺的算子。而反过来， RAG 只是一种架构模式，它代表了如何让 LLM 面向企业级私域数据提供访问能力，因此 RAG 所涵盖的，不仅仅是单轮简易对话，还包含诸如在用户对话意图明确时，如何进行多跳问答（答案涉及跨文档，以及单个提问需要分解为多个子问题等情况）；用户对话意图不明时，如何提供答案，等等诸如此类的情况。在这些情况下，RAG 本身反过来需要依赖 Agent 机制来实现 Agentic RAG，也就是引入 Agent 的动态编排来处理对话，根据用户提问的不同意图，引入反馈和查询改写，从而服务上述复杂的提问。因此， Agent 和 RAG 可以说两者互为基石。

其次，RAGFlow 近期开源刚满 3 个月，已经获得了 github 万星，我们有必要站在这个阶段，来回顾和展望一下，RAGFlow 做对了什么，未来将如何演进。

上图是一个标准的 RAG 工作流程，这种基于语义相似度的方法已经工作了很多年，它可以分为4个阶段：分块、索引、检索、生成。这个流程的建立很简单，但效果却很一般，因为这套朴素的基于语义相似度的搜索系统包含若干局限：

• Embedding 是针对整块文本的处理，对于一个特定的问题，它无法区分文字中特定的实体/关系/事件等权重明显需要提高的 Token，这样导致 Embedding 的有效信息密度有限，整体召回精度不高。

• Embedding 无法实现精确检索。例如如果用户询问“2024年3月我们公司财务计划包含哪些组合”，那么很可能得到的结果是其他时间段的数据，或者得到运营计划，营销管理等其他类型的数据。

• 对 Embedding 模型很敏感，针对通用领域训练的 Embedding 模型在垂直场景可能表现不佳。

• 对如何数据分块很敏感，输入数据的解析、分块和转换方式不同，导致的搜索返回结果也会大不同。而依托于LLMOps 工具的体系，对于数据分块的逻辑往往简单粗暴，忽视了数据本身的语义和组织。

• 缺乏用户意图识别。用户的提问可能并没有明确的意图，因此即便解决了前述的召回精度问题，在意图不明的情况下，也没有办法用相似度来找到答案。

• 无法针对复杂提问进行回答，例如多跳问答。

因此可以把这类以 LLMOps 为核心的 RAG 看作 1.0 版本，它的主要特点在于重编排而轻效果，重生态而轻内核。因此，从面世一开始就迅速普及，普通开发者可以借助于这些工具快速搭建起原型系统，但在深入企业级场景时，却很难满足要求，并且经常处于无计可施的状态。基于这些，我们认为未来的 RAG 2.0 应该是这样工作的：

其主要特点为：

1. RAG 2.0 是以搜索为中心的端到端系统，它将整个 RAG 按照搜索的典型流程划分为若干阶段：包含数据的信息抽取、文档预处理、构建索引以及检索。

2. RAG 2.0 是典型的 AI Infra，它无法用类似的 LLMOps 工具来编排。因为以上环节之间相互耦合，接口远没有到统一API和数据格式的地步，并且环节之间还存在循环依赖。例如对问题进行查询重写，是解决多跳问答、引入用户意图识别必不可少的环节。查询重写和获得答案，是一个反复检索和重写的过程。

3. 需要一个更全面和强大的数据库，来提供更多的召回手段，这是由于为解决 RAG 1.0 中召回精度不高的痛点，需要采用多种方法混合搜索。

4. 数据库只能涵盖 RAG 2.0 中的数据检索和召回环节，还需要站在整个 RAG 的链路上，针对各环节进行优化，这包括：需要有单独的数据抽取和清洗模块，来针对用户的数据，进行切分。切分的粒度，需要跟最终搜索系统返回的结果进行迭代。数据抽取模块，需要考虑到用户的各种不同格式，包含复杂文档例如表格处理和图文等，因此它必须依托于若干模型才能完成任务。高质量的数据抽取模块，是保证高质量搜索的前置条件。

5. 抽取出的数据，在送到数据库索引之前，还可能需要若干预处理步骤，包括知识图谱构建，文档聚类，以及针对垂直领域的 Embedding 模型微调等。这些工作，本质上是为了辅助在检索阶段提供更多的依据，从而让检索更加精准。这个步骤不可或缺，它是针对用户的复杂提问，例如多跳问答，意图不确定，以及垂直问答等情况下的必要手段。通过把文档中包含的内部知识以多种方式组织，才能确保在召回结果包含所需要的答案。

6. 检索阶段分为粗筛和精排。精排通常放在数据库外进行，因为它需要不同的重排序模型。除此之外，还需要对用户的查询不断改写，根据模型识别出的用户意图不断改写查询，然后检索直至找到满意的答案。这些阶段，可以说每个环节都是围绕模型来工作的。它们联合数据库一起，共同保证最终问答的效果。

RAGFlow 目前的开源版本，着重解决的是以上环节的第一环，用深度文档理解模型来提供数据的 Quality in, quality out。此外它在第三个环节 Indexing 阶段也采用了 2 路召回混合搜索的方式，同时进行关键词全文搜索和向量搜索。这些是它区分于其他 RAG 产品的主要点。可以说，RAGFlow 正在向着 RAG 2.0 方向稳步推进。

从 RAGFlow 0.8 开始推出的 Agent ，就是进一步在 RAG 2.0 的其他阶段提供的基础支撑能力。举例来说，我们希望引入查询意图来决定如何对话，并引入类似 Self-RAG 的机制，对检索结果打分和重写，这就需要用到 Agent 来实现 Agentic RAG，并且这种 Agent 是包含反思能力的编排系统，也就是说是一个包含“环”的图，而并非普通意义上的工作流（DAG：有向无环图），如下所示意。

这种包含环的图编排系统，为 Agent 引入了反思机制，可以说，具备反思能力，是 Agent 走向智能的必备基础，反思可以引导对话探索意图，理解目标，从而做到对上下文的自适应，最终完成高质量的回答。

除了能够实现 Agentic RAG，为后续更多的 RAG 2.0 特性奠定基础之外，工作流业务系统也是 RAG 支撑企业必备的功能。有了 RAG 2.0 的加持，Agent 承载 LLM 真正走向企业的场景就更加顺理成章。因此，RAGFlow 提供以无代码方式来编辑工作流。不论是 Agentic RAG ，还是工作流业务系统，都可以采用。下图是目前无代码工作流编辑系统提供的若干内置模板模板供用户创建参考，例如客服系统，HR 候选人沟通对话系统，等等，这些模板将会不断增加，以期望覆盖更多场景。

下图是一个 Self-RAG 的工作流样例，检索出的结果，会有一个 Relevant 算子评估是否跟用户提问相关，如果不相关，就改写查询，直到 Relevant. 算子评估符合要求。

下图是一个 HR 管理候选人的业务系统，这是一个典型的多轮对话场景。无代码编排模板后边紧跟的就是基于该工作流进行对话的样例展示。

下边是 RAGFlow 目前所支持无代码编辑的工作流算子，分隔线上是功能性算子，跟 RAG 和对话密切相关， 这部分算子是 RAGFlow 显著区分于其他系统的地方。分隔线之下是各类 Tools，这部分目前已有的各类工作流 Agent 系统接入得非常多， RAGFlow 目前还是初期，更多的 Tools 后续会不断添加进来。

再回到最开始的提问，RAGFlow 的这套编排体系和无代码框架，跟市面同类产品的区别在哪里？首先，这套体系是以 RAG 为中心而非 LLM 为中心，因此它更强调在企业级场景如何利用 RAG 去支撑垂直业务。其次，它的存在是同时兼顾 RAG 2.0 的核心诉求，将查询意图，查询改写，数据预处理等等搜索相关的技术编排起来，从而提供更加精准的对话，也兼顾以工作流编排为主要特色的业务系统。

RAGFlow 的未来，是以 RAG 2.0 为中心的 Agentic 体系， 让 RAG 在企业 Flow 起来，这是我们的目标