Dify V2.0.0 beta版本带来知识管道与图引擎两大革命性升级，重新定义RAG工作流！

核心内容：

1. 知识管道架构：模块化编排文档处理全流程

2. 7种专业模板与DSL语言：快速构建定制化解决方案

3. 基于队列的图引擎：实现稳定可控的工作流执行

Dify V2.0.0终于来了，虽然只是测试版，但它带来的功能绝对是大家期待已久的RAG 2.0。老版本在V1.6.0就已经原生支持了MCP，而这次V2.0更是迎来了知识库管理的大改版。从趋势来看，后续两个重磅功能估计也快要登场了，是时候一起冲了。

在Dify 2.0中，引入了两项主要的新功能：知识管道和基于队列的图形引擎。知识管道为知识的提取和处理提供了模块化且可扩展的工作流，而基于队列的图引擎则使工作流的执行更加稳健且可控。下图就是知识库编排的一个示例：

1 新版本特性

1.1 知识管道（Knowledge Pipeline）

1.1.1 简介

借助全新的知识管道编排界面，一项根本性的架构升级被引入，它重塑了文档处理的设计与执行方式。这提供了一个更模块化、更灵活的工作流，使用户能够编排管道的每一个阶段。通过集成市场中丰富的强大插件，能够灵活地集成多样化的数据源和处理工具。最终，这种架构能够构建高度定制化、特定领域的RAG解决方案，以满足企业对可扩展性、适应性和精确性日益增长的需求。

1.1.2 为什么需要它？

以前，Dify的RAG用户在实际应用中仍然面临持续的挑战——从不准确的知识检索和信息丢失，到有限的数据集成和扩展性。常见的痛点包括：

• 数据源集成受限
• 缺失表格和图像等关键元素
• 不理想的分块结果

所有这些都会导致糟糕的答案质量，并阻碍模型的整体性能。作为回应，Dify中的RAG被重新构想为一种开放且模块化的架构，使开发者、集成商和领域专家能够构建符合其特定需求的文档处理管道——从数据提取到分块存储和检索。

1.1.3 核心能力

1、知识管道架构

知识管道是一个基于节点的可视化编排系统，专用于文档采集。它提供了一种可定制的方式来自动化复杂的文档处理，实现细粒度的转换，并将原始内容与结构化、可检索的知识连接起来。开发人员可以像拼拼图一样逐步构建工作流程，使文档处理更易于观察和调整。

2、模版与管道DSL

除了空白模版外，提供了7种方式的模版：

• 通用方式模版
• 父子模版
• 简单问答模版
• 包含了图片、表格的复杂PDF模版
• 使用LLM进行上下文丰富模版
• 转换为Markdown模版
• 基于大语言模型生成问答模版

• 通过官方模版可以快速上手。
• 通过DSL（领域特定语言）的导入/导出功能，可以定制和分享管道，从而更便于重复利用和协作。

我们可以简单的看一下简单问答模版，包含三个节点：文件作为输入源，然后是问答处理器、知识库节点。这个流程可以分为三个部分：数据提取、数据处理和数据存储。

首先是数据提取。数据源为本地文件，并接受.xlsx、.xls、.csv等格式的文件。接着是数据处理。数据从"FILE"节点进入"Q&A PROCESSOR"节点。这个处理器能够从文件中提取指定的问答对，并通过"问答匹配"策略来匹配用户的查询，从而检索到相关的答案。这种策略在处理高频或相似的用户问题时非常有效。最后是数据存储。经过处理的问答对最终会被存储到"KNOWLEDGE BASE"（知识库）节点。图片右侧的描述显示，知识库提供了两种索引方法："高质量"和"经济"模式，以满足不同的需求。

3、可定制的数据源和工具

官方现在提供了13个数据源插件。

每个知识库均可支持多个数据源。可以通过基于插件的采集框架无缝集成本地文件、在线文档、云盘和网络爬虫。开发者可以使用新的数据源插件扩展生态系统，而市场处理器则处理公式、电子表格和图像解析等特殊用例，确保数据采集的准确性和结构化呈现。

