简介：《DeepSeek+Dify本地部署知识库》是一份面向大模型应用初学者与个人开发者的实操型PDF文档，聚焦在Windows环境下搭建可离线运行的AI知识库，适合希望绕开复杂云端配置、快速理解本地部署链路的读者。文档围绕系统环境变量、Ollama模型管理、DeepSeek-R1与bge-m3拉取、Docker镜像配置以及Dify平台安装与知识库创建展开，配有界面截图与关键配置说明，可帮助读者建立从模型运行到应用接入的完整认知。资源包共1个PDF文件，大小约1.47MB，轻量便于查阅和随查随用。目前已有2349人学习，说明该主题在AI知识库落地场景中关注度较高。读者可从中获得本地部署的整体流程框架、常见环境配置要点与模型接入Dify的排错思路，并据此复现一套可对话、可挂载知识库的本地AI应用，适合作为入门实践与部署清单参考。

1. 从一台 16G 内存的办公机说起：DeepSeek+Dify 本地知识库到底解决什么

有个做工程投标的朋友问过我一个很实际的问题：几百份历史标书、技术规范、验收报告，能不能直接丢给在线大模型去问？答案通常是不能，卡点不在模型能力，而在数据出不了内网。DeepSeek+Dify 这套本地部署知识库方案要解决的就是这件事——模型权重、向量库、Web 控制台全部跑在自己机器上，断网也能完成"提问—检索—作答"的完整链路。整条栈的分工很清楚：Ollama 管模型拉取与推理，Docker 管容器编排，Dify 管应用层和知识库。Windows 11 上一台 16G 内存的办公机，跑 8B 级别的对话模型加一个 bge-m3 向量模型是够用的。适合手上有一堆 PDF/Word 要检索、又不愿意把内容传出去的从业者，也适合想先把 RAG 全链路摸一遍再谈上生产的技术人。不适合指望它替代线上大模型 API 的人。

2. Ollama 落地：模型权重存哪、端口怎么验、参数档位怎么选

这一章解决的是"模型跑起来"这件事。很多人装完 Ollama 直接ollama run，跑到一半发现 C 盘红了，或者拉完模型发现 Dify 连不上，回头再改就得多花一倍时间。顺序应该反过来：先定权重目录，再装软件，最后拉模型。

2.1 为什么先设 OLLAMA_MODELS 而不是先装软件

Ollama 在 Windows 上默认把模型权重放在用户目录下的.ollama\models，也就是 C 盘。deepseek-r1:8b 这一档的量化权重在 5GB 上下，bge-m3 约 1.2GB，看起来不多，但 Ollama 拉取过程中会有临时分片，加上后续你可能再拉 14B、32B 做对比，C 盘空间消耗是滚雪球式的。血泪经验是：等 C 盘报警再迁目录，得先删模型、改变量、重拉一遍，白等半小时。

正确的做法是装软件之前先把环境变量写好。图形界面路径是右击"此电脑"—属性—高级系统设置—环境变量—新建用户变量；命令行等价写法如下：

# 把 Ollama 权重目录指向空间充足的盘，装软件之前执行 setx OLLAMA_MODELS "E:\Ai\Ollama3" # 变量写完后新开一个终端验证，旧终端读不到新变量 echo %OLLAMA_MODELS%

setx写入的是用户级环境变量，持久化到注册表，但只对之后新开的进程生效，所以写完必须重开终端，稳妥一点直接重启系统。变量值必须是已经存在的目录，或者至少父目录存在，Ollama 首次启动时会自己在里面建models\blobs和models\manifests两级结构。如果你习惯用系统级变量而非用户级，效果一样，只是所有账户共享。

提示：setx对超过 1024 字符的值会截断，路径别写太长，也别塞多个路径进去。

变量设完再装 Ollama，安装包双击后基本一路默认，装完托盘区会出现一个小图标，说明后台服务已经起来了。这一步不需要你手动启动任何东西。

2.2 安装后的第一件事是验端口，不是拉模型

Ollama 装完会在本地起一个 HTTP 服务，默认监听127.0.0.1:11434。后面 Dify 接入模型、写脚本批量测试，走的都是这个端口。所以装完先验一下，比直接拉 5GB 模型高效得多：

