Dify 最容易被低估的功能，不是工作流编排，而是知识库。很多人以为“上传文档，然后让 AI 回答”就算完成了 RAG，其实真正决定效果的，是文档怎么整理、怎么切分、怎么召回、怎么测试。
如果你只是想了解 Dify 和 n8n 的定位差异，可以先看 Dify 和 n8n 有什么区别。这篇文章只聚焦一个更具体的搜索意图：Dify 知识库怎么搭，才能做出可用的 RAG 问答应用？
先明确：Dify 知识库不是资料仓库，而是问答上下文系统
知识库不是把 PDF、网页、Word 文档扔进去就结束。它的作用是：当用户提问时，从已有资料里找出最相关的内容块，交给大模型作为上下文，再生成回答。
所以你要优化的不是“上传了多少资料”，而是这几个问题：
- 用户常问的问题，资料里有没有明确答案？
- 答案是否被切在一个足够完整的 chunk 里？
- 检索时能不能把正确 chunk 排到前面？
- 模型回答时是否能引用资料，而不是自由发挥？
- 上线后能不能复盘哪些问题召回失败？
这也是 RAG 和普通提示词最大的区别。提示词解决表达方式，知识库解决事实来源。想先补概念，可以看站内百科 检索增强生成（RAG）。
第一步：先整理资料，不要急着上传
很多 Dify 知识库效果差，不是模型问题，而是资料本身太乱。上传前建议先做一次“面向问答”的资料整理。
适合放进知识库的资料
- 产品说明、价格规则、售后政策、常见问题。
- 公司内部 SOP、培训手册、销售话术、交付标准。
- 课程大纲、知识卡片、专题文章、操作教程。
- 有明确版本和更新时间的业务文档。
暂时不适合直接放的资料
- 没有结构的聊天记录。
- 大量重复、过期、互相矛盾的历史文档。
- 只有图片扫描件、表格嵌套很深、格式严重混乱的文件。
- 包含大量敏感信息但没有脱敏规则的资料。
我的经验是，先把资料整理成“一个问题对应一段清楚答案”的结构，后面的切分和召回都会轻松很多。做 AI 客服尤其如此，之前站内写过 Dify + Coze 搭 AI 客服机器人，真正上线时最费时间的往往不是搭界面，而是整理可回答的知识。
第二步：选择切分方式，决定召回颗粒度
Dify 创建知识库时，会让你选择 chunk 设置。简单说，chunk 就是文档被拆成的小段。用户提问后，系统检索的是这些小段，而不是整篇文档。
切分太大，答案上下文完整，但容易召回一大段不精确内容；切分太小，匹配更精准，但上下文可能不够，模型容易答半截。
普通 FAQ：用较短 chunk
如果资料是常见问题、产品政策、价格说明，建议让每个 chunk 尽量围绕一个问题或一个规则。这样用户问“退款多久到账”，系统更容易召回退款规则，而不是召回整份售后手册。
教程和流程文档：保留上下文
如果资料是教程、流程、SOP，chunk 不要切得太碎。比如一个步骤依赖上一步，或者参数说明必须和案例一起看，就要保留相邻内容。Dify 支持设置 chunk overlap，用来让相邻片段有一定重叠，减少关键信息被切断的问题。
长文档：优先按标题和段落清理
不要指望系统自动理解混乱排版。长文档最好先按一级标题、二级标题、段落重新整理，删掉页眉页脚、导航、版权声明、重复目录，再上传。尤其是从网页抓取来的内容，清理噪音非常重要。
第三步：设置索引和检索，不要只看默认值
知识库建好后，需要关注索引方式、Embedding 模型、Top K、分数阈值、是否启用 rerank 等设置。不同项目没有统一答案，但有几个实用原则。
- 高准确问答：优先追求召回准确，Top K 不宜太大，必要时启用 rerank。
- 资料探索：可以适当放宽 Top K 和分数阈值，让用户看到更多相关片段。
- 客服机器人：宁可少答，也不要乱答。没有召回到明确资料时，应提示转人工或让用户补充信息。
- 内部知识助手：可以返回引用来源，让员工判断资料是否可信。
如果你的目标是搭一个完整 AI Agent，不只是知识库问答，可以把这篇和 AI 智能体与自动化专题、n8n AI Agent 工作流教程 一起看。Dify 更适合把知识、对话和应用封装在一起，n8n 更适合连接外部系统和动作执行。
第四步：用召回测试验证，而不是凭感觉上线
Dify 知识库提供检索测试页面，可以模拟用户问题，查看召回了哪些文本块、分数如何、是否命中正确资料。这个步骤不要跳过。
建议至少准备三类测试问题：
- 标准问题：资料里有明确答案，例如“企业版支持几个人使用？”
- 口语化问题：用户不按文档标题提问，例如“我买了之后能退款吗？”
- 边界问题：资料里没有答案，例如“能不能帮我开发一个独立 App？”
测试时重点看三件事：
- 正确 chunk 是否出现在前几条结果里？
- 召回内容是否足够回答问题？
- 错误或无关 chunk 是否分数过高？
如果标准问题都召回失败，先回去改资料结构和切分方式；如果口语化问题失败，考虑补充同义词、FAQ 表述或优化提问改写；如果边界问题也强行召回无关内容，就要提高阈值或在应用提示词里加入“不知道就说不知道”的规则。
第五步：接入 Chatflow 或 Workflow
知识库本身只是基础设施，真正给用户使用还要接到 Dify 应用里。常见做法是：
- 用户输入问题。
- Knowledge Retrieval 节点检索知识库。
- LLM 节点根据用户问题和检索结果生成回答。
- Answer 节点输出答案，必要时带上引用来源。
如果是企业客服，我建议在回答前加一个判断：没有召回到足够高分内容时，不让模型编答案，而是返回“当前资料中没有找到明确说明，请联系人工确认”。这会牺牲一点“看起来很智能”的流畅度，但能明显降低误导用户的风险。
更多 AI 工具选型和教程，我会继续放在 AI 工具评测专题 和 老达 AI 实践专题。Dify 适合做应用入口，但真正可用的 AI 应用，往往还需要权限、日志、人工审核和外部系统自动化配合。
上线前检查清单
准备把 Dify 知识库问答开放给用户前，建议按下面清单检查：
- 文档是否去重、去旧、去掉无关导航和格式噪音？
- 每个核心问题是否能召回正确资料？
- 口语化表达是否能命中同一答案？
- 资料没有答案的问题，是否会被拦住而不是乱答？
- 是否能看到检索记录，方便后续优化？
- 是否给敏感业务设置人工确认或转人工入口？
老达点评
Dify 知识库的门槛看起来很低，但真正做好 RAG，需要把“上传文档”换成“设计问答系统”。资料整理、chunk 切分、召回测试、引用检查，比模型选择更影响最终效果。
我的建议是：先用 20 个真实用户问题做小范围测试，不要一上来把所有文档全塞进去。能稳定答好核心问题，再逐步扩资料、调检索、接工作流。这样搭出来的 Dify 应用，才更像一个能交付的工具，而不是一个漂亮但不可靠的演示。
参考资料：Dify Chunk Settings 文档、Dify Retrieval Testing 文档、Dify Knowledge Retrieval 节点文档。
