简介：这份PDF文档面向希望零基础完成大模型与AI知识库本地部署的开发者和AI爱好者，围绕DeepSeek与Dify的组合方案，解决私有化知识库搭建门槛高、流程繁琐的问题。资源包共1个PDF文件，大小约1.47MB，内容以图文步骤形式呈现，涵盖系统环境变量设置、Ollama软件下载安装、DeepSeek-R1与bge-m3模型的拉取、Docker安装与镜像配置，以及Dify开源平台的下载、配置与运行全流程。读者可据此在Windows 11环境下逐步完成从环境准备到知识库创建、聊天助手配置的完整操作，获得一套可复用的本地部署思路与排错参考。目前已有2337人学习下载，适合需要快速上手私有化AI知识库的中初级用户参考。
1. 为什么我宁愿在 Windows 11 上折腾 DeepSeek+Dify，也不把文档丢进在线知识库
去年底我把一批内部技术文档传到某在线知识库，结果一次误操作把整个索引重建了，原始分段全乱。从那以后我开始认真考虑本地部署知识库这件事。DeepSeek+Dify 这套组合的核心思路是：用 Ollama 在本地跑 DeepSeek-R1 推理模型和 bge-m3 向量模型，用 Docker 拉起 Dify 应用平台，最终在浏览器里得到一个完全离线的 RAG 知识库。整个过程不需要写一行代码，但涉及环境变量、模型拉取、容器编排、API 地址映射四个环节，任何一个环节的配置偏差都会导致后面“模型连不上”或“知识库检索为空”。这篇笔记面向的是手上有 Windows 11 机器、想把内部文档做成可问答知识库的从业者，也适合刚接触本地大模型部署、想找一个完整可复现路径的新手。下面按实际操作的顺序拆开讲，每一步都标注了我踩过的坑和参数含义。
2. 环境变量与 Ollama 安装：模型存哪里、怎么拉
2.1 先设 OLLAMA_MODELS，别等 C 盘爆了再后悔
Ollama 默认把模型文件放在 C 盘用户目录下，DeepSeek-R1 的 8B 版本量化后大约 4.9GB，bge-m3 大约 1.2GB，加上后续可能拉取的其他模型，C 盘空间会迅速吃紧。所以第一步不是装软件，而是改模型存储路径。
操作路径：右击“我的电脑”→“属性”→“高级系统设置”→“环境变量”→ 在“用户变量”或“系统变量”区域新建。
| 变量名 | 变量值示例 | 说明 |
|---|---|---|
| OLLAMA_MODELS | E:\Ai\Ollama3 | 模型文件的落盘目录，需提前建好文件夹 |
设置完成后必须重启系统，否则 Ollama 安装后仍会读取默认路径。这个坑我踩过：先装 Ollama 再设环境变量，结果模型已经下到 C 盘，只能手动迁移。常见做法是先把环境变量配好、重启一次，再进入安装环节。
2.2 Ollama 安装与 DeepSeek-R1 模型拉取
从 Ollama 官网下载OllamaSetup.exe，双击后点击 Install，安装程序会自动完成。安装完成后 Ollama 会常驻系统托盘，提供http://localhost:11434的本地 API 服务。
接下来拉取推理模型。打开https://ollama.com/search，搜索deepseek-r1，根据机器配置选版本。8B 版本对显存要求相对友好，量化后约 4.9GB，16GB 内存的机器可以跑；如果机器配置更高，可以考虑 14B 或 32B，但响应速度会明显下降。
# 按 Win+R 输入 cmd 打开命令行，粘贴以下命令拉取 DeepSeek-R1 8B ollama run deepseek-r1:8b # 拉取完成后会进入交互对话界面，输入任意问题测试 # 测试没问题后按 Ctrl+C 退出对话，再按 Ctrl+D 退出模型ollama run的逻辑是：先检查本地是否已有该模型，没有则从 registry 拉取，拉取完成后直接加载并进入交互模式。这里有个细节：Ctrl+C是中断当前生成，Ctrl+D才是退出模型加载。如果只按Ctrl+C就以为退出了，模型仍占用内存。
2.3 拉取 bge-m3 向量模型并验证
知识库的检索质量取决于 embedding 模型。Dify 的知识库流程需要把文档分段后转成向量，bge-m3 支持多语言且对中文友好，是本地部署场景下比较稳妥的选择。
# 拉取 bge-m3 向量模型 ollama pull bge-m3 # 查看本地已下载的模型列表，确认两个模型都在 ollama listollama pull只下载不加载，适合提前把模型准备好。ollama list的输出包含模型名称、ID、大小和修改时间，后面在 Dify 里配置模型时需要用到模型名称这一列。如果ollama list里看不到 deepseek-r1:8b 或 bge-m3，说明拉取没成功，需要检查网络或磁盘空间。
注意：Ollama 的服务端口默认是 11434，如果这个端口被其他程序占用，Ollama 启动时会报错。可以用
netstat -ano | findstr 11434检查端口占用情况。
3. Docker Desktop 安装与镜像配置：容器跑起来的前置条件
3.1 安装 Docker Desktop 并改镜像存储位置
Dify 的社区版通过 Docker Compose 编排多个容器（API、Worker、Web、PostgreSQL、Redis、Weaviate 等），所以 Docker 是必装项。从 Docker 官网下载Docker Desktop Installer.exe，双击后自动安装。安装完成后打开 Docker Desktop，进入 Settings → Resources → Advanced，把 Disk image location 改到非系统盘，比如D:\Docker\DockerDesktopWSL。这个设置决定了所有容器镜像和卷的存储位置，不改的话 C 盘会被迅速占满。
3.2 配置 registry-mirrors 加速镜像拉取
Docker Hub 的镜像拉取在国内网络环境下经常超时。在 Docker Desktop 的 Settings → Docker Engine 里，用以下配置覆盖原有内容：
{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "registry-mirrors": ["https://hub.rat.dev"] }registry-mirrors指定镜像加速地址，defaultKeepStorage控制构建缓存上限，20GB 对 Dify 的镜像依赖来说够用。配置完成后点击 Apply & restart，Docker 会重启生效。这里有个常见翻车点：如果 JSON 格式写错（比如多了一个逗号），Docker 会启动失败并弹窗报错，需要检查括号和引号是否匹配。
提示：如果
docker compose up -d拉取镜像时仍然很慢，可以先把 Docker Desktop 退出，确认配置已保存后再重新打开，让镜像加速配置完全生效。
4. Dify 源码包配置与容器编排：从 .env 到 docker compose up
4.1 下载 Dify 并配置 .env 文件
从https://github.com/langgenius/dify/archive/refs/heads/main.zip下载源码包，解压到 D 盘或 E 盘，文件夹命名为dify。进入dify/docker目录，找到.env.example文件，复制一份并重命名为.env。这个文件是 Docker Compose 的环境变量来源，Dify 的所有服务都从这里读取配置。
用记事本打开.env，拉到文件末尾，追加以下内容：
# 启用自定义模型 CUSTOM_MODEL_ENABLED=true # 指定 Ollama 的 API 地址（根据部署环境调整 IP） OLLAMA_API_BASE_URL=host.docker.internal:11434CUSTOM_MODEL_ENABLED=true是让 Dify 允许接入自定义模型供应商，不加这一行在模型供应商列表里看不到 Ollama 选项。OLLAMA_API_BASE_URL是关键参数：Dify 跑在 Docker 容器里，Ollama 跑在宿主机上，容器内的localhost指向容器自身而不是宿主机，所以必须用host.docker.internal这个特殊域名来访问宿主机的服务。如果这里填了127.0.0.1，Dify 会报连接拒绝。
4.2 启动容器并验证服务状态
在dify/docker目录下，右击空白处选择“在终端中打开”，执行：
# 后台启动所有 Dify 依赖服务 docker compose up -d # 查看容器运行状态，确认所有服务都是 Up 状态 docker compose psdocker compose up -d会依次拉取 PostgreSQL、Redis、Weaviate、Dify API、Worker、Web 等镜像并启动容器。首次执行需要下载大量镜像，时间取决于网络速度。docker compose ps的输出中，如果某个容器显示Exit或Restarting，说明该服务启动失败，需要用docker compose logs <服务名>查看日志。
常见问题是 PostgreSQL 容器启动失败，多数是因为端口 5432 被宿主机上已有的 PostgreSQL 占用。解决办法是修改.env里的EXPOSE_POSTGRES_PORT或直接停掉宿主机的 PostgreSQL 服务。
注意：Dify 的 Web 服务默认映射到宿主机的 80 端口。如果 80 端口被 IIS 或其他 Web 服务占用，需要在
.env里修改EXPOSE_NGINX_PORT为其他端口，比如 8080。
5. Dify 初始化与模型接入：从管理员账号到知识库问答
5.1 初始化管理员账号并登录
容器全部启动后，打开浏览器访问http://127.0.0.1/install。如果能看到 Dify 的初始化页面，说明容器编排成功。设置管理员邮箱和密码后登录，进入 Dify 主界面。
如果页面打不开，先检查docker compose ps里 Web 容器是否正常运行，再确认 80 端口是否被占用。另一个常见情况是浏览器缓存了旧的重定向，换一个无痕窗口访问通常能解决。
5.2 在 Dify 中接入 Ollama 的 LLM 和 Embedding 模型
登录后点击右上角账号 → 设置 → 模型供应商，找到 Ollama，点击“添加模型”。这里需要填三个关键参数：
| 参数 | 填写内容 | 说明 |
|---|---|---|
| 模型名称 | deepseek-r1:8b | 必须与ollama list输出的名称完全一致 |
| 基础 URL | http://host.docker.internal:11434 | 容器内访问宿主机的 Ollama 服务 |
| 模型类型 | LLM | 对话推理模型选 LLM |
保存后再添加一个模型，模型类型选 Text Embedding，模型名称填bge-m3，基础 URL 同上。两个模型都添加成功后，在模型供应商列表里能看到 Ollama 下面有两条记录。
这里最容易翻车的地方是模型名称写错。ollama list输出的名称是deepseek-r1:8b，如果写成deepseek-r1或deepseek-r1-8b，Dify 会报模型不存在。另一个坑是基础 URL 用了localhost或127.0.0.1，容器内无法回连宿主机，必须用host.docker.internal。
5.3 创建知识库并接入聊天助手
回到 Dify 主界面，先创建聊天助手应用：点击“聊天助手”→“创建空白应用”→ 填写应用名称 → 创建。然后创建知识库：点击“知识库”→“创建知识库”→ 选择数据源“导入已有文本”→ 上传文本文件 → 下一步。
分段设置选“通用”，索引方式选“高质量”，检索设置选“向量检索”，点击“保存并处理”。Dify 会调用 bge-m3 把文档分段转成向量存入 Weaviate。处理完成后，回到聊天助手应用，在上下文里点击“添加”，选择刚才创建的知识库。
此时就可以在聊天助手的对话框里提问了。如果回答内容引用了知识库里的文档片段，说明 RAG 流程已经跑通。如果回答与文档无关，检查知识库是否处理完成、上下文是否添加成功、检索设置是否为向量检索。
6. 避坑与排查：模型连不上、知识库检索为空、容器反复重启
6.1 Ollama 模型在 Dify 里显示连接失败
现象：在 Dify 模型供应商里添加 Ollama 模型后，点击保存报“credentials validation failed”或连接超时。
原因：Dify 容器内无法通过localhost访问宿主机的 Ollama 服务，或者 Ollama 没有监听在0.0.0.0。
解决：确认.env里OLLAMA_API_BASE_URL=host.docker.internal:11434，并且在 Dify 模型配置的基础 URL 里也填这个地址。如果仍然不通，在宿主机命令行执行ollama serve确认服务在运行，然后用curl http://localhost:11434/api/tags测试 Ollama API 是否可达。
6.2 知识库上传文档后检索不到内容
现象：文档上传并显示“处理完成”，但聊天助手回答时完全不引用知识库内容。
原因：索引方式选了“经济”而不是“高质量”，或者 embedding 模型没有正确配置。
解决：删除知识库重新创建，索引方式必须选“高质量”，检索设置选“向量检索”。确认 Dify 模型供应商里 Text Embedding 类型的 bge-m3 已添加且状态正常。如果 bge-m3 模型没拉取成功，ollama list里看不到它，Dify 处理文档时会静默失败。
6.3 docker compose up -d 后部分容器反复重启
现象：docker compose ps显示某个容器状态为 Restarting，Web 页面无法访问。
原因：端口冲突或环境变量缺失。最常见的是 5432（PostgreSQL）或 6379（Redis）被宿主机已有服务占用。
解决：用docker compose logs <服务名>查看具体报错。如果是端口冲突，修改.env里对应的EXPOSE_*_PORT变量，然后docker compose down再docker compose up -d。如果是环境变量缺失，检查.env文件是否从.env.example正确复制，以及追加的内容是否在文件末尾且没有语法错误。
6.4 模型拉取到一半中断，ollama list 里显示不完整
现象：ollama pull过程中网络中断，重新拉取时提示模型已存在但实际不可用。
原因：Ollama 的模型文件是分片下载的，中断后可能留下不完整的分片。
解决：执行ollama rm deepseek-r1:8b删除不完整的模型，再重新ollama pull。如果磁盘空间不足也会导致拉取中断，检查 OLLAMA_MODELS 指向的磁盘剩余空间。
6.5 Dify 页面能打开但登录后一直转圈
现象：http://127.0.0.1/install能打开，设置管理员账号后登录，页面卡在加载状态。
原因：Dify 的 API 容器和 Web 容器之间的网络通信异常，或者数据库迁移未完成。
解决：查看docker compose logs api和docker compose logs worker，确认没有数据库连接错误。首次启动时 API 容器需要执行数据库迁移，如果迁移失败会一直重试。等待几分钟后刷新页面，如果仍然不行，docker compose down后重新docker compose up -d，让迁移重新执行。
7. 进阶技巧：用 ollama list 和 docker compose logs 做日常巡检
跑通整套流程之后，日常维护其实就两件事：确认模型在、确认容器在。我养成了一个习惯，每次重启机器后先跑一遍下面这组命令，三十秒内就能判断整套环境是否健康。
# 检查 Ollama 模型列表，确认 deepseek-r1:8b 和 bge-m3 都在 ollama list # 检查 Dify 容器状态，确认所有服务都是 Up cd /d E:\dify\docker docker compose ps # 如果某个容器状态异常，查看最近 50 行日志 docker compose logs --tail=50 apiollama list的输出里重点看两列：NAME 和 SIZE。如果 SIZE 显示为 0 或异常小，说明模型文件损坏，需要ollama rm后重新拉取。docker compose ps的输出里重点看 STATUS 列，Up后面跟的时间表示容器已运行时长，如果某个容器频繁重启，这个时间会一直很小。
还有一个容易被忽略的点：Dify 的知识库索引存在 Weaviate 容器里，如果 Weaviate 容器被删除，知识库的向量数据会丢失。所以docker compose down时不要加-v参数，-v会删除数据卷。我一般只在升级 Dify 版本时才动容器，平时不轻易执行down。
另外，如果后续想换更大的 DeepSeek 模型，比如从 8B 换到 14B，只需要ollama pull deepseek-r1:14b，然后在 Dify 模型供应商里把 LLM 的模型名称改成deepseek-r1:14b即可，不需要重新配置知识库。Embedding 模型不建议频繁更换，因为换 embedding 模型意味着所有文档的向量需要重新计算，知识库要重建。
从那以后我每次重启开发机，都强制走一遍ollama list+docker compose ps这套巡检，确认模型和容器都在线再开始干活。希望帮到你。
本文还有配套的精品资源，点击获取
