本地知识库实战：Ollama + DeepSeek-R1 + Dify 部署与调优

简介：这份文档面向希望本地搭建个人知识库的开发者与AI爱好者，围绕ollama、deepseek、docker与Dify四类工具的协同使用展开，帮助读者理解从模型部署到知识库问答的完整链路，适合具备基础命令行操作能力、想低成本落地私有知识检索系统的中级学习者。资源包共1个doc文件，约5.19MB，以图文步骤形式记录环境变量配置、模型拉取、容器启动与知识库创建等关键环节，便于对照操作与复盘。目前已有3396人学习下载，说明该部署路线在社区中具有较高关注度。文档内容覆盖ollama安装与版本校验、deepseek-r1模型下载与运行、docker-desktop部署Dify项目、分词方式配置及聊天应用接入ollama接口等要点，并提示命令行需保持运行、模型参数可按需调整等细节，可作为搭建个人知识库时的操作参考与排错线索。

1. 本地知识库这套组合拳：为什么我选 Ollama + DeepSeek + Dify 而不是直接上云

上周有个做运维的朋友问我，公司内部一堆 PDF 手册和故障记录，想搞个能问答的知识库，但数据不能出内网。我第一反应就是这套组合：Ollama 跑本地模型、DeepSeek-R1 做推理、Docker 起 Dify 做知识库管理和对话界面。整套东西全在自己机器上，断网也能用，模型文件落在本地硬盘，知识库向量存在 Docker 卷里，没有任何数据往外走。

这套方案适合谁？手上有 Windows 10/11 机器、内存 16G 起步、愿意花半小时折腾环境的人。新手照着步骤能跑通，熟手可以跳过基础部分直接看参数调优和避坑。它解决的核心问题是：把「模型推理」和「知识库检索」拆成两个独立服务，Ollama 负责前者，Dify 负责后者，中间用 HTTP 接口对接，谁挂了都不影响另一个。下面按我实际部署的顺序拆，每一步都标清楚参数和容易翻车的地方。

2. 先把 Ollama 和 DeepSeek-R1 跑起来：安装、环境变量与模型拉取

2.1 Ollama 安装与版本验证

Windows 下直接去 Ollama 官网下安装包，双击走完 Install 流程就行。装完别急着拉模型，先验证一下。按Win+R输入cmd打开命令行，执行：

ollama --version

正常会回一行版本号，比如ollama version is 0.x.x。如果提示「不是内部或外部命令」，说明安装时没把路径写进系统 PATH，要么重装，要么手动把C:\Users\你的用户名\AppData\Local\Programs\Ollama加进环境变量。这一步看着简单，但我见过不少人卡在这，以为装失败了，其实是命令行没刷新环境变量，关掉重开一个 cmd 窗口就好。

2.2 环境变量：模型存放路径必须提前改

这是整套部署里最容易被忽略、后面最难受的一步。Ollama 默认把模型存在 C 盘用户目录下，DeepSeek-R1 就算只拉 1.5B 版本也要占一两个 G，7B 以上直接十几个 G，C 盘空间紧张的人拉到一半就报磁盘不足。所以装完第一件事就是改存储路径。

右键「此电脑」→ 属性 → 高级系统设置 → 环境变量，在「系统变量」里新建一条：

OLLAMA_MODELS决定模型文件落哪，OLLAMA_HOST决定监听地址。第二个变量是给后面 Dify 对接埋的伏笔——Docker 容器里的 Dify 要访问宿主机的 Ollama，如果 Ollama 只监听127.0.0.1，容器里是够不着的。设成0.0.0.0表示监听所有网卡，容器通过host.docker.internal就能连上。改完环境变量一定要重启命令行窗口，不然新变量不生效。

2.3 拉取 DeepSeek-R1 模型并保持服务运行

环境变量配好后，在命令行里执行：

ollama run deepseek-r1:1.5b

这条命令做两件事：先检查本地有没有这个模型，没有就从官方源拉取，拉完直接进入交互式对话。1.5B 版本下载量大概 1G 出头，网速正常几分钟就完事；如果你机器显存够，想上 7B 或 14B，把标签换成deepseek-r1:7b即可，但下载时间会成倍增加，我见过拉 14B 拉了两个多小时的。

拉完之后命令行会变成>>>提示符，直接输入问题就能对话。这里有个关键认知：这个命令行窗口不能关。Ollama 的模型服务是挂在这个进程上的，窗口一关，11434端口就没了，后面 Dify 对接会直接报连接失败。如果你不小心关了，重新执行ollama run deepseek-r1:1.5b就行，模型已经在本地了，秒进，不用重新下载。

