1. 数据治理文档堆成山之后我为什么转向RAG方案干过数据治理项目的朋友应该都有同感真正难的不是写制度而是让制度活起来。某集团几千页的数据治理制度、分类分级标准、数据资产盘点规范、应急响应预案全都躺在共享盘和知识库里平时没人看真到用的时候又找不到。我接手这个项目时第一件事就是整理这些文档。统计下来光是《数据治理管理办法》《数据分类分级指南》《数据质量管理细则》《数据安全应急响应预案》这类核心制度就有47份加上各类模板、操作手册、会议纪要总量超过1200页。同事们查询某个问题时要么翻半天目录要么在文档里CtrlF碰运气。更麻烦的是很多问题答案分散在不同的文档里比如重要数据出境需要走什么流程可能要同时参考分类分级指南、安全管理办法、审批流程三个文件才能拼出完整答案。这就是典型的非结构化知识应用场景。当时有两条路可以选要么做一套传统的关键词检索系统要么上用RAG检索增强生成架构的智能问答。传统检索看起来简单但治理类问题的特点是问法灵活、答案分散、依赖上下文比如客户信息属于几级数据和哪些个人信息要脱敏本质上是同一个知识点传统检索很难识别这种语义关联。最终我选定了基于RAG的方案具体平台用了Dify。原因也很直接Dify把文档解析、向量化、分段、检索、大模型调用这些环节都做成了可视化配置不需要自己从零搭建向量数据库和检索链路。对一个偏治理业务背景、又不是专职算法团队的组来说这是最快能落地的路径。但这篇文章不打算只讲怎么点按钮。我想把从文档清理、分段策略、应用编排到参数调优的完整过程都说清楚尤其是一些常规教程里不会写的坑。如果你正准备给团队搭一个数据治理知识库或者想验证RAG在企业文档场景下到底行不行这篇应该对你有用。2. 建库前的准备工作文档筛选与治理语料清洗很多人拿到Dify就急着建库上传结果做出来的问答效果惨不忍睹。我踩过这个坑后来总结出一句话RAG的上限由语料质量决定向量化只是把语料原本的质量呈现出来。2.1 治理类语料有哪些选哪些进库数据治理相关的文档大体分四类制度规范类管理办法、实施细则、分类分级标准、考核办法。这类是问答的核心语料几乎90%的问题答案都在这里。流程操作类审批流程说明、系统操作手册、应急预案步骤。答案往往强依赖流程顺序分段时要特别小心。模板表单类登记表、审批单、检查表。这类通常不需要全文入库只把填写说明和适用场景抽出来就好。会议纪要、汇报材料时效性强容易和现行制度冲突。除非有明确的已生效标记否则不建议进库。我第一次建库时贪多把1200多页一股脑传上去。结果问数据分类分级的流程时模型同时召回了两年前会议纪要里的旧流程和今年的正式制度回答里出现两个互斥的版本。后来清理掉非正式文档准确率立刻上来了。所以筛选语料时坚持一个原则只放当前有效、有明确权威性、表述稳定的文档。拿不准的宁可不放。2.2 清洗与命名规范文档清洗这块我建议按照下面几步操作统一格式所有文档尽量转成PDF或DOCX。扫描件要先做OCR。Dify本身能做一定的文档解析但扫描版的表格识别率真的不稳定。去水印和页眉页脚很多制度文件的页眉带有部门名称和版本号如果不处理分段时会产生大量重复片段检索时容易拉偏。去掉修订痕迹拿的是带修订标记的Word版本建议先接受所有修订再导出。统一命名规则我采用的命名格式是编号-类别-名称-版本号例如GR-制度-数据分类分级管理细则-V3.2。这个习惯很有用检索调试时能直接看出答案来自哪个版本的哪份文件。这里要给一个具体的教训有一份《数据安全管理办法》正文里嵌入了一个矩阵图图的文字部分提取之后完全乱序。某次回答存储敏感数据需要满足哪些安全要求时模型把矩阵图里的一列错误当成完整条目引用。处理方式是把这类图表单独截图在文件里加一段说明文字再重新上传。2.3 文档格式与扫描件的处理治理文档里常见两类特殊文件一类是盖章扫描件另一类是带大量表格的Excel制度清单。扫描件我强烈建议先做OCR再入库而且OCR之后要人工抽查关键页。数据治理项目里反复出现的数据分类分级清单经常是扫描版表格OCR出来的内容列错位、单元格合并丢失都很常见。抽查的时候重点看数字、级别名称如核心数据重要数据一般数据这类关键字段对不对。表格类的Excel呢如果只是简单清单可以直接入库但如果单元格里嵌套了说明文字最好拆分成带上下文的文本说明。我在这个环节花了两天时间。有一天半在做清洗和抽查真正在Dify里建库反而只用了半天。这个比例并不夸张。3. Dify知识库创建流程模型选择与分段策略语料准备完毕后进入Dify的操作环节。知识库的全流程其实是四件事创建知识库、选嵌入模型、设分段规则、上传文档。每一步都有讲究尤其后两步直接决定检索质量。3.1 从零创建一个知识库在Dify的知识库页面点击创建知识库给这个库起名比如数据治理制度库-生产环境。注意Dify允许把多个知识库关联到同一个应用所以我建议按主题拆库制度库放管理办法、细则、标准流程库放审批流程、操作手册模板库放各类登记表说明拆库的好处是检索时范围更聚焦关联到应用时可以按权重控制哪个库优先。一个超大混合库对RAG而言往往意味着更多误召回。下一步是选择嵌入模型。这块我单独说。3.2 嵌入模型怎么选嵌入模型负责把文本转换成向量。知识库检索的匹配效果如何一半靠它。当时我对比了三类选择Dify系统内置的默认模型、单独配置的商用嵌入模型、还有开源部署方案。判断标准有三条中文效果、维度成本、上下文长度。这里有一个容易忽略的细节嵌入模型本身也有上下文长度限制。如果你分段后每段只有300字那大部分嵌入模型都够用但如果你用母子分段模式把父段设成2000字就必须确认嵌入模型支持这个长度否则超长部分会被截断向量表示就不完整。我们在实际项目中最终选了一款中文效果比较稳的商用嵌入模型它的最大输入长度能覆盖到较大的分段粒度。考虑到这是入门系列我的建议是先用Dify默认提供的模型把流程跑通后续再迭代替换。不要一开始就在模型选型上内耗更重要的是把分段和检索参数调好。3.3 分段设置里的几个关键参数创建知识库时Dify会让你设置分段模式常见的有自动分段和自定义分段里面涉及几个参数分段标识符默认按换行符分段。治理制度文档常常有条目编号例如3.2.1可以考虑增加编号前缀作为分段依据。最大分段长度默认是500个字符左右token数视版本。这个值决定了每一段文本的粒度。分段重叠长度相邻分段之间共享的部分。不设置重叠的话一个知识点恰好落在两个分段结合部时检索会丢信息。以《数据分类分级管理细则》为例制度条文通常是一个条款一个主题。如果最大分段长度设得太小比如200一条完整的重要数据判定标准会被拆成两段提问时只召回前一半答案就会残缺。我后面会专门做一组切分实验说明这个问题。另外Dify有一个索引方式选项常见的是高质量向量索引和经济型索引。我第一次建库时选了经济型想着省资源结果检索召回率明显差。后来又重建了一次。如果你的场景是制度问答这种对准确性要求高的别在经济型索引上省。4. 分段实测制度文件切割的三次实验与结果对比分段是整个RAG链路里最容易被低估的环节。同一份PDF换一种切法回答质量可以天差地别。我拿《数据分类分级管理细则》做了组对照实验把过程和结论完整记录下来。4.1 实验场景与测试问题集测试文件是一份16页的细则内容包括总则、分类分级原则、数据类别定义、级别判定标准、职责分工、附则六章全文约1.2万字。测试问题准备了5个尽量贴近真实使用场景个人信息属于哪个数据类别如何定级核心数据的访问控制要求是什么谁负责数据分类分级的复核工作数据定级之后多久需要重新评估一般数据需要做脱敏处理吗每个问题的答案都分布在文件的特定条款里。不同分段模式下对比标准是能否召回包含完整答案的那一段。4.2 三次切分的结果对比实验一共做了三种配置第一次Dify自动分段最大长度默认值500无重叠。这种模式把文件按自然段落切分。结果5个问题里问题2和问题5能稳定答对。问题3涉及职责分工答案段落比较短检索时被其他段落带偏答错了。问题4的重新评估周期恰好卡在两个分段的边界中间两个分段各含一半信息模型拼接时张冠李戴。第二次自定义分段最大长度提高到800重叠长度设为80并且把第X条识别为分段标识。这次切分基本保证了每条制度条文独立成段。5个问题的召回全部正确回答质量明显上升。问题4的边界问题因为重叠的存在而被解决两个相邻分段都包含12个月评估一次的关键信息。第三次特意做了一次反向实验最大分段长度压到200重叠设为0。结果问题1和问题3失败——个人信息定级标准被拆成三段提问时只召回了中间一段模型给出的答案不完整甚至把重要数据的判定标准张冠李戴到个人信息上。4.3 治理文档的分段经验总结结合实验我对治理制度类文档的分段建议是优先按条款切分制度文件天然以条为逻辑单元把分段标识符设置为第X条或编号模式是效果最稳的方案。分段长度宁大勿小治理文档的条款通常300到600字留出余量设到800到1000都比较安全。太短会导致语义单元被截断。重叠长度设50到100cost很低但可以显著降低边界切割带来的召回流失。表格和列项较多的文档谨慎使用纯换行符分段。表格里每一行都可能被单独切成碎片。这是我做RAG项目以来收获最大的一组测试。原因很简单切分策略不花钱但收益立竿见影。多数人第一次做知识库效果不好问题大概率出在分段而不是模型。5. 应用编排与检索调优让知识库真正听懂治理问题知识库建好后要把它挂到应用里才能问答。这一步看起来简单但编排方式和提示词的写法对回答质量的影响很大。5.1 创建对话应用并关联知识库在Dify的工作室里创建应用类型为聊天助手然后在上下文配置中添加知识库。这里有一个关键选择知识库可以设置召回策略。Dify支持多路召回和模型引用我建议先把模式设为多路召回再手动调优不要直接依赖模型自行选择知识库。关联完知识库还需要在提示词区域编排系统提示词。我的编排思路分三层角色定义说明这是一个数据治理制度问答助手只依据已入库制度文件回答。回答要求必须标注答案出处引用文件名和条款编号无法从知识库找到答案时明确说不知道不许编造。处理边界对于涉及具体处罚、法律责任的敏感问题提示模型引用原文条款不做主观扩展。具体的提示词示例简化版你是一个数据治理制度问答助手。请仅基于提供的文档内容回答用户问题。 回答要求 1. 引用具体条款时请标明来源文件名和条款编号。 2. 如果文档内容不足以回答直接回答“根据当前知识库内容无法确认”。 3. 对分类分级判定类问题请先复述判定标准再给出结论。 4. 不要讨论文档内容之外的话题。5.2 提示词里的上下文约束实际调试中我发现提示词里关于引用出处的要求不能太笼统要写清楚格式。比如《数据分类分级管理细则》第12条。如果不限定模型有时会生成一个模糊的根据公司制度无法追溯这在数据治理场景里是不可接受的。另外要约束模型的过度服务倾向。治理类问题通常会触发模型拼命给建议哪怕文档里没依据。我在提示词里加了一条不要补充知识库之外的操作建议。加上之后回答的合规性明显改善也更容易发现语料本身的缺口——模型不编了缺什么就暴露什么。5.3 召回参数调优记录应用侧有几个检索相关的参数Dify通常在知识库设置里可以调TopK召回的分段数量。默认可能是3或4。治理问答场景下我建议从3开始。如果回答缺上下文就调高到5如果经常答非所问就调低到2。Score阈值低于一定相似度的结果不展示。这个阈值要结合你的嵌入模型实际分数分布来看。我在调试时打印了测试问题的召回分数发现正确片段的分数普遍在0.35到0.5之间而无关片段在0.2以下所以把阈值设在0.3附近比较合理。Rerank开关打开Rerank可以对召回结果重新排序。如果只用向量相似度偶发会出现语义相近但答案不对的片段排到前面。加上Rerank之后这类情况减少很多但会增加一点响应延迟。调试时建议专门准备一份黄金问题集每次改动参数之后都用同一组问题回归测试。我那个问题集就是上一节里的5个问题后来又补到了15个覆盖了分类分级、流程审批、权限要求、应急响应等常见场景。没有这个问题集调参就变成了碰运气。6. 上线后的真实踩坑排查格式陷阱、切分边界与召回空白流程跑通、demo演示顺利不代表生产环境没坑。知识库上线后前两周我至少处理了三个典型的线上问题。这里的排查过程非常有代表性分享出来供参考。6.1 表格和图片条款的提取失败第一个线上问题是业务同事问数据资产登记表的必填项有哪些知识库答非所问。排查时我先在Dify后台的文档列表里找到对应文件点击预览解析结果发现登记表对应的表格整块被解析成了无结构的文本行列名和填写项完全分不开。原因很明确上传的是某个系统导出的带格式表格文件Dify解析时把它当成普通文本处理了。解决方案是第一步做文档预处理时就把该表格重新整理成结构化文本必要时补充一段登记表必填项包括数据名称、数据类别、所属系统……的说明文字放进文档里。改完之后重新上传该问题解决。6.2 分段把制度条款拦腰截断第二个问题是重要数据的定义是什么答得不完整。我打开知识库的分段预览发现《分类分级指南》重要数据定义这一段因为包含了一个很长的枚举列表被自动切成了三段其中枚举列表的第二段缺失了。这个坑的根源是我在分段参数里虽然设置了按第X条分段但部分条款内部很长没有子标题Dify只认换行符结果在一个条款内部的列表项之间就切断了。改进办法把这一份文件单独用自定义分段处理在关键的枚举列表前后手动添加分隔符确保整条定义完整在同一个分段内。这也是为什么我强烈建议建库时先选1到2份核心制度做试切在分段预览里人工翻一遍再决定是否批量上传其他文档。6.3 召回为空时的排查链路最让人头疼的问题是用户问了一个明确该有答案的问题知识库却完全没召回任何内容。我排查过三次总结出如下链路先确认文档真的包含答案。用关键词在原文里搜索如果原文就没有那问题出在语料缺失而不是RAG参数。确认分段没问题。查看分段预览答案是否落在一个完整的分段里还是被切碎甚至丢失。打印检索分数。在Dify的日志里查看应用实际召回的分段和相似度分数。如果正确分段的分数低于阈值考虑降低阈值或换嵌入模型。如果召回内容正确但回答错误那是大模型推理或提示词问题和检索无关需要调整提示词。比较典型的一次是数据提供方需要承担什么责任这个问题原文里有明确条款但召回为空。排查发现该条款所在的页面是扫描图片OCR后的文本质量差嵌入后的向量和用户问法匹配度太低。后来重新提取文本、修复扫描页问题解决。数据治理知识库的维护是持续性的。制度修订后要有版本替换机制旧版本要下架而不是堆在库里。我在Dify里把知识库命名为生产环境-当前有效每次制度更新就新建一个版本库验证通过后把旧库停用。这套流程虽然土但非常可靠。如果你正准备动手我的建议是先挑一份最核心的制度文件花半天时间把清洗分段做到极致跑通端到端问答再逐步扩库。RAG项目的成败从来不是模型决定的而是你对语料的理解深度决定的。