年初接了个企业知识库的项目客户给了一堆扫描版合同、财报和制度文档要求做问答。我先后试了 RAGFlow 和 Dify来回折腾了两个多月。网上评测大多是“一图看懂”“超详细对比”这类真到自己落地上跑的时候才发现坑全在细节里。这篇文章不打算重复那些官方案例而是从“我实际用它做完一件事”的角度说说 RAGFlow 和 Dify 到底该怎么选、怎么用以及哪些地方会让你的项目从“跑通”变成“好用”。先说结论这两个框架根本不是一个物种。RAGFlow 侧重“把文档理解了再检索”Dify 侧重“把大模型应用编排出来再接入知识库”。真正做技术选型时应该先看清自己缺的是“文档解析能力”还是“应用编排能力”否则很容易被首页 demo 带偏。1. 选 RAG 框架先把 RAG 产品拆成六个必答题市面上聊 RAG 的文章很多但真到框架选型时很多人被“RAG 就是检索 生成”这句话害了。检索 生成只是表面链路一个能交付给业务方的 RAG 系统至少包含六个环节每个环节都有不同的实现深度。第一文档解析与分块。这是最容易被低估的一环。真实业务里绝大多数知识不是干净 Markdown而是 PDF、扫描件、Excel 表格、PPT。PDF 里还有页眉页脚、多栏排版、表格嵌套、图片注释。解析得好不好直接决定后面检索能不能命中。RAGFlow 的 DeepDoc 模块在这里下了很大功夫Dify 则基本靠通用文本切分没有原生的深度文档理解能力。第二嵌入模型管理。选哪个 Embedding 模型、向量维度多少、是不是支持中文检索、需不需要本地部署这决定了检索召回的底子。RAGFlow 和 Dify 都支持 OpenAI 兼容接口也都能接 Ollama、Xinference、本地模型。第三向量存储与检索策略。是只用向量检索还是向量 全文混合检索要不要 Rerank 重排召回 TopK 设多少得分阈值卡多少这两个框架都能配置但配置入口的灵活度差别很大。RAGFlow 在知识库级别就能做不少检索参数控制Dify 则把更多控制权放在应用编排层。第四生成链路。大模型怎么调用、上下文怎么组织、Prompt 怎么拼、引用怎么展示。RAGFlow 的生成链路相对固定你更像在使用一个“知识库问答产品”。Dify 把生成链路完全开放成工作流节点写死也能跑但灵活编排才是它的主场。第五应用编排与权限。做企业内部知识库时要考虑这个对话机器人是纯问答还是要能调用 API、查数据库、走多轮对话、做身份隔离。Dify 把 Agent、工具调用、条件分支、迭代器都做成了可视化节点适合复杂应用。RAGFlow 的定位更收敛核心是把文档问答做好。第六运维与二次开发。开源框架不是装完就完的。Docker Compose 升级、Redis 不稳定、镜像拉取失败、向量库持久化、日志排查这些都是日常。两家框架都有活跃社区但 RAGFlow 的 API 开放程度和自定义工作流能力明显比 Dify 收敛很多。你可以把这六项当成一张检查表后面评测 RAGFlow 和 Dify 时我都是拿着这张表去对照的。不先想清楚自己缺哪一项很容易被“界面好看”“demo 聪明”这些表象带跑。2. RAGFlow 实测文档解析的“深”掩盖了不少工程上的硬脾气我实际部署的 RAGFlow 版本是 0.17 左右跑在 Ubuntu 服务器上用 Docker Compose 方式安装。整体印象是它在“理解文档”这件事上的确比其他开源框架高出一截但工程细节需要耐心调尤其是刚启动那段时间。2.1 安装阶段最容易踩的坑镜像拉取失败和 Redis 连接报错RAGFlow 官方提供了 Docker Compose 和 Helm Chart 两种方式。K8s 环境用 Helm 部署没问题但如果只是验证功能我建议老老实实用 Docker Compose省掉一层排查成本。我在安装时就遇到“拉取镜像失败”的问题。这里有一个容易忽略的地方RAGFlow 依赖的镜像比较多而且有一些是第三方镜像仓库的镜像。网络不稳定时 docker compose up 会卡住反复重试也没用。我当时是手动把镜像拉下来、确认镜像完整后再 docker compose up比让它自动拉要稳。如果你是用国内网络环境最好提前确认镜像源和仓库地址都配置正确而不是断断续续重试。启动成功后另一个高频报错是“连接不上 Redis”。很多人一看到这个报错就以为是 Redis 没起来其实多数情况是 Redis 容器先启动了RAGFlow 后端容器启动较晚两者启动顺序不对或者 Redis 没做数据持久化、重启后数据丢失。我后来在 docker-compose.yml 里给 Redis 加了 volume并保证依赖服务的健康检查完成后再启动业务容器问题才彻底解决。提示遇到 RAGFlow 启动后一直报 Redis 连接异常先不要急着改代码。先看docker compose ps各个容器是否都在运行再查 Redis 容器日志最后确认后端服务和 Redis 是否在同一个 Docker 网络里。大部分情况是编排问题不是代码问题。2.2 模型接入Ollama 和 Xinference 的组合玩法RAGFlow 的模型接入走的是“模型工厂”的思路支持 OpenAI 兼容 API也支持接入 Ollama、Xinference 这类本地推理服务。我在项目里没有用云端模型而是本地部署了 Ollama 做 Chat 模型和 Embedding 模型因为企业内部文档不能出内网。这里有一个特别容易踩的坑RAGFlow 界面里设置 Ollama 的 API 地址时不能写 localhost 或 127.0.0.1。因为 RAGFlow 后端跑在 Docker 容器里容器里的 localhost 指向的是容器自己不是你宿主机上的 Ollama。必须填宿主机的内网 IP例如http://192.168.1.10:11434否则模型连接一直是失败的。另外创建知识库时要选对 Embedding 模型。RAGFlow 的默认模型配置是可以改的但很多人没注意创建知识库后才发现用的 Embedding 模型不对重新索引又得花时间。我建议在系统设置里把默认嵌入模型和默认 Chat 模型都提前配好再接知识库。我实际用的是 Qwen 系列作为 Chat 模型嵌入向量用的是 bge-m3再挂一个 bge-reranker-base 做重排。这套组合在中文技术文档、合同条款上的表现比单纯用通用嵌入模型好很多尤其“召回准确率”和“上下文相关性”两个指标有明显提升。2.3 知识库创建与 DeepDoc 分块RAGFlow 最值得借鉴的地方RAGFlow 在创建知识库时会要求你选一个分块Chunk方法。它有通用分块、DeepDoc 分块等几种模式。通用分块和普通框架差不多重点看 DeepDoc。DeepDoc 处理扫描版 PDF 时会先做版面分析识别标题、段落、表格、图片区域再按版面结构切分文本。我用一份 40 多页的扫描版合同测试大部分条目能正确切分表格被相对完整地抽出来而不是碎成一片一片的文本。这个表现确实比我之前用 LangChain 自带 PDF 解析器要好。不过 DeepDoc 不是万能的。复杂表格、带水印的文字、彩色背景的流程图偶尔还是会解析错。我的经验是解析完成后一定要在知识库页面抽查几页切分结果尤其看表格和页眉页脚。RAGFlow 提供了切分预览功能发现有问题可以直接修改切分或者针对单一文档重新解析不需要把整个知识库删掉重来。另一个实用技巧是控制分块粒度。RAGFlow 默认的分块参数对长文档比较保守块太长会导致检索时命中片段不够精确。我当时把分块长度适当调小重叠区域调大一点检索命中率明显提升。但每类文档的最佳参数不一样制度文档和合同问答的调法差别很大。2.4 需要直说的硬伤文档理解很强但应用编排相对保守RAGFlow 最大的优势是文档理解但它的硬伤恰恰也在这里——它更像一个“知识库问答产品”而不是“大模型应用开发平台”。我在测试多轮对话时发现 RAGFlow 对上下文和工具调用的支持比较有限。如果你的需求只是“基于私有文档做问答”它体验很好但如果你的业务需要大模型去查数据库、调第三方 API、走复杂的条件分支RAGFlow 会让你绕很多路甚至需要直接改代码。还有一个现实问题RAGFlow 的自定义 API 虽然在逐步开放但相比 Dify文档和插件生态还差一个量级。我在项目里想做一个“先查合同条款再调用企业 ERP 接口回写数据”的流程在 RAGFlow 里折腾了很久最后还是切到了 Dify 完成。3. Dify 实测知识库只是入口工作流和 Agent 才是主角Dify 我最早是在社区版 1.10 用的后来一路升级到 1.17.1。它的定位和 RAGFlow 完全不同Dify 更像一个“大模型应用开发平台”知识库只是其中一个模块真正的重头戏是工作流编排、Agent 工具调用和对外 API 封装。3.1 部署与升级多租户体验和 Windows 本地部署的注意事项Dify 官方推荐 Docker Compose 部署。社区版在 1.10 之后把工作空间和成员管理做得更像多租户了可以在一个实例里给不同团队划分独立空间这对企业内部使用很关键因为不同部门的知识库要隔离应用权限也要分开管理。升级 Dify 是件需要小心的事。我在 1.17.1 版本发布后升级过一次升级前把docker-compose.yml和.env文件提前备份好再执行docker compose pull和docker compose up -d。升级过程大体顺利但遇到过镜像拉取失败和数据库迁移耗时较长的问题。这里强烈建议生产环境升级前先把数据库和对象存储做快照备份不要直接在业务高峰时间升级。如果你是在 Windows 上做本地部署Dify 的 Docker Desktop 方式也能跑通但要注意文件路径的挂载格式和性能问题。本地验证倒是问题不大生产环境不建议 Windows 直接扛。3.2 知识库流水线Dify 的 RAG 能力比我想象中完整Dify 知识库支持自定义分段规则、自动分段、父子分块等模式还能设置索引方式高质量模式和经济模式。高质量模式会调用 Embedding 模型做向量索引经济模式则用关键词索引检索效果差别明显。在知识库召回上Dify 支持向量检索、全文检索、混合检索三种模式还能设置 Rerank 模型。这一点让我挺意外因为很多人以为 Dify 只是个工作流工具其实它在 RAG 链路上已经补得很全。我实际测试下来用混合检索 Rerank 的配置在召回效果上完全不输 RAGFlow前提是源文档本身是干净文本。但 Dify 的弱项也很明显文档解析。如果我们给 Dify 上传扫描版 PDF它基本只能做文本抽取复杂版式会乱。所以我现在的习惯是先用 RAGFlow 或者其他工具把 PDF 解析成 Markdown再把这些干净文本导入 Dify 知识库。这样既拿到 RAGFlow 的文档理解优势又利用 Dify 的工作流能力。另外Dify 知识库支持把外部结构化数据导入到数据库再接入知识库这一点对企业实战很有价值。比如把 ERP 导出的产品表、客户表清洗入库后再通过知识库检索比硬塞给大模型上下文要稳定得多。3.3 工作流、Agent 节点与 1.17.1 版本的真实体感Dify 工作流是我最喜欢也是吐槽最多的地方。喜欢的是它把复杂逻辑可视化一个“知识库问答 条件分支 迭代处理 工具调用”的流程能直接拖拽出来不用写一堆胶水代码。吐槽的是节点多了以后排错比较麻烦变量引用偶尔会搞混。1.17.1 版本更新后我感受到最明显的变化不是新功能而是工作流节点的批量处理能力和变量管理的顺滑度提升。以前想对检索结果批量做后处理得写代码节点或者反复加循环现在迭代器的用法变得更清晰批量变量也更顺手。对做知识库流水线的人来说这个版本值得升级。Dify 里最常用的几个节点我列一下知识检索节点指定知识库、设置召回模式和 TopK。LLM 节点写 Prompt引用前置节点输出。条件分支节点根据检索结果得分、用户输入类型走不同分支。迭代节点对多段内容批量处理例如给多个知识片段分别打分。工具节点调用外部 API 或者自定义 OpenAPI Schema。Agent 节点让大模型自行决定调用哪些工具适合开放性任务。我做企业知识库时最常用的流程是用户输入后先判断是闲聊还是知识类问题知识类问题走知识检索引擎拿召回片段再做一个 Rerank 过滤低分结果最后把高分段内容拼进 Prompt交给大模型回答。这个流程看起来简单但在 Dify 里用可视化方式搭出来后调整参数和排错都方便得多。3.4 Dify 的硬伤文档解析要“外包”深度定制要开发Dify 最大的硬伤就是文档解析能力。它更像一个“应用开发平台”把干净数据喂给它它能帮你做得很好但如果你指望它像 RAGFlow 一样直接吞进复杂 PDF 再完美切分现实会让你失望。其次是版本升级风险。Dify 更新节奏快社区版偶发升级后插件不兼容、工作流导出导入出问题的情况。我吃过一次亏后就养成了升级前导出工作流 DSL、备份数据库的习惯。还有一个边界感问题Dify 虽然灵活但如果你想在知识库侧做特别深度的定制比如自定义索引算法、自定义检索排序逻辑它的平台边界很快就会挡住你。这种时候还是得考虑直接基于 LangChain、LangGraph 这类库写自己的 RAG 服务而不是继续在框架里硬塞。4. 按业务场景做选型我整理的决策矩阵和结论评测说再多不如直接告诉你怎么选。我根据自己做过的客户项目把常见 RAG 场景分成四类每一类对应的选型结论如下。业务场景首选方案原因合同、财报、扫描版 PDF 等复杂文档问答RAGFlowDeepDoc 的版面解析能力在开源工具中领先省去大量文档清洗工作面向 C 端的智能客服多轮对话 多工具调用Dify工作流编排和 Agent 能力成熟便于接入 API、做条件分支快速验证 RAG MVP公司团队本地体验Dify Ollama部署简单知识库够用工作流可视轻量场景下性价比高深度定制 Agentic RAG需要自控检索与生成逻辑直接用 LangChain / LangGraph 向量库框架的抽象层会成为定制瓶颈不如写代码掌控全链路如果你的业务是“知识密集型文档问答”为主比如证券公司研报、律所合同、政府公文RAGFlow 的文档解析优势会让你省很多事。不要因为 Dify 生态热闹就盲目选 Dify否则你会花大量时间清洗 PDF而清洗 PDF 恰恰是 RAG 项目里最脏最累的活。如果你的业务是“大模型应用交付”为主比如做一个带知识库的多轮客服、一个需要调用 ERP 接口的智能助手Dify 的效率远高于 RAGFlow。它让你把精力放在业务逻辑和 Prompt 上而不是重新发明工作流轮子。我的经验比例大概是源文档复杂、知识库是核心资产的场景七成选 RAGFlow应用逻辑复杂、知识库只是背景板的场景七成选 Dify。不要只看框架名要看你的核心痛点在哪一层。5. 嵌入模型、向量库与下一代 Agentic RAG 的演进窗口选完框架不等于一劳永逸。RAG 项目做久了你会发现框架本身只是底座真正决定问答质量的是嵌入模型、检索策略和知识库运维。这块我再分享几条实际经验。5.1 嵌入模型选型本地化部署不是越“大”越好如果你做的是企业内部知识库数据不能出内网那 Ollama、Xinference 这类本地推理服务几乎是标配。嵌入模型上我的建议是优先考虑中文效果好的向量模型比如 bge-m3、bge-large-zh、bge-small-zh 这类。不是说越大越好而是要看你的文档量级和查询匹配方式。几十万条文档的企业知识库用 bge-m3 这类中大规模模型是合适的如果是小团队几百条文档用小模型反而更快、更省资源。RAGFlow 和 Dify 都支持自定义 Embedding 模型接口。实际接入时我习惯先在 Xinference 里把模型跑起来拿到一个 OpenAI 兼容的 API 地址再填到框架的模型供应商配置里。这样模型管理和框架解耦后面换模型不影响知识库索引。5.2 向量库选择pgvector 和 Milvus 的典型用法Dify 和 RAGFlow 内置了多种向量数据库支持。小项目可以直接用 Docker 起一个 pgvector既有 PostgreSQL 的关系查询能力又能做向量检索运维成本低。数据量超过千万级或者对检索延迟要求很高再考虑单独部署 Milvus。我见过不少团队一上来就部署 Milvus结果知识库才几千条文档完全是大材小用。个人建议MVP 阶段用 pgvector等数据量起来之后再平滑迁移到 Milvus。框架里的向量库配置通常是可切换的不用在一开始就压重注。5.3 Agentic RAG 是下一步FastAPI LangChain LangGraph 的定制路线现在社区里 RAG 方向的讨论已经逐渐转向 Agentic RAG。热门的关键词已经从“分块”“召回”扩展到“FastAPI LangChain LangGraph RAG pgvector 的 AI Agentic RAG”。这个趋势的本质是不再把 RAG 当成一次性的“检索 拼接 回答”而是让大模型在对话过程中自主判断“什么时候该检索、检索哪类文档、检索结果够不够、要不要换个方式再查一次”。Dify 和 RAGFlow 都在往这个方向走但框架难以覆盖的恰恰是高度个性化的 Agent 检索策略比如“先检索合同目录再按条款号二次检索”“把历史检索失败的高频问题记录下来下次先查错题集”。这类需求一旦出现我的建议是直接用 LangGraph 构建一套自己的 Agent 工作流用 FastAPI 包一层服务对外提供 API再搭配 LangChain 的检索组件和 pgvector 存储。RAGFlow 和 Dify 这时可以退居二线只作为内部工具辅助文档处理而不是主链路。5.4 我给新团队的建议别一开始就写代码最后一条建议也是我踩过很多坑后的总结新团队做 RAG 项目不要一上来就写代码。先用 Dify 或 RAGFlow 把知识库和对话链路跑通把文档处理、分段、检索参数、用户反馈这些环节都摸一遍再根据业务瓶颈决定是否需要自研。很多问题在可视化框架里几分钟就能试出来但写代码可能要折腾几天而且不一定比框架做得好。框架是快速验证的工具也是学习 RAG 的最佳教材。打开 Dify 的工作流节点看看知识检索节点输出的是什么结构看看迭代节点怎么处理多条召回结果这些都是在文档和源码之外最直观的学习素材。看懂框架怎么做你才能在自己写代码时做出更好的设计。我在实际项目中通常会把 RAGFlow 和 Dify 同时部署RAGFlow 专职解析复杂文档Dify 专职做应用编排和 API 封装。中间用一份干净的 Markdown 目录做桥梁文本从 RAGFlow 出来后再导入 Dify 知识库。这套组合拳帮我在不少企业知识库项目里省了大量时间。先搞清楚自己要的是“文档理解”还是“应用编排”再决定选型方向这是我这几个月最有价值的体会。 RAGFlow vs Dify：企业知识库选型与 RAG 落地实战指南
年初接了个企业知识库的项目客户给了一堆扫描版合同、财报和制度文档要求做问答。我先后试了 RAGFlow 和 Dify来回折腾了两个多月。网上评测大多是“一图看懂”“超详细对比”这类真到自己落地上跑的时候才发现坑全在细节里。这篇文章不打算重复那些官方案例而是从“我实际用它做完一件事”的角度说说 RAGFlow 和 Dify 到底该怎么选、怎么用以及哪些地方会让你的项目从“跑通”变成“好用”。先说结论这两个框架根本不是一个物种。RAGFlow 侧重“把文档理解了再检索”Dify 侧重“把大模型应用编排出来再接入知识库”。真正做技术选型时应该先看清自己缺的是“文档解析能力”还是“应用编排能力”否则很容易被首页 demo 带偏。1. 选 RAG 框架先把 RAG 产品拆成六个必答题市面上聊 RAG 的文章很多但真到框架选型时很多人被“RAG 就是检索 生成”这句话害了。检索 生成只是表面链路一个能交付给业务方的 RAG 系统至少包含六个环节每个环节都有不同的实现深度。第一文档解析与分块。这是最容易被低估的一环。真实业务里绝大多数知识不是干净 Markdown而是 PDF、扫描件、Excel 表格、PPT。PDF 里还有页眉页脚、多栏排版、表格嵌套、图片注释。解析得好不好直接决定后面检索能不能命中。RAGFlow 的 DeepDoc 模块在这里下了很大功夫Dify 则基本靠通用文本切分没有原生的深度文档理解能力。第二嵌入模型管理。选哪个 Embedding 模型、向量维度多少、是不是支持中文检索、需不需要本地部署这决定了检索召回的底子。RAGFlow 和 Dify 都支持 OpenAI 兼容接口也都能接 Ollama、Xinference、本地模型。第三向量存储与检索策略。是只用向量检索还是向量 全文混合检索要不要 Rerank 重排召回 TopK 设多少得分阈值卡多少这两个框架都能配置但配置入口的灵活度差别很大。RAGFlow 在知识库级别就能做不少检索参数控制Dify 则把更多控制权放在应用编排层。第四生成链路。大模型怎么调用、上下文怎么组织、Prompt 怎么拼、引用怎么展示。RAGFlow 的生成链路相对固定你更像在使用一个“知识库问答产品”。Dify 把生成链路完全开放成工作流节点写死也能跑但灵活编排才是它的主场。第五应用编排与权限。做企业内部知识库时要考虑这个对话机器人是纯问答还是要能调用 API、查数据库、走多轮对话、做身份隔离。Dify 把 Agent、工具调用、条件分支、迭代器都做成了可视化节点适合复杂应用。RAGFlow 的定位更收敛核心是把文档问答做好。第六运维与二次开发。开源框架不是装完就完的。Docker Compose 升级、Redis 不稳定、镜像拉取失败、向量库持久化、日志排查这些都是日常。两家框架都有活跃社区但 RAGFlow 的 API 开放程度和自定义工作流能力明显比 Dify 收敛很多。你可以把这六项当成一张检查表后面评测 RAGFlow 和 Dify 时我都是拿着这张表去对照的。不先想清楚自己缺哪一项很容易被“界面好看”“demo 聪明”这些表象带跑。2. RAGFlow 实测文档解析的“深”掩盖了不少工程上的硬脾气我实际部署的 RAGFlow 版本是 0.17 左右跑在 Ubuntu 服务器上用 Docker Compose 方式安装。整体印象是它在“理解文档”这件事上的确比其他开源框架高出一截但工程细节需要耐心调尤其是刚启动那段时间。2.1 安装阶段最容易踩的坑镜像拉取失败和 Redis 连接报错RAGFlow 官方提供了 Docker Compose 和 Helm Chart 两种方式。K8s 环境用 Helm 部署没问题但如果只是验证功能我建议老老实实用 Docker Compose省掉一层排查成本。我在安装时就遇到“拉取镜像失败”的问题。这里有一个容易忽略的地方RAGFlow 依赖的镜像比较多而且有一些是第三方镜像仓库的镜像。网络不稳定时 docker compose up 会卡住反复重试也没用。我当时是手动把镜像拉下来、确认镜像完整后再 docker compose up比让它自动拉要稳。如果你是用国内网络环境最好提前确认镜像源和仓库地址都配置正确而不是断断续续重试。启动成功后另一个高频报错是“连接不上 Redis”。很多人一看到这个报错就以为是 Redis 没起来其实多数情况是 Redis 容器先启动了RAGFlow 后端容器启动较晚两者启动顺序不对或者 Redis 没做数据持久化、重启后数据丢失。我后来在 docker-compose.yml 里给 Redis 加了 volume并保证依赖服务的健康检查完成后再启动业务容器问题才彻底解决。提示遇到 RAGFlow 启动后一直报 Redis 连接异常先不要急着改代码。先看docker compose ps各个容器是否都在运行再查 Redis 容器日志最后确认后端服务和 Redis 是否在同一个 Docker 网络里。大部分情况是编排问题不是代码问题。2.2 模型接入Ollama 和 Xinference 的组合玩法RAGFlow 的模型接入走的是“模型工厂”的思路支持 OpenAI 兼容 API也支持接入 Ollama、Xinference 这类本地推理服务。我在项目里没有用云端模型而是本地部署了 Ollama 做 Chat 模型和 Embedding 模型因为企业内部文档不能出内网。这里有一个特别容易踩的坑RAGFlow 界面里设置 Ollama 的 API 地址时不能写 localhost 或 127.0.0.1。因为 RAGFlow 后端跑在 Docker 容器里容器里的 localhost 指向的是容器自己不是你宿主机上的 Ollama。必须填宿主机的内网 IP例如http://192.168.1.10:11434否则模型连接一直是失败的。另外创建知识库时要选对 Embedding 模型。RAGFlow 的默认模型配置是可以改的但很多人没注意创建知识库后才发现用的 Embedding 模型不对重新索引又得花时间。我建议在系统设置里把默认嵌入模型和默认 Chat 模型都提前配好再接知识库。我实际用的是 Qwen 系列作为 Chat 模型嵌入向量用的是 bge-m3再挂一个 bge-reranker-base 做重排。这套组合在中文技术文档、合同条款上的表现比单纯用通用嵌入模型好很多尤其“召回准确率”和“上下文相关性”两个指标有明显提升。2.3 知识库创建与 DeepDoc 分块RAGFlow 最值得借鉴的地方RAGFlow 在创建知识库时会要求你选一个分块Chunk方法。它有通用分块、DeepDoc 分块等几种模式。通用分块和普通框架差不多重点看 DeepDoc。DeepDoc 处理扫描版 PDF 时会先做版面分析识别标题、段落、表格、图片区域再按版面结构切分文本。我用一份 40 多页的扫描版合同测试大部分条目能正确切分表格被相对完整地抽出来而不是碎成一片一片的文本。这个表现确实比我之前用 LangChain 自带 PDF 解析器要好。不过 DeepDoc 不是万能的。复杂表格、带水印的文字、彩色背景的流程图偶尔还是会解析错。我的经验是解析完成后一定要在知识库页面抽查几页切分结果尤其看表格和页眉页脚。RAGFlow 提供了切分预览功能发现有问题可以直接修改切分或者针对单一文档重新解析不需要把整个知识库删掉重来。另一个实用技巧是控制分块粒度。RAGFlow 默认的分块参数对长文档比较保守块太长会导致检索时命中片段不够精确。我当时把分块长度适当调小重叠区域调大一点检索命中率明显提升。但每类文档的最佳参数不一样制度文档和合同问答的调法差别很大。2.4 需要直说的硬伤文档理解很强但应用编排相对保守RAGFlow 最大的优势是文档理解但它的硬伤恰恰也在这里——它更像一个“知识库问答产品”而不是“大模型应用开发平台”。我在测试多轮对话时发现 RAGFlow 对上下文和工具调用的支持比较有限。如果你的需求只是“基于私有文档做问答”它体验很好但如果你的业务需要大模型去查数据库、调第三方 API、走复杂的条件分支RAGFlow 会让你绕很多路甚至需要直接改代码。还有一个现实问题RAGFlow 的自定义 API 虽然在逐步开放但相比 Dify文档和插件生态还差一个量级。我在项目里想做一个“先查合同条款再调用企业 ERP 接口回写数据”的流程在 RAGFlow 里折腾了很久最后还是切到了 Dify 完成。3. Dify 实测知识库只是入口工作流和 Agent 才是主角Dify 我最早是在社区版 1.10 用的后来一路升级到 1.17.1。它的定位和 RAGFlow 完全不同Dify 更像一个“大模型应用开发平台”知识库只是其中一个模块真正的重头戏是工作流编排、Agent 工具调用和对外 API 封装。3.1 部署与升级多租户体验和 Windows 本地部署的注意事项Dify 官方推荐 Docker Compose 部署。社区版在 1.10 之后把工作空间和成员管理做得更像多租户了可以在一个实例里给不同团队划分独立空间这对企业内部使用很关键因为不同部门的知识库要隔离应用权限也要分开管理。升级 Dify 是件需要小心的事。我在 1.17.1 版本发布后升级过一次升级前把docker-compose.yml和.env文件提前备份好再执行docker compose pull和docker compose up -d。升级过程大体顺利但遇到过镜像拉取失败和数据库迁移耗时较长的问题。这里强烈建议生产环境升级前先把数据库和对象存储做快照备份不要直接在业务高峰时间升级。如果你是在 Windows 上做本地部署Dify 的 Docker Desktop 方式也能跑通但要注意文件路径的挂载格式和性能问题。本地验证倒是问题不大生产环境不建议 Windows 直接扛。3.2 知识库流水线Dify 的 RAG 能力比我想象中完整Dify 知识库支持自定义分段规则、自动分段、父子分块等模式还能设置索引方式高质量模式和经济模式。高质量模式会调用 Embedding 模型做向量索引经济模式则用关键词索引检索效果差别明显。在知识库召回上Dify 支持向量检索、全文检索、混合检索三种模式还能设置 Rerank 模型。这一点让我挺意外因为很多人以为 Dify 只是个工作流工具其实它在 RAG 链路上已经补得很全。我实际测试下来用混合检索 Rerank 的配置在召回效果上完全不输 RAGFlow前提是源文档本身是干净文本。但 Dify 的弱项也很明显文档解析。如果我们给 Dify 上传扫描版 PDF它基本只能做文本抽取复杂版式会乱。所以我现在的习惯是先用 RAGFlow 或者其他工具把 PDF 解析成 Markdown再把这些干净文本导入 Dify 知识库。这样既拿到 RAGFlow 的文档理解优势又利用 Dify 的工作流能力。另外Dify 知识库支持把外部结构化数据导入到数据库再接入知识库这一点对企业实战很有价值。比如把 ERP 导出的产品表、客户表清洗入库后再通过知识库检索比硬塞给大模型上下文要稳定得多。3.3 工作流、Agent 节点与 1.17.1 版本的真实体感Dify 工作流是我最喜欢也是吐槽最多的地方。喜欢的是它把复杂逻辑可视化一个“知识库问答 条件分支 迭代处理 工具调用”的流程能直接拖拽出来不用写一堆胶水代码。吐槽的是节点多了以后排错比较麻烦变量引用偶尔会搞混。1.17.1 版本更新后我感受到最明显的变化不是新功能而是工作流节点的批量处理能力和变量管理的顺滑度提升。以前想对检索结果批量做后处理得写代码节点或者反复加循环现在迭代器的用法变得更清晰批量变量也更顺手。对做知识库流水线的人来说这个版本值得升级。Dify 里最常用的几个节点我列一下知识检索节点指定知识库、设置召回模式和 TopK。LLM 节点写 Prompt引用前置节点输出。条件分支节点根据检索结果得分、用户输入类型走不同分支。迭代节点对多段内容批量处理例如给多个知识片段分别打分。工具节点调用外部 API 或者自定义 OpenAPI Schema。Agent 节点让大模型自行决定调用哪些工具适合开放性任务。我做企业知识库时最常用的流程是用户输入后先判断是闲聊还是知识类问题知识类问题走知识检索引擎拿召回片段再做一个 Rerank 过滤低分结果最后把高分段内容拼进 Prompt交给大模型回答。这个流程看起来简单但在 Dify 里用可视化方式搭出来后调整参数和排错都方便得多。3.4 Dify 的硬伤文档解析要“外包”深度定制要开发Dify 最大的硬伤就是文档解析能力。它更像一个“应用开发平台”把干净数据喂给它它能帮你做得很好但如果你指望它像 RAGFlow 一样直接吞进复杂 PDF 再完美切分现实会让你失望。其次是版本升级风险。Dify 更新节奏快社区版偶发升级后插件不兼容、工作流导出导入出问题的情况。我吃过一次亏后就养成了升级前导出工作流 DSL、备份数据库的习惯。还有一个边界感问题Dify 虽然灵活但如果你想在知识库侧做特别深度的定制比如自定义索引算法、自定义检索排序逻辑它的平台边界很快就会挡住你。这种时候还是得考虑直接基于 LangChain、LangGraph 这类库写自己的 RAG 服务而不是继续在框架里硬塞。4. 按业务场景做选型我整理的决策矩阵和结论评测说再多不如直接告诉你怎么选。我根据自己做过的客户项目把常见 RAG 场景分成四类每一类对应的选型结论如下。业务场景首选方案原因合同、财报、扫描版 PDF 等复杂文档问答RAGFlowDeepDoc 的版面解析能力在开源工具中领先省去大量文档清洗工作面向 C 端的智能客服多轮对话 多工具调用Dify工作流编排和 Agent 能力成熟便于接入 API、做条件分支快速验证 RAG MVP公司团队本地体验Dify Ollama部署简单知识库够用工作流可视轻量场景下性价比高深度定制 Agentic RAG需要自控检索与生成逻辑直接用 LangChain / LangGraph 向量库框架的抽象层会成为定制瓶颈不如写代码掌控全链路如果你的业务是“知识密集型文档问答”为主比如证券公司研报、律所合同、政府公文RAGFlow 的文档解析优势会让你省很多事。不要因为 Dify 生态热闹就盲目选 Dify否则你会花大量时间清洗 PDF而清洗 PDF 恰恰是 RAG 项目里最脏最累的活。如果你的业务是“大模型应用交付”为主比如做一个带知识库的多轮客服、一个需要调用 ERP 接口的智能助手Dify 的效率远高于 RAGFlow。它让你把精力放在业务逻辑和 Prompt 上而不是重新发明工作流轮子。我的经验比例大概是源文档复杂、知识库是核心资产的场景七成选 RAGFlow应用逻辑复杂、知识库只是背景板的场景七成选 Dify。不要只看框架名要看你的核心痛点在哪一层。5. 嵌入模型、向量库与下一代 Agentic RAG 的演进窗口选完框架不等于一劳永逸。RAG 项目做久了你会发现框架本身只是底座真正决定问答质量的是嵌入模型、检索策略和知识库运维。这块我再分享几条实际经验。5.1 嵌入模型选型本地化部署不是越“大”越好如果你做的是企业内部知识库数据不能出内网那 Ollama、Xinference 这类本地推理服务几乎是标配。嵌入模型上我的建议是优先考虑中文效果好的向量模型比如 bge-m3、bge-large-zh、bge-small-zh 这类。不是说越大越好而是要看你的文档量级和查询匹配方式。几十万条文档的企业知识库用 bge-m3 这类中大规模模型是合适的如果是小团队几百条文档用小模型反而更快、更省资源。RAGFlow 和 Dify 都支持自定义 Embedding 模型接口。实际接入时我习惯先在 Xinference 里把模型跑起来拿到一个 OpenAI 兼容的 API 地址再填到框架的模型供应商配置里。这样模型管理和框架解耦后面换模型不影响知识库索引。5.2 向量库选择pgvector 和 Milvus 的典型用法Dify 和 RAGFlow 内置了多种向量数据库支持。小项目可以直接用 Docker 起一个 pgvector既有 PostgreSQL 的关系查询能力又能做向量检索运维成本低。数据量超过千万级或者对检索延迟要求很高再考虑单独部署 Milvus。我见过不少团队一上来就部署 Milvus结果知识库才几千条文档完全是大材小用。个人建议MVP 阶段用 pgvector等数据量起来之后再平滑迁移到 Milvus。框架里的向量库配置通常是可切换的不用在一开始就压重注。5.3 Agentic RAG 是下一步FastAPI LangChain LangGraph 的定制路线现在社区里 RAG 方向的讨论已经逐渐转向 Agentic RAG。热门的关键词已经从“分块”“召回”扩展到“FastAPI LangChain LangGraph RAG pgvector 的 AI Agentic RAG”。这个趋势的本质是不再把 RAG 当成一次性的“检索 拼接 回答”而是让大模型在对话过程中自主判断“什么时候该检索、检索哪类文档、检索结果够不够、要不要换个方式再查一次”。Dify 和 RAGFlow 都在往这个方向走但框架难以覆盖的恰恰是高度个性化的 Agent 检索策略比如“先检索合同目录再按条款号二次检索”“把历史检索失败的高频问题记录下来下次先查错题集”。这类需求一旦出现我的建议是直接用 LangGraph 构建一套自己的 Agent 工作流用 FastAPI 包一层服务对外提供 API再搭配 LangChain 的检索组件和 pgvector 存储。RAGFlow 和 Dify 这时可以退居二线只作为内部工具辅助文档处理而不是主链路。5.4 我给新团队的建议别一开始就写代码最后一条建议也是我踩过很多坑后的总结新团队做 RAG 项目不要一上来就写代码。先用 Dify 或 RAGFlow 把知识库和对话链路跑通把文档处理、分段、检索参数、用户反馈这些环节都摸一遍再根据业务瓶颈决定是否需要自研。很多问题在可视化框架里几分钟就能试出来但写代码可能要折腾几天而且不一定比框架做得好。框架是快速验证的工具也是学习 RAG 的最佳教材。打开 Dify 的工作流节点看看知识检索节点输出的是什么结构看看迭代节点怎么处理多条召回结果这些都是在文档和源码之外最直观的学习素材。看懂框架怎么做你才能在自己写代码时做出更好的设计。我在实际项目中通常会把 RAGFlow 和 Dify 同时部署RAGFlow 专职解析复杂文档Dify 专职做应用编排和 API 封装。中间用一份干净的 Markdown 目录做桥梁文本从 RAGFlow 出来后再导入 Dify 知识库。这套组合拳帮我在不少企业知识库项目里省了大量时间。先搞清楚自己要的是“文档理解”还是“应用编排”再决定选型方向这是我这几个月最有价值的体会。