Dify 实战篇：从文档上传到精准问答，手把手搭建企业知识库 RAG 应用

公众号：码海寻道

在前两篇文章中，我们已经介绍了 Dify 的平台定位，以及五类应用的区别与选型方法。理解这些概念之后，最适合进入实战的场景，就是企业知识库问答。

企业内部通常沉淀了大量文档，例如产品手册、技术规范、制度流程、FAQ、运维文档和项目资料。过去这些知识往往散落在飞书、语雀、Confluence、Word、PDF 或网盘中，查找成本很高。

RAG 的价值就在于：让大模型不只依赖自身训练知识，而是能够基于企业自己的文档进行检索和回答。

这篇文章将以 Dify 为平台，讲清楚如何从文档上传开始，逐步搭建一个可用、可调优、可上线的企业知识库 RAG 应用。

1. 什么是 RAG

RAG 是 Retrieval-Augmented Generation 的缩写，通常翻译为检索增强生成。

它的基本思路是：用户提出问题后，系统先从知识库中检索相关资料，再把检索结果作为上下文交给大模型生成答案。

一个典型 RAG 流程可以概括为：

用户问题→ 问题理解→ 知识库检索→ 召回相关片段→ 拼接上下文→ 大模型生成答案→ 返回答案与引用来源

相比直接问大模型，RAG 的优势在于：

• • 可以回答企业私有知识：模型本身不知道企业内部文档，但可以基于检索内容回答。
• • 降低幻觉概率：答案可以约束在知识库内容范围内。
• • 知识可更新：更新文档即可更新问答能力，不必重新训练模型。
• • 便于追溯来源：可以展示答案来自哪些文档片段。

不过，RAG 并不是“上传文档就自动精准问答”。真正影响效果的因素包括文档质量、切分策略、Embedding 模型、召回参数、Prompt 约束和测试评估。

2. 为什么用 Dify 做 RAG

如果完全用代码实现 RAG，通常需要自己处理以下环节：

• • 文档解析。
• • 文本切分。
• • 向量化。
• • 向量数据库存储。
• • 相似度检索。
• • Prompt 拼接。
• • 模型调用。
• • 对话管理。
• • 日志记录。
• • API 封装。

这些工作并不难理解，但工程细节很多。对于业务验证和团队落地来说，Dify 的优势是把这些基础能力产品化。

在 Dify 中，你可以通过界面完成：

• • 创建知识库。
• • 上传文档。
• • 配置文档切分。
• • 选择 Embedding 模型。
• • 在应用中绑定知识库。
• • 编写约束型 Prompt。
• • 测试问答效果。
• • 查看调用日志。
• • 发布 WebApp 或 API。

因此，Dify 很适合用来快速搭建企业知识库问答应用，并在后续持续调优。

3. 实战目标

本文要搭建的目标应用是一个“企业知识库助手”。

它需要具备以下能力：

• • 用户可以用自然语言提问。
• • 系统从企业文档中检索相关内容。
• • 回答必须尽量基于知识库，不随意编造。
• • 如果知识库没有答案，要明确说明无法确认。
• • 尽量返回结构清晰、便于阅读的答案。
• • 后续可以通过 WebApp 或 API 集成到其他系统。

为了让流程更通用，本文不绑定某一种具体行业文档。你可以把它应用到产品手册、课程资料、客服 FAQ、内部制度或技术文档中。

4. 第一步：准备知识库文档

RAG 的效果首先取决于文档质量。很多问答效果不好，并不是模型能力不行，而是文档本身不适合检索。

建议优先选择以下类型的文档：

• • 结构清晰的产品说明。
• • 标题层级明确的技术文档。
• • 高频问题整理成的 FAQ。
• • 操作步骤明确的流程文档。
• • 内容准确、没有过期信息的制度规范。

不建议一开始就上传大量混乱文档，例如：

• • 多个版本混在一起的历史文档。
• • 含有大量扫描图片但没有 OCR 文本的 PDF。
• • 标题混乱、段落过长的 Word 文档。
• • 内容互相矛盾的资料。
• • 过期但未标注失效的信息。

在上传之前，可以先做一次轻量整理：

删除过期内容；合并重复文档；补充清晰标题；把长段落拆成短段落；把问答类内容整理成 FAQ 格式；保留必要的来源信息和更新时间。

这一步看起来不复杂，但它往往决定了 RAG 应用的上限。

5. 第二步：创建 Dify 知识库

进入 Dify 后，可以在知识库模块中新建一个知识库。

建议命名时体现业务范围，例如：

产品帮助中心知识库内部制度知识库运维故障处理知识库课程资料知识库客服 FAQ 知识库

命名不要过于宽泛。一个知识库最好对应一个相对明确的业务领域。

如果把所有文档都放进一个“大杂烩知识库”，检索时容易出现噪声，模型可能召回不相关片段，最终影响答案质量。

更推荐的方式是按领域拆分知识库：

产品文档知识库售后 FAQ 知识库技术支持知识库内部流程知识库

后续可以在不同应用中按需绑定一个或多个知识库。

6. 第三步：上传文档

