前面三篇我们把 Dify 从平台搭建聊到了基础应用编排不少朋友已经能在里面拖拽出一个能对话的聊天助手了。这一篇我们来点真家伙用 RAG 把一个“数据治理”知识库从零搭起来并且接入到对话应用里让它真正能被业务方使用。之所以拿数据治理当练手场景是因为它是特别典型的“文档又多又杂、回答必须严谨、查不到就得明确说不知道”的领域正好能把 RAG 链路里的每个环节都逼出来。跟着走完这一篇你能把一堆制度文档变成一个能回答问题、能给出处的知识库全程不碰代码在 Dify 界面里点击完成。这套流程我也在几个模拟项目里完整跑过中间踩了不少坑。这篇不光是操作演示更会把我调参数、看召回结果、修提示词的经验一起写出来。无论你之前有没有接触过 RAG按这个路径走一遍基本就能理解知识库应用为什么有的好用、有的答非所问了。1. RAG 到底解决了什么问题1.1 大模型不是数据库也不是公司内部百科先说一个很容易被忽视的点大模型本身并不知道你们公司的数据标准、字段字典、考核口径。它训练时读的是公开语料知识库截止时间往往也是过去某个节点。你把“数据资产管理实施细则”发给它它只能给你一个“一般意义上”的回答甚至编出一套看起来合理但完全是臆想的流程。这不是模型笨是它的工作机制决定的。它擅长的是根据上下文生成语言而不是从某个内部系统里精确检索一条制度条文。你问“数据标准变更申请需要哪些材料”如果没有任何参考资料它只能根据“公文写作常识”给你编一份流程。RAG 解决的正是这个矛盾。它的思路很朴素先在一堆文档里检索出和问题最相关的片段再把片段连同问题一起交给大模型让它“看着材料回答”。大模型从“凭记忆编答案”变成了“现场翻资料答题”。1.2 RAG 的链路拆开看只有五步如果你在 Dify 里建过知识库你会发现背后其实就是一条固定流水线加载文档把 PDF、Word、Markdown、网页内容导入知识库分段切块把长文档切成一个个可以独立检索的片段向量化嵌入用一个嵌入模型把每个文本片段变成一串数字向量存储与检索把向量存进向量数据库用户提问时把问题也转成向量算相似度找出最接近的几个片段生成回答把“问题 检索到的片段”拼进提示词交给大模型生成答案你可以把这段链路理解成给一个什么都懂一点、但没看过你们公司文件的顾问递上一摞贴好便签的资料让他现场查阅后作答。Dify 把这条链路的大部分环节可视化掉了但理解每一步在做什么仍然决定着你后续能不能调好它。1.3 为什么拿数据治理当第一个实战场景数据治理这个领域有个特点文档成体系、术语密集、答案必须可追溯。比如说“数据所有者”指的是哪个岗位“主数据”和“参考数据”有什么区别这些在制度文档里都有明确定义不能靠模型自由发挥。实践中我见过不少团队拿“规章制度问答”做 RAG 试点最后效果很差原因往往不是技术不行而是文档本身太虚。数据治理场景相对好得多因为它的文档通常是组织过、规范过的有层级、有编号、有明确流程步骤。这类文档喂给 RAG比较容易得到清晰、可验证的答案。另一个原因是业务价值明确。查询数据质量规则、了解字段口径、确认数据安全分级、查看数据资产盘点流程这些需求在业务侧真实存在且高频。把知识库做出来业务方是真的会用而不是做一个演示完就吃灰的玩具。2. 动手前先备料数据治理文档的整理策略2.1 第一件事不是建库是盘点你手里有什么很多人打开 Dify 的第一反应是直接上传 PDF结果知识库建完检索结果一塌糊涂。问题往往不是出在参数上而是出在文档上。做知识库和做饭一样食材质量决定了成品上限后面的分段、向量、检索都是加工环节只能把已有的信息结构优化不能无中生有。数据治理知识库通常包含以下几类文档你可以先按这个清单去盘点制度规范类数据管理办法、数据标准规范、数据安全分级分类制度流程操作类数据资产盘点作业指导书、数据质量规则配置流程、数据共享申请流程术语解释类数据字典、字段口径说明、专有名词定义常见问答类制修订历史FAQ、系统操作问答、指标口径答疑如果你手里只有几份几十页的 PDF先别急着上传花点时间把每份文档的目录结构看一遍标注出它到底覆盖了哪些问题。这一步半小时的投入能省下后面几小时的调参时间。2.2 文档清洗很多检索问题其实是脏数据问题上传前还有一个必要动作清洗文档。我整理了一个实用清单你可以直接照着过一遍扫描版 PDF 必须先做文字识别OCR否则内容全是图片检索什么都查不到表格要被正确转成文本行Dify 对原生 PDF 的表格提取能力有限必要时把重要表格单独转成 Markdown 或纯文本去掉封面、目录、页眉页脚、空白页这些内容会污染分段一份文档如果被拆成多个小文件先合并再上传避免上下文被切碎清理过时的版本如果同一制度存在新旧两版只放现行有效版本我自己踩过最典型的坑是上传了一份带“征求意见稿”字样的旧版制度结果用户问道“流程需要几步”知识库召回的是旧流程。后来我把文件命名统一成“文件名生效日期”上传前再人工核对一遍版本状态才解决这个问题。2.3 给文档分类别把所有内容塞进一个知识库对文档做分类不是形式主义它会直接影响检索质量。数据治理文档的类型差异很大制度规范是长篇幅条文流程操作是步骤清单术语解释是短小定义。它们混在一个知识库里分段策略会很难权衡——按长文档的段落长度切块术语类短文档会被切得支离破碎按短文档切长文档又会超出上下文。更合理的做法是开场前就分库。我的建议是最少拆成两个库一个“制度与流程库”一个“术语与口径库”。前者承载操作类问题比如“数据质量规则怎么配置”后者承载解释类问题比如“‘数据落标’是什么意思”。这样后续调参数和提示词时每个库的策略都能更贴合内容特征。3. 在 Dify 里创建第一个知识库3.1 创建知识库的路径和关键选项现在开始操作。在 Dify 左侧菜单点“知识库”进入子页面后点击“创建知识库”上传你整理好的文档。上传完成后Dify 会进入分段设置页面这里有四个选项需要你逐个理解而不是一路点“下一步”分段标识用于切分文本的符号Dify 默认支持自定义分隔符最大分段长度单个分段允许的最大长度超过会强制切断分段重叠长度相邻分段之间保留的重叠内容长度嵌入模型把文本转换成向量的模型索引方式高质量模式或经济模式这四个参数决定了知识库的“颗粒度”和“语义理解能力”。颗粒度太粗一个分段塞下好几页内容检索时相关性会被稀释颗粒度太细一个完整条目被切成好几段语义又不完整。所以不要直接使用默认值下面的内容值得认真看。3.2 分段长度和重叠长度怎么调参数背后的逻辑先讲最大分段长度。Dify 里默认值是 500 个 token中文场景下大概是不到 500 个字因为中文一个字的 token 消耗远大于一个英文字母。这个值对不同文档影响很大。制度类文档往往结构清晰每一条下面有明确的“一二三”条款这种文档我倾向于用段落边界切。可以在“分段标识”里填入“\n\n”让 Dify 按空行切分同时把最大分段长度调到 1000 字符左右保证完整条款不被拦腰切断。术语类文档本身就很短一个词条可能只有几十个字最大分段长度设成 300 都够。再讲分段重叠长度。它的作用是避免一个完整句子刚好落在分段边界上导致检索时只命中后半段缺失前半段的背景信息。默认值是 50 个 token我一般会调到 100-200特别是文档里常有“综上所述”“根据前述规定”这类代指性表述时重叠能让上下文更连贯。耗时一句话宁可让分段稍微偏长、内容冗余一点也别让关键信息被切碎。边界处丢失的 20 个字可能就是用户提问的核心答案。3.3 嵌入模型怎么选中文场景的取舍嵌入模型的作用是把文字变成数学向量。这个向量要能表达“语义相近的文本在空间中靠近”。选错模型中文检索效果会肉眼可见地变差。Dify 里接入嵌入模型的方式有两种一种是用平台内置的在线模型一种是配置你已有的模型服务接口。如果你主要面对中文文档建议优先选择对中文做过优化的嵌入模型。常被验证效果不错的包括 bge-m3 这类开源中文模型以及 text-embedding-ada-002 这类通用文本嵌入接口。前者在国内环境部署和调用都比较方便中文语义理解扎实后者胜在整体稳定但在中文术语密集的内容上有时不如专门榜单。选型时有两点提醒嵌入模型的维度越高不代表越好但成本会上升。数据治理文档规模通常在几万到几十万字符普通模型完全够用嵌入模型一旦选定后期不要轻易更换。因为已经入库的向量都是用旧模型计算的换模型必须重建索引成本很高3.4 索引方式高质量还是经济模式区别在哪Dify 在创建知识库时会让选“索引方式”。高质量模式会调用嵌入模型生成向量支持混合检索经济模式则基于关键词直接建索引不做语义向量化最终效果接近“搜索引擎按词匹配”。我的建议很直接只要不是纯英文、纯短词场景一律选高质量模式。数据治理问题里用户会用“我要查一下数据资产盘点流程”这种口语化表达去问而文档里写的可能是“数据资产盘点作业指导书”。这两个句子没有共同关键词经济模式很难召回高质量模式靠语义相似度却能兜住。经济模式唯一的优势是省钱和快适合那些文档规模巨大但问题形式高度固定的内部场景。对于数据治理知识库这个场景质检、盘点、分级这类语义近义词太多了高质量模式几乎是必需的。4. 把知识库接入聊天助手先查后答的完整配置4.1 创建应用、关联知识库的完整步骤知识库建好之后它只是一个“资料库”还需要接进聊天助手里才能真正面对用户。在 Dify 中点击“创建应用”选“聊天助手”进入编排界面后在下方的“上下文”区域选择“添加知识库”把刚才建好的库关联进去。关联完成后编排页面的“上下文”里会出现已选知识库的信息。这里解释一下上下文就是每次用户提问时系统会把从知识库检索到的片段拼到这个区域一起发送给大模型。知识库本身不直接产生回答它提供的是回答所依赖的素材。4.2 召回参数召回模式、Top K 和 Score 阈值关联好知识库后点击“召回设置”里面有几个默认参数它们的含义直接决定了“每次提问会抓哪些片段”召回模式向量检索、全文检索、混合检索Top K召回候选片段的数量Score 阈值候选片段的相似度最低分数低于这个分数直接丢弃召回模式建议首选混合检索。向量检索擅长找“意思相近但关键词不同”的内容全文检索擅长精确匹配编号、人名、系统名。数据治理文档里充斥着系统名称和字段编号比如“DGP 平台”“ODS 层”“数据元编号”混合检索能把两者的优势都保留下来。Top K 默认 3对制度问答来说通常可以开到 4-5。Top K 太小关键片段容易漏太大噪声片段会被塞进上下文反而干扰生成。一个简单的经验你可以打开“召回测试”输入典型问题看返回的片段里有多少是相关的、有多少是无关的据此慢慢调整。Score 阈值是把双刃剑。设得太高比如 0.8很多真正相关的片段会被误杀设得太低比如 0.1一堆弱相关内容进来稀释答案质量。我通常从 0.3 起步测试时观察“该召回的都召回了没有”再决定往上调还是往下调。4.3 提示词调校让大模型“看着资料说人话”关联好知识库、调好召回参数后还差最后一步在提示词里把 RAG 的使用方式约束清楚。很多人的知识库之所以回答得“像机器人”就是因为这里没写明白。我常用的系统提示词模板如下你可以在这个基础上改你是一位数据治理领域的资深顾问。请严格基于知识库中检索到的内容回答用户问题。 要求 1. 如果知识库内容能支持回答请引用相关内容给出清晰的结论和依据。 2. 如果知识库内容不足以回答请直接回复“知识库中暂无相关信息”不要编造或猜测。 3. 引用条款时请注明文档名称或章节编号。 4. 回答尽量结构清晰涉及流程步骤时按顺序列出。这里最关键的是第二点允许“不知道”。默认情况下大模型倾向于宁可编造也不承认不会。如果你不明确允许它拒绝回答它就会在知识库完全没相关内容时用“一般经验”凑出答案。对于数据治理这种严谨领域编造一个“数据质量规则配置流程”是没法接受的。另外可以在提示词里要求引用编号或出处。大模型看到“文档名称或章节编号”的指令就会更主动地把检索片段里的信息翻译进答案而不是把检索结果原样复述一遍。这一点是知识库应用体验好坏的分水岭。5. 核心调试为什么召回的片段对不上问题5.1 用“召回测试”定位问题出在哪个环节知识库接入应用后先别急着发给业务方你需要先做一轮召回测试。Dify 的知识库页面和编排页面里都能对知识库发起测试输入一个问题系统会返回召回的文本片段和相似度分数。这个功能是排查问题的核心入口。当用户反馈“答得不对”时第一件事不是改提示词而是先看召回结果对不对。召回结果不对后面一切优化都白搭召回结果对了而回答不对那才是提示词问题。我通常用同一批问题分三轮测试第一轮看相关片段能不能被召回第二轮看召回片段顺序是否合理第三轮看最终答案是否准确使用了召回片段。哪一轮出问题就针对哪一轮做功而不是从头到尾乱调。5.2 “查不到”的典型原因和解决方案“查不到”是知识库应用最常见的问题表现为用户问了一个真实存在的问题但系统回答“知识库中暂无相关信息”。排查方向有三个第一文档根本没进知识库。这个听起来荒唐但真的发生过。上传时某些页数多的 PDF 解析失败Dify 会显示部分文档“处理失败”或“索引异常”。我在操作时习惯上传后先点进文档详情确认分段数大于零再继续后面的配置。第二问题里的关键词和文档里的表述差异太大。比如用户问“表怎么建”文档里写的可能是“模型设计规范建立”。这种情况下向量检索有时也兜不住因为语义距离可能被拉得太大。解决方法不是改参数而是补充同义词或在文档里加入“别名”段落。第三分段不合理关键内容被切碎或边界截断。这种情况下召回到的片段看起来“沾边”但信息不完整。解决方案是回看分段设置调大重叠长度并检查分隔符是否按文档结构生效。5.3 “答得不对”的三类现场记录我在实际调试中遇到过三次特别典型的“答不对”写出来给大家对照参考。第一个现场用户问“数据资产盘点多久做一次”系统回答了一堆“数据质量管理的基本原则”看起来相关但完全答非所问。我一看召回测试结果发现召回的第一片段来自一份“数据质量管理办法”原因是该文档和盘点流程文档混在同一个知识库且分段切分时“盘点”这个关键词把两者关联上了。解决方案是把流程文档单独拆成一个知识库并在问题里增加限定词“盘点流程”。第二个现场用户问“核心系统数据备份的恢复时间要求”召回结果为空。排查后发现原文档是扫描版 PDFOCR 文字质量极差Dify 解析出来全是乱码和断裂文本。重新用 OCR 工具转成高质量文本后再上传问题消失。这类问题在“数据治理”领域尤其常见因为很多制度文件都来自纸质印发版本。第三个现场用户问“数据安全分级有几个等级”召回片段确实准确但模型给出的回答冗长含混先讲了一大段背景才给出“四个等级”的答案。问题出在提示词没有约束输出格式。我在提示词里加了“直接给出结论再补充依据”的表述回答立刻干净利落。重要提示RAG 调试的核心流程是“先查召回再调提示词”。千万不要在召回还没看明白的时候就开始改提示词那样只会越调越乱。5.4 一个完整的调优循环案例说一个我完整跑过的流程大家感受一下“改参数-复测-再改”的节奏。某次知识库测试我问“数据质量规则配置的原则有哪些”召回结果第一片段只命中了“数据质量管理目标”和问题关联度一般真正写规则配置原则的片段排到第三位。这个问题直接导致最终回答只列出了两条原则而文档里其实有四条。我做的调整是三步先把 Top K 从 3 提到 5保证关键片段能进候选再把分段重叠长度从 50 调到 150让“配置原则”这段内容不要被边界截断最后在提示词里加了“请检查知识库中的所有相关片段尽量完整列出原则”。复测后召回前五位里出现了两条直接相关的片段回答终于补全了四条原则。这个案例说明知识库调优往往不是某一个参数的问题而是“文档清洗、分段设置、召回参数、提示词约束”配合的结果。你改任何一个环节都要用同一批测试问题去复测看整体效果有没有变好。6. 让数据治理知识库真正好用起来的进阶打法6.1 分库策略制度库、术语库、FAQ 库各司其职如果你的数据治理文档量比较大建议在起步阶段就按文档性质拆成多个知识库并在不同应用里关联不同库。我的分法是这样的制度与流程库承载“怎么操作”类问题术语与指标库承载“是什么意思、口径是什么”类问题FAQ 库承载高频重复问题比如“数据治理和元数据管理有什么区别”。这样分开之后每个库的参数和提示词都能更有针对性检索精度也会高很多。多个知识库之间还可以设置“知识库分组”Dify 里可以对分类命名。这里没什么高深技巧本质上是让后续维护的人能快速看懂你的文档组织方式。6.2 开启引用标注让每个回答都能溯源在 Dify 聊天助手的编排页面里有一个“功能开关”区域里面可以开启“引用与归属”。开启后模型回答时会附带上引用的知识库分段用户可以点开看到底是哪份文档的哪一段支撑了这个答案。这个功能对数据治理场景非常重要。业务人员看到答案后第一反应通常是“这个口径对不对”如果能看到原文引用信任度会大幅提升也方便管理人员核对内容是否需要修订。我建议在生产环境里务必开启它对排查“答错”也有帮助——哪种答案引用错了文档一眼就能定位。6.3 知识库不是一次建完而是持续运营的一个项目知识库建成只是起点后续的更新和维护才是关键。数据治理制度本身是动态的今年可能修订了数据安全分级办法明年可能新增了主数据管理规范。你需要在知识库里定期更新文档并删除旧版本否则系统就会变成“拿着去年的制度回答今年问题”的状态。更实用的一点是养成查看“未命中提问”的习惯。Dify 的对话日志和标注面板里能看到用户实际问了哪些问题、系统召回了什么、有没有标准答案。把这些“冷启动问题”收集起来每周补充一次 FAQ 文档再上传进 FAQ 知识库。连续迭代一个月知识库的命中率会有肉眼可见的提升。我个人在实际操作中的体会是RAG 知识库的工程量往往集中在“文档治理”而不是“技术调参”。技术层面的东西Dify 已经把大部分封装好了真正拉开体验差距的是你对文档的组织方式、对提问场景的理解以及持续迭代的耐心。数据治理知识库尤其如此它的价值恰恰来自我们把制度、术语、流程这些“组织知识”系统性地喂给了检索系统并让大模型学会在引用材料的前提下作答。最后再分享一个小技巧刚开始做知识库时不要追求大而全。先拿一个高频业务场景做通完整链路比如“数据质量规则查询”验证召回、生成、引用都顺畅了再慢慢扩充其他主题。一步到位往往意味着沟通和维护成本成倍增加从小处着手反而能走得更远。