# 确认服务在监听，正常应返回 {"version":"..."} 之类的 JSON curl http://127.0.0.1:11434/api/tags # 或者用 Ollama 自己的客户端命令看已下载模型列表 ollama list

/api/tags返回空列表也是正常的，代表服务通了但还没拉模型。如果 curl 直接报连接被拒绝，先看托盘图标是否在、任务管理器里有没有ollama.exe和ollama app.exe两个进程，再考虑端口冲突——11434 被别的程序占用的情况不常见，但确实存在。改端口的方式是设环境变量OLLAMA_HOST=0.0.0.0:11435，注意这里同时决定了监听地址，只写端口号会退回默认。

还有一个容易被忽略的点：默认只听127.0.0.1。这意味着宿主机上的浏览器能访问，但 Docker 容器内部通过host.docker.internal访问时，走的是宿主机网卡地址，某些配置下会被拒。后面第 5 章会专门讲这个坑的排查方法，这里先记住一个结论：如果 Dify 里加 Ollama 供应商时连不通，把OLLAMA_HOST显式设成0.0.0.0:11434再重启 Ollama，八成能解决。

2.3 模型档位怎么选：不是越大越好，是能塞进去才好

拉模型这一步，新手最容易犯的错是照着教程抄deepseek-r1:70b，然后机器卡死。参数量直接对应内存/显存占用，量化后的粗略换算可以按"参数量 × 0.6GB"估，再留 2GB 给上下文和运行时。下表是我在几台不同配置机器上实际跑下来的经验区间，不是官方指标，仅供参考：

8B 这一档是大多数人应该选的起点：16G 内存的机器能塞下，纯 CPU 推理时首 token 大概几秒到十几秒，可以接受。如果你有 8GB 以上显存的独立显卡，Ollama 会自动把部分层 offload 到 GPU，速度提升非常明显，这个不需要手动配置。

拉取命令很直接：

# 拉取对话模型，run 会自动触发 pull 再进入交互式会话 ollama run deepseek-r1:8b # 交互式会话里问一句测试，退出用 /bye，或者 Ctrl+C 中断、Ctrl+D 发送 EOF # 退出后拉取向量模型，这个模型不产出对话，只做 embedding ollama pull bge-m3 # 最后确认两个模型都在 ollama list

ollama run和ollama pull的区别值得说清楚：run是"拉取 + 启动交互会话"，模型已存在时直接进会话；pull只下载不启动。测试完对话模型记得退干净，不然它占着显存，后续拉 bge-m3 或者启动 Dify 时资源会紧张。

bge-m3 是这套方案里的向量模型，作用是把知识库里的文本块转成向量，检索时靠向量相似度找回相关段落。它支持多语言、长文本输入，输出 1024 维向量，这个维度数字后面在 Dify 里配 Text Embedding 时要对上。它不参与对话生成，所以哪怕你的机器跑 8B 对话模型有点喘，跑 bge-m3 一般没问题。

ollama list的输出里会列出模型名、大小和修改时间，模型名那一列（比如deepseek-r1:8b）后面在 Dify 里填模型名称时必须一字不差，包括 tag。这一点看起来很废话，但确实是新手填错频率最高的地方之一——有人填deepseek-r1不带 tag，有人填deepseek-r1:8B大写 B，都会报模型不存在。

3. Docker 与 Dify 编排：三个配置文件决定这套栈能不能起来

Ollama 只负责模型，Dify 是一个由多个服务组成的应用（Web 前端、API、后台 worker、数据库、缓存、向量库、沙箱、反向代理），靠 Docker Compose 一次性拉起来。这一章的重点不是"点下一步"，而是三个配置文件——Docker Engine 配置、.env、docker-compose.yaml——各自管什么，改错了会以什么形式报错。

3.1 Docker Desktop 的两个设置：磁盘位置和镜像加速

Docker Desktop 安装本身没什么可讲的，双击安装包，勾选接受协议，装完重启一次。真正要动的是装完之后的 Settings。

