dify+ragflow知识库

团队要搭内部知识库，看到 Dify 和 RAGFlow 都能干，纠结到底用哪个，或者两个都想用却不知道谁管解析、谁管编排。这篇不重复原理，只给落地路线的判断标准和执行顺序：先划边界，再定联调方式，最后用一套可复现的评测和排错清单收口。

团队要搭内部知识库，把 Dify 和 RAGFlow 摆在一起看，最常见的纠结不是「哪个更强」，而是「哪个管什么」。两边都能上传文档、都能问答、都能接模型，功能表摆出来高度重合，于是很容易演变成两边各改一半、出问题互相甩锅。

这篇不聊原理，只给落地路线的判断标准和执行顺序：先把边界划清楚，再定联调方式，最后用一套可复现的评测和排错清单收口。你按这个顺序走，选型这件事就不会一直悬着。

先划边界：谁管文档进料，谁管问答编排

一句话区分：RAGFlow 的强项在文档解析、切片和召回质量；Dify 的强项在对话流程编排、多轮改写和对外接口。一个偏「怎么把文档变成能用的片段」，一个偏「拿到片段之后怎么组织成一次对话」。先认清这一点，边界就好划了。

• 边界一旦定了就写进文档：谁负责切片参数、谁负责重排、谁负责兜底，白纸黑字，避免两边都在改同一层配置
• 给每层定一个「责任人 + 可改范围」，检索层的问题先查切片语料，编排层的问题先查流程与提示词
• 把「检索返回什么字段」当成两边的合同，而不是实现细节，后面换模型、换切片策略都不动这层
• 提前说清楚不适用的情况：团队没有运维能力托管两套服务时，双组件的复杂度会反噬效率，不要硬上

联调顺序：从最小连通到全链路打通

联调最容易犯的错是「一上来接全部语料」，然后问题满天飞，分不清是解析、检索还是生成的锅。正确做法是一层层加，每层都能单独验证，出问题时能立刻定位到某一环。

1. 只验证连通用一个已知答案的问题打穿「Dify 能拿到 RAGFlow 的检索结果」，先别接全部语料，只看这条链路是否通
2. 固定字段契约把返回的片段正文、来源标识、相关度分数约定成固定结构，写清楚每个字段的含义和取值范围，后续换模型或换切片策略都不动这层
3. 接生成模型先跑非流式确认答案正确，再开流式处理首字延迟和断流，两段分开测，别混在一起判断
4. 补超时与降级检索超时就走兜底回答，不要让整条对话卡死；具体档位到 /tools/speed-test 按自己的延迟基线定

每完成一步都留一个「可回滚点」：改配置前记录当前状态，改完只验证这一步的效果。联调阶段最值钱的不是速度，是出问题时你知道该回退哪一层。

上线前的小评测：别凭手感说效果好

很多团队上线前只问几个自己出题自己答的问题，全对就认为好了。这种评测没有区分度。真正有用的是小批量、分类别、留证据的评测集，跑一次能看出是哪一层在拖后腿。

• 每条记录期望来源，重点看检索有没有把该出的片段召回；生成质量差，往往是召回先错了
• 切片参数、嵌入模型、重排，只要动一项就跑一遍评测，记录改动前后的对比，别攒一堆改动一起上
• 评测集要能复现：同一个问题、同一批语料，两次跑出来的差异才说明是改动带来的
• 模型侧的能力和价位会变，选型前到 /price-watch 核对当时的数字，别用印象里的旧结论下判断
• 评测结果留档，哪怕只是一张表，也能在下次换方案时告诉你「上回为什么选了这条路」

日常维护与排错顺序

上线之后问题不会消失，只是换了个形式：以前是「搭不起来」，现在是「答得不对、偶尔很慢」。这时候需要一条固定的排查顺序，让值班的人不用凭直觉猜。

1. 倒着查按「服务在线 → 检索能返回 → 来源对不对 → 生成答得准」四步倒着查，先定位是检索问题还是生成问题，再往下钻
2. 日志留三段问题、召回片段标识、耗时三段必须留，缺一段事后就没法复盘是哪一环慢、哪一环丢了
3. 语料更新后自检新增文档后先小范围问几个只有新文档能答的问题，确认切片真的生效，别等用户发现才回头查
4. 对齐上限并发和限流按团队实际访问量留余量，两个组件各自的连接数上限要对齐，别让一方先被打满

维护阶段还有一个常被忽略的点：谁来负责「知识库变旧」。文档有生命周期，切片参数、召回策略也要跟着语料变化调整，把这件事排进固定节奏，比出问题再救火省力得多。