Dify 入门系列写到第四篇，终于轮到 RAG 实战了。标题里的“数据治理”我特意加了引号——它不是那种从元数据到血缘再到数据资产的宏大平台，而是我近期基于 Dify 搭起来的一个面向企业内部数据治理场景的知识库。什么是数据治理？就是公司里数据标准、数据质量规则、安全分级、各种口径定义这些事。它们散落在制度文档、会议纪要、FAQ 和一个个 Excel 里，业务人员找不到，规则又天天在变。我把这些材料全部收进 Dify 知识库，再用 RAG 让同事用自然语言提问，系统自动去库里检索片段并生成答案。这个项目做下来，我最大的感受是：RAG 不再是一个只能跑 demo 的概念，而是能真正贴合具体业务域的知识服务形态。
这套东西适合谁参考？如果你手头有一批散落的业务文档、制度文件、操作手册，想快速做一个能回答问题的内部知识助手，而且不想从零去写向量库、调 Embedding、管理召回链路，那 Dify 会是一个非常顺手的底座。我会把从数据准备、知识库创建、参数配置、应用编排到效果调优的全过程，结合我实际踩过和修补过的坑，完整拆开讲一遍。
1. 项目背景与整体思路拆解
1.1 这个“数据治理”知识库到底要解决什么问题
我接触到的这个模拟场景，是一家集团型企业的数据治理推进项目。集团下面有多个子公司，每个子公司都在做制度落地上传、数据标准对齐、质量规则核查。问题在于，真正管数据治理的人只有几个，被问得最多的永远是那几类问题。
第一类是制度查询：比如“数据安全分级管理办法里，第三级数据到底包含哪些字段”。这类问题本质上是查原文，答案必须一字不差，不能模型自己发挥。第二类是口径解释：比如“订单金额到底按含税还是不含税统计”，这类问题散落在各种会议纪要和标准文档里，常常存在前后版本不一致的情况。第三类是整改执行：比如“上个月的数据质量问题整改报告格式是什么，提交给谁”。
这些问题的共同特点是：答案明确、来源固定、但分布散乱。传统做法是查目录、开文档、搜关键字，效率低还得靠人工判断哪个版本有效。RAG 要解决的，就是把“找文档再读文档”变成“直接提问给答案，并且能指出出处”。Dify 在这里的价值，是让我几乎不用写后端代码，就把这套检索增强问答链路跑起来。
1.2 为什么选 Dify 而不是自研 RAG 管线
在动手之前，我认真评估过自研路线的成本。一套标准的 RAG 系统，至少包含文档解析、分段、Embedding、向量存储、Query Embedding、向量召回、可选重排、LLM 生成这么几层。如果完全自己搭，光是对接不同模型、处理不同文档格式、维护向量库的增删改查，就够忙一两周。而且后续还有权限、引用标注、日志追踪这些工程细节，工作量藏在暗处。
用 Dify 则把大部分复杂度收掉了。它在产品层面把 RAG 抽象成“知识库”和“应用”两个核心实体：先建知识库，导入文档，Dify 负责分段和向量化；再建应用，编排检索和模型生成逻辑。中间可视化的流程界面让你能清楚看到数据是怎么流动的，这对后续排查问题特别重要。知识库支持多文档批量导入，应用侧支持召回模式切换、重排模型挂载、引用来源显示，这些刚好覆盖一个内部问答产品的全部刚需。
自研当然也有优点：灵活、可控、能对付千万级文档规模。但就数据治理知识库这个体量——几百份文档、几千个分段——Dify 的甜区恰到好处。我的建议是：先想清楚数据规模、迭代频率、团队维护水平。如果你的场景是中小规模、业务文档为主、希望业务人员也能参与维护，果断用 Dify 起步；如果将来数据量到了百万级文档、需要自定义召回策略和复杂权限矩阵，再考虑迁移到自研或混合架构。第一步最重要的是验证业务价值，不要把工程炫技当目的。
1.3 项目整体架构简析
整个系统的结构，我用文字描述一下，理解了这个后面所有配置才不会懵。离线阶段：原始文档进来，人工做一轮清洗，删掉页眉页脚、重复版本、OCR 错字；然后按文档类型选择分段策略；Dify 将每段文本交给 Embedding 模型转成向量，写入内置向量库；同时 Dify 会保留原始分段文本，供后续引用展示。
在线阶段：用户在应用里输入问题，Dify 先对问题做 Embedding，然后在向量库中做相似度召回，得到一批候选分段；如果启用了 Rerank，再对这批候选做一次精排；之后把排序靠前的分段拼进提示词模板，交给大模型生成答案；最后答案连同引用来源一起返回给用户。
理解这条链路，就能明白 RAG 效果好不好，不只是模型选得好不好，而是每一个环节都可能成为瓶颈。文档没清洗干净，召回就会带噪音；分段策略不合理，语义就被切碎；Rerank 阈值设太高，该召回的内容又被过滤掉。后面每一节，我都是沿着这条链路去讲解的。
2. 数据准备与处理：决定 RAG 效果的上游工程
2.1 先给文档分好类，别急着上传
很多人做知识库，上来就把一堆文档往 Dify 里拖，结果效果稀烂，回头还怪模型不好。我自己的习惯是：先花半天把文档盘一遍，按使用场景分类。数据治理场景下，我大致分成四类。
第一类叫制度规范类，比如《数据安全管理办法》《数据标准管理办法》。这类文档的特点是条款式、结构清晰、条款之间独立性较强，用户提问时经常是直接引用原文。第二类叫标准字典类，比如数据元标准、代码集标准、字段级的数据字典。通常以表格形式存在，比如字段名、数据类型、业务含义、来源系统。第三类叫操作指南类，比如“如何提交数据质量整改报告”“如何申请数据服务接口”。这类是步骤型文本，经常包含流程、表单、时限。第四类是 FAQ 类，比如“数据责任人变更流程是什么”“指标口径在哪里发布”。这四类文档的写法差异很大，分段策略和检索策略也必须区分。
2.2 清洗环节，新手最容易跳过的关键步骤
没清洗过的文档直接进知识库，后面一定出问题。常见情况有三种。第一种是扫描版 PDF 或老旧 Word，里面全是 OCR 错字，“数据”变成“教据”，“责任人”变成“责任入”。这些脏数据进到向量库里，检索时很难被正确命中。第二种是页眉页脚残留，“XX集团内部资料”“第 3 页 共 20 页”这些内容一旦被分进段落里，会稀释正文的语义浓度。第三种是表格转换混乱，从 PDF 拷贝出来的表格经常变成一团乱麻，列和行对不上，这会让后续检索表格数据时完全无法使用。
我的清洗流程很朴素：统一转成 Markdown 或纯文本；删除封面页、目录、页眉页脚；表格尽可能转成 Markdown 表格或 CSV，而不是截图或散落文本；只保留当前生效版本，历史版本单独存档，不进知识库；做了清洗的文档，文件名加日期和状态后缀，比如“数据安全分级标准_2025Q1生效”。这一步累人，但能省掉后面大量效果调优的时间。
2.3 分段策略：不同文档类型用不同参数
Dify 里创建知识库时要配置分段规则，核心参数是分段标识符、最大分段长度、分段重叠长度。我见过很多人一套参数走天下，这恰恰是召回效果平庸的根源。分段太短，比如 200 tokens，一个完整的制度条款被拦腰截断，检索时语义不完整；分段太长，比如 2000 tokens，一个段落里混杂多个主题，向量表示会被平均化，查什么都有一点相关，但都不精准。
我的经验是，制度规范类用“句子换行符 + 句号”作为分段标识符，最大分段长度设在 500 到 800 tokens，重叠长度 80 到 100 tokens。标准字典类如果表格保存完好，按表格整体作为一个分段，或者拆成“表头字段注释 + 数据行片段”，避免整张大表变成一个巨大向量。操作指南类按步骤标识符分段，比如“1. 2. 3.”或者“第一步、第二步”。FAQ 类最简单，一个问题配一个答案，直接整体作为独立分段，不要再切。
2.4 利用分段元数据，让知识库更好维护
Dify 的分段信息里，除了正文内容外，还可以填写元数据，比如文档来源、部门、责任人、生效日期、文档版本。数据治理知识库特别需要版本和来源信息，因为制度类文档经常更新，如果模型同时从旧版本和新版本中检索到内容，回答就可能自相矛盾。
我当时的做法是，把“来源部门”和“生效日期”写进每个分段的元数据里，在提示词中要求模型优先采用生效日期较新的内容，并明确回答中提示信息出处。虽然这个方案在 Dify 里做不到非常细粒度的筛选，但至少让引用标注时能看到“来自哪个文档的哪个段落”，这对建立用户信任非常关键。知识库后期迭代时，元数据也是维护的重要线索，定期清理过期版本时能知道哪些分段来自哪份文档。
3. 在 Dify 中构建知识库：关键配置与参数详解
3.1 创建知识库与选择索引方式
进入 Dify 控制台，左侧导航找到“知识库”，点击创建。创建时要填知识库名称和描述，我建议名称带清晰业务域，比如“集团数据治理知识库”，描述里注明覆盖范围，方便后续多知识库情况下在应用侧做区分。
接下来是选择索引方式。Dify 提供高质量索引和经济索引两种模式。高质量模式会将文档分段并通过 Embedding 模型向量化，检索时用向量相似度召回。经济模式只做关键词索引，不走向量化，成本低但语义匹配能力很弱。数据治理知识库涉及大量术语和同义表达，比如用户问“数据拥有者是谁”，文档里可能写的是“数据责任人”，纯关键词检索会漏。所以必须选高质量索引，这一步不要省。
3.2 Embedding 模型怎么选：中英文混合场景的取舍
Dify 需要在系统设置里配置 Embedding 模型。你可以在模型供应商里接入多种模型，也可以在知识库级别指定使用哪一个。我自己的实践是，如果文档以中文为主，优先选支持中文的模型。当时试过通用英文向量模型在中文制度文档上的效果，检索召回率明显不如中文优化模型。
对于本地化需求更强的团队，可以部署开源的 Embedding 模型，比如 bge-m3。这类模型对中文长文本的支持比较成熟，而且可以完全内网部署，避免敏感制度文档的外传风险。部署方式可以是本地模型服务，再通过 Dify 的 OpenAI-API 兼容接口接入。这里有个小提醒：Embedding 模型一旦上线就不要频繁更换，因为不同模型的向量空间不一致，换模型意味着全库重新向量化，否则新旧向量无法混在一起做相似度计算。数据治理知识库这种场景，稳定性优先。
3.3 召回模式与 Rerank 配置：检索效果的分水岭
Dify 知识库支持向量检索、全文检索、混合检索三种召回模式。向量检索擅长语义匹配，能解决“数据责任人”和“数据拥有者”这种用词不一致的情况。全文检索擅长精确匹配，适合查代码、字段名、编号这种必须一字不差的场景。混合检索则是先分别做向量召回和全文召回，再将结果合并去重。
在数据治理知识库里，混合检索几乎是必须的。因为用户经常拿字段名或编号提问，比如“DQ-2025-001 这条质量规则怎么处理”，全文检索能精确锁定，向量检索反而可能被语义相近的其他规则干扰。Dify 开启混合检索后，还可以挂一个 Rerank 模型对合并结果做相关性重排。重排的价值是：把两路召回的结果放在同一个更精准的排序模型下重新打分，避免向量召回高分但实际无关的段落排在前面。
Rerank 模型我建议选择专门的排序模型，而不是复用 Embedding 模型。部署排序模型同样可以走本地服务或云端 API。参数方面，TopK 决定最终送入大模型的段落数量。简单问答设 3 就够；制度条款查询我建议设 5，给大模型多一些筛选空间。如果发现答非所问，先别急着改提示词，先检查是不是 Rerank 的 Score 阈值设太高把正确答案滤掉了。我当时就把阈值从 0.5 调低到 0.3，召回率立刻涨了一截。
3.4 多知识库设计与权限隔离
数据治理相关的文档中，有一部分是全员公开的制度，有一部分只有核心管理人员能看，比如数据安全定级清单。如果全塞进一个知识库，应用侧又没有任何权限控制，那就是在裸奔。Dify 本身不是专业权限系统，我对这种场景的处理方法是物理隔离。
具体做法：建多个知识库，公开制度库给全员问答应用使用，涉密清单库只接入内部管理端的 Chatflow。应用与知识库是一对多绑定的关系，哪个应用能访问哪个知识库，在应用的上下文设置里可以控制。这样至少做到了应用级隔离。如果你的权限粒度要精确到“某个部门的人只能看某几段”，那 Dify 原生能力覆盖不了，需要在外层加代理或自定义系统，把用户身份映射成不同的应用入口。这个要在项目规划阶段就想清楚，别等上线了再补。
4. 应用编排与提示词设计：让 RAG 真正好用
4.1 选聊天助手还是 Chatflow
知识库建好之后，接下来就是创建应用。Dify 应用类型有聊天助手、Agent、Chatflow、工作流等几种。我的建议是：如果只是让用户自由提问并返回回答，聊天助手就能胜任；如果你需要在用户提问之后先做意图判断、再决定走知识库还是走通用对话，那 Chatflow 更合适。
我最终选择了 Chatflow。原因是数据治理场景对控制力要求比较高，我希望流程是固定的：先判断问题类型，如果是制度查询就专门走知识检索节点，如果是闲聊则走普通对话。Chatflow 上有非常直观的节点画布，可以把知识检索、问题分类、LLM 生成串起来。Agent 模式虽然灵活，但 Agent 自主调工具的行为不可控，对于业务知识库这种容错率低的场景，我不建议一上来就上 Agent，等规则足够成熟再迭代也不迟。
4.2 提示词调优：约束模型别“自由发挥”
很多初次接触 RAG 的人把重心放在模型选型上，却忽略了提示词。数据治理知识库对答案准确性的要求很高，回答错了可能直接影响整改工作。我的 System Prompt 里写死了几个原则。
第一，只依据知识库提供的内容回答，不得自行编造业务规则。第二，如果知识库中没有相关内容，明确回答“知识库中未找到相关信息”，并建议用户查阅制度原文或联系数据治理组。第三，回答时尽量引用具体来源段落，标注文档名称和条款编号。第四，当多个来源存在冲突时，优先采用生效日期较新的内容，并提醒用户当前内容存在版本差异。
Dify 的提示词支持变量占位符，在知识检索节点之后，可以把检索到的分段内容注入到提示词中。我设计提示词的结构是：“你是集团数据治理助手。请基于以下【参考资料】回答问题。如果资料不足，请直接说明。参考资料：{context}。用户问题：{query}。”这套模板很朴素，但实测下来比那些长篇大论的“角色扮演”提示词稳定得多。
4.3 引用标注与答案后处理
RAG 应用有一个很容易被忽略的体验细节：引用标注。Dify 在知识检索节点后，会自动携带来源分段信息，你可以在最终回复中设置“引用”组件，把命中的文档标题、段落展示给用户。这件事不只是体验问题，还能倒逼模型忠实于原文。当用户看到答案是引用自《数据安全分级标准》第 X 节时，他对答案的信任度会明显提高，你的知识库出了问题也更方便追责和修正。
我同时给答案做了后处理规则：在 Chatflow 的 LLM 生成节点后面加一个“直接回复”节点，把答案和引用包装成统一格式。格式包括答案正文、命中分段列表、文档来源。注意不要把引用写成“根据资料显示”这种含糊的话，要直接展示链路。考虑到数据治理文档的敏感性，还可以加一层脱敏提示词：禁止输出涉及人员联系方式、账号密码等信息，即使知识库中出现了相关内容。
4.4 小型验收流程：从 demo 到可用的门槛
应用编排完成后，不要急着欢欣鼓舞，先拿一套最小验收集跑一遍。我准备了 20 个真实问题，覆盖制度查询 7 题、口径解释 7 题、FAQ 6 题。每条问题的判定标准有三个维度：答案是否与知识库原文一致、是否包含有效引用、是否能在 15 秒内返回。跑完之后统计准确率，如果低于 80%，别急着给业务方演示，先回头调数据或提示词。
这个验收流程成本很低，但价值极高，它定义了你对“可用”的理解。我见过太多内部工具上线后没人用的案例，根本原因就是准确率不够、答案不敢信。与其追求功能多，不如先把 20 个问题做到全对，再逐步扩大问题集。
5. 检索效果调优与发展评估：从“能回答”到“答得准”
5.1 问题预处理：别把原话直接丢给检索器
RAG 的一个反直觉之处在于：用户怎么问，和文档怎么写的，经常是两种语言。数据治理领域尤其明显。用户可能说“数据谁负责”，文档里写的是“数据责任人”。如果直接把原问题去检索，向量召回有概率匹配到，但不够稳定。更好的做法是在 Chatflow 里给检索节点加一个前置处理步骤。
我当时的做法是加一个“问题改写”节点，用大模型把用户口语化成的问题补充成适合检索的表述。比如“数据谁负责”改写为“数据责任人的定义和职责是什么”。这一步不要求大模型给出最终答案，只要求它做忠实改写，成本很低，但对召回的提升很明显。还可以做一个简单意图分类：根据用户问题判断这是一个制度条款查询、指标口径查询还是整改流程查询，然后按类型给检索节点附加关键词提示。这不是花活，几条规则就能让准确率提升一个档次。
5.2 从答案反推问题：检索参数排查路径
当用户反馈“答案不对”时，我有一套固定的排查路径，而不是瞎调参数。如果回答内容看上去相关但不够完整，优先检查 TopK 是否太小，或者分段是否太短，导致参考文献覆盖不全。如果回答完全驴唇不对马嘴，优先检查混合检索是否开启、Rerank 模型是否误杀、问题改写节点是否把意思改偏了。如果回答引用了知识库内容但逻辑混乱，那问题多半出在 LLM 提示词，它没有按要求组织多个来源的观点。
把这四个问题分开排查之后，大部分“模型答错”的锅，最后都会落在数据或参数上，而不是模型本身。这也提示了一个关键认知：RAG 系统调试的耐心，应该大部分放在检索链路，而不是反复更换生成模型。
5.3 建立迷你评测集：数据治理问答的“验收基准”
没有评测集的调优，基本靠感觉。我在项目里建了一个迷你评测集，大概 30 条问题，分三类：原文可查型，比如某个制度中的具体条款；逻辑推断型，比如多个文档联合才能回答的问题；否定回答型，即知识库中本来就没有答案的问题，测试模型会不会乱编。
每次改动分段、重排或提示词，都把评测集跑一遍，记录正确率。这个基线不需要多精密，关键是稳定。只要改动让正确率下降，哪怕主观感觉“回答更流畅了”，也要考虑回滚。后来我还把这套人工评测的方式转成了一个简单的 Prompt 评估流程：把“问题 + 参考答案 + 实际回答 + 引用来源”喂给一个大模型评分器，让它按 1 到 5 分评估忠实性和相关性。这种方式虽然不能完全替代人工，但至少让效果回归有了可复现的依据。
5.4 数据更新的闭环：知识库不是一次性项目
知识库上线三个月后最容易出现的情况是：文档更新了，知识库里还是旧版本。数据治理领域的制度文件经常修订，如果不建立更新机制，准确率会随时间快速衰减。我建议把知识库维护纳入业务流程：每当一份制度文件修订发布，责任人同步更新 Dify 知识库中的对应文档，同时将旧版本移出或标注废止。
Dify 支持对知识库文档进行替换、删除与分段管理，你可以手工操作，也可以通过 API 接入专门的文档管理页面。如果团队有余力，建议在每次更新后跑几条该制度相关的问题，确认新版本已生效。最后，定期查看应用日志里的用户问题，把高频未命中问题挑出来，人手补充成 FAQ 文档。知识库的成长本身就是持续运营的过程，这也是它区别于普通静态文档库的最大价值。
6. 常见问题与避坑记录
6.1 召回结果为空或者答非所问
这是出现频率最高的问题。我遇到的典型场景是：用户提问“数据安全定级有哪些级别”，知识库明明有《数据安全分级指南》，但回答却说没有找到。排查后发现问题出在分段。那份 PDF 在转换时把“级别”和“分类”两个词混用了，而用户用的是“定级”，向量模型在短查询下没有把两者关联起来。
这类问题的解法分几步。确认 Embedding 模型支持中文语义匹配；开启混合检索，让全文检索兜底；把问题改写节点加上，把用户问法与文档用语对齐；最后，如果还不行，去 Dify 的召回测试页面手动输入问题，逐条查看召回到哪些分段，一目了然。Dify 提供了专门的召回测试入口，调试时不借助这个功能，等于盲人摸象。
6.2 模型编造答案或引用过期版本
大模型的“幻觉”在 RAG 里依然存在，只是被知识库约束了一部分。数据治理场景最怕的不是完全不相关，而是看上去专业、实则错误。我踩过最典型的坑：旧版《数据质量规则》里规定“月度核查”，新版改成了“按周核查”，但旧文档没有删除，模型检索时同时命中两个版本，居然在答案里把两条都列出来，还自圆其说地解释了二者关系。
解决方法是多管齐下。知识库文档只保留当前有效版本；分段元数据填写生效日期；提示词明确要求“当多个来源冲突时，默认采用最新生效日期”；在引用中展示文档版本号，让用户自己也能核对。如果你不要负面的“幻觉”展示，还可以设置一个关键词守卫，当模型回答中出现“旧版”“历史规定”等词时，强制要求它提示用户以最新制度为准。
6.3 表格类数据检索严重失真
数据治理知识库里有大量表格，比如数据元登记表、代码集对照表。表格一旦被转成普通文本，列与行的语义关系就丢掉了。用户问“客户状态代码 01 是什么意思”，如果表格被拆成了零散行，模型很难把“01”和“正常”关联起来。
我的做法是尽量把关键表格转成 Markdown 格式，并在分段时以整个表格为一个独立分段。Dify 对 Markdown 表格的解析相对友好，保留表格语法能够维持结构。数量巨大的代码集，我干脆拆成键值对形式的文本，“代码 01，含义 正常，备注 无”。虽然不够优雅，但检索命中率显著提升。对于大型表格，Dify 现有的分段能力比较有限，这时可以在文档准备阶段手工拆分，把它变成适合检索的小块数据。
6.4 性能与成本：别让混合检索拖垮体验
混合检索加 Rerank 的效果好，但性能和成本都不低。每来一个问题，要同时跑向量召回和全文召回，再对候选做一次重排模型推理，再加上大模型生成，响应时间轻松上 10 秒。业务人员的耐心没那么大，我从上线第一天就在监控接口耗时。
几个实用的降本手段：对相似问题做缓存，如果用户问的是完全相同的问题，直接返回缓存结果；在 Chatflow 里加一个前置分类节点，只有高风险查询才启用混合检索，普通制度查询只走向量召回；Rerank 模型使用的时候，把候选数量控制住，不要让它对上百分段逐条打分。成本方面，中小规模知识库其实很便宜，几十万 tokens 的文档 Embedding 成本基本可以忽略，主要开销反而在反复调试时频繁调用大模型生成答案。我自己在调提示词阶段，会故意用便宜的模型做试验，最终稳定了再切到效果更好的模型。
6.5 关于“数据治理”知识库的边界意识
最后说一个我在项目里感触最深的事。用户很容易把“知识库”当成“万能数据平台”，来问“帮我算一下本季度的数据质量合格率”“把各子公司提交的整改报告汇总一下”。这类问题需要的是数据计算和汇聚，不是文档检索，RAG 在这里无能为力。我后来在应用的开场白里明确告诉用户：本助手只解答制度与口径类问题，不涉及实时数据查询和计算。这看起来像是在限制功能，实际上是在保护用户体验，避免他们对着一个文档问答工具提数据平台需求。
6.6 一个小技巧：把失败案例变成知识库的一部分
每次出现答错或者答不准，不要只修参数，把问题记录到一个“待补充文档”清单里。积累到一定数量后，把高频问题统一写成 FAQ 文档补进知识库。这不是偷懒，而是在把系统的边界一点点撑大。我做了三个月之后，知识库里新增了 40 多条 FAQ 分段，全都是从真实用户问题里沉淀出来的。这些新分段对准确率的提升，比换一个大模型来得明显得多。
从我个人的实际体验来看，用 Dify 搭 RAG 知识库，真正的难点从来不是界面操作，而是你愿不愿意在前期的数据清洗、分段设计、评测集构建上下笨功夫。Dify 把链路的复杂度消化在了产品设计里，但把判断力留给了使用者。你越理解文档和用户问题之间的关系，这套系统就越聪明。接下来我打算继续往这条路走：把评测集自动化、把更新机制嵌入业务流程，让这个知识库真正成为一个有生命的治理工具。