第一个是磁盘镜像位置。Windows 上 Docker 走 WSL2 后端，所有镜像和容器的数据落在虚拟磁盘文件里，默认在 C 盘用户目录下。Dify 全套镜像拉下来大概 5-8GB，加上后续知识库产生的数据，C 盘又会紧张。路径在 Settings—Resources—Advanced 里的 Disk image location，改到D:\Docker\DockerDesktopWSL这种位置，改完点 Apply 会提示迁移，等它跑完。

第二个是 Docker Engine 配置，在 Settings—Docker Engine 里，是一段 JSON。拉镜像慢或者反复超时的，在这里加镜像加速入口：

{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "registry-mirrors": ["https://hub.rat.dev"] }

builder.gc.defaultKeepStorage控制构建缓存的上限，设成 20GB 是给后续自己构建镜像留余地，纯用官方镜像的话这个值影响不大。registry-mirrors是拉取镜像时的加速入口，填一个当前可用的地址即可；这类地址的可用性会变，如果拉取报pull access denied或长时间卡在Pulling，先怀疑这里，换一个再试。改完点 Apply & restart，Docker 会重启一次引擎。

验证 Docker 是否正常，开一个 PowerShell：

# 能输出版本信息说明引擎和客户端都通了 docker version # 跑一个最小容器验证拉取和运行链路 docker run --rm hello-world

第二条命令如果能看到 "Hello from Docker!"，说明镜像拉取、容器创建、运行、清理全链路没问题，可以往下走了。这一步别省，很多人后面docker compose up -d失败，排查半天发现是 Docker 引擎本身没起来。

3.2 Dify 的 .env：三行配置里有两个必须改

Dify 的源码包从项目仓库的 main 分支下载 zip，解压到比如E:\Ai\dify。真正要动的是dify\docker这个目录，里面有三个关键文件：.env.example、docker-compose.yaml、nginx配置目录。

第一步是把.env.example复制成.env。Windows 下直接右键重命名会提示"必须键入文件名"，用命令行更省事：

# 进入 dify 的 docker 目录 cd E:\Ai\dify\docker # 复制环境变量模板 copy .env.example .env

然后用记事本或任意编辑器打开.env，拉到文件末尾，追加两行：

# 允许在 Dify 里接入自定义模型供应商 CUSTOM_MODEL_ENABLED=true # 告诉 Dify 后端，Ollama 的 API 在哪个地址 OLLAMA_API_BASE_URL=http://host.docker.internal:11434

第一行CUSTOM_MODEL_ENABLED=true决定模型供应商列表里能不能加 Ollama 这类自托管模型，不开的话界面上根本看不到添加入口。第二行是 Ollama 服务地址，host.docker.internal是 Docker Desktop 提供的一个特殊域名，容器内部解析它就能访问到宿主机，不需要你查本机 IP。

这里有个版本差异要说明：较新的 Dify 版本里，Ollama 的基础 URL 主要靠在 Web 界面上填，.env里这一行更多是给后端一个默认值，填了不亏，但别指望它覆盖界面配置。另外原文给的写法是不带协议头的host.docker.internal:11434，实际部署中带http://更稳妥，因为部分组件拼 URL 时不会自动补协议。如果按一种写法连不上，换成另一种再试，这是五分钟能排除的变量。

docker-compose.yaml一般不需要改，除非 80 端口被占。Dify 默认用 nginx 监听宿主机的 80 端口，如果你的机器上跑着 IIS 或者其他 Web 服务，docker compose up -d会报端口绑定失败。解决办法是在.env里加一行EXPOSE_NGINX_PORT=8080，之后改用http://127.0.0.1:8080访问。

3.3 启动之后到底起了哪些容器

在dify\docker目录下右键"在终端中打开"，执行：

# 后台启动全套服务，首次会拉取所有镜像，耗时取决于网络 docker compose up -d # 查看容器状态，正常应该是全部 Up 或 Up (healthy) docker compose ps # 出问题时盯 api 和 worker 两个服务的日志 docker compose logs -f api docker compose logs -f worker

