做Dify这一系列写下来，前面几篇都在讲平台的基础玩法，直到这一篇，才算真正进入让很多刚入门的人既兴奋又头大的环节：RAG。我见过不少朋友卡在知识库这一步，要么是文档传进去但问出来的答案驴唇不对马嘴，要么是压根不知道分段、向量化这些参数到底该怎么填。这篇就用一个非常贴近实际工作的场景——数据治理，把从准备语料、创建知识库、配置参数到最终上线可问的全过程拆开讲一遍。你可以把它当成一份可以直接照做的操作手册，看完就能动手搭出第一个真正能用的知识库。
为什么偏偏选“数据治理”这个主题来做第一个RAG实战？因为数据治理领域的文档有极其鲜明的特点：术语密集、规则明确、职责划分清晰，而且大部分企业内部都有真实的制度文件和标准规范可以拿来练手。这类语料恰恰是RAG最能发挥价值的地方。大模型本身对“数据所有者是谁”“数据质量规则怎么定”这类企业内部知识是完全陌生的，必须靠知识库补充。我写下这些话，就是想让你在跟着实操的同时，也能理解每一步配置背后的逻辑，而不是稀里糊涂地把按钮都点一遍。
1. 先搞清楚：RAG 到底在帮你解决什么问题
1.1 大模型天生记不住你的存量知识
接触过几个大模型API之后，你会发现一个很尴尬的现实：模型再聪明，它的知识截止日期就摆在那里，而且它的训练语料里根本不可能包含你公司内部的《数据管理办法》或者某个系统的数据字典。你直接问它“我们公司的数据Owner是谁”，它只能一本正经地胡说八道。这种看似专业实则虚构的回答，在内部知识问答场景里是完全不可接受的。
RAG（Retrieval-Augmented Generation，检索增强生成）的思路其实特别朴素：既然模型不知道，那就先别让它瞎编，而是先从一个预先准备好的知识库里面把相关的资料片段检索出来，拼接到提示词里，再让模型基于这些资料生成回答。整个过程就像你面试前从资料柜里翻出应聘者的简历，递给面试官说“你照着这份简历来提问”，而不是让面试官凭空发挥。
这里有一个很多人容易混淆的概念要提前说清楚：RAG并不改变模型本身，它只是在生成环节之前增加了一个“查资料”的动作。所以知识库的质量——文档怎么切、向量怎么存、检索怎么排序——直接决定了下游生成的质量。这就是为什么我反复强调，建知识库这件事值得认真对待，参数不是随便填填就完事的。
1.2 Dify 把 RAG 做成了“搭积木”
Dify这类平台之所以能火，很大程度上是因为它把RAG这条原本需要自己写代码才能跑通的链路，封装成了可视化界面上可以拖拽配置的流程。你不需要自己动手实现Embedding接口、不需要自己搭向量数据库、不需要写检索排序的逻辑——这些在Dify里都已经是现成的模块，你要做的是理解每个环节在干什么，然后把合适的语料喂进去，把合适的参数调出来。
一个标准的RAG流程在Dify里面对应的就是知识库的完整生命周期：上传文档，平台自动帮你分段；调用Embedding模型把每一段文字转换成向量；把向量存入内置的向量数据库，同时保留原文；你发起提问时，你的问题也被转成向量，去和知识库里所有向量做相似度计算；排在最前面的几个片段作为参考上下文，和你的问题一起交给大模型生成回答。Dify把这几个环节全部放在后台自动执行，但每个环节的参数选择，比如分段长度、检索数量、相似度阈值，都留给了你做主。
理解了这条链路，再去操作界面的时候思路会清晰很多。你在界面上调整的每一个参数，影响的都是这条链路上某个具体的环节。反过来，遇到结果不好的时候，也应该沿着这条链路逐段排查：文档有没有进去、分段是不是合理、向量化有没有成功、检索是不是没召回到、大模型是不是没理解。这套排查方法论掌握了，比记住任何单个按钮的作用都值钱。
1.3 为什么第一个知识库选“数据治理”
我做过的第一个完整知识库项目，就是用某个模拟项目X内部的数据治理文件做的。选这个领域纯粹是误打误撞，但做完之后回过头检讨，发现数据治理其实是RAG新手练手最理想的主题。原因有三条，我可以直接分享给你参考。
第一条，数据治理的语料获取最容易。每个稍微成规模的组织里，多多少少都有《数据管理办法》《数据标准规范》《数据质量检查细则》《数据安全分级指南》这类文档，就算没有正式的，也会有项目总结或者会议纪要。用真实工作场景里的文档练手，比起随便找一堆科普文章拼凑，效果和心态都完全不同。第二条，这个领域的问答带有天然的“标准答案”属性。比如“数据质量规则有哪几类”，文档里写清楚了就是写清楚了，不需要模型去发挥创造，非常适合用来检验RAG本身的召回准确性。最后一条，数据治理的文档结构层次感非常强，有章有节有条目，天然有利于分段切割和后续的检索命中。
所以如果你还在纠结第一个知识库拿什么语料练手，我强烈建议你翻一翻手边有没有数据类的制度文件或操作手册，用它们来走完这篇实战，收获会远超预期。
2. 动手前先把语料备好：数据治理文档的准备与清洗
2.1 语料清单：哪些文档最适合入库
在Dify里点“上传文档”之前，你得先想清楚一个问题：不是所有文档都适合进知识库。数据治理领域的文档多种多样，但适合作为首批语料的，我建议你先从这三类入手。
第一类是制度类文件，比如数据管理办法、数据治理工作制度、组织职责分工说明。这类文件回答的是“谁负责、按什么流程做”的问题，是知识库的骨架。第二类是标准规范类，比如数据标准、数据分类分级指南、命名规范。这类文件往往带有大量表格和枚举清单，回答的是“数据应该长什么样”的问题，是知识库的肌肉。第三类是操作类文档，比如数据质量规则配置手册、数据平台使用指南、异常数据处理SOP。这类文件回答的是“具体怎么做”的问题，是知识库的神经末梢。
我自己是建议第一批语料控制在十到二十个文件之间，总页数五十页以内。别贪多。原因很简单，第一批语料的价值在于让你把整条链路跑通、把参数的感受建立起来，而不是追求知识的覆盖面。文件太多反而会让问题排查变得复杂，出了问题你根本不知道是哪个文件里的哪一段惹的祸。语料宁精勿滥，这是知识库建设初期很重要的一条心法。
另外特别提醒一句：别把PDF扫描件直接拖进来就完事。很多数据治理的制度文件都是老式扫描件，里面全是图片，文字根本没法提取。这种文件进知识库之后，检索到的全是空文本或乱码，你后面怎么调参都白搭。Dify对文字型PDF的解析尚可，但扫描件必须先经过OCR识别转成可编辑的文本格式，再拿来做入库。这一步偷懒了，后面就会用无数的调参时间来还债。
2.2 清洗：做不好这一步，后面召回全是噪音
语料准备好之后，最容易被忽视但影响最大的环节就是清洗。我见过太多人直接把一份几十页的Word文档原封不动传进去，连目录、页眉页脚、修订痕迹都没去掉，结果就是：用户问一个很明确的问题，召回回来的片段里夹杂着“第3页共12页”、“内部资料，请勿外传”这类垃圾内容，模型自然就被带偏了。
清洗这件事不需要用到多复杂的工具，基础的文本处理就足够解决九成的问题。我实操中的做法是这样的：先把所有文档统一转成Markdown或纯文本格式，这一步推荐用Pandoc这类工具批量完成，Word、PDF都能转。然后重点检查三类问题。一是页眉页脚，docx转出来的文本里通常会有“第X页”这类残留，直接正则替换掉；二是表格结构，数据标准类文档里表格极多，转成Markdown之后表格通常会保留，但要注意列错位、单元格串行的问题，这类问题会造成语义混乱；三是特殊符号，比如全角半角空格混用、无意义的“***”分隔线，这些噪音都会干扰后续的向量化效果。
清洗完之后的文本质量怎么验证？我会随便抽出几段，把自己代入用户的视角去读一遍：这段话单独拿出来看，能不能看懂它在讲什么？如果一段话脱离上下文就看不懂，说明分段之后模型也看不懂。这个标准虽然朴素，但非常管用。
2.3 命名与版本：知识库维护的地基
这一点跟数据治理领域本身强调的“元数据管理”不谋而合，你能想象一个连文件命名都不规范的知识库后期维护起来有多痛苦吗？我第一批语料里有一个数据标准的V1版本和一个V2版本，因为文件名里没有版本号，两个文件同时传进了知识库，结果同一个问题每次回答的内容还有出入，排查了半天才想到是版本冲突。
规范的经验是：入库的每个文件命名统一用“【分类】文件名V版本号_日期”的格式，比方说“【数据标准】数据分类分级指南V2.1_20250601.md”。分类标签的用词也要统一，别一会儿“标准”一会儿“规范”，这会影响你对知识库的管理效率。每次有更新版本，不要在原文件上覆盖，而是新增一个带新版本号的文件入库，然后把旧版本在知识库里禁用或删除。这样知识库内容的演进历史始终是清晰的，出了问题能追查到底是哪个版本在起作用。
很多人把知识库当成一次性工程，做完了就不管了。但实际上知识库是一个需要持续运营的资产，它的健康度直接决定问答质量。命名规范、版本管理这些看似琐碎的习惯，恰恰是支撑长期运营的基础设施，值得在动手第一批语料的时候就建立起来。
3. 在 Dify 里创建你的第一个知识库
3.1 新建知识库与选择 embedding 模型的讲究
语料准备妥当，打开Dify控制台，左侧菜单进“知识库”，点击“创建知识库”，输入一个能让自己一眼看懂的名称，比如就叫“模拟项目X-数据治理知识库”。这里的命名建议跟语料的分类规则保持一致，方便后面扩展到更多知识库时不会混淆。
接下来一个很关键的决策点：选Embedding模型。Dify支持配置多种Embedding模型，包括平台内置的几个选项，也可以接入外部API。Embedding模型的选择对中文语料的检索效果影响极其明显。我在数据治理这批语料上做过对比，使用通用型的开源中文向量模型，比使用以英文语料为主的模型，召回准确度明显要好。Dify里常见的做法是选择基于中文优化的向量模型，这类模型在中文场景下的相似度计算更可靠。
还有一个直接相关的参数叫“向量维度”，有些模型提供不同维度的版本供你选择。维度越高，理论上表达能力越强，但存储开销和计算成本也随之上升。对于数据治理知识库这种体量在几十个文件内的场景，低维度版本已经完全够用，没必要追求最高配置。选好模型之后就固定下来，不要频繁切换。因为每次切换Embedding模型，都需要对所有文档重新做向量化，耗时且消耗API额度，而且不同模型产出的向量之间天然不兼容，混用会直接导致检索失效。
embedding模型这块，我给一个很直接的建议：如果你用的是Dify云服务或者Docker自部署版本，优先选择界面里标注的中文优化模型，或者社区评价高的开源中文向量模型，先跑通全流程再说。之后如果发现特定场景下检索效果不够，再针对性替换，不要一开始就在模型选型上花太多精力。
3.2 分段规则：Chunk 大小怎么设
创建知识库时最让人纠结的往往是“分段”那一步。Dify里默认的分段设置叫“自动分段”，它可以识别文档结构自动切分。但我个人的建议是：第一批语料，尤其是数据治理这种结构化的文档，强烈建议手动设置分段标识，而不是完全依赖自动模式。
先理解一下为什么要分段，大模型一次能处理的上下文长度是有限的，你不可能把整个几十页的文档全部塞进提示词，而且一次提问只需要相关的某几段就足够了。分段就是把文档切成一个个合适大小的“积木块”，检索的时候按块拉取，拼接成上下文。块切得太大会怎么样？无关内容混进来，稀释真正的答案信息，模型容易被冗余内容带偏；切得太小又会怎么样？上下文不完整，答案缺乏前因后果，模型只能猜。
对于数据治理文档，我实测下来比较稳的参数是这样的：分段标识设为“连续换行”或“章节标题”都可以，关键看你的文档结构；最大分段长度设置在800到1200 token之间，分段重叠设置在200 token左右。设置稍长的分段长度，是因为数据治理文档的很多结论性语句都依赖前文定义，上下文切断了语义就断了；而适当的分段重叠可以保证跨段边缘的信息不会因为切割而丢失。
很多人在这一步会犯一个错误：把所有文档用一种分段参数一刀切。实际上，制度类和操作类的文档结构差异巨大，混合使用同一套参数往往导致部分文档效果很差。我的做法是先跑一个批次，检索效果不理想再单独调整特定文档的分段设置。Dify支持对单个文档重新设置分段规则，这一点值得好好利用。
3.3 索引方式：高质量与经济模式的取舍
Dify创建知识库的时候，还有一个选择会直接改变整个流程的运作方式：索引方式。界面里通常有两种模式，一种是高质量模式，另一种是经济模式。高质量模式意味着内容会被向量化处理，检索的时候用语义相似度来匹配，效果最好但调用Embedding模型会产生费用。经济模式则是直接对文本内容做关键词匹配，不需要向量化，适合对成本敏感或者语料量不大的场景。
对数据治理知识库，我毫不犹豫地推荐高质量模式。原因有两点：第一，用户在做数据治理相关提问时，经常用的是问句、口语化表达甚至含糊的表述，关键词匹配很容易漏掉那些表述不同但语义相近的答案，而向量检索对这类模糊匹配的容错能力更强。第二，前面说过数据治理文档术语密集，同样的概念在不同文档里可能措辞差异很大，向量化正好可以捕获这种语义层面的关联，这是关键词匹配做不到的。
另外需要提一下的是，Dify在某些版本里还支持“父子分段”功能，大意是先有一个大块的整体上下文，再在细粒度层次上做检索，检索到子片段时把父级上下文也带上。这种设计对数据治理这种章节感很强的文档来说非常实用。比如用户问“数据质量规则怎么配置”，检索命中了某一小节的操作步骤，同时也把该小节所属的整个章节带过来供大模型参考，回答自然多了一层上下文保障。如果你的Dify版本支持这个功能，建议在数据治理语料上开启试试，实测对回答质量的提升是很明显的。
4. 接入应用：让知识库真正“能问会答”
4.1 编排一个带知识库的聊天助手
知识库建好了，但此时它还只是一个孤立的仓库，用户还不能直接跟它对话。接下来需要创建一个应用，把知识库挂载上去。在Dify里，这一步通常是在“创建应用”时选择聊天助手类型，然后在应用编排界面里把刚刚建好的知识库关联进来。
关联完成之后，还有一个非常重要的配置项：提示词。很多人觉得提示词是给模型看的，随便写两句就行，其实不然。在带知识库的RAG应用里，提示词承担着一个关键职责：约束模型严格依据检索回来的知识库内容回答，不要自己发挥。对于数据治理的知识库这点尤其重要，因为制度条款需要的是准确引用，而不是模型的自由创作。
我用来约束模型的一套提示词逻辑大概是这样：先给模型一个身份设定，比如“你是企业内部的数据治理专家助手”；再给出明确的回答规则——基于提供的参考内容回答问题，参考内容中没有的信息要明确说不知道，不要凭空编造；最后要求回答的时候可以引用参考内容的原文表述，确保答案的口径和制度文本保持一致。这套逻辑是通用的，你可以根据自己的风格再润色，但核心的约束一定要保留：没有依据就不要编。
编排界面上还有“召回模式”的选项，通常可以在“向量检索”和“全文检索”之间切换。刚入门的话先用默认的向量检索即可，前面已经解释过原因。重点是别忽略Dify的预览调试面板，你在右侧的调试框输入一个问题，左侧就能看到实际召回了哪些内容片段、模型又是怎么基于这些片段生成回答的。这条调试链路是整个RAG应用最直观的体检入口。
4.2 召回设置与引用来源
回到应用编排界面，你会发现有几个参数经常被忽略，但它们直接影响问答质量，而且排错时最先要查的就是它们。第一个是TopK，也就是每次检索最多取回多少个片段。默认值通常是3，1到8之间是常见范围。数据治理场景下我建议先设为4到5，因为回答这类问题往往需要横跨多个制度文件的交叉验证，取回的片段太少容易漏掉关键信息。
第二个是Score阈值，也就是相似度要超过多少才算匹配成功。这个值设置得太低，那些根本不相关的内容也会混进来，模型就会被垃圾信息干扰；设置得太高，又会导致有些答案明明存在却因为措辞偏差被漏掉。Dify里这个值的默认设置有版本差异，实践中可以先按默认跑一轮，然后用一批测试问题集中检验，根据召回结果的命中情况再微调。对于数据治理场景，我个人的经验是阈值宁可稍微偏低也别偏高，宁可把候选内容多留给大模型去筛选，也不要在检索阶段就把正确答案拦截掉。
第三个是重排序（Rerank）。如果你的Dify版本支持，强烈建议在知识库层面开启重排序模型。重排序的原理是，向量检索先召回一批候选片段，然后用一个专门模型对候选片段与问题之间的相关性做更精细的排序，把真正有用的片段顶到最前面。数据治理知识库的文档之间内容交叉很多，重排序对甄别哪个片段才是真正切题的效果极佳。开启重排序之后，TopK的取值也可以适当放宽，让召回阶段更“宽进”，再靠重排序“严出”，整体效果会稳定很多。
最后还有一个使用体验上的关键点：一定要记得打开回答附带的“引用来源”。Dify支持让模型在回答时标注信息来源，这样用户看到答案是来自《数据管理办法》的哪个章节，而不是一个来路不明的AI自说自话。在企业内部的知识问答场景里，“这句话的依据是什么”比“这句话对不对”更重要，引用来源不仅提升可信度，也为之后发现问题时的追溯排错提供了路径。这一步在实际使用中虽然不起眼，但价值非常大。
4.3 用数据治理的典型问题实测
配置完成之后，你的知识库到底行不行，得通过真实问题来检验。不要随便问几个无关痛痒的问题就草草收工，建议准备一组有代表性的测试问题，覆盖数据治理的典型场景，反复验证回答质量。
我常用的测试问题集是这样的：第一类是定义类，比如“数据Owner和数据管理者的职责有什么区别”，这考的是文档语义召回以及模型对关键术语的理解。第二类是规则类，比如“数据质量规则包含哪些维度”，这考的是枚举型信息的完整召回，模型必须把文档里列出的所有维度找全，不能漏项。第三类是流程类，比如“数据需求变更的处理流程是什么”，这考的是跨章节的信息组织和顺序还原能力。第四类是反例类，比如问一个数据治理文档里根本没有的问题“公司年会怎么请假”，正确行为应该是模型回答“知识库中没有相关信息”，而不是强行编一个答案。反例测试是很多人忽略但极其重要的一环，它直接检验提示词对幻觉的约束效果。
我在第一次跑数据治理知识库的实战中，就发现一个典型问题：问“数据质量规则包含哪些维度”时，模型只回答了文档中“完整性、准确性、一致性”三个维度，但漏掉了“唯一性”。查了召回详情才发现，包含“唯一性”这一维度的片段没有进入TopK的候选范围。把TopK从3调到5之后，这个问题就解决了。这种排查经验说明一件事：测试问题集不单一，你就不可能有针对性地调参。
5. 常见问题与效果优化实录
5.1 知识库问答的典型翻车现场
做到这里，你大概率会遇到一些让人抓狂的场景，我提前把最常见的几类列出来，并给出排查路径，你可以直接对照处理。
问题A：提问之后模型回答“不知道”，但明明知识库里有答案。排查顺序先看召回，在调试面板里检查检索源里有没有相关的片段被召回。如果召回为空，大概率是分段太细或者关键词被切没了，调大最大分段长度，或者换用更适合中文语义的Embedding模型。如果召回有但模型说不知道，那就是提示词约束过于严格，让模型在“参考内容不足以支撑回答时”选择了拒绝，需要把提示词改成“参考内容中有相关信息时优先回答”。
问题B：回答内容跑偏，答非所问，或者说了一堆跟问题没直接关系的话。这个现象的根源几乎都在召回内容被大量无关信息污染。先查看Score阈值，如果设得太低，那就上调；再检查文档清洗是不是没做干净，页眉页脚和残留表格串位的内容会让片段语义非常混乱。
问题C：引用来源与实际内容对不上，模型引用了某个文件，但引用的段落里根本没有用户想问的答案。这通常是重排序没启用或者父级上下文没带上的结果。片段本身可能跟问题语义相关，但详细的规则落在上级章节，模型引用了一个“子片段”，信息却不完整。开启父子分段或重排序，这个问题就能得到明显改善。
问题D：同一个问题每次回答的内容不一样，而且差异很大。先查知识库里是否存在重复或版本冲突的文件，优先删掉旧版本；其次检查模型参数里的温度设置，温度过高会让生成结果随机性变大，回答的问法可能变化，但核心事实应该一致。如果核心事实来回跳，那大概率是版本冲突，而不是温度问题。
5.2 从“能答”到“答得好”：优化三板斧
知识库跑通之后，你会发现“能答”和“答得好”之间还有不小的距离。想从能用变成好用，我的经验可以浓缩成三板斧，按顺序做，性价比极高。
第一板斧是补充同义改写。数据治理里面“数据Owner”和“数据责任人”、“数据安全”和“数据保密”这类同义术语特别多。用户可能用哪个词来提问完全是随机的，但知识库里的文档可能只用了其中一种表述。要解决这个问题，可以在入库前对文档做一轮术语归一，或者在上层做一层意图改写。Dify某些版本支持查询改写功能，即把用户的问题先改写成更规范的表述再检索。效果实测很不错，可以查一下你的版本有没有。
第二板斧是上重排序。前面已经详细讲过了，这里只补充一句话：重排序是效果提升最直接的一招，要比反复调Embedding模型参数划算得多。如果你的Dify版本支持，别犹豫，直接启用。
第三板斧是细化知识库结构。当你的语料越铺越多时，一个知识库放所有数据治理相关文档的做法会越来越吃力。按“数据标准”“数据质量”“数据安全”“数据制度”这样拆成多个子知识库，在应用编排里按需关联，每个知识库内部再按文档分类维护。这样做的收益不仅仅是检索精度提升，还包括后续运营更新的边界清晰、权限可以按库划分。知识库从单库走向多库，是一个必然要做出的调整。
5.3 别忘了数据治理的本行：知识库自身的治理
这篇文章以“数据治理”作为实战场景，但到了优化阶段，我想请你跳出场景本身想一个问题：你这个知识库，本身是不是也需要“治理”？这个反问不是文字游戏，而是实实在在的工程经验。
知识库上线之后不能放任不管。权限管理是第一件事：哪些人只能问答，哪些人能修改配置？Dify的角色权限体系里可以对成员做区分，至少别让所有人都能改应用配置。内容更新是第二件事：数据治理制度不可能是一成不变的，每次修订后旧版本要清理、新版本要及时入库，同时注意我在2.3里讲的版本命名规则。质量监控是第三件事：定期用一套固定的测试问题集跑一遍，对比回答的历史质量，凡是分数下降的，一般都是知识库结构或文档发生了变动。把这些问题纳入运维习惯之后，你的知识库才能随着资料的更迭逐步成长，而不是一两周之后就开始悄悄变笨。
所以在数据治理场景里建RAG，从来不是单纯的技术搭建，它本身就需要用数据治理的视角去建设和维护。词源上还有一层很微妙的呼应：你在用RAG处理数据治理的文档，同时你也在治理这个处理数据治理文档的知识库。这两件事互相映照，才是这个实战真正完整的模样。
我自己这一套流程走下来，最深的体会是：建知识库真正花时间的不是Dify上的配置操作，而是语料准备和一遍又一遍地用真实问题去校准。只要你对分段的语义边界保持敏感，对检索回来的每一段内容都认真看一遍，这个知识库就一定不会差到哪里去。数据治理本身就是一个需要细心和耐心的领域，拿它来做RAG入门，反而让你从一开始就养成了好习惯。希望这篇能帮你在Dify里顺利做出第一个真正能用的数据治理知识库，也为后面更复杂的RAG应用打好基础。
