RAGFlow 正式进入 Agentic 时代

从 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 是针对整块文本的处理，对于一个特定的问题，它无法区分文字中特定的实