提示：想确认服务是否在跑，另开一个命令行执行ollama list，能看到模型列表就说明本地有货；再执行curl http://127.0.0.1:11434/api/tags能返回 JSON，说明服务端口正常。

3. Docker 拉起 Dify：源码、compose 文件与容器编排

3.1 获取 Dify 源码与目录结构确认

Dify 是开源项目，从它的 GitHub 仓库把源码下下来，解压后能看到docker目录，里面放着docker-compose.yaml和.env.example。有 git 的话直接克隆更省事：

git clone https://github.com/langgenius/dify.git cd dify/docker

进到docker目录后先别急着 up，把.env.example复制一份改名成.env：

copy .env.example .env

这个.env是 compose 编排的配置文件，里面定义了数据库密码、端口映射、镜像版本等。不改也能跑，但默认端口是 80，如果你本机 80 端口被别的服务占了（比如 IIS 或某些开发工具），启动会报端口冲突。稳妥做法是打开.env把EXPOSE_NGINX_PORT改成8080之类没被占用的端口。

3.2 docker-compose up 启动与镜像拉取

在docker目录的地址栏输入cmd回车，直接在当前路径打开命令行，执行：

docker-compose up -d

-d是后台运行，不加的话日志会刷满整个窗口。第一次执行会拉一堆镜像——PostgreSQL、Redis、Weaviate、Nginx、API 服务、Web 前端，加起来好几个 G，时间取决于网速，十几分钟到半小时都正常。拉完后 Docker Desktop 的 Containers 列表里会出现一组dify-开头的容器，状态变成 running 就说明起来了。

这里有个版本号对不上的问题很多人会慌：compose 文件里写的镜像 tag 和你本地拉下来的 digest 可能不完全一致，只要容器状态是 running、日志没报错，就不用管。真正要盯的是dify-api和dify-web这两个容器，它们挂了整个界面就打不开。启动失败最常见的原因是内存不够——Dify 全家桶跑起来至少吃 4G 内存，8G 的机器建议先把其他大程序关掉。

3.3 首次登录与管理员账号初始化

容器全部 running 后，浏览器打开http://127.0.0.1（如果你改了端口就是http://127.0.0.1:8080）。第一次访问会跳转到初始化页面，要求设置管理员邮箱和密码，设完就能进主界面。这个账号信息存在 PostgreSQL 容器里，只要不删数据卷，下次启动直接登录，不用重设。

进主界面后先别急着建知识库，去「设置 → 模型供应商」确认一下 Ollama 能不能连上，连不上后面全白搭。这一步的验证方法在下一章展开。

4. 知识库与对话应用：分词、向量化与 Ollama 接口对接

4.1 创建知识库与分段策略选择

主界面左侧点「知识库」→「创建知识库」，把你的 PDF、Word、Markdown 拖进去。Dify 会给一套默认的分段配置，核心参数是分段长度和重叠长度。默认分段大概 500 字符、重叠 50 字符，对结构清晰的手册够用；如果你的文档是那种大段连续文字、没有小标题的，建议把分段调小到 300 左右、重叠调到 80，避免一个语义块被硬切断导致检索时答非所问。

保存后 Dify 开始解析和向量化，这个过程吃 CPU，文档多的话等几分钟到十几分钟。解析完成后点「前往文档」，能看到每个分段被切成了什么样，以及对应的向量是否生成成功。如果某个文档一直卡在「处理中」，多半是文件格式有问题或者编码不对，换一份重新上传试试。

4.2 在 Dify 中接入 Ollama 模型供应商

回到「设置 → 模型供应商」，往下拉找到 Ollama，点「添加模型」。这里要填一个 Base URL，填的是从 Docker 容器视角看宿主机的地址：

http://host.docker.internal:11434

为什么不是127.0.0.1:11434？因为 Dify 跑在容器里，容器里的127.0.0.1指的是容器自己，不是你的 Windows 宿主机。host.docker.internal是 Docker Desktop 提供的特殊域名，专门用来从容器访问宿主机。这也是前面为什么要把OLLAMA_HOST设成0.0.0.0——如果 Ollama 只监听回环地址，容器通过这个域名过来也会被拒。

填完 URL 后，模型名称填deepseek-r1:1.5b，和你ollama list里看到的名字一字不差。保存成功后，供应商列表里会出现 Ollama 卡片，点进去能看到模型已就绪。如果报连接失败，按这个顺序排查：Ollama 命令行窗口是不是关了 →OLLAMA_HOST环境变量设了没 → 改完环境变量重启过 Ollama 没。