-d是后台运行，不加这个参数日志会刷屏占住终端。首次执行会依次拉取 api、worker、web、db（PostgreSQL）、redis、向量库（默认 weaviate）、sandbox、ssrf_proxy、nginx 这些镜像，加起来几个 GB，网络差的时候十几分钟很正常。中途 Ctrl+C 不会损坏什么，重新执行会断点续传已完成的层。

docker compose ps是最有用的诊断命令。健康状态下每一行都是 Up，db 和 redis 可能显示Up (healthy)。如果某个容器显示Restarting或者Exited，基本可以锁定问题在它身上：db 起不来说明数据卷权限或端口冲突，api 反复重启通常是.env里数据库连接串或密钥没配好，worker 起不来多半是依赖 api 没就绪。看日志时优先-f api，因为大部分启动期错误都会在 api 的日志里打出来。

全部容器 Up 之后，浏览器访问http://127.0.0.1/install（改过端口就是http://127.0.0.1:8080/install），能看到管理员账户设置页面，说明编排这一层通了。设置完邮箱和密码登录进去，接下来才是模型接入和知识库。

注意：这个安装页面只在首次初始化时出现，设置完管理员后同样的地址会跳转到登录页。忘了密码只能进容器重置，所以第一次设的时候记牢。

4. 控制台接入：把 Ollama 模型挂进 Dify 并建成可检索的知识库

前面两章是基础设施，这一章才真正碰到业务：让 Dify 认识你本地的两个模型，然后用它们建一个能问答的知识库。整个流程分三步——配供应商、建知识库、挂到应用上，每一步都有容易填错的具体字段。

4.1 添加 LLM 与 Text Embedding：字段填错就白搭

登录 Dify 后，点右上角账户—设置—模型供应商，找到 Ollama，点"添加模型"。这里要加两次，一次加对话模型，一次加向量模型。

对话模型的填写项：

向量模型同样走 Ollama—添加模型，模型类型选 Text Embedding，模型名填bge-m3，基础 URL 相同，向量维度填 1024。这个 1024 不能随便写，要和 bge-m3 的实际输出维度对上，填错了建知识库时会报维度不匹配。

保存后 Dify 会做一次连通性测试，界面上会显示成功或失败。失败的话先别急着改 Dify，回到命令行确认两件事：ollama list里模型名是不是一模一样，curl http://127.0.0.1:11434/api/tags宿主侧能不能通。宿主侧通、Dify 侧不通，那就是第 2 章提到的OLLAMA_HOST监听地址问题。

4.2 创建知识库：分段策略比模型选择更影响效果

回到主界面，进"知识库"—"创建知识库"—数据源选"导入已有文本"，上传你的文档。上传完成后会让你选分段设置和索引方式，这两个选项决定了后面检索的质量，值得多花两分钟。

分段选"通用"，分段标识符默认是换行，最大分段长度建议 500 tokens 左右，分段重叠 50 tokens。重叠的作用是防止一句话被硬切在边界上导致语义断裂，50 是个稳妥值。如果你的文档是合同、规范这类条目清晰的文本，可以适当调小到 300，让每段更聚焦；如果是叙述性的技术文档，800 也行。没有万能值，后面第 6 章会给一组可对比的参数。

索引方式选"高质量"，它需要调用 embedding 模型把每段文本转成向量，这也是前面必须先拉 bge-m3 的原因。如果选"经济"，走的是关键词检索，省钱但召回质量差一截，中文场景下同义词基本匹配不上。

检索设置选"向量检索"，TopK 填 3-5，Score 阈值填 0.5 左右。TopK 是每次提问召回多少个文本块，填太大容易把不相关内容塞进上下文，反而干扰模型；填太小可能漏掉关键段落。3-5 是本地知识库的常用区间。Score 阈值是相似度下限，低于这个值直接丢弃，0.5 开始调比较安全，如果发现经常答"文档中没有提到"，可以降到 0.4 试试。

点"保存并处理"，Dify 会进后台排队做分段和向量化。处理时间取决于文档量，几百页的 PDF 大概几分钟。处理完成后知识库里能看到分段数量和每个分段的预览，这一步必须人工抽查几条，看看有没有把表格切碎、把标题和正文切散的情况。

