先问一个问题你在用大模型做知识问答时是不是经常遇到它一本正经地“胡说八道”或者你上传了一份内部产品手册问它细节时它回答得模棱两可甚至把 A 产品的参数安到了 B 产品头上这几乎是所有直接使用大模型做企业应用的团队都会踩的坑。大模型本身并不知道你公司内部的资料它只会根据训练时见过的公开数据来“猜”。想要让它基于你自己的知识库去回答就必须引入RAG检索增强生成。但 RAG 的原理虽然听起来不复杂真正落地时却有一堆麻烦事文档怎么切分向量库怎么选召回之后怎么让大模型只依据上下文回答如果全部自己用代码写一遍工作量并不小。本文要分享的是基于Dify这个开源平台从零搭建一套企业级 AI 知识库与智能问答系统的完整过程。即使你没有系统学过 AI 应用开发只要会基础的 Docker 操作也能跟着把整套系统跑起来。文章会包含环境准备、知识库创建、应用编排、工作流配置、API 对接和常见问题排查内容偏实战建议收藏后跟着做。1. 背景与核心概念1.1 什么是 RAGRAG 的全称是Retrieval-Augmented Generation翻译过来就是“检索增强生成”。它的核心思路并不复杂当用户提出一个问题时系统先从我们预先准备好的知识库中检索出相关的文本片段再把“问题 相关资料”一起交给大模型让大模型基于这些资料来生成答案。这样做的好处非常明显缓解幻觉大模型不再“凭空想象”而是有了确切的参考依据。知识实时更新知识库里的文档可以随时更新不需要重新训练模型。保护私有数据企业内部的资料不需要上传到模型训练集只作为检索时的临时上下文。回答可溯源可以返回回答引用了哪些文档片段方便用户核对。可以简单理解成RAG 给大模型配了一位“图书管理员”。大模型回答问题前先由这位管理员去资料室把相关书籍翻出来再照着书念。1.2 什么是 DifyDify 是一个开源的 LLM 应用开发平台同时具备Agent 智能体、RAG 管道、工作流编排、模型管理、可观测性等功能。过去我们做 AI 应用需要自己处理模型 API 接入、Prompt 模板管理、知识库向量化、对话历史记录、用户权限这些琐碎事情。而 Dify 把这些能力全部做成了可视化的界面我们可以像搭积木一样搭建一个完整的 AI 应用。Dify 比较适合以下场景企业内部知识库问答。客服机器人 / 销售助手。文档分析与内容生成。复杂的多步骤 AI 工作流。需要快速把大模型能力集成到现有系统中的团队。1.3 为什么用 Dify 来做 RAG从零手写 RAG 需要做的事情包括选择 Embedding 模型、实现文档解析与分段、维护向量数据库、实现召回逻辑、设计 Prompt、管理对话上下文。这一整套流程并不轻松。而 Dify 把 RAG 链路做成了可视化配置上传文档自动完成分段和向量化。可视化选择检索策略。通过“知识检索”节点在工作流中召回内容。内置多种模型供应商适配不需要自己对接各家 API。所以对于大多数企业和开发者来说用 Dify 搭建 RAG 应用是当前性价比很高的方式。2. 环境准备与版本说明在开始之前我们先准备好运行环境。2.1 运行环境本文示例以Linux 服务器为例本地开发机如果是 macOS 或 Windows带 WSL2也可以参考。需要确保以下环境已安装软件作用安装建议Docker运行 Dify 容器20.10 以上版本Docker Compose 插件编排多个容器通常随 Docker 一起安装Git获取 Dify 源码可选也可以直接下载压缩包浏览器访问 Dify 控制台Chrome / Edge 均可验证 Docker 是否安装成功docker --version docker compose version如果输出了版本号说明环境基本可用。这里不写死具体版本号因为 Dify 更新比较快。建议拉取当前最新的稳定版本。2.2 获取 Dify 源码git clone https://github.com/langgenius/dify.git cd dify/docker如果 GitHub 访问不便也可以在 Dify 官方仓库页面下载源码压缩包解压后进入docker目录即可。2.3 配置环境变量在docker目录下有一个.env.example文件我们需要复制一份为.envcp .env.example .env.env文件里包含了 Dify 各组件的端口、密钥、数据库配置等。默认配置可以直接启动。如果你希望修改默认端口可以打开.env文件调整EXPOSE_NGINX_PORT和EXPOSE_NGINX_SSL_PORT等参数。2.4 启动 Difydocker compose up -d首次启动会拉取多个镜像耗时取决于网络状况。启动完成后可以通过以下命令查看容器状态docker compose ps正常情况下你会看到nginx、api、worker、db、redis、weaviate等多个容器处于运行状态。然后访问http://你的服务器IP首次访问会进入管理员账号初始化页面设置好管理员邮箱和密码后就可以进入 Dify 主界面了。2.5 模型供应配置Dify 本身不提供大模型能力它需要对接外部的大模型 API。进入控制台后点击右上角头像进入“设置 - 模型供应商”然后配置你需要的模型。对于 RAG 知识库应用至少需要配置两类模型系统推理模型用于生成回答例如聊天模型。Embedding 模型用于将文本转换为向量。常见的 OpenAI 兼容接口、国产大模型平台等都可以在 Dify 中找到对应的供应商配置入口。你需要准备好对应的 API Key。如果没有 API Key也可以先用一些提供免费额度的模型平台做测试等正式开发时再切换生产模型。3. 核心原理拆解RAG 的完整链路在动手配置之前我们先拆解一下 Dify 中 RAG 知识库的原理。只有理解了原理后面遇到检索效果不好时才知道怎么调优。3.1 RAG 的四大环节一个完整的 RAG 系统可以划分为四个环节文档加载与解析将 PDF、Word、Markdown、TXT 等格式的文档读取为纯文本。文本分段Chunking将长文本切分成若干小块。Dify 中叫“分段”。向量化Embedding把每一段文本通过 Embedding 模型转换成向量并存储到向量数据库中。检索与生成用户提问时将问题向量化在向量库中检索相似度最高的文本片段再交给大模型生成回答。3.2 Dify 知识库的创建逻辑在 Dify 中知识库的流程是创建知识库。上传文档。选择分段模式自动分段 / 自定义分段。选择索引方式高质量 / 经济。完成索引后知识库中的文本就变成了可检索的向量数据。当我们在应用中关联了知识库后用户在对话时Dify 会先调用 Embedding 模型把用户问题向量化再到知识库中做相似度检索最终将命中的文本片段和用户的原始问题一起发送给大模型。3.3 Dify 的工作流如何服务 RAGDify 的工作流是一种可视化的节点编排能力。在 RAG 应用中我们会用到几个核心节点开始节点接收用户的输入。知识检索节点在指定的知识库中检索相关内容。LLM 节点调用大模型将“用户问题 检索到的上下文”组合成最终回答。结束节点返回结果给用户。你也可以在知识检索后增加问题分类、条件分支、模板转换、变量聚合等节点实现更复杂的业务逻辑。3.4 为什么只是简单拼接还不能直接商用很多人第一次搭 RAG 应用时觉得“能回答问题了”就算成功了。但在企业场景中还需要考虑检索到的内容是否足够精准而不是召回了大量无关文本。大模型是否会忽略上下文继续“自由发挥”。用户问题含糊时是否需要反问澄清。同一问题是不是能命中多个知识库并做结果合并。这些问题会在后面的实战环节中逐步体现。先记住一个原则RAG 的效果上限取决于检索质量而检索质量的上限取决于文本分段和知识库的设计。4. 从零搭建企业级 AI 知识库现在开始正式实操。我们先创建一个知识库上传文档并完成索引。4.1 创建知识库在 Dify 控制台左侧菜单中点击“知识库”然后点击“创建知识库”。填写知识库名称和描述比如名称产品技术手册 描述包含公司产品的安装、配置、常见故障排查文档。点击“创建”后进入文档上传页面。4.2 上传文档并选择分段模式Dify 支持上传多种格式包括 PDF、DOCX、TXT、Markdown 等。选择你的文档后需要选择分段模式。自动分段与清洗适合大多数场景系统会自动识别段落并清理无关字符。你只需要设置“分段标识符”默认是换行和“最大分段长度”。自定义分段适合格式固定、对分段要求较高的文档。分段长度需要结合你的知识库内容来调整。如果分段太短上下文信息不完整如果分段太长检索时容易混入大量无关信息而且会增加 Token 消耗。对于初次尝试可以先使用默认参数等后面检索效果不好时再回来调整。4.3 选择索引方式Dify 的索引方式通常分两种高质量调用 Embedding 模型生成向量检索效果更好但需要消耗模型 API 调用。经济使用关键词索引不调用 Embedding 模型成本低但效果一般。建议测试环境用“经济”模式验证流程生产环境选择“高质量”模式。选择好之后点击“保存并处理”。系统会开始对文档进行分段、向量化并写入向量数据库。处理完成后你会看到知识库中出现了对应的文档并且可以预览每一段的内容。4.4 配置检索设置知识库处理完成后在知识库详情页中可以设置检索参数参数作用检索模式向量检索 / 全文检索 / 混合检索TopK召回多少个文本片段Score 阈值相似度达到多少才认为相关重排序是否引入 Rerank 模型对召回结果重新排序初次使用时建议检索模式选择“混合检索”。TopK 设置在 3 到 5 之间。Score 阈值先设置为 0.4 到 0.5 之间后续根据实际效果调整。5. 实战创建知识库问答应用知识库创建完成后我们来创建一个可用的问答应用。5.1 创建空白应用在 Dify 控制台点击“创建应用”选择“聊天助手”类型。在应用编排页面中左侧是对话预览中间是 Prompt 编排区域右侧可以设置模型参数和上下文。在“上下文”区域选择我们刚才创建的知识库上下文产品技术手册然后配置系统 Prompt你是一个企业知识库问答助手。请根据上下文中的资料回答用户问题。 如果上下文中没有相关信息请明确回答“知识库中暂未找到相关信息”不要编造答案。 回答时请分点说明并标注引用的文档片段。这里的关键是“不要编造答案”这一句。企业知识库问答最怕的就是模型在找不到资料时强行输出一个“看起来合理”的答案。5.2 配置模型参数在右侧模型参数中建议设置温度Temperature0.2 左右。温度越低回答越稳定适合知识库问答。最大 Token 数根据你的答案长度需要调整建议至少 512。顶部概率Top P0.85 左右。5.3 发布应用右上角点击“发布”然后通过“运行”按钮在调试页面中测试问答。提问一个与知识库相关的问题观察回答是否准确、是否引用了正确的文档片段。然后故意问一个与知识库无关的问题观察模型是否会诚实回答“不知道”。到这里一个最基础的 Dify RAG 问答应用就完成了。但如果你希望这套系统更接近企业级我们还需要把工作流编排起来。6. 实战基于 Dify 工作流的 RAG 智能问答借助 Dify 的工作流能力我们可以把问答过程设计得更严谨。下面以一个“企业技术支持问答”的场景为例完整演示工作流的搭建思路。6.1 需求分析我们希望实现如下流程用户提问。系统先对用户问题进行意图分类。如果问题属于“产品技术类”进入知识库检索流程。检索到相关内容后交给大模型生成回答。如果问题属于“闲聊”则直接以友好的方式回应。如果检索结果为空或相似度过低则提示用户换种方式提问。6.2 工作流节点设计在 Dify 中点击“创建工作流”选择从空白开始。然后依次添加节点开始节点定义输入变量sys.query即用户的原始问题。LLM 节点意图分类调用分类模型判断问题意图输出结果为technical或chat。条件分支节点IF/ELSE判断意图分类结果如果为technical进入知识检索分支。如果为chat进入闲聊回复分支。知识检索节点选择“产品技术手册”知识库并设置检索参数。判断节点判断知识检索结果是否为空。如果检索结果非空进入 LLM 生成节点。如果检索结果为空进入“未找到答案”回复分支。LLM 节点生成回答将用户问题与知识检索结果拼接为 Prompt生成最终回答。结束节点输出最终结果给用户。6.3 配置知识检索节点在知识检索节点中需要做两件事选择要检索的知识库。将“开始节点”中的sys.query作为检索的查询输入。检索节点输出的是一个数组包含了命中的文本片段、相似度分数、文档来源等信息。6.4 配置生成回答的 LLM 节点生成回答的 Prompt 可以这样写你是企业技术支持助手。请严格依据以下资料回答用户问题。 资料内容 {{#context#}} 用户问题 {{#sys.query#}} 要求 1. 如果资料中没有答案明确回答“资料库中暂无相关信息”。 2. 不要编造资料中不存在的参数或功能。 3. 答案用简洁的中文分点输出。这里{{#context#}}是知识检索节点的输出引用方式{{#sys.query#}}是开始节点的用户输入。不同版本 Dify 的变量引用格式基本相同但具体到界面中更推荐直接点击输入框左侧的“变量”按钮插入避免手动拼写错误。6.5 运行工作流验证配置完成后保存并运行工作流。在运行面板输入一个问题例如产品无法连接网络应该如何排查观察工作流中的每个节点是否按预期执行。可以在每个节点上查看输入和输出确认知识检索是否命中了正确的文档以及最终 LLM 是否基于检索内容生成了答案。这也是工作流比“直接对话应用”更直观的原因你可以在可视化界面中看到每一步发生了什么。6.6 将工作流接入应用工作流调试通过后回到应用设置将应用类型切换为“工作流”或者新建一个“工作流”类型的应用并关联该工作流。这样用户在对话时就会按工作流的逻辑执行。7. 对接 API把问答能力集成到你的业务系统如果只是在一个独立平台上对话还不能叫“集成”。在真实项目中我们通常需要把问答能力嵌入到现有的业务系统例如网站客服、企业微信机器人、内部管理后台。Dify 为每个应用都提供了 API 访问能力。7.1 获取 API 密钥在应用详情页点击顶部“访问 API”进入 API 管理页面。在这里可以创建新的 API 密钥。密钥格式类似app-xxxxxxxxxxxxxxxx请妥善保管这个密钥不要泄露到前端页面。生产环境中应通过后端服务调用 Dify API。7.2 使用 Python 调用 Dify API下面是一个 Python 调用示例核心是向/chat-messages接口发送对话请求。import requests import json # Dify 应用 API 地址 url http://你的服务器IP/v1/chat-messages # 在 Dify 控制台创建的 API 密钥 api_key app-xxxxxxxxxxxxxxxx # 请求头 headers { Authorization: fBearer {api_key}, Content-Type: application/json } # 请求体 payload { inputs: {}, query: 产品无法连接网络应该如何排查, response_mode: blocking, conversation_id: , user: test-user-001 } response requests.post(url, headersheaders, jsonpayload) if response.status_code 200: result response.json() print(回答, result.get(answer)) print(会话ID, result.get(conversation_id)) else: print(请求失败, response.status_code, response.text)参数说明inputs工作流定义的输入变量简单问答应用可以传空{}。query用户的问题。response_modeblocking表示阻塞等待返回完整结果streaming表示流式返回。conversation_id会话标识。第一次传空字符串服务端会返回新的会话 ID后续对话传同一个 ID 可以保持上下文。user业务系统中的用户标识用于区分不同用户。如果你希望在接口请求时传入额外的业务参数可以在 Dify 工作流的“开始节点”中新增输入变量并通过inputs字段传递。8. 常见问题与排查思路在实际搭建和使用的过程中最容易遇到下面几类问题。8.1 本地部署 Dify 失败问题现象常见原因解决思路容器启动失败端口被占用修改.env中的EXPOSE_NGINX_PORT镜像拉取超时网络问题配置 Docker 镜像加速源页面无法访问容器未完全启动执行docker compose ps检查状态数据无法持久化卷挂载异常检查docker/volumes目录权限建议在启动前先执行docker compose pull手动拉取所有镜像确认都能成功后再up -d。8.2 知识库文档无法索引问题现象常见原因解决思路上传后一直处于“处理中”Embedding 模型 API Key 配置错误检查模型供应商配置和余额处理失败提示包含“分段”文档格式特殊或扫描版 PDF转换为文本后再上传索引成功但检索不到内容文档分段过大或检索阈值过高调大 TopK、降低 Score 阈值扫描版 PDF 其实是图片需要先做 OCR 识别成文字后再上传否则检索效果会非常差。8.3 工作流提示“请安装缺失的包”在 Dify 的代码执行节点中如果你使用了系统未内置的 Python 包运行时会报错。解决方法是在 Dify 的容器环境中安装缺失的包。以api容器为例docker exec -it docker-api-1 bash pip install 包名然后重启 API 容器docker restart docker-api-1需要说明的是直接进入容器安装的包在容器重建后会丢失。生产环境更推荐在 Dify 的自定义插件或服务中处理这类需求而不是临时进容器装包。8.4 回答仍然出现幻觉如果检索确实命中了正确片段但模型依然乱答需要检查Prompt 中是否强调了“仅依据上下文回答”。温度参数是否设置过高。是否将多个无关片段同时传给了模型导致信息混杂。检索到的片段是否长度过短缺少必要上下文。8.5 API 调用返回 401一定是 API 密钥错误或密钥与当前应用不对应。检查请求头中的Authorization格式Bearer app-xxxxxxxx注意中间有一个空格且密钥要与目标应用匹配。9. 最佳实践与工程建议到这里整套系统已经能跑起来了。但企业级应用和演示 Demo 之间还有一段距离。以下是我在实际落地过程中比较看重的一些细节。9.1 知识库设计建议先清洗文档再上传。不要一股脑把所有 PDF 丢进去。建议先去除页眉页脚、目录、表格中的无效内容避免这些噪音进入向量库。控制分段大小。中文场景中分段长度建议在 300 到 800 字之间。过短会丢失上下文过长会引入噪音并增加 Token 成本。为知识库区分主题。把产品手册、故障排查、销售话术分成不同的知识库。在工作流中根据用户意图选择特定的知识库检索效果通常优于一个巨大的混合知识库。9.2 检索策略调优如果业务文档是规范化文本优先用“混合检索”。先不要追求高精度先把 TopK 调大一些观察召回内容质量再逐步收紧。Score 阈值需要反复测试。设得太高很多问题会回答“不知道”设得太低会召回无关内容。有条件的话引入重排序Rerank模型对召回结果进行二次筛选效果提升非常明显。9.3 Prompt 设计建议面向企业知识库的 Prompt最重要的三句话是1. 请严格依据上下文资料回答。 2. 如果资料中没有相关信息明确说不知道。 3. 不要编造不存在的参数、功能或结论。这三点能大幅降低幻觉概率。9.4 安全与权限Dify 管理后台要设置强密码并限制访问来源。API 密钥不要直接暴露在浏览器端必须由后端服务转发。如果系统涉及敏感数据建议在内网部署或者在反向代理层增加认证。多人使用时通过user参数区分不同用户便于审计和会话隔离。9.5 维护与监控定期备份 Dify 的数据库和向量库数据防止容器异常导致数据丢失。关注模型的调用量和费用设置预算告警。记录用户的“回答不满意”反馈定期分析哪些问题检索不到答案持续优化知识库。Dify 版本更新较快升级前先备份.env文件和volumes目录。10. 总结与下一步学习方向到这里我们已经完成了从零部署 Dify、创建 RAG 知识库、搭建工作流应用、对接 API 的完整闭环。你可以打开自己的 Dify 控制台试着上传一份真实业务文档造一个知识库问答应用然后通过工作流把问答逻辑编排起来。如果基础流程已经跑通下一步可以尝试的方向包括接入多个知识库并在工作流中做基于意图的检索路由。引入重排序模型优化检索精度。将 Dify 应用接入企业微信、飞书、钉钉等 IM 平台。使用 Dify 的 Agent 能力让模型在回答问题前自行决定调用哪些工具和知识库。分析用户反馈数据建立知识库持续优化循环。RAG 应用往往是“搭起来容易调好难”。真正拉开差距的不是你会不会拖拽节点而是你对知识库分段、检索策略、Prompt 设计和业务场景的理解深度。这也是做 AI 应用开发最值得投入时间的地方。希望这篇文章能帮你迈出第一步。如果你在搭建过程中遇到了其他问题欢迎在评论区留言讨论。