最近一直被同一个问题轰炸：RAG到底用哪个框架？尤其RAGFlow和Dify，两拨人吵得不可开交。作为从RAG概念还不普及就开始折腾向量检索的老玩家，我花了几周时间把这两个热门开源框架从部署到实际业务完整过了一遍，用同一份企业知识库文档做了对比实验。这篇东西没有厂家立场，只有我自己的实测数据、部署记录和踩坑清单，给正在做技术选型的团队一份能直接照抄的参考。
先划个重点：RAG开源框架选型，本质上不是比谁功能多，而是比谁更贴合你的数据形态、技术栈和交付周期。RAGFlow和Dify虽然都叫RAG框架，但设计哲学的差异非常大，甚至到了“用错场景就完全使不上劲”的程度。下面我会从架构设计、核心功能、部署体验、实战效果、常见坑位五个维度逐一拆开讲，最后给出一个我私心觉得最实用的决策顺序。
1. 为什么我会同时盯上RAGFlow和Dify
先说背景。我手上的项目是一个典型的制造业知识库问答系统，文档形态极其混乱：有几十页带复杂表格的PDF工艺文件、有老工程师手写的扫描件、有Word格式的SOP、还有大量Excel里的设备参数。之前试过直接用向量数据库配通用文本切块，效果一言难尽——把表格切碎、把标题和正文切断、把同一张图的说明文字分到两个chunk里，检索出来的东西完全没法看。
后来我给自己定了个评测目标：不迷信“大而全”的平台，只看谁能解决我的“脏文档”问题。
1.1 两个框架的定位差异
RAGFlow的核心定位是“深度文档理解驱动的RAG引擎”，它的卖点不在于你接了多少个模型，而在于解析层做得有多深。项目里内置了基于布局识别的大模型，能把PDF页面里标题、正文、表格、图片、页眉页脚分开处理，再结合视觉特征做版面重构。这一点对于我这种天天跟PDF工艺文件打交道的人来说，几乎是刚需。
Dify的定位则是“LLMOps工作流平台”，它的强项是把大模型应用串成流水线——模型管理、Prompt编排、Agent工具调用、知识库、日志观测全放在一个平台里。虽然它也做RAG，但它的知识库功能更接近“给向量检索提供一个配置入口”，文档解析和切块策略不是它的核心竞争力。
这两个框架看起来都在做“知识库问答”，实际上一套是文档理解优先，一套是应用编排优先。选错了就是拿自己的短板去碰别人的长板。
1.2 我的评测方法和环境
为了控制变量，我做了下面的约定：
- 硬件环境：单台32核64G内存服务器，一块RTX 4090显卡，Ubuntu 22.04系统。
- 嵌入模型：全部使用本地部署的bge-large-zh-v1.5，保证不依赖外部API。
- 测试文档：同一批20份制造业文档，包括复杂表格PDF、扫描件、Word SOP、Excel参数表。
- 评测维度：部署难度、中文解析效果、检索准确性、二次开发成本、运维友好度。
测试不走“官方demo”，全部用真实业务数据跑。谁在脏数据上表现好，我就倾向谁。
2. RAGFlow深度拆解：把“解析”做成了护城河
RAGFlow这名字起得很直白，它就是冲着“RAG流程”来的。项目地址我记不太清了，但官方文档里那句“Get insights from your complex documents”基本就是它的真实写照。
2.1 深度文档理解：对版面差的文档确实有用
RAGFlow的文档解析不是简单的“按字数切块”，它会先走一遍版面分析流程。拿PDF来说，它能识别出页面里的标题层级、段落边界、表格结构、图片区域，甚至能做OCR把扫描件里的文字抠出来。系统完成版面重构后，会生成一个带坐标信息的中间表示，然后再根据标题层级决定如何切块。
这个机制对我那个制造业项目太关键了。那些带复杂表格的工艺文件，如果用普通分隔符切块，表格中间插入几个换行符就直接“拦腰斩断”。RAGFlow在同一张表格没切碎，它会把表格当成一个整体处理，检索的时候能把表格标题和表体内容关联起来。
不过别把它想得太神。它内置的DeepDoc模型对中文印刷体的识别准确率还不错，但对特别潦草的手写扫描件还是会翻车。我的做法是把手写件单独走人工整理流程，机器能解的交给机器解，机器解不了的不要硬撑。
2.2 分块策略：模板配置远好过手工调参
RAGFlow的分块逻辑跟传统“按字符串长度硬切”完全不同。它提供了一套模板化的分块方式，在RAGFlow中，模板定义了chunk的粒度（按段落、按页面、按章节点），系统会根据文档的版面结构自动套用。比如面对PDF你选“按段落切块”，它会沿着版面分析的段落边界去切，不会把段落从中间劈开。
我在测试中对比了固定512字符切块和RAGFlow模板切块，同样是那批工艺文件，模板切块的检索命中率明显更高。原因是模板切出来的chunk在语义上是完整的最小单元——一个段落就是一个完整的操作指引，而固定长度切块经常把“禁止带电操作”和“操作步骤”分到两个chunk里，检索时只捞到前半句，最后回答内容就是残缺的。
2.3 知识图谱与RAG的融合
最近大家讨论比较多的“Agentic RAG”，RAGFlow其实也做了一部分。它内置了知识图谱关联，可以在文档里提取实体和关系，并把它们与向量检索结果做融合。简单说就是：向量检索负责“找出相关片段”，图谱检索负责“找出相关实体之间的关系”，两者一结合，回答链条更完整。
我在某份设备维修手册上试过这个功能。问“这台机器在什么情况下会触发过载保护”时，纯向量检索只找到“过载保护触发条件”这一小段，图谱融合后能把“过载保护→电流异常→轴承磨损→润滑周期”这条因果链拉出来，回答的推理感强很多。
但图谱构建有成本。它在后台会用LLM抽取实体关系，长文档跑起来相当慢。如果文档数量大、更新频繁，图谱重建会让索引管道变成一个肉眼可见的瓶颈。小团队用的时候建议只在核心资产文档上开图谱，别全量开。
3. Dify深度拆解：工作流驱动的智能体平台
Dify给我最直观的感受是：它不把自己叫“RAG框架”，而是叫“LLMOps平台”。它解决的问题是“大模型应用从原型到生产全流程管理”。RAG只是它众多能力中的一个模块。
3.1 知识库流水线：快速建库不是问题
Dify的知识库创建流程确实够顺滑。你只要上传文档、选切块方式、选嵌入模型、创建索引，几步就能跑起来。它支持TXT、Markdown、PDF、DOCX、HTML，最新版本也支持从Notion等外部数据源同步。对“想把文档快速变成一个能聊天的知识库”这种需求来说，Dify的上手成本比RAGFlow低得多。
切块策略上，Dify提供了“自动分段”和“自定义分段”两种模式。自动分段本质还是按段落、标题、字数来做启发式切分，处理那种结构规整的在线文档、Markdown文档效果还行，但一旦遇到我那些复杂表格PDF，它跟RAGFlow的差距就出来了——Dify不会做版面重构，它更依赖文件本身的结构。
我在Dify里试同一批工艺文件，结果就是表格内容被切散、扫描件文字全部丢失（它不内置OCR）。所以Dify更适合“结构化程度较高”的知识库，不适合把它当“脏文档清洗机”用。
3.2 工作流编排：拼接RAG和外部工具的神器
Dify真正强的地方是工作流（Workflow）。你可以用可视化拖拽的方式，把一个RAG问答串成一条完整的流水线：用户问题进来，先做意图识别，再决定走知识库检索还是调用外部API，最后把检索结果拼进Prompt交给LLM回答。中间还能嵌入HTTP请求、代码节点、条件分支。
这个能力对构建“Agentic RAG”非常有帮助。我见过有人用Dify搭了一个售后助手：用户上报故障码，工作流里的代码节点先把故障码解析出来，然后调用设备API查型号，再用型号去知识库检索对应的维修手册，最后生成带操作建议的回复。整个过程不用写一行后端代码，全在Dify的画布里完成。
我自己的体验是，Dify的工作流把“复杂业务逻辑”从代码搬到了配置层。改一个分支逻辑不用重新发布服务，直接在画布里拖一拖，保存发布就生效。这种迭代速度，对业务变化快的团队特别友好。
3.3 多租户与生产级特性
Dify社区版从1.10开始加入了多租户能力，到1.17.1版本，仪表盘、权限管理、模型计费这些能力也补上了一截。团队内部按项目组拆工作空间，各自管理自己的知识库和模型Key，这在企业环境里非常实用。
日志和观测方面，Dify自带完整的日志链路。每一次问答的输入输出、检索到的文档片段、模型调用耗时和Token消耗都有记录。我实际排查问题的时候基本不用去后端看日志，直接在前端观测面板里就能定位是检索的问题还是模型的问题。
但我要泼一盆冷水：Dify的“生产级”是指它提供的功能符合生产使用需求，别理解成部署上去就永不宕机。它底层依赖PostgreSQL、Redis、向量数据库（默认Weaviate，也可配Qdrant、Milvus），中间的容器编排逻辑配置错误照样会拉不起来。
4. 实战部署与关键配置：从零跑起来
部署环节我踩的坑比预期的多。这里把两个框架的部署过程完整复盘一遍，包括我遇到的报错和解决办法。
4.1 硬件与前置条件
- 最低配置：8核CPU、16G内存、建议单独SSD放向量索引。如果还用本地嵌入模型和本地LLM，至少加一块24G显存的显卡。
- 推荐配置：16核CPU、32G内存、512G SSD、一张4090或A6000。
两个框架都推荐用Docker Compose一键拉起。不会Docker的人建议先补一点docker-compose的基础，不然排查起容器网络问题会一头雾水。
4.2 RAGFlow本地化部署流程
RAGFlow的部署目录很清晰，启动前要检查环境变量设置文件。我用的是默认的docker-compose，但把镜像源改成国内加速地址，不然拉取会超时。
核心流程如下：
- 拉取代码并进入docker目录。
- 检查.env文件里的SVR_HTTP_PORT、MYSQL_PASSWORD、MINIO_USER等默认值。
- 用“docker compose -f docker-compose.yml up -d”启动服务。
- 等待所有容器进入healthy状态，注意不光要看容器运行状态，还要看healthcheck是否通过。
我第一次启动后遇到了“连接不上Redis”的报错。排查发现是Redis容器还没完全就绪，而API服务启动太快，连接池初始化失败。解决办法是调整healthcheck的间隔和超时，或者在API容器上增加depends_on条件，让它等Redis、MySQL、Elasticsearch、MinIO全部healthy之后再启动。
RAGFlow的架构里，Elasticsearch承担文档检索和向量检索，MinIO负责对象存储，MySQL存元数据，Redis做缓存。任何一个组件不健康，上层API都会表现成“服务启动成功但功能异常”。所以启动后一定别急着传文档，先看整体健康状态。
嵌入模型配置方面，我用了Xinference，因为RAGFlow官方对Xinference和本地嵌入模型的支持比较好。在Xinference里启动bge-large-zh-v1.5之后，把模型注册到RAGFlow的模型管理器，然后在“模型设置”里把默认嵌入模型和默认重排模型都指向它。注意RAGFlow会让你设置一个默认重排模型（Rerank），因为它的检索流程默认是“双路召回+重排”，没有重排模型效果会明显下降。
我当时把“Embedding”和“Rerank”混为一谈，一直没找到配置入口。其实在RAGFlow里，进入“模型提供商”页面，先把Xinference添加为provider，再做“模型型号”绑定，最后在“设置”里修改默认组合，三个步骤缺一不可。
4.3 Dify本地部署与常见镜像问题
Dify的部署相对简单，同样用Docker Compose。目录里自带docker-compose.yaml和.env，里面有从API服务、Worker、Web前端到PostgreSQL、Redis、Weaviate一整套容器。
我最开始碰到的是“拉取镜像失败”。这不是Dify的问题，是网络环境导致的镜像下载超时。靠改Docker Hub加速源解决的。注意改完加速源之后要重启Docker服务，再重新执行compose，不然加速配置不会生效。
Dify的模型接入是另一个重点。它不像RAGFlow那样强依赖Xinference，它对Ollama、Xinference、OpenAI等多种运行时都做了很好的适配。我在Dify里同时接了Ollama上的qwen2.5作为主对话模型，和Xinference上的bge-m3作为嵌入模型，两条通道都很顺畅。
Dify的知识库配置页面里有“检索设置”和“生成式设置”两块。Embedding模型在“知识库-嵌入模型管理”里统一配置，所有知识库共用同一个嵌入模型。要特别提醒的是：已经创建的知识库不会因为嵌入模型变更而自动重建索引，改模型之后必须重建知识库索引，否则维度对不上，查询直接报错。
于是“Dify知识库流水线”就成形了：上传文档→选择分段模式→选嵌入模型→创建索引→关联到应用。整个过程如果文档规整，十分钟内能完成一个可用知识库。
4.4 使用Ollama做本地大模型推理
很多团队不放心把企业数据送到外部API，一定要纯本地推理。这块两个框架都支持Ollama，只是接法略有差别。
RAGFlow接Ollama需要在模型提供商里选Ollama，填上Ollama服务的地址，然后把本地已下载的模型名填进去。注意RAGFlow在Ollama里要区分“对话模型”和“嵌入模型”，对话模型可以用qwen2.5 14B这类，嵌入模型用bge-m3这类，别混填。
Dify接Ollama更简单，直接在模型供应商里选Ollama，配置服务器URL，它会自动拉取该地址上可用的模型列表。在“系统模型设置”里给“系统推理模型”和“嵌入模型”分别指派对应的本地模型即可。
实测下来，Ollama在Dify里的集成功能更加顺手，因为Dify的模型供应商体系本来就是为了兼容多种后端设计的。
5. 常见问题与排查技巧实录
这一段全是凭印象记录的实战问题，比较杂，但每条都是我或者社区群里真实出现过的。按出现频率来写。
5.1 服务启动成功但一直连不上Redis
这类问题在RAGFlow那里几乎天天有人问。表象是容器起来了、前端能打开，但一旦开始创建知识库就报“连接Redis失败”。
原因一般有三个：
- Redis容器还没ready，检查“docker compose ps”里的health状态，状态是starting就继续等。
- 容器网络隔了不同compose网络，API容器和Redis容器不在同一网络里，解决方法是全部用同一个compose文件，不拆分启动。
- Redis配置了密码但.env里的密码没对上，两边的REDIS_PASSWORD不一致。
我的排查顺序是：先看容器状态，再看docker network，最后比对.env，基本能解决九成。
5.2 Docker拉取镜像失败
这个在中文网络环境下特别常见。RAGFlow镜像比较大，Dify的镜像也不少，尤其Dify的weaviate镜像有时会拉不下来。
解决方案：
- 配置Docker镜像加速器。
- 拉取失败时候多试几次，网络抖动是常态。
- 如果某个镜像一直卡住，可以把镜像名换成带完整仓库地址的形式手动拉取，再回来跑compose。
- “docker compose build”下来的本地镜像，注意tag要和compose文件里的镜像名一致。
Dify升级到1.17.1的时候，我也遇到过类似问题。先修改compose里版本号，再手动清理旧镜像，最后重新执行up。切记拉镜像之前先“docker compose down”，避免新旧容器混跑。
5.3 中文分块与检索效果差
很多人上传中文文档之后说“检索不到答案”，大部分不是框架的问题，是分块策略没选对。
RAGFlow那边，我建议对中文文档优先用“按段落切块”，同时开启“自动识别标题层级”。如果文档是扫描件，先走OCR预处理再切块，别直接让分块器处理二进制图片。
Dify那边，自定义分段模式下，分隔符我推荐用“\n\n”先按大段分，再在高级设置里加一个“二级分隔符”把超长段落二次切分。注意别把chunk size调太小，中文分块因为Token计算的偏差，固定字符数并不等于Token数，我一般直接设500到800字符，重叠度50到100，出来的检索效果比较平衡。
还有一个让我印象深刻的坑：Dify的“生成式回答”里，如果“检索结果引用数量”设得过大，无关片段会被塞进Prompt，反而把模型的注意力带偏了。我在实际项目里调成3到5个片段，配合Rerank重排，效果比直接给8个片段好很多。
5.4 嵌入模型与向量数据库维度不匹配
这种报错集中在“创建知识库成功，但问答时报维度错误”的情况。很可能是你已经建立了知识库索引，后来换了一个不同维度的嵌入模型，新查询的向量维度和库里已有向量的维度对不上。
解决办法只有重建索引。Dify里把对应知识库删掉重建，RAGFlow则要重新上传文档并重新解析。我在Dify里把这个写进文档：任何嵌入模型的变更都等同于一次知识库重构，别指望热切换。
5.5 扫描版文档乱码或文字缺失
这算RAGFlow和Dify都逃不掉的痛点。RAGFlow的DeepDoc对扫描件OCR之后，准确率还凑合，但遇到印刷质量差的书本扫描页，会漏字；Dify则根本没有内置OCR，扫描件全靠用户自己预处理。
我的经验是：对扫描件先做图像预处理，旋转矫正、去黑边、增强对比度，再走OCR。这一步是脏活累活，但没有捷径。别指望一个RAG框架能把所有文档问题都挡掉，它能帮你解决的是“文字提取之后怎么切片、怎么检索”，不代表它就是一个万能文字识别器。
6. 选型决策矩阵：到底该用哪个
写到这里，很多读者会想要一个明确答案。我直接用“什么场景选哪个”来收尾这部分。
6.1 按项目类型选择
如果你的项目符合下面任意一条，我会优先推荐RAGFlow：
- 核心资产是大量PDF、Word等版式复杂的文档。
- 文档里表格多、图片多、标题层级混乱。
- 团队愿意为“深度文档理解”花时间调优。
- 不希望自己写OCR和版面解析代码。
RAGFlow适合把“文档进、知识出”当成核心价值来做的知识中台项目。
如果你的项目符合下面任意一条，我会优先推荐Dify：
- 知识库文档来源规整，比如在线文档、结构化页面、Markdown。
- 你更关注模型管理、Prompt编排、Agent工具调用这些上层应用能力。
- 希望用可视化工作流快速交付，减少后端开发工作量。
- 团队需要多项目组隔离、日志观测、生产级发布流程。
Dify适合把“大模型应用平台”当成统一底座，知识库只是其中一个模块的场景。
6.2 技术栈和运维能力的影响
RAGFlow运维起来比Dify要费心一点，因为它对底层组件（ES、MySQL、MinIO、Redis、Xinference）的依赖更深。它的监控没有Dify那么统一，出了问题基本上要自己进容器看日志。
Dify的运维相对更“平台化”，官方提供了完整的观测界面和文档，新手照着做也能比较顺利跑起来。它对API服务和Worker做了拆分，多用户高并发场景下可以单独扩容，这一点考虑得比RAGFlow周到。
不过如果团队有Java后端背景，RAGFlow的二次开发上手也不难，它的后端是Python FastAPI，前端是React，整个项目结构比Dify更简单直接。Dify的前后端复杂度更高，真要改内部逻辑，学习成本不小。
6.3 我的最终建议
我给大多数知识库场景的建议是：先把RAGFlow当成“文档解析与索引引擎”，如果后续要扩展多Agent、多模型编排，再在RAGFlow前面加一层Dify。这两个不一定是谁替代谁，它们可以共存，一个做脏活累活，一个做应用编排。
不过这带来一个问题：两套系统的数据如何打通。我的做法是让RAGFlow负责原始文档解析和chunk切块，把切好的chunk和元数据同步到Dify的知识库接口，Dify只负责检索和编排。中间可以用消息队列或者定时任务来做数据同步。这样既拿到了RAGFlow的解析能力，又享受Dify的LLMOps体验。
7. 实操心得和最后的提醒
按我自己的体会，RAG开源框架选型真正难的从来不是框架本身，而是想清楚你的“脏文档”和“上线路径”。
再分享一个小技巧：别一上来就全量上传所有文档。先拿10份最具代表性的文档跑完全流程，看检索命中率和回答质量是否达标。这个“样品实验”阶段如果能在一个下午内完成，再决定投入哪套框架，能省下后面至少一周的返工时间。
另外，嵌入模型和重排模型对最终效果的影响，有时候比框架本身更大。我强烈建议在选型阶段同时测试两到三组模型组合。同一个知识库，用bge-large和bge-m3，检索效果可能差很多。别省这个测试时间，它对你的终点体验影响极其显著。
最后说句掏心窝的话：框架是工具，不是信仰。你在RAGFlow上遇到的问题，换个思路在Dify里也许根本不是问题；反过来也一样。选型的目的不是证明哪个更厉害，而是给团队找到一条能持续交付的路径。文档解析、检索策略、模型调优、运维监控，每一环都要有人真正扛起来。这才是决定项目成败的关键。