Dify 支持通过界面上传文档。具体支持格式会随版本和部署配置变化而变化，常见类型通常包括文本、Markdown、PDF、Word 等。

上传文档时要关注三个问题。

6.1 文档是否能被正确解析

上传后需要检查文档内容是否被正确识别。尤其是 PDF 和 Word 文档，可能存在格式解析问题。

如果解析后出现大量乱码、空白或断句异常，建议先把文档转换成 Markdown 或纯文本格式，再上传。

6.2 文档是否有清晰结构

RAG 检索依赖文本片段。如果文档缺少标题和段落结构，系统很难知道哪些内容属于同一个主题。

推荐使用类似下面的结构：

# 一级标题## 二级标题### 具体问题问题描述……处理步骤……注意事项……

对于 FAQ 文档，可以使用：

## 问题：如何重置密码？回答：用户可以在登录页点击“忘记密码”，根据手机号或邮箱进行验证后重置。适用范围：企业版、专业版。

这种结构更容易被切分和召回。

6.3 文档是否需要分批上传

如果文档很多，不建议一次性全部上传。更稳妥的方式是先选择一小批高质量文档进行验证。

推荐路径是：

先上传 10 到 30 篇核心文档→ 构建测试问题集→ 测试召回和回答质量→ 调整切分与 Prompt→ 再逐步扩大文档范围

这样可以更快定位问题，而不是面对一个巨大知识库却不知道错误来自哪里。

7. 第四步：配置文档切分策略

文档切分是 RAG 中非常关键的一步。

如果切分块太大，检索结果可能包含太多无关内容，模型抓不住重点。如果切分块太小，又可能丢失上下文，导致答案不完整。

可以把文本块理解为知识库检索的最小候选单元。

7.1 切分过大的问题

例如一个文本块包含 3000 字，里面同时讲了登录、权限、订单和报表。用户问“如何修改角色权限”时，这个块可能被召回，但其中大部分内容与问题无关。

结果是模型拿到一个很大的上下文，却需要自己从中找重点，回答质量容易下降。

7.2 切分过小的问题

如果每个块只有一两句话，用户问复杂问题时，单个块可能只包含局部信息。

例如一个操作流程被拆成多个碎片，模型只召回了其中一部分，就可能生成不完整步骤。

7.3 推荐策略

对于一般企业文档，可以从中等长度切分开始，再根据测试结果调整。

经验上可以遵循几个原则：

• • 一个文本块尽量围绕一个明确主题。
• • 一个完整操作步骤不要被切得过碎。
• • FAQ 类型文档尽量让“问题 + 回答”保持在同一个块中。
• • 标题信息要尽量保留在文本块中。
• • 对长文档优先按标题和段落切分。

如果 Dify 提供了自动切分和自定义切分能力，建议先使用默认策略跑通流程，再根据测试结果逐步优化。

8. 第五步：选择 Embedding 模型

Embedding 模型负责把文本转换成向量，用于语义检索。

用户问题和知识库片段都会被转换成向量，系统通过向量相似度找到最相关的内容。

Embedding 模型会直接影响召回质量。选择时要关注：

• • 语言能力：是否适合中文语义检索。
• • 领域适配：是否能理解技术、法律、医疗、金融等专业术语。
• • 成本：大量文档向量化会产生计算或 API 成本。
• • 部署方式：使用云端模型还是本地模型。
• • 稳定性：生产环境是否有可用性保障。

如果主要处理中文企业文档，建议优先选择中文效果较好的 Embedding 模型，并用真实问题集进行测试，而不是只看模型介绍。

9. 第六步：创建聊天助手并绑定知识库

知识库准备好之后，可以创建一个 Chat Assistant 类型应用，用于搭建问答入口。

基础配置包括：

• • 选择合适的 LLM。
• • 绑定前面创建的知识库。
• • 配置检索参数。
• • 编写系统 Prompt。
• • 设置开场白和示例问题。

对于企业知识库助手，Prompt 的核心不是让模型“尽量聪明”，而是让它“遵守边界”。

可以使用类似下面的 Prompt：

你是一个企业知识库助手。你的任务是基于知识库检索结果回答用户问题。回答要求：1. 优先依据知识库内容回答，不要编造未提供的信息。2. 如果知识库内容不足以回答，请明确说明“根据当前资料无法确认”。3. 如果问题涉及操作步骤，请使用编号列表输出。4. 如果问题涉及多个条件，请分点说明。5. 保持回答简洁、准确、可执行。知识库上下文：{{context}}用户问题：{{query}}

这个 Prompt 的重点是明确回答边界，降低模型脱离资料自由发挥的概率。

10. 第七步：设置检索参数

RAG 的答案质量很大程度上取决于召回内容。

常见需要关注的参数包括 Top K、相似度阈值和重排策略。

10.1 Top K

Top K 表示每次检索返回多少个相关片段。

Top K 太小，可能漏掉关键内容。Top K 太大，可能引入噪声，并增加上下文长度和 Token 成本。

可以从 3 到 5 开始测试。如果问题需要跨多个文档综合回答，可以适当增大。

10.2 相似度阈值