4.3 挂到聊天助手：提示词决定了它会不会胡说

知识库建好后，进"工作室"—创建空白应用—选"聊天助手"，填个名字和图标创建。然后在应用的编排界面里，找到"上下文"，点"添加"，选中刚建的知识库。

到这里其实就能对话了，但实际效果会很飘：模型有时候不引用知识库，直接凭自己的知识回答。要收一下，在"提示词"里加一段约束：

你是一个基于内部文档回答问题的助手。 回答前先检索上下文中的文档片段，只依据检索到的内容作答。 如果上下文中没有相关信息，直接回答"文档中未提及"，不要编造。 引用内容时在句末标注来源文档名。

这段提示词的作用是把模型的行为从"自由发挥"掰到"基于检索"，尤其是"未提及就说未提及"这句，能挡掉大部分幻觉。加完之后在对话框里问几个你明确知道答案的问题，看它是不是引用了正确的文档段落；再问一个文档里绝对没有的问题，看它会不会老实说不知道。这两个测试通过，这套知识库才算能用。

Dify 的对话界面右侧会显示引用的知识库片段和相似度分数，这个面板是调试利器——答案不对时先看它，如果召回的分段本身就是错的，问题在分段策略或检索参数，不在模型。

5. 避坑排查：五个把部署卡住的真实翻车点

这套栈的坑有个共同特点：报错信息都很模糊，connection refused、internal server error、处理失败，看不出根因。下面五条是按"现象—原因—解决"整理的排查记录，基本覆盖了从零部署会撞上的大部分情况。

5.1 模型拉取卡在某个百分比不动

现象：ollama pull或ollama run输出进度条后长时间不动，十几分钟还是同一个数字，最后报 timeout。

原因：权重文件是分片下载的，中途某个分片连接断开后重试逻辑不一定能接上；另一种情况是目标磁盘剩余空间不足，写入失败但不立刻报错。

解决：先 Ctrl+C 中断，检查OLLAMA_MODELS指向的盘剩余空间是否大于模型体积的两倍，然后重新执行 pull。反复失败的话，关掉其他占带宽的程序再试，或者换个时间段。还有一个隐蔽原因——OLLAMA_MODELS写成了不存在的路径且没有写权限，Ollama 会退回默认目录，结果权重还是下到 C 盘，用ollama list看不到异常但磁盘在涨，这种情况去%USERPROFILE%\.ollama下确认一下有没有多出来的 blobs 目录。

5.2 Dify 添加 Ollama 供应商时连接超时

现象：界面上点保存后转圈很久，最后提示连接失败或超时；但宿主机浏览器访问http://127.0.0.1:11434是通的。

原因：Ollama 默认只监听127.0.0.1，容器内部的host.docker.internal解析到的是宿主机网卡地址，请求打过去被拒。

解决：设环境变量OLLAMA_HOST=0.0.0.0:11434，然后退出托盘里的 Ollama 再重新启动，让它监听所有网卡。重开终端执行netstat -ano | findstr 11434确认监听地址变成了0.0.0.0:11434。改完再去 Dify 里保存，基本就通了。安全上要注意，这会让你所在局域网的其他机器也能访问这个端口，如果环境敏感，用完后改回来。

5.3 知识库一直"处理中"，最终变成失败状态

现象：上传文档后进度卡在索引阶段，等很久最后状态变成失败，重试还是一样。

原因：两个高发点——Text Embedding 模型没配对（模型名错、维度错、供应商没启用），或者向量库容器没起来。

解决：先docker compose ps看向量库容器（默认是 weaviate）是不是 Up，不是的话docker compose logs weaviate看报错。容器正常就回到模型供应商页面，对 bge-m3 点一次测试，看能不能返回向量。都正常的话，去docker compose logs -f worker看处理任务的具体报错，通常会有明确的"dimension mismatch"或"model not found"字样。

5.4 中文 PDF 上传后答非所问

现象：文档明明上传成功、分段数量也对，但提问时召回的内容驴唇不对马嘴，或者干脆说没找到。

