最近一直被同一个问题轰炸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里也许根本不是问题反过来也一样。选型的目的不是证明哪个更厉害而是给团队找到一条能持续交付的路径。文档解析、检索策略、模型调优、运维监控每一环都要有人真正扛起来。这才是决定项目成败的关键。