Dify 知识库做单一问答时并不复杂：上传资料、配置检索、写好提示词，就能先跑起来。但一到真实业务，问题很快会变成“资料太多、场景太杂、该查哪个知识库说不清”。
比如同一个客服机器人，既要回答售后政策，又要解释产品功能，还要给销售同事查报价口径。如果所有资料都塞进一个知识库，短期看省事，长期会出现召回混乱、答案口径打架、权限边界不清的问题。
这篇文章不重复讲基础搭建。如果你还没跑通第一版，可以先看 Dify客服知识库怎么搭？从资料清洗到人工接管的落地流程。本文重点解决第二阶段的问题：Dify 多知识库应该怎么分组、怎么路由、怎么测试。
相关背景也可以放到 AI智能体与自动化专题 和 老达AI实践专题 里理解：真正可交付的 AI 应用，不是“能回答一次”，而是面对不同用户和不同资料时，能稳定选对信息来源。
先决定：多知识库是为了什么
不要因为资料多，就立刻拆成很多知识库。拆分的理由应该来自业务边界，而不是文件夹习惯。
我更建议按这四类边界来判断：
- 对象不同：客户、销售、售后、内部员工看到的答案不一样。
- 口径不同：产品功能、价格政策、合同条款、技术支持不能混答。
- 更新频率不同：活动政策每天变，使用手册可能几个月才改一次。
- 风险等级不同：公开资料可以直接回答，内部制度和报价口径需要更谨慎。
如果资料只是主题不同，但用户问题经常需要一起引用，可以先不拆太细。过度拆分会让路由变复杂，也会增加维护成本。
三种常见的路由方式
Dify 多知识库并不是只有一种玩法。你可以根据业务成熟度选择不同方案。
1. 直接多路检索
Dify 官方文档里提到，多路检索会在应用关联的多个知识库中同时查找相关片段，再通过 rerank 等策略把更相关的内容排到前面。这种方式适合资料边界不算敏感、用户问题可能跨多个资料源的场景。
例如一个产品问答助手，可以同时关联“产品手册”“常见问题”“版本更新记录”。用户问“这个功能为什么没有入口”，系统可能需要同时参考手册和版本说明。
它的优点是简单，缺点是如果知识库质量差、术语冲突多，就容易把相似但不该混用的内容召回到一起。
2. 用问题分类器先分流
如果不同场景差异明显，更推荐先用 Question Classifier 做意图分类，再进入不同路径。Dify 的问题分类器可以根据用户输入，把问题分到预设类别，再走对应工作流。
例如你可以先分成：
- 售后问题：查退换货、发票、物流和保修资料；
- 产品问题：查功能说明、操作教程和限制条件；
- 销售问题：查套餐、报价边界和适合人群；
- 无关问题：不查知识库，直接引导用户换个问法或转人工。
这种方式的关键不是分类名字写得漂亮，而是类别之间要有足够区分度。不要同时设置“产品咨询”和“使用问题”这种容易重叠的类别，否则分类器会摇摆。
3. 外部知识库按系统接入
如果资料不适合直接上传到 Dify，例如还在企业内部系统、CRM、工单系统或自建知识平台里，可以用外部知识库 API 的方式接入。这样 Dify 负责应用编排，你自己的系统负责检索和权限控制。
这类方案更适合团队已经有内部数据系统的情况。个人或小团队刚开始做，先用 Dify 自带知识库跑通流程，再考虑外部知识库，不要一上来就把架构做重。
推荐的知识库分组模板
以本地商家或小团队客服场景为例，可以先拆成四个知识库。
- 公开产品资料：功能介绍、使用教程、常见限制，适合直接回答。
- 售后政策资料：退款、换货、发票、服务时效，需要明确边界。
- 销售口径资料：套餐、报价说明、适合人群，建议加人工确认。
- 内部运营资料：交付流程、人员分工、特殊客户备注，默认不直接对外输出。
这里最容易踩坑的是把“销售口径”和“公开产品资料”混在一起。产品资料可以相对客观，销售资料往往带有价格、承诺和适配条件，一旦答错就可能造成纠纷。
如果你正在把 Dify 和 n8n 组合成客户交付流程，可以继续看 Dify 和 n8n 怎么一起用？给小团队交付 AI 自动化的组合方案。Dify 负责问答和分流，n8n 更适合接表单、消息通知、工单和人工审核。
路由流程可以这样搭
一个比较稳的 Dify 多知识库工作流，可以按下面的顺序设计：
- 开始节点接收用户问题和必要变量，例如用户类型、来源渠道、是否登录。
- 问题分类器判断问题属于售后、产品、销售、内部或无关类别。
- 不同分支连接不同知识库检索节点，必要时设置不同 top-k 和 rerank 策略。
- LLM 节点根据检索结果生成答案，并明确“不知道就说明无法确认”。
- 对价格、合同、退款、投诉等高风险问题，进入人工审核或人工接管。
- 记录用户问题、分类结果、召回片段和最终答案，定期复盘。
这套流程看起来比单知识库复杂，但复杂度是有价值的：它把“该查哪里”和“怎么回答”分开了。后续要调优时，也能知道是分类错、召回错，还是生成错。
测试时不要只问标准问题
多知识库路由上线前，至少准备一组小测试集。每个类别 10 条问题，也比临时凭感觉强。
测试集要包含四类问题：
- 明确问题：一看就应该进入某个知识库。
- 模糊问题：用户表达不完整，需要分类器判断上下文。
- 跨库问题：可能同时涉及产品和售后，测试是否需要多路检索。
- 拒答问题：资料里没有答案，或者不应该由 AI 直接回答。
如果你发现知识库能召回资料，但答案仍然答偏，可以回看 Dify知识库命中率低怎么办？RAG召回、分段和测试优化清单。多知识库路由解决的是“去哪查”，召回优化解决的是“查得准不准”。
上线后重点看四个指标
Dify 多知识库不是搭完就结束。上线后最好每周看一次日志，重点检查四件事。
- 分类准确率：用户问题有没有被分到正确路径。
- 召回命中率：正确路径里有没有找到相关片段。
- 人工接管率：哪些问题经常需要人工处理，是否该补资料。
- 答案风险点：是否出现价格承诺、政策误读、过度保证等问题。
不要只追求自动回答率。对业务来说，错误自动化比人工慢一点更危险。高风险场景宁可多一步人工确认，也不要让 AI 自己编一个看似完整的答案。
老达点评
Dify 多知识库路由的核心，不是把资料拆得更细，而是让 AI 在回答前先做一次“业务判断”：这个问题属于谁、该查哪套资料、有没有权限直接回答。
对个人站长、内容运营和本地商家自动化服务来说，最实用的起步方案是“问题分类器 + 关键知识库 + 人工兜底”。先把售后、产品、销售这三类分清，再逐步补日志复盘和召回测试。
如果你想继续系统化搭建这类流程，可以关注 AI智能体与自动化专题。很多 AI Agent 项目失败，不是模型不够强，而是资料边界、流程边界和人工边界没有设计清楚。
