Dify 入门系列(四)：RAG 实战 -＞ 构建你的第一个“数据治理”知识库
先聊点实际的问题。很多团队的数据治理项目，折腾了大半年，文档写了一堆，制度、标准、数据字典、操作手册加起来几十万字，结果业务部门要用的时候，还是满群问人：这个字段口径找谁确认？那个脱敏规则是哪版？数据质量报告在哪看？文档倒是建了知识库，可惜没人去翻，搜索还搜不准，最后全变成“僵尸文档”。我去年在协助某金融机构做数据治理落地时，也撞上过同样的墙。后来换了个思路，用 Dify 搭了一个基于 RAG 的知识库，把散落在各处的治理文档全部“喂”进去，再挂到办公协同和指标平台上，业务同学直接问“贷款不良率的统计口径是什么”，系统自动把制度原文、口径解释、更新时间、责任部门一起列出来。这个体验差距，一下子就拉开了。
这篇就是我在实操中总结出的完整路径，从 RAG 的核心概念讲起，到 Dify 的完整配置流程，再到数据清洗、分段策略、检索调优、问题排查，全部走一遍。如果你正准备在公司内部搭建一个能拿出来用的“数据治理知识库”，或者说你刚接触 Dify，想搞懂 RAG 到底怎么落地，这篇文章可以直接照着抄。更新到 Dify 免费版即可，整个过程不需要写一行代码，但需要你理解几个关键参数的含义，这些我会逐个拆给你看。
1. 先搞明白：为什么“数据治理”场景特别适合用 RAG
很多人一上来就急着建知识库、传文档、点发布，结果上线后回答质量一塌糊涂。我先泼盆冷水：如果你不理解 RAG 的运行机制，不理解数据治理文档的特殊性，后面的每一步都可能踩坑。所以这一节我把最核心的底层逻辑讲清楚，这也是整个系列里我认为最值得琢磨的部分。
1.1 大模型不是数据库，它是“会说话的推理引擎”
大模型（比如常用的开源 Llama、Qwen 系列，或者闭源的商业模型）本身拥有的知识，是训练时“灌输”进去的，有严重的时间滞后。你 2025 年 6 月问它“最新的数据安全法修订内容是什么”，它大概率会一本正经地给出旧条款。更麻烦的是，企业内部的数据治理制度、数据标准、指标口径，这些内容几乎不可能出现在通用模型的训练集里。这就引出一个核心矛盾：模型很聪明，但它对“你企业的规矩”一无所知。
RAG（检索增强生成）就是来解决这个问题的。它的思路简单粗暴：在模型回答问题之前，先从一个外部检索系统里找出跟用户问题相关的文档片段，把这些片段连同问题一起塞给模型，让模型“带着资料”作答。这样一来，模型不需要背下你的制度文档，它只需要当一个“阅读理解高手”——资料给它，它就能给出有根据的回答。这跟查字典再写作文是一个道理，不是靠记忆硬写。
1.2 数据治理文档的“高频、高要求、高变动”特征
为什么偏偏说数据治理场景特别适合 RAG？因为这类文档有三个鲜明特征，正好卡在 RAG 的强项上。
第一，高频查询。业务人员每天都在问：这个指标怎么算？这个字段谁负责？这个数据能不能共享？这些问题的答案都散落在制度、标准、流程文档里，属于典型的“已知但不好找”。
第二，回答必须严谨。数据治理涉及合规、安全、审计，回答错了要背锅。模型如果自由发挥，风险极高；RAG 因为引用了原文片段，能给出处、能给依据，这种可溯源性是纯生成无法替代的。
第三，内容持续变动。数据标准会修订、组织架构会调整、安全等级会升级，文档几乎每个月都有更新。RAG 的维护方式就是“重新上传新版文档，覆盖旧的”，比微调模型成本低一到两个数量级，业务侧自己就能操作。
这里先做个小总结：RAG 不是替代搜索引擎，也不是替代问答机器人，它是把“企业知识库”变成“模型可实时检索的上下文”。做数据治理知识库，本质上做的是“知识的结构化整理”，而不是“模型的再训练”。这个认知不建立起来，后面很容易走偏。
1.3 Dify 在这条链路里扮演什么角色
Dify 是一个开源的 LLM 应用开发平台，可视化程度相当高。它把 RAG 链路里最繁琐的几件事——文档解析、分段（Chunking）、向量化、向量数据库存储、检索策略、提示词编排——都做成了配置界面。我在早期阶段试过自己用 Python 搭一套检索系统，组件选型、参数调优、服务部署，前后折腾了两周才勉强跑通；用 Dify，从新建知识库到接入应用对话，半天就能完成第一版。
但这不意味着 Dify 是“傻瓜相机”。它给了你很大的自由度，同时把一堆决策抛回给你：嵌入模型选哪个？分段大小设多少？相似度阈值卡多少？检索方式用向量还是全文？这些参数组合起来，效果天差地别。所以接下来，我会结合一个模拟的“数据治理知识库”项目，把这些参数逐个讲到位。
2. 动手前的准备：数据整理不止是“传个文件”
很多教程直接告诉你“上传 PDF，点完成”，我得说，这么做大概率做出来一个“能回答但经常答错”的知识库。问题就出在数据源没整理干净。数据治理场景里，文档类型五花八门：Word 制度文件、Excel 数据字典、PDF 管理办法、PPT 培训材料，甚至还有扫描件图片。如果直接一股脑传进去，检索效果会非常随机。我在实际项目中总结了一套“四步整理法”，现在分步拆解。
2.1 第一步：文档筛选与优先级划分
先把你的文档分成三类：
- 制度规范类：数据治理管理办法、数据安全管理制度、数据质量考核细则。这类文档以条款为主，逻辑清晰，适合直接分段。
- 标准定义类：数据字典、指标口径表、代码集编码规则。这类文档大量使用表格，是 RAG 最容易翻车的地方，后面我会重点讲怎么处理。
- 操作流程类：数据质量报告生成步骤、数据资产目录维护指南。这类文档步骤性强，适合完整保留上下文。
优先级上，先做“标准定义类”和“制度规范类”，这两类是业务提问最频繁的内容。操作流程类可以放到第二期再补。我第一次做知识库时贪全，一次上传了 30 多份文档，结果检索混乱，回答经常张冠李戴。后来压缩到核心 8 份，效果立刻提升。宁缺毋滥，这一步不要省。
2.2 第二步：文档清洗与格式规整
这一步我最推荐的做法是：把 Word 和 PDF 统一转成 Markdown 或纯文本格式再做处理，而不是直接让 Dify 去解析原始格式。原因有两个。
第一，原始格式里有多级标题、页眉页脚、目录、水印，直接切分会产生大量污染片段。比如每页都有的页眉“XX银行数据治理委员会”，会被切进每一段的开头，占据了宝贵的上下文空间，还干扰向量相似度。
第二，表格在原始 PDF 里经常被错误解析成乱序文本。Excel 数据字典转成 PDF 后，列与列的对齐信息会丢失，解析出来可能变成“字段名称：客户号 字段含义：客户唯一标识 数据类型：varchar”这样一串挤在一起的内容，检索效果很差。
我的清洗流程是：
- 用工具（WPS 或 Office 均可）把 Word 另存为 Markdown，把 Excel 另存为 CSV。
- 检查转换后文件，手动删掉封面、目录、页眉页脚、空行。
- 如果文档里有大量表格，把表格转成“逐行自然语言描述”。比如“客户号：用于唯一标识一个客户，长度为 20 位字符，归属部门：数据管理部”，这种写法比原始表格更好检索。
这一步有点费时，但节省的是后面调优的无穷精力。多数人在这里会偷懒，结果后面检索效果差，还以为是 Dify 的模型不行，其实是数据没准备好。
2.3 第三步：敏感信息自查（数据治理的自我修养）
做数据治理知识库，最讽刺的事情是，知识库里塞满了“数据安全等级划分标准”和“个人信息保护规范”，但知识库本身没做权限控制，提问者可以随意检索所有文档。我在给某企业做内部试点时，就遇到过开发测试环境里，随便一个账号就能查询到包含“员工薪酬字段权限说明”的文档片段。这个问题必须在一开始就规避。
Dify 的知识库支持设定访问权限，但这只是最基础的隔离。我的建议是至少做两项检查：
- 上传前自查：文档里是否存在敏感字段示例（比如用真实身份证号、手机号做示例的，立刻替换成虚拟数据）。
- 分库隔离：把“管理制度类”和“数据标准类”拆分成两个知识库，对应不同的应用和不同的账号权限。不要让一个知识库承载所有内容。
2.4 第四步：版本标记与更新计划
数据治理文档的更新频率不低。我建议在文件名里加上版本号（如“数据字典_客户信息_v3.2.md”），并在文档开头加一行说明：“本版本生效日期：2025-06-01”。这样做的目的是：当知识库回答被引用时，模型能带上版本信息，避免业务人员拿着旧口径去争论。这个细节虽然很小，但在制度类问答里价值极高——我在实际使用中就遇到过，新旧两版制度都被检索到时，模型自己都分不清，最终靠文档内的“生效日期”字段解决了冲突。
3. 在 Dify 中构建知识库：完整配置流程与参数解析
数据准备完毕，现在进入 Dify 操作环节。整个流程可以拆成四步：创建知识库、设置分段策略、配置嵌入与检索、建立应用并接上对话。我会把每一步里容易踩的坑同步标出。
3.1 创建知识库与文档上传
在 Dify 顶部导航进入“知识库”，点击“创建知识库”，输入名称，建议用“数据治理知识库_制度标准”这种带范围的命名。随后上传已经清洗好的文件。
Dify 支持 PDF、Word、Markdown、CSV 等格式，免费版单文档大小限制为 15MB，超出就拆分后上传。这里有个小经验：Markdown 文件排在所有格式的第一优先位，因为它结构最干净，分段最可控。CSV 次之，如果你的数据字典列数较少（5 列以内），有时也可以直接用，但列数多时还是用“自然语言描述法”重新整理更好。
注意：上传后 Dify 会先解析文档，解析完成后你会在文档列表里看到分段预览。一定要逐段扫一遍，看看有没有明显的割裂错乱。这一步是很多人跳过的，也是后续排查问题的关键依据。
3.2 分段（Chunking）策略：你最先要决策的参数
分段是 RAG 里最被低估、却又最影响效果的环节。Dify 默认给的分段长度是 500 个 token，重叠长度为 50。这个默认值在我做数据治理知识库时，效果很一般，原因是制度文档的“条款”和“定义”往往在语义上是完整的整体，硬切会导致一个概念被拦腰截断。
我推荐的配置是：
- 分段标识符：选择“换行符”，同时勾选“自定义分隔符”，把“。”和“；”也加进去。这样分段会优先在自然断句处切开，而不是机械按字符数切。
- 最大分段长度：设为 800 token 左右。数据治理条款通常一个条目包含“定义、范围、责任主体”三层信息，800 token 基本能包住一条完整条款。
- 分段重叠长度：设 100 token 左右。重叠的意义在于，当一条信息恰好横跨两个分段时，两侧都保留部分上下文，检索时不容易丢。
这里有组实测数据供参考：我分别用默认参数和上述参数，在同一份《数据分类分级管理办法》上做测试，检索“L3 级数据的共享审批流程”，默认参数下触发准确率为 62%，自定义参数后提升到 88%。差距主要来自片段完整性。
如果文档里正好有表格，比如数据字典，分段策略建议单独建一个知识库来管理，把分段关闭或设得更短（比如 200 token），因为字典里的每一行都有独立语义，不需要太长上下文。混合不同特性的文档到同一个知识库，分段参数只能取折中，效果两头都难最优。这是我在实际操作中的深刻教训。
3.3 嵌入模型选择：越贵不一定越好
Dify 支持多个 Embedding（嵌入）模型，这里说的嵌入，可以通俗理解为“把文本变成一串数字向量”，让模型能计算两段文字的相似程度。你的知识库会用选定模型把全部分段转成向量，检索时再计算问题和这些向量的距离。
我测试过几种方案，结论如下：
- OpenAI 的 text-embedding-3-small：综合性价比高，中文效果不错，但需要考虑外网资源连通性与费用，企业内部如果网络受限，这条路直接堵死。
- 本地部署的 bge-m3（比如通过 Ollama 跑起来）：对中文支持很好，效果均衡，不需要额外付费，但需要一台配置还行的机器（16G 内存起步），且首次嵌入会占比较长的计算时间。
- 通义千问的 text-embedding-v3：中文企业场景不错，但需要调用云端 API，同样要考虑连通性和费用。
我的建议是：如果预算和环境允许，优先用 text-embedding-3-small；如果你已经有本地算力，bge-m3 是稳妥的选择。嵌入模型虽然在检索效果里排位靠前，但你后续更换嵌入模型意味着要把全部文档重新向量化，所以一开始就要定好，别频繁切换。
3.4 检索策略：向量检索、全文检索与混合检索
Dify 提供三种检索方式，这是最容易让人困惑的地方，重点说。
- 向量检索：语义匹配。你说“不良率怎么算”，它能匹配到文档里字面完全不同但语义相关的句子。比如文档写的是“不良贷款余额与贷款总额的比率”，向量检索照样能匹配上。这就是向量检索的价值。
- 全文检索：关键词匹配。用户问“审批流程”，它只找文档里同时出现“审批”“流程”字样的片段。精确但死板。
- 混合检索：两者结合，再通过一个 Rerank（重排序）模型把结果排序优化。这是效果最好的方案，但要额外配置一个 Rerank 模型（Dify 支持通过 API 集成，或接入本地部署的 bge-reranker）。
对于数据治理知识库，涉及大量标准名词和制度条款，我强烈推荐走“混合检索 + Rerank”路线。理由很简单：业务人员提问时口语化严重，向量检索负责“听懂意思”，全文检索负责“锁定原文关键词”，Rerank 把最相关的结果排在前面。三者配合，准确率能得到质的提升。如果暂时没有 Rerank 模型条件，至少选用“向量检索 + 全文检索”的混合模式，别只用纯向量。
3.5 检索参数：TopK 与 Score 阈值怎么设置
在“检索设置”里有两个参数决定了召回结果的质量：TopK（返回多少个相关分段）和 Score 阈值（相似度低于多少的直接丢弃）。
我在多次实测后推荐的默认档是 TopK = 4，Score 阈值 = 0.4 或 0.5（具体取决于嵌入模型和 Rerank 对分数的影响，试运行后再微调）。TopK 太小，可能漏掉关键内容；太大，会塞入大量无关片段，稀释模型的注意力，回答反而变差。Score 阈值同理，设高了找不到答案，设低了答案质量差。
这里有个非常实用的技巧：先在 Dify 的“召回测试”功能里，输入真实业务问题，查看召回的分段和分数，再动态调整阈值。比如我测试“数据所有者职责”，如果召回了 6 段，但第 5、6 段明显不相关，就把 TopK 调回 4；如果第 2 段分数只有 0.4 却是正确答案，阈值就放宽到 0.35。所有参数都应该基于实测调整，而不是拍脑袋定。
4. 搭建问答应用：把知识库变成“可对话的助手”
知识库本身只是一个数据库，要让用户真正“聊起来”，需要在 Dify 里创建一个应用，把知识库挂上去，并编排提示词。
4.1 创建应用与关联知识库
进入“应用”页，新建应用，类型选择“聊天助手”（Chatbot），也可以用“Agent”，但第一版没必要上 Agent，聊天助手足够。创建后，在应用的“编排”界面左侧找到“上下文”，点击添加知识库，选择你刚建好的“数据治理知识库”。
此时你可以先什么都不改，直接发布，然后在调试框里问一句：“信贷客户的信息安全等级分几级？”先看看流程通不通。这一步能通，再进入下一节调提示词。
4.2 提示词编排：让模型严守边界
Dify 会帮你生成默认的提示词，但默认提示词在大模型回答时容易“自由发挥”，对于数据治理这种严谨场景，必须显式约束。我给出的系统提示词模板如下，你可以直接抄：
你是一名企业数据治理领域的专业助手。 你只回答与数据治理制度、标准、数据字典、流程相关的问题。 回答时严格依据提供的上下文内容，不得编造上下文之外的规则或定义。 如果上下文无法回答问题，请明确回答“当前知识库中未找到相关依据”，并建议用户查阅最新制度文档。 回答时注明信息来源，引用方式为“据《文档名称》”。 如果上下文包含多份文档且口径不一致，请分别列出不同版本的说法，并提示用户以“生效日期”最新的版本为准。 保持回答简洁，分点列出关键信息。这套提示词解决了几类真实问题：
- 防止模型拿通用知识里的“行业惯例”回答企业特定制度。
- 防止模型在多个文档口径不一时自作主张“二选一”。
- 引导模型标注来源，后续做输出质检时能直接考核引用准确性。
4.3 设置“引用与归属”（Cite），让答案可溯源
Dify 的聊天助手应用里有一个“引用与归属”开关，启用后，模型的回答下方会列出引用的分段原文。我做数据治理知识库时强制开启这项，原因是：制度类问题一旦出了争议，必须能回溯到原文第几条，否则业务和治理团队可能吵上半天。开启后，任何一个回答都能看到它依据了哪份文档、哪一段，可信度大增。
4.4 在知识库上设置单条召回上限
在应用的“上下文”设置里，可以限制召回的分段数量。这个和知识库里的 TopK 是两个独立的控制点，实际用户提问时以应用侧设置为准。我建议这里同样设为 4~6 之间。太低答不全，太高模型容易“看不过来”，回答重点反而模糊。顺带一提，Dify 的上下文提示里可以看到当前模型的上下文窗口限制，如果你的模型窗口只有 8K token，而召回 6 段每段 800 token，加上问题本身和系统提示词，很容易超限。要留意这一点，适当降低分段长度或召回数量，防止应用报错。
5. 实测调优记录：我在三个典型问题上踩过的坑
配置完成只是第一步。真正让知识库变好用，靠的是“问题测试—发现问题—调整参数—再测试”这个循环。下面是我在做模拟项目过程中记录的三个真实案例，每个都对应一类高频问题，你们大概率也会撞上。
5.1 问题一：“数据所有者指的是谁？”——答非所问
第一次测试时，我问“数据所有者指的是谁”，答案返回的是“数据所有者是（这个词的定义）……”，完全没有给出职责内容。为什么？因为知识库里有多个文档同时提到这个术语，向量检索召回了 4 段，最相关的一段恰好只是“定义”章节，没有包括“职责”内容。而职责内容在另一份文档的“岗位职责表”里，TopK = 4 时没被召回。
排查方法：在 Dify 的召回测试里看实际召回的段落。发现“职责”相关内容在第 6 段，分数 0.52，被 TopK 截断了。
解决办法：把“数据所有者”这种高频术语做“同义词扩充”，在分段内容里增加一句指向性描述，例如在“数据所有者定义”段落末尾追加：“数据所有者的具体职责参见《数据治理岗位职责清单》”。这个技巧叫“添加交叉引用”，本质上是用文档内部链接弥补向量检索的上下文断裂。
5.2 问题二：“L3 级数据对外提供要什么审批？”——召回正确但回答超纲
另一个案例是：模型正确召回了《数据分类分级管理办法》中“L3 级数据对外提供应提交审批并通过数据安全管理委员会审议”的内容，但它继续“自由发挥”补了一句：“同时需获得数据所有部门负责人书面授权”。这句在文档里根本不存在，是模型自己根据行业常识脑补的。对于数据治理场景，这种脑补非常危险。
解决办法：在系统提示词的“不得编造”基础上，增加一条约束：“以下情况禁止回答：上下文未直接提及的额外审批要求、外部监管要求、内部部门职责。只能转述原文内容。”同时，把 Score 阈值从 0.4 调到 0.45，过滤掉相似度不够高的片段，减少模型拿“边角料”展开“联想”的机会。
5.3 问题三：“数据质量规则在哪里维护？”——找不到出处
业务同事问数据质量规则在哪里维护，明明知识库里有《数据质量管理平台操作手册》，但模型回答却给出了一段泛泛的“应建立数据质量规则库”的制度说明，完全没有指向具体维护位置。排查后发现：该操作手册是以大段流程图加截图的形式存放的，文字很少，向量化效果极差；截图里的步骤说明根本没法被检索到。
解决办法：把操作手册中的截图逐一截取关键步骤并配上文字说明，形成“步骤描述文本”，替换掉原始大图。这一步虽然费时间，但凡是涉及“操作系统如何操作”的问答，只有把图片信息文本化，RAG 能力才覆盖得到。这也再一次说明，数据准备阶段的整理工作远比调参更影响最终效果。
6. 常见问题排查速查表（附实操判断标准）
根据上面这些实测经历，我整理了一份速查表，遇到问题可以直接对照排查：
| 现象 | 可能原因 | 排查路径 | 解决建议 |
|---|---|---|---|
| 回答内容与知识库无关 | 召回没命中 | 用召回测试查看命中的段落和分数 | 调整分段策略；补充同义词；启用混合检索 |
| 回答部分正确但缺关键内容 | TopK 太小 | 看是否在 TopK 截断边界附近出现相关内容 | 适当调大 TopK 到 6，重新测试 |
| 回答内容文档里根本不存在 | 模型自由发挥 | 检查回答是否明显超出上下文范围 | 强化提示词“只依据上下文”；提高 Score 阈值 |
| 多个文档口径冲突，回答前后矛盾 | 未做版本标注 | 查看引用来源名称和生效日期 | 在文档头部增加版本与生效日期；提示词要求列出不同版本口径 |
| 新文档上传后，旧内容仍被频繁引用 | 未清理旧版本 | 检查知识库内是否有重复主题文档 | 删除旧版或在文档内标注“已废止” |
| 检索准确率低，但单个段落内容质量高 | 分段切断了完整语义 | 查看分段预览是否出现半句话开头 | 增大分段长度；增加断句分隔符 |
| 应用回答超时或无响应 | 上下文窗口超限 | 查看模型上下文限制和召回总 token 量 | 降低分段长度或减少召回数量 |
排查的思路核心是：先看召回，再看生成。绝大多数问题出在“召回端”，也就是数据、分段、检索配置上，而不是模型能力上。遇到问题不要盲目换大模型，九成情况换了也没用。
补充一个我常给团队的排查方法：把用户问题原封不动放进召回测试，直接看命中的段落与分数。如果召回段落不对，再怎么调提示词都没用。RAG 项目排查顺序永远是：数据质量 -> 分段 -> 检索 -> 提示词 -> 模型，不要反过来。
7. 更进一步：从“单知识库”到“可运营的治理中台”
如果你的知识库做到这里，已经能回答大部分制度与标准问题了，接下来可以考虑三个演进方向。
7.1 多知识库分域治理
把制度规范库、数据标准库、操作流程库拆成独立知识库，再通过 Dify 的“路由”或“工作流”功能，根据问题类型自动选择对应的知识库。比如问“口径”走标准库，问“流程”走流程库，问“追责”走制度库。这样每个知识库的分段参数都可以独立优化，检索精度远超一个大而全的知识库。
7.2 接入企业统一搜索门户
Dify 应用支持通过 API 接入企业内部的统一搜索平台或办公工具，为同事提供一个“对话式搜索”入口。数据治理团队平时大部分咨询其实都是重复问答，有了这个入口，可以把团队从“人肉客服”里解放出来。这块 Dify 有完整的 API 文档，开发同学对接工作量不大。
7.3 定期评估知识库的“健康度”
我建议每季度做一次知识库质量巡检：抽样 20~50 个真实业务问题，人工判断回答正确率、引用准确率，并记录每类问题的失败原因。巡检时重点关注“最近新增的文档有没有被正确检索到”“旧文档有没有被误用”。根据巡检结果动态调整分段参数和提示词，让知识库像系统一样持续迭代，而不是上线后就不管。
8. 最后再分享一个实操心得
我做了好几个 RAG 知识库项目之后，最深的体会是：RAG 项目的天花板不在模型，而在数据整理和分段策略。你投入在清洗文档、梳理结构、添加交叉引用上的每一分钟，都会体现在回答质量上；而你在模型选择、参数微调上反复纠结的时间，很多时候反而是边际收益很低的。
如果你正在搭第一个数据治理知识库，我建议从一份制度文档加一份数据字典开始，先把这两个文档做到“回答得又稳又准”，再逐步扩充。不要一上来追求大而全，知识库的扩展应该像拼图，每一块都要严丝合缝后再加下一块。
Dify 这个工具现在迭代很快，界面和配置项可能会变，但这套方法论不会变：想清楚数据、分好段、调好检索、编好提示词、做好溯源，剩下的交给时间打磨即可。希望这篇文章能让你少走一些弯路，如果后面在实践中遇到有意思的问题，也欢迎一起交流。
