上个月就给大家同步了dify的下一个工作，rag2.0，当时我和他们的产品聊过rag2.0，核心的rag不会变动太多(dify本身rag能力够用，问题最多的在于文档格式)。主要是数据解析这块，以流水线的方式处理文档。 也叫知识管道。
上周dify发布了1.8.1以后，随后又发布了预览版dify 2.0.0 作为dify的大版本升级，更新的内容会比较多，如果是生产环境，建议先不要升级，等到正式发布以后再动，如果只是体验，可以直接升级。
注意，注意，注意，升级前一定要先备份一下。
升级
本次预览版的升级，是以tag的形式发布的。如果你fork的代码，不会同步tags和其他分支的，你可以把.git/config里的地址改为dify的。
如果自己本身代码有改动，先拉一个分支，本地提交下，然后再创建一个新的分支，来试验2.0.0版本。# 只拉取指定的tag
git fetch origin tag 2.0.0-beta.2
# 创建一个2.0.0-beta的分支
git checkout -b 2.0.0-beta 2.0.0-beta.2
关闭并重启
docker compose down
docker compose up -d
#执行2.0升级命令，分组名称，默认是docker-api-1 我命名为dify了
docker exec -it dify-api-1 uv run flask transform-datasource-credentials
知识管道
在升级之前我们要么在后台直接上传文本处理知识库，要么在通过工作流或者代码直接调用api处理。在本次升级以后，官方直接把知识库的处理流程给开放了出来，并且提供了一些模板案例。
在升级之前，我们通过工作流也能完成，无非麻烦一些，升级以后，官方将处理流程进行了抽象。变化
升级以后，可以在知识库中创建知识库的下方看到有一个通过知识流水线创建知识库。
在知识库里有一个流水线的功能，存量知识库可以转换为流水线。通过知识管道处理知识库
知识管道创建
知识管道创建有两种模式，一种是创建一个空白的管道自己配置，一种是利用官方内置流水线（Built-in Pipeline)。
先看下内置的流水线种类，以及作用。内置的知识流水线有以下七种：
| | | | |
|---|
1 | | | | 将文档内容分割成较小的段落块（通用块），直接用于匹配用户查询和检索。 |
2,父子模式（Parent-child Structure) | | | | 采用了高级分块策略，将文档文本分成较大的”父块”和较小的”子块”。其中，“父块”包含了”子块”。这样既保证了检索的精确性，又维持了上下文的完整性。 |
3 | | | | 将表格数据转化为一问一答的形式，通过问题匹配来快速找到对应的答案信息。适用于结构化表格数据。 |
4,复杂 PDF （含图片和表格）（Complex PDF with Images & Tables） | | | | |
5,LLM 上下文增强（Contextual Enriching Using LLM) | | | | 将文档内的图片和表格提取出来，使用大型语言模型自动生成描述性注释，实现上下文的智能增强。 |
6,Markdown 转换（Convert to Markdown) | | | | 专为 DOCX、XLSX 和 PPTX 等 Office 原生文件格式设计，将其转换为 Markdown 格式以便更好地进行信息处理。 |
7,LLM 生成问答（LLM Generated Q&A) | | | | 使用大型语言模型自动生成结构化的问答对，通过问题匹配机制找到相关的答 |
需要注意的是，断网情况下这些内置流水线加载不出来。从日志上可以看到，先从官方加载，官方网络不通，直接从本地加载，我是一路升级过来的，数据库里应该没有对应的信息。
通用模式
创建以后，可以看到依赖一堆的插件。因为官方是示例性质的，所以是一个大而全的集合。这里需要重点说一下两个插件
在知识管道里，点击空白右键，添加节点，在面板中有数据源的选项，这个是和现有工作流的差异。
- •
第二步文档处理：这个示例里配置了两个处理器，一个是dify内置的文档解析器（Dify Extractor），一个是原来工作流节点的文档提取器。 - •
第三步：文本分块，这里使用的是dify 封装的通用分块器 - •
第四步：知识库配置，这里主要是配置索引方法和检索策略，这个和第三步紧密关联，
在第四步，分段结构没有必要，这个由第三步的分块器决定的，有这块配置反而增加了配置的复杂度。还不如直接根据第三步直接填写。从dify的示例来说，大都是父子分段的格式，从另外一个层面可以反映出来，复杂文档，父子分段的效果最好。
我再讲解两个复杂的案例。
复杂 PDF 处理
这个是从模板4创建而来的。
- •
第二步文档处理：这里使用的是MINERU，除了MINERU还可以用其他的文档处理插件处理。 - •
第四步：知识库配置，这里主要是配置索引方法和检索策略，这个和第三步紧密关联，
大家关闭梯子，去mineru的官网申请token就可以
https://mineru.net/apiManage/token
最后配置完索引方式和检索设置以后，别忘点击右上角的发布，发布的工作流，只是在本知识库中使用。回到文档那里，我们上传文档，然后等待管道的处理即可。
这个是上传的一个ppt的解析效果。图片解析出来了，也显示了。这个折腾了1个多小时，才显示出图片，需要注意，升级那里的配置图片显示。
LLM 上下文增强
- •
第二步文档处理：这里使用的是MINERU+LLM，我使用的qwen-vl.
对比
上图左侧为通过多模态增强的解析，右侧为只用mineru解析，可以看到
单纯的从解析出来的内容来看，多模态对图片进行了简单的描述，方便检索到对应的图片，同时内容的准确度也有极大的提升。
mineru只是对图片进行了简单的解析，图片后面跟的是后面的内容，并没有对图片进行描述。其他
数据源插件
在插件市场有一个数据源的插件的分类。是数据管道支持的数据源类型。大家可以看看。文档处理
文档处理器是一个特殊的插件，官方示例里有下面几种：
- • Dify 提取器 (Dify Extractor)：dify开发的内置提取器，针对 Doc 文件进行了专门优化。它能够从文档中提取图片，进行存储并返回图片的 URL
- • Unstructured：将文档转换为结构化的机器可读格式，具有高度可定制的处理策略
在插件市场我们可以看到其他的插件，比如合合
分块器
目前dify官方支持三种分块器，其实就是知识库里的配置进行了抽取。
- • 通用分块器 (General Chunker)
- • 父子分块器 (Parent-child Chunker)
- • 问答处理器 Q&A Processor (Extractor+Chunker)
每个分块器都有不同的特点和使用场景。
分块器的设置，是在处理文档的时候进行设置，每个文档都可以自定义。
知识库配置
索引方式和检索设置参考原知识库设置即可。
常见问题解决
新建流水线空白
mineru 异常
- •
关闭梯子
图片不显示
按照下面的内容配置以后，销毁并重启服务
.env配置
# 配置文件外网路径，自己本机ip或者域名
FILES_URL=http://10.1.0.65:5001
# 内网地址,不能配置，否则无法显示图片
INTERNAL_FILES_URL=
docker-compose.yaml配置
# 我增加了name,不加，默认为docker
name: 'dify'
services:
# API service
api:
image: langgenius/dify-api:2.0.0-beta.2
ports:
- '${DIFY_PORTS:-5001}:5001' # 开放api的的端口，用于文件访问
粤ICP备14082021号
免费POC，
零成本试错
