简介：这份PDF资料面向希望零基础搭建本地AI知识库的技术爱好者与开发者，围绕DeepSeek大模型与Dify开源平台，给出从系统环境变量配置、Ollama安装、模型拉取到Docker与Dify部署的完整落地路径，帮助读者在个人电脑上跑通一套可对话、可检索的私有知识库，无需深厚运维背景也能按图操作。资源包共1个PDF文件，约1.47MB，以图文步骤形式串联各环节，涵盖环境变量设置、deepseek-r1与bge-m3模型拉取、Docker镜像配置及Dify模型供应商接入等关键节点，便于对照实操与排错。目前已有2345人学习，适合想低成本体验大模型本地化、构建个人或团队知识库的读者参考。
1. 本地知识库这套组合拳，为什么值得你花一个下午跑通
手里有一堆产品手册、内部规范、项目复盘文档，想用大模型直接问，结果要么把文件传到别人的服务上心里发毛，要么模型答得云山雾罩、张口就来。DeepSeek+Dify 这套本地部署知识库方案解决的正是这个矛盾：模型跑在自己机器上，文档不出内网，检索增强（RAG）把回答锚定在你上传的资料里。整条链路是 Ollama 管模型、Docker 管容器、Dify 管应用和知识库编排，Windows 11 上一路点下来就能跑通。适合谁？手里有敏感文档不能外传的从业者、想低成本验证 RAG 效果的技术负责人，以及被云端 API 账单劝退、想先把流程跑顺再谈扩容的开发者。这篇按我实际拆装的顺序写，参数、命令、翻车点都给到，照着抄能复现。
2. 环境与模型先行：Ollama 装好、DeepSeek 拉下来
本地知识库的第一块地基不是 Dify，而是模型运行时。很多人一上来就折腾 Dify 的 docker compose，结果容器起来了、模型连不上，回头排查半天，血泪经验就是顺序别乱：先把 Ollama 跑通、模型能对话，再动容器编排。
2.1 先改 OLLAMA_MODELS，别让模型默认塞进 C 盘
Ollama 默认把模型权重放在系统盘用户目录下，一个 8B 模型加一个 embedding 模型轻松吃掉十几 GB，C 盘红了再迁移很麻烦。装之前先把存储路径定好，这是最省后悔药的一步。
Windows 11 下操作：右击「此电脑」→「属性」→「高级系统设置」→「环境变量」→ 在「系统变量」里新建，变量名填OLLAMA_MODELS，变量值指向你规划好的目录，比如E:\Ai\Ollama3。目录提前建好，别指望它自动创建。确定后重启系统，让变量对后续启动的进程生效。
# 验证环境变量是否生效（新开一个 cmd 窗口执行） echo %OLLAMA_MODELS% # 期望输出：E:\Ai\Ollama3这里的关键是「系统变量」而不是「用户变量」，因为 Ollama 的服务进程可能以不同上下文启动，系统级变量覆盖更稳。变量值只写目录、不带引号、结尾不加反斜杠，这三点踩过就知道，多一个字符都可能让路径解析失败。重启不是玄学，是让已登录会话重新加载环境块，省这一步后面ollama list看不到模型别怪工具。
2.2 装 Ollama 并拉取 deepseek-r1 与 bge-m3
到 Ollama 官网下载OllamaSetup.exe，双击后点 Install，安装程序会自动完成，装完托盘里会有个常驻进程。接着开命令行拉模型，模型选型直接决定你这台机器能不能跑得动。
# 拉取对话模型，8b 是显存/内存友好档，配置高可换 14b、32b ollama run deepseek-r1:8b # 进入交互后随便问一句验证，退出用 Ctrl+C 再 Ctrl+D # 拉取向量化模型，知识库检索必须靠它 ollama pull bge-m3 # 确认两个模型都在本地 ollama listollama run第一次执行会先下载再进入对话，下载量按模型规模从几个 GB 到几十 GB 不等，网络差就耐心等，中断了重跑会续传。bge-m3是 embedding 模型，负责把文档切块转成向量，Dify 建知识库时「高质量」索引就依赖它，别漏。ollama list输出里要能同时看到deepseek-r1:8b和bge-m3，NAME、SIZE 两列对得上才算落地。选型上，8B 在 16GB 内存的机器上能跑但偏慢，32B 起步建议 32GB 内存加独立显卡；先拿 8B 把流程跑通，再按硬件往上换，这是我一贯的做法。
提示：模型拉取完成后先别急着关命令行，用一句中文提问确认输出正常，再退出。模型文件损坏或下载不完整时，
ollama list照样列得出来，但一对话就报错，提前验证能省掉后面在 Dify 里瞎猜的时间。
3. Docker 与 Dify 落地：镜像、.env 与 compose 三件事
模型侧通了，接下来是应用侧。Dify 官方推荐 Docker Compose 部署，本质是把 Web 前端、API、数据库、向量库等一串服务编排起来。这一章的重点不是「点下一步」，而是三个容易翻车的配置点：镜像加速、.env里的 Ollama 地址、compose 启动后的健康检查。
3.1 Docker Desktop 安装与镜像源配置
到 Docker 官网下载 Windows AMD64 版本的Docker Desktop Installer.exe，双击自动安装，装完启动。首次启动会要求启用 WSL2，按提示走完重启。然后进 Settings 做两处配置。
第一处是镜像存储位置：Settings → Resources → Advanced，把 Disk image location 改到空间充足的盘，比如D:\Docker\DockerDesktopWSL。默认放 C 盘，Dify 全套镜像拉下来几个 GB，加上后续数据增长，早点挪走省心。
第二处是 Docker Engine 配置，在 Settings → Docker Engine 里把配置改成下面这样，覆盖后点 Apply & restart：
{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "registry-mirrors": ["https://hub.rat.dev"] }registry-mirrors是拉镜像时的加速地址，国内网络环境下不加这一项，docker compose up很可能卡在 pulling 阶段一动不动。defaultKeepStorage控制构建缓存上限，20GB 对个人机器够用，太小会频繁清缓存导致重复构建。改完必须 Apply & restart，配置不重启不生效，这是 Docker Desktop 的老规矩。
3.2 下载 Dify、改 .env、compose 起服务
从 Dify 的 GitHub 仓库下载 main 分支压缩包，解压到 D 盘或 E 盘，目录命名为dify。进dify\docker目录，把.env.example复制一份改名为.env（Windows 下直接重命名，弹窗点「是」）。用记事本打开.env，拉到文件末尾，空一行后追加两行：
# 允许接入自定义模型供应商 CUSTOM_MODEL_ENABLED=true # 容器内访问宿主机 Ollama 服务的地址，端口固定 11434 OLLAMA_API_BASE_URL=host.docker.internal:11434CUSTOM_MODEL_ENABLED=true是让 Dify 的模型供应商列表里出现 Ollama 选项，不加这一行后面根本找不到入口。host.docker.internal是 Docker Desktop 提供的宿主机别名，容器里的 Dify 靠它回连你本机的 Ollama；如果你把 Ollama 装在另一台机器上，这里换成那台机器的局域网 IP，但要注意 Ollama 默认只监听本机，跨机访问需要额外配置监听地址，个人单机部署就用默认值。保存后在该目录空白处右击「在终端中打开」，执行：
# 后台拉起全部依赖服务，首次会拉取镜像，耗时取决于网络 docker compose up -d # 查看容器状态，全部 Up 或 healthy 才算成功 docker compose ps-d是后台运行，不加会占住终端。首次执行会拉取 postgres、redis、weaviate、api、web 等一长串镜像，配合前面的镜像加速通常十几分钟能完成。docker compose ps里如果有容器反复重启（Restarting），先看docker compose logs <服务名>，九成是端口冲突或.env写错。全部起来后浏览器访问http://127.0.0.1/install，能看到初始化页面就说明应用侧通了。
注意：
.env文件在 Windows 记事本里保存时容易带上 BOM 或把换行存成 CRLF 混用，导致 compose 解析异常。如果启动报变量解析错误，用支持 UTF-8 无 BOM 的编辑器重存一次，这个坑很隐蔽。
4. 在 Dify 里把模型接上、把知识库建起来
服务起来只是空壳，真正让它变成「知识库」的是两步：注册模型供应商，以及创建知识库并挂到应用上。这一章按界面操作顺序走，每一步说清填什么、为什么这么填。
4.1 注册 Ollama 的 LLM 与 Text Embedding
访问http://127.0.0.1/install设置管理员账号并登录，右上角头像进「设置」→「模型供应商」，找到 Ollama 点「添加模型」。这里要加两次，一次对话模型、一次向量模型，类型别选错。
先用ollama list确认本地模型名，再按下表填：
| 字段 | LLM（对话） | Text Embedding（向量） |
|---|---|---|
| 模型名称 | deepseek-r1:8b | bge-m3 |
| 基础 URL | http://host.docker.internal:11434 | http://host.docker.internal:11434 |
| 模型类型 | LLM | Text Embedding |
| 模型上下文长度 | 按模型实际能力填，8B 填 8192 起步 | 保持默认 |
模型名称必须和ollama list输出完全一致，大小写、冒号、标签都不能差，差一个字符保存时就报连接失败。基础 URL 带http://前缀，端口 11434 是 Ollama 默认监听端口。上下文长度填太小，长文档问答会被截断；填超过模型实际支持的值，请求会直接报错，拿不准就先用保守值。两个模型都保存成功后，供应商页面会显示已配置状态，这时才算模型接入完成。
4.2 建知识库：分段、索引与检索三组参数怎么定
回到主界面，先建应用：选「聊天助手」→「创建空白应用」，填应用名称和图标，创建。然后建知识库：「知识库」→「创建知识库」→ 数据源选「导入已有文本」→ 上传你的文档（txt、md、pdf 都支持）→ 下一步进入分段与索引设置。
分段选「通用」，索引方式选「高质量」，检索设置选「向量检索」，保存并处理，等状态变成可用。这三组参数的含义值得说清：
- 分段：通用模式按固定长度切块，块太大检索不准、块太小上下文断裂，默认值对大多数手册类文档够用，文档结构复杂再考虑自定义分隔符。
- 索引方式：「高质量」会调用
bge-m3做向量化，检索效果好但建库慢、吃算力；「经济」只做关键词索引，快但语义匹配弱。既然本地有 embedding 模型，选高质量。 - 检索：向量检索按语义相似度召回，适合自然语言提问；如果文档里全是编号、型号这类精确词，可以后续在应用里叠加关键词检索做混合召回。
知识库处理完成后，回「工作室」打开你的聊天助手，在「上下文」里点「添加」，选中刚建的知识库。到这里，提问时模型就会先检索你上传的文档再作答。测试时故意问一个只有文档里才有的细节，答得出来且能给出引用来源，说明整条链路真正打通了。
5. 避坑与排查：五个我实际踩过的坑
5.1 容器起来了但模型连不上
现象：Dify 里添加 Ollama 模型时提示连接失败或超时。原因多半是OLLAMA_API_BASE_URL写成了127.0.0.1:11434，容器内的 127.0.0.1 指向容器自己而不是宿主机。解决：改成host.docker.internal:11434，改完docker compose up -d重建容器让新环境变量生效，只重启不重建不读新值。
5.2 compose 卡在拉镜像不动
现象：docker compose up -d长时间停在 pulling，终端没进展。原因是镜像源没配或配了但没重启 Docker。解决：确认 Docker Engine 配置里registry-mirrors已写入，点 Apply & restart 后重试；仍慢就检查磁盘空间，镜像存储盘满了也会表现为卡住。
5.3 知识库建完检索不到内容
现象：文档上传成功、状态可用，但提问时模型答「没有相关信息」。原因通常是索引方式选了「经济」而检索用了向量模式，两边不匹配；或者分段过长导致关键信息被稀释。解决：重建知识库，索引选「高质量」、检索选「向量检索」，分段长度调小一档再试。
5.4 模型名对不上导致保存失败
现象：添加模型时点保存报错，提示模型不存在。原因是填的模型名和ollama list输出不一致，比如漏了:8b标签或大小写不同。解决：命令行跑ollama list原样复制 NAME 列，粘贴到模型名称字段，别手敲。
5.5 重启机器后 Dify 打不开
现象：第二天开机访问127.0.0.1无响应。原因是 Docker Desktop 没随系统启动，或容器处于停止状态。解决：先启动 Docker Desktop，等托盘图标稳定后在dify\docker目录执行docker compose up -d，用docker compose ps确认服务恢复。养成开机先看容器状态的习惯，比出问题再排查省事。
6. 进阶：把知识库问答调准的几个实操技巧
流程跑通只是及格线，真正决定这套本地知识库好不好用的是检索质量和回答约束。分享几个我反复调过的点，都是能直接改配置验证的。
第一，分段策略要按文档类型分。产品手册这种结构化文本，按标题层级切比按固定字数切召回准得多；会议纪要这类松散文本，固定长度加适度重叠更稳。Dify 的分段设置里可以自定义分隔符，把##、###这类标题标记加进去，切出来的块语义更完整。改完重建知识库，用同一批问题对比召回片段，肉眼就能看出差别。
第二，检索参数别用默认值一把梭。向量检索的 TopK 和相似度阈值是两个关键旋钮：TopK 太小召回不全，太大引入噪声；阈值太低把不相关片段塞进上下文，模型反而被带偏。我的习惯是先设 TopK=4、阈值 0.5 左右，拿十个典型问题测，答非所问就调高阈值，漏答就加 TopK，小步试。
第三，在应用里加系统提示词约束回答边界。本地小模型容易「自由发挥」，提示词里明确写「仅依据检索到的上下文回答，上下文没有的信息直接说不知道」，能显著降低幻觉。这条对 8B 这种规模的小模型尤其有效，比换更大模型来得快。
第四，验证环节别只看「答得像不像」。准备一份带标准答案的问题集，逐条核对回答是否引用了正确文档片段、是否编造了文档里没有的数字。我一般会抽 20 条做回归，每次改分段或检索参数都重跑一遍，用表格记录命中率，避免凭感觉调参。
| 调优项 | 默认倾向 | 建议起点 | 观察指标 |
|---|---|---|---|
| 分段长度 | 固定字数 | 按标题切分 | 召回片段完整性 |
| TopK | 偏大 | 4 | 上下文噪声比例 |
| 相似度阈值 | 偏低 | 0.5 | 答非所问比例 |
| 系统提示词 | 无约束 | 限定仅用上下文 | 幻觉出现频次 |
最后说个习惯。这套东西涉及环境变量、容器网络、模型服务三层，任何一层改动都可能让另一层失效，所以我每次动完配置，都强制走一遍「ollama list→docker compose ps→ 提一个已知答案的问题」这三步验证，确认链路没断再继续。早期我图省事跳过验证，结果在一个演示前夜发现容器重建后丢了环境变量，临时排查到凌晨，从那以后这个三步检查再没省过。希望帮到你。
本文还有配套的精品资源，点击获取