4.3 创建聊天应用并挂载知识库

左侧「工作室」→「创建空白应用」→ 选「聊天助手」，起个名字点创建。进到编排界面，右上角模型下拉框里选刚才接入的deepseek-r1:1.5b。然后找到「上下文」旁边的加号，把之前建好的知识库挂上去。

挂载后可以调两个关键参数：召回分段数和评分阈值。召回数默认 4，意思是每次提问从知识库里捞最相关的 4 段塞给模型；文档量大、问题跨度广的话可以调到 6 到 8，但太多会挤占模型上下文窗口。评分阈值控制相关性门槛，调高只召回高匹配段落、回答更精准但可能漏，调低召回范围大但容易带进无关内容。我一般先默认跑几轮，看回答质量再微调。

测试时先问一个知识库里明确有的问题，比如某份手册里的操作步骤，看回答是否引用了对应段落。Dify 会在回答下方标注引用来源，点开能核对原文。如果模型答得泛泛而谈、没引用知识库，说明召回没生效，检查知识库是否真的挂上了、文档是否解析完成。

5. 避坑清单：五个我实际踩过的坑

坑一：Dify 报「模型连接失败」，但 Ollama 明明在跑。现象是添加模型供应商时一直转圈然后报错。原因九成是 Base URL 填了127.0.0.1，容器里访问不到宿主机。解决：改成http://host.docker.internal:11434，同时确认OLLAMA_HOST=0.0.0.0:11434已设且 Ollama 重启过。

坑二：模型拉到一半报磁盘空间不足。现象是ollama run下载进度条走到一半中断。原因是默认模型路径在 C 盘，空间不够。解决：提前设OLLAMA_MODELS指向大容量盘，已经下了一半的删掉重拉，Ollama 不支持断点续传到新路径。

坑三：docker-compose up卡在拉镜像，或者容器起来又退出。现象是某个容器状态反复 restarting。先看日志docker logs dify-api，常见是内存不足被 OOM kill，或者 80 端口被占。解决：关掉占端口的服务或改.env里的EXPOSE_NGINX_PORT，内存不够就加内存或减少同时运行的其他容器。

坑四：知识库文档解析一直「处理中」。现象是上传后状态不动。原因是文件编码或格式不被解析器支持，比如扫描版 PDF 没有文字层。解决：换可复制文字的 PDF，或者先用 OCR 转一遍；Word 文档另存为 docx 而非 doc。

坑五：对话回答不引用知识库，像在瞎编。现象是问手册里的内容，模型给的是通用回答。原因是知识库没挂到应用上，或者召回阈值太高一段都没捞到。解决：检查编排界面「上下文」是否已添加知识库，把评分阈值调低到 0.3 左右再试，同时确认文档解析完成且分段内容可读。

6. 调优与验证：让 1.5B 模型在知识库场景下真正可用

1.5B 的 DeepSeek-R1 胜在轻量、启动快，但推理能力和 7B 以上有明显差距，直接裸聊容易答得浅。我的做法是在 Dify 的「提示词」编排里加一段系统指令，强制模型优先基于上下文回答、找不到就说找不到，而不是自由发挥。具体在聊天助手编排页的「指令」框里写：

你是一个基于内部文档的问答助手。回答时优先使用提供的上下文内容， 如果上下文中没有相关信息，直接说明「文档中未找到相关内容」，不要编造。 回答尽量简洁，涉及步骤时按顺序列出。

这段指令配合知识库召回，能把 1.5B 的「乱答」概率压下去不少。另一个技巧是调低模型的 temperature，在模型参数里设到 0.3 以下，输出更稳定、更贴文档，代价是灵活性下降，看你场景取舍。

验证知识库是否真的生效，我习惯用三个层次的问题测：第一层问文档里明确写了的操作步骤，看是否准确引用；第二层问需要跨两个段落综合的问题，看召回是否覆盖到；第三层问文档里根本没有的内容，看模型是否老实说「未找到」。三层都过了，这套知识库才算能用。

还有个容易被忽略的点：Ollama 那个命令行窗口长期开着，机器休眠或重启后服务就断了，Dify 那边不会主动提示，只会在你提问时报错。我的习惯是每次开机先跑一遍ollama list确认服务活着，再去开 Dify。从那以后我每次部署完这套东西，都会把「Ollama 服务自检」写进日常检查清单，省得半夜被叫起来排查「知识库怎么不回答了」。希望帮到你。

本文还有配套的精品资源，点击获取