1. 数据治理文档堆成山之后，我为什么转向RAG方案
干过数据治理项目的朋友应该都有同感：真正难的不是写制度，而是让制度"活"起来。某集团几千页的数据治理制度、分类分级标准、数据资产盘点规范、应急响应预案，全都躺在共享盘和知识库里，平时没人看，真到用的时候又找不到。
我接手这个项目时，第一件事就是整理这些文档。统计下来光是《数据治理管理办法》《数据分类分级指南》《数据质量管理细则》《数据安全应急响应预案》这类核心制度就有47份，加上各类模板、操作手册、会议纪要，总量超过1200页。同事们查询某个问题时，要么翻半天目录，要么在文档里Ctrl+F碰运气。更麻烦的是，很多问题答案分散在不同的文档里，比如"重要数据出境需要走什么流程"，可能要同时参考分类分级指南、安全管理办法、审批流程三个文件才能拼出完整答案。
这就是典型的非结构化知识应用场景。当时有两条路可以选：要么做一套传统的关键词检索系统，要么上用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到100：cost很低，但可以显著降低边界切割带来的召回流失。
- 表格和列项较多的文档：谨慎使用纯换行符分段。表格里每一行都可能被单独切成碎片。
这是我做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项目的成败从来不是模型决定的，而是你对语料的理解深度决定的。
