Dify + Ollama 实战：搭建数据不出本地的私有知识库
为什么需要”本地私有”组合
把企业内部文档、技术手册、产品资料交给 ChatGPT 这类在线服务，绕不开两个顾虑：一是数据上传到第三方服务器，存在合规和泄露风险；二是断网或服务降级时业务直接停摆。Dify + Ollama 这套组合正好对症下药：Ollama 在本地跑开源大模型，所有推理过程不离开机器；Dify 提供可视化的 RAG 流程，把文档切片、向量化、检索、回答串成一条线。最终成果是一个可以基于内部文档回答问题的聊天助手，部署在自己的服务器或个人电脑上。
前置准备
整个方案依赖两个组件在同一台机器（或能互通的网络）上同时运行。
Ollama 端
Ollama 是本地大模型运行框架，负责实际加载模型和提供推理接口。它没有复杂的安装过程，macOS 直接下载安装包，Linux 一条 curl 命令即可完成。安装完成后 Ollama 默认监听 11434 端口（具体配置请参考 Ollama 官方文档）。
Dify 端
Dify 的部署非常成熟，仓库自带 Docker Compose 配置。按官方 README 要求，最低硬件为 CPU ≥ 2 Core，RAM ≥ 4 GiB，并需要提前安装 Docker 与 Docker Compose v2.24.0 或更高版本。部署命令如下：
cd dify
cd docker
cp .env.example .env
docker compose up -d启动完成后浏览器访问 http://localhost/install，跟着引导完成管理员账号创建。
如果之后需要自定义配置，编辑 docker/.env 文件，基础启动项在 docker/.env.example，可选的进阶变量按主题拆分在 docker/envs/ 目录下。改完之后在 docker 目录重新执行 docker compose up -d 即可。
> 这里有一个容易被忽略的部署规范：Dify 跑在 Docker 容器里，Ollama 跑在宿主机上，两者并不在同一网络命名空间。后面会专门讲怎么处理这个问题。
让 Ollama 准备好两个角色
在 RAG 系统里，”大模型”并不是只干一件事，它至少扮演两个角色：
| 角色 | 职责 | 典型模型 |
|---|---|---|
| Embedding 模型 | 把文本转成向量，用于后续相似度检索 | nomic-embed-text、mxbai-embed-large |
| 对话模型 | 根据检索到的上下文生成最终回答 | qwen2.5、llama3、mistral |
为什么需要两个？因为负责”理解语义做检索”的模型和负责”流利对话写答案”的模型，最优选择通常不一样。Embedding 模型小而快，几百 MB 就能跑；对话模型一般更大，对显存有要求。
先用 Ollama 把两个模型都拉下来：
ollama pull nomic-embed-text
ollama pull qwen2.5如果公司对中文支持要求更高，可以替换 qwen2.5 为 qwen2.5:7b 或其他中文能力更强的版本；如果显存紧张，对话模型也可以选更小的规格。具体可用模型请参考 Ollama 模型库。
Dify 接入 Ollama
进入 Dify 控制台，依次点击 设置 → 模型供应商，在列表中找到 Ollama。点击添加，填入以下信息：
- API Key：随便填一个字符串即可（Ollama 默认不校验）
- API Base URL：这是最关键的一项
如果 Dify 和 Ollama 装在同一台机器的 Docker 中，不要填 http://localhost:11434，因为这里的 localhost 指的是 Dify 容器内部。正确写法是：
http://host.docker.internal:11434host.docker.internal 是 Docker 为容器提供的特殊 DNS，专门用来访问宿主机。如果是 Linux 服务器上的 Docker，需要确认 Docker 版本是否支持该特性，或者改为宿主机在局域网中的实际 IP。跨机器部署时同理，填 Ollama 所在机器的可达地址即可。
填好后保存，再点击 系统模型设置，把 Ollama 加入可用列表。之后在创建知识库和应用时就能选到本地的对话模型和 embedding 模型了。
构建第一个知识库
回到 Dify 顶部菜单的 知识库，点击创建知识库。把准备好的 PDF、Word、Markdown 文档拖进去。支持的格式不止这几种，具体清单请参考 Dify 官方文档。
上传文档后进入分段与清洗步骤。这里有几个关键选项：
- 分段模式：通用模式适合结构清晰的文档，父子模式适合带章节的长文档
- Embedding 模型：下拉框里选择刚才在 Ollama 配置好的
nomic-embed-text - 分段长度：中文文档建议 500~1000 字一段，过短会丢失上下文，过长会稀释检索精度
配置完成后点击 保存并处理，Dify 会调用 Ollama 把每个文档片段转成向量并存入数据库。这步会消耗一定时间和 CPU/内存。
{{图：知识库分段设置页面，标注 embedding 模型选择与分段长度设置}}
搭建聊天助手
知识库就绪后，到 工作室 创建一个聊天助手类型应用。在右侧编排面板里：
- 把上一步创建的知识库拖入上下文节点
- 把 Ollama 的对话模型（如
qwen2.5）设为 LLM - 在提示词里说明助手身份，例如：”你是一个企业内部知识助手，请只根据上下文回答，不知道就说不知道”
Dify 的提示词 IDE 支持多轮对比调试，可以同时跑几个模型看效果差异。
测试与验证
发布前先在调试面板里提问几个文档里的具体问题验证：
- 提问文档原文出现过的内容 → 应该能引用上下文回答
- 提问文档没覆盖的内容 → 应该拒绝回答，而不是瞎编
如果发现回答完全脱离了文档，大概率是知识库没正确关联；如果回答质量差，可以调整检索参数中的 Top K（召回片段数）和 Score 阈值。
{{图：Dify 聊天助手调试界面，展示用户提问与带引用来源的回答}}
进阶玩法
基础功能跑通之后，还有一些可以继续打磨的方向：
- 分段策略调优：对中文长文档，规则分段经常在表格、代码块处切断，可以改用父子模式保留上下文
- 检索增强：开启重排序（Rerank）能显著提升 Top 结果的相关性，但需要额外部署 Rerank 模型
- 发布为 API：调试满意后点发布，Dify 会给出一个 OpenAI 兼容的 API endpoint，前端、业务系统可以直接调用
- 持续运营：Dify 的 LLMOps 模块会记录每一次对话和用户反馈，是后续优化模型和提示词的依据
常见坑与排查
坑一：连接 Ollama 失败
检查 API Base URL 是不是用了 localhost。在 Dify 容器里 localhost 指向容器本身，不是宿主机。改成 host.docker.internal 或宿主机局域网 IP。
坑二：选不到 Ollama 模型
说明 Ollama 还没在 Dify 的模型供应商列表里添加，或者添加后没有在系统模型设置里启用。
坑三：embedding 阶段报错
通常是 embedding 模型没在 Ollama 里 pull 过。Dify 调用的是模型名，实际权重必须在 Ollama 本地存在，否则会 404。
坑四：中文文档检索效果差
优先确认 embedding 模型对中文的支持程度。nomic-embed-text 对中文表现一般，如果文档以中文为主，可以考虑替换为多语言 embedding 模型或国产 embedding 模型。
坑五：回答很慢
对话模型越大、首 token 延迟越高。如果对响应速度敏感，选 7B 以下规格的模型，并把 num_ctx（上下文长度）调到够用即可，不要盲目给大。
相关评测参考
如果想了解 Dify 在 LLM 应用开发平台中的横向对比，可以看这篇 Dify 评测：https://fangyinai.com/ai-tools/llm-apps/741/ ；Ollama 在本地大模型工具中的定位与同类对比，可以看这篇 Ollama 评测：https://fangyinai.com/ai-tools/local-ai/212/ 。
整套方案的核心思路就一句话：让 Dify 负责”知识怎么组织、答案怎么生成”的编排逻辑，让 Ollama 负责”数据永远不离开本机”的执行环节。两者通过标准 HTTP 接口解耦，后续要换模型、换检索策略、换部署方式，都不需要推倒重来。
评论(0)