相似度阈值用于过滤低相关片段。

阈值太低，会召回很多不相关内容。阈值太高，可能没有任何内容被召回。

建议结合测试问题观察：

有答案的问题是否能召回正确片段；无答案的问题是否会误召回不相关片段；相似问题是否能稳定召回同一类文档。

10.3 Rerank

Rerank 通常用于对初步召回结果重新排序，提高最相关片段的排名。

如果知识库规模较大、文档相似度较高，Rerank 往往能改善检索质量。但它也会带来额外耗时和成本。

是否启用 Rerank，建议根据应用重要性和响应时间要求决定。

11. 第八步：构建测试问题集

很多团队做 RAG 只测试几个随手问题，这很难判断系统是否真的可用。

建议准备一组测试问题集，至少覆盖以下类型：

• • 精确命中问题：文档中有明确答案。
• • 同义表达问题：用户换一种说法提问。
• • 跨段落综合问题：答案需要结合多个片段。
• • 边界问题：问题与知识库主题相关，但文档没有答案。
• • 无关问题：知识库完全不包含相关内容。
• • 易混淆问题：多个文档中存在相似术语或相似流程。

可以使用如下表格记录测试结果：

测试问题集是 RAG 调优的基础。没有测试集，就很难判断参数调整是否真的有效。

12. 第九步：根据日志调优

Dify 的日志能力可以帮助你观察每次问答的输入、输出、命中内容和用户反馈。

调优时可以重点看几个问题：

• • 用户原始问题是什么。
• • 系统召回了哪些文档片段。
• • 召回内容是否与问题相关。
• • 模型是否基于召回内容回答。
• • 是否出现了编造内容。
• • 用户是否继续追问或表达不满意。

常见问题与处理方式如下：

RAG 应用上线后，调优应该是持续过程，而不是一次性配置。

13. 第十步：发布 WebApp 或 API

当问答效果达到可接受水平后，可以考虑发布。

Dify 通常提供两种常见交付方式：

• • WebApp：适合内部快速使用、演示和轻量级试点。
• • API：适合集成到企业微信、飞书、钉钉、官网、客服系统或内部管理后台。

如果是 API 集成，需要重点关注：

• • API Key 或 Token 的安全管理。
• • 用户身份与权限控制。
• • 是否需要区分不同用户可访问的文档范围。
• • 请求频率限制。
• • 日志审计与异常告警。
• • Token 成本统计。

对于企业知识库助手，不建议一开始就全员开放。更稳妥的方式是先进行小范围试点，收集真实问题，再逐步扩大使用范围。

14. 生产环境注意事项

14.1 知识库要有更新机制

企业文档会持续变化。产品功能更新、制度调整、流程变更都会影响问答准确性。

建议建立知识库维护机制：

指定文档负责人；标注文档更新时间；定期清理过期内容；重要文档变更后重新测试；记录用户反馈并补充 FAQ。

14.2 明确回答边界

知识库助手不应该回答所有问题。尤其是涉及法律、财务、人事、医疗等敏感内容时，需要设置明确边界。

如果资料不足，应该让模型承认不知道，而不是生成看似合理但未经验证的答案。

14.3 做好权限隔离

不同用户可能只能访问不同范围的文档。例如普通员工不能查看管理层制度，外部客户不能访问内部技术资料。

如果存在权限要求，需要在系统集成层或知识库设计层做好隔离。

14.4 控制成本与延迟

RAG 会引入向量检索、重排和大模型生成。生产环境需要关注：

• • 单次请求 Token 消耗。
• • 平均响应时间。
• • 高峰期并发量。
• • Embedding 与 LLM 调用成本。
• • 失败重试策略。

对于高频场景，可以考虑缓存高频问题答案，或者为不同业务场景选择不同模型。

15. 一套推荐落地流程

如果你准备在团队中落地 Dify 知识库助手，可以按下面步骤执行：

1. 选择一个边界明确的业务场景2. 整理 10 到 30 篇高质量文档3. 创建知识库并上传文档4. 配置切分和 Embedding 模型5. 创建 Chat Assistant 并绑定知识库6. 编写约束型 Prompt7. 准备测试问题集8. 调整 Top K、阈值和切分策略9. 小范围发布 WebApp10. 根据日志和反馈持续优化11. 稳定后再通过 API 集成到业务系统

这套流程的核心思想是：先小范围验证效果，再逐步扩大知识库和使用范围。

16. 总结

Dify 降低了搭建 RAG 应用的门槛，但并不意味着 RAG 可以完全自动化完成。

一个可靠的企业知识库助手，需要同时做好文档治理、知识库配置、Prompt 约束、检索参数调优、测试问题集建设和上线后的持续运营。

如果只是上传文档，然后期待模型自动精准回答，效果通常不会稳定。

真正可落地的 RAG 应用，应该遵循一个工程化闭环：

整理知识 → 构建知识库 → 配置检索 → 约束生成 → 测试评估 → 日志调优 → 持续更新

对于 Dify 用户来说，掌握这套闭环，比单纯记住某个参数更重要。

这也是从“能跑起来”走向“能稳定服务业务”的关键一步。