原因：扫描版 PDF 是图片，没有文本层，Dify 抽出来的是空白或乱码；另一种是 PDF 里的表格排版复杂，抽取后顺序全乱，分段语义断裂。

解决：先用任意 PDF 阅读器试着选中文字，选不中就说明是扫描件，得先过一遍 OCR 转成可搜索 PDF 或直接转 txt 再上传。表格密集的文档，建议先在源文件里把表格转成 markdown 或纯文本段落，再上传，效果比让解析器硬啃好得多。这一步没有技术捷径，纯靠预处理。

5.5 重启电脑后 Dify 打不开

现象：昨天好好的，今天开机访问http://127.0.0.1打不开，docker compose ps也报错连不上 Docker。

原因：Docker Desktop 没设开机自启，或者引擎启动了但容器没设自动重启策略。

解决：先手动启动 Docker Desktop，等托盘图标稳定后，进dify\docker目录重新执行docker compose up -d。要一劳永逸，可以在docker-compose.yaml里给关键服务加restart: always，或者在 Docker Desktop 设置里勾选开机启动。另外注意 Docker Desktop 启动后引擎就绪需要几十秒，太早执行 compose 命令会报连不上守护进程。

6. 把检索精度调上来：分段、topK 与一轮回归测试

部署跑通只是及格线，真正决定这套知识库能不能用的是检索质量。我踩过的坑是：一开始把所有参数都用默认值，问十个问题有四个答偏，误以为是 8B 模型能力不行，换了 14B 也没好转，最后发现问题全在分段和 TopK 上。

调参有个顺序，别乱试。先固定模型，调分段；分段定了再调 TopK 和阈值；最后才动提示词。下面这组是我在技术文档类语料上对比出来的，可以作为起点：

改参数的验证方法不能靠"感觉好像好了一点"。我一般会准备一组 10-15 条的固定问答对，每条包含问题和一个"必须命中的关键词"，然后用 Dify 的接口批量跑一遍，统计关键词命中率。Dify 提供了对话接口，用一段脚本就能做回归：

import requests # Dify 应用的 API Key，在应用的"访问 API"页面生成 API_KEY = "app-xxxxxxxxxxxxxxxx" # 本地部署的接口地址，端口按实际 nginx 暴露的来 BASE_URL = "http://127.0.0.1/v1/chat-messages" # 固定测试集：问题 + 期望命中的关键词 CASES = [ {"q": "验收标准里对气密性怎么规定的", "kw": "气密性"}, {"q": "质保期是多久", "kw": "质保"}, {"q": "现场安全问题由谁负责", "kw": "安全"}, ] hit = 0 for case in CASES: resp = requests.post( BASE_URL, headers={ "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", }, json={ "inputs": {}, "query": case["q"], "response_mode": "blocking", # 阻塞模式，方便脚本直接拿结果 "conversation_id": "", "user": "regression-test", }, timeout=120, ) answer = resp.json().get("answer", "") ok = case["kw"] in answer hit += ok print(f"{'PASS' if ok else 'FAIL'} | {case['q']} -> {answer[:60]}") print(f"命中率 {hit}/{len(CASES)}")

这段脚本做的是最朴素的端到端校验：把问题打给应用，看回答里有没有出现预期关键词。response_mode用blocking是为了拿完整结果，本地模型生成慢，timeout给到 120 秒比较稳。conversation_id传空字符串表示每次都是新会话，避免上下文互相污染。user字段是必填的，随便给个固定值即可。

跑一遍拿到基线命中率，改一组参数再跑一遍，对比才有意义。我自己的经验是：分段长度的影响最大，TopK 次之，阈值最后微调。还有一个容易被忽略的调试入口——对话界面右侧的引用面板，它直接告诉你这次召回了哪几段、相似度多少。命中率上不去的时候，先看面板里召回的分段是不是本来就无关，如果召回的段落本身是对的但答案错了，那是提示词或模型的问题，别再去动分段了。

从那以后我每次改检索参数，都会先把这十几条问答跑一遍，绝不靠随手问两个问题就下结论——人脑记不住上一版的细微差别，只有数字记得住。希望这套流程能帮你少走几晚弯路。

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