4、新的分块策略

除了常规模式和父子模式外，新的问答处理器插件还支持问答结构。这扩大了对更多用例的覆盖范围，并在检索精度和上下文完整性之间取得了平衡。

5、图像提取与检索

从多种格式的文档中提取图像，将它们作为URL存储在知识库中，并启用混合文本图像输出以改进LLM生成的答案。

6、测试运行和调试支持

在发布管道之前，可以：

• 独立执行单个步骤或节点
• 详细检查中间变量
• 在变量检查器中以Markdown格式预览字符串变量

这在每个阶段都提供了安全的迭代和调试。

7、一键迁移旧知识库

通过单一操作将现有知识库无缝转换为知识管道架构，确保平稳过渡和向后兼容。

1.1.4 为什么它很重要

知识管道使知识管理更加透明、可调试且可扩展。它并非终点，而是未来增强功能（例如多模态检索、人机协作和企业级数据治理）的基础。期待看到它如何被应用以及来自社区的反馈。

1.2 基于队列的图形引擎（Queue-based Graph Engine）

1.2.1 为什么需要它

以前，使用并行分支设计工作流通常会导致：

• 难以管理分支状态和重现错误
• 调试信息不足
• 执行逻辑僵化，缺乏灵活性

这些问题降低了复杂工作流程的可用性。为了解决这个问题，围绕队列调度重新设计了执行引擎，改进了并行任务的管理。

1.2.2 核心能力

1、队列调度模型

所有任务进入统一队列，调度程序在此管理依赖关系和顺序。这减少了并行执行中的错误，并使拓扑更加直观。

2、灵活的执行起点

执行可以在任何节点开始，支持部分运行、恢复和子图调用。

3、流处理组件

新的ResponseCoordinator处理来自多个节点的流输出，例如逐个令牌的LLM生成或长期运行任务的阶段性结果。

4、命令机制

使用CommandProcessor，可以在执行期间暂停、恢复或终止工作流，从而实现外部控制。

5、GraphEngineLayer

新增插件层，无需修改核心代码即可扩展引擎功能。它可以监控状态、发送命令并支持自定义监控。

2 未来计划

本次Beta测试版仅仅是个开始。即将推出的改进包括：

• 调试工具：可视化界面，实时查看执行状态和变量。
• 智能调度：利用历史数据优化调度策略。
• 更完整的命令支持：添加暂停/恢复、断点调试。
• 人机循环：支持执行过程中的人为干预。
• 子图功能：增强模块化和可重用性。
• 多模式嵌入：支持文本之外更丰富的内容类型。

期待社区的反馈和体验，以使引擎更加实用。

3 升级指南

升级后，必须运行以下迁移来转换现有数据源凭据。此步骤是确保与新版本兼容所必需的：

uv run flask transform-datasource-credentials

3.1 Docker Compose部署

1、备份yaml文件

cd docker
cp docker-compose.yaml docker-compose.yaml.$(date +%s).bak

2、从主分支获取最新代码

git checkout 2.0.0-beta.1
git pull origin 2.0.0-beta.1

3、停止服务，在docker目录下执行

docker compose down

4、备份数据

tar -cvf volumes-$(date +%s).tgz volumes

5、升级服务

docker compose up -d

6、在容器启动后迁移数据

docker exec -it docker-api-1 uv run flask transform-datasource-credentials

3.2 源码部署

1、停止API Server、Worker和Web前端服务

2、获取最新发布分支的代码

git checkout 2.0.0-beta.1

3、更新Python依赖项

cd api
uv sync

4、运行迁移脚本

uv run flask db upgrade
uv run flask transform-datasource-credentials

5、最后，再次运行API Server、Worker和Web前端服务

最后再多说一句。这次Dify 2.0推出了不少知识管道模板，后续会逐一深入讲解。

本次发布的只是V2.0 beta版本，功能虽然强大，但在生产环境使用还是要谨慎。强烈推荐在测试环境中先跑一跑，体验一下知识管道和图引擎的魅力。至于生产环境，还是稳一点，等正式版发布后再进行升级也不迟。