★ FEATURED ARTICLE 简介这份资源面向希望本地搭建个人知识库的开发者与AI爱好者围绕ollama、deepseek、docker与Dify四件套的协同部署展开帮助读者理解搜索引擎框架、深度学习模型、容器化运行与知识库问答之间的配合关系适合具备基础命令行操作能力、想动手实践本地大模型应用的中级学习者。压缩包内为1个doc文档约5.19MB以图文步骤形式记录从安装ollama、配置环境变量、下载deepseek-r1模型到用docker-desktop启动Dify项目、创建知识库并接入ollama接口的完整流程并附有分词配置、模型供应商设置与问答测试等关键环节的界面示意。已有3396人学习该资源可作为搭建本地知识库时的对照参考帮助读者理清各工具的安装顺序与接口衔接方式减少环境配置与模型接入中的摸索成本。1. 本地知识库这套组合拳ollama 拉模型、Docker 跑 Dify、DeepSeek 接进工作流很多人第一次听到「本地部署个人知识库」脑子里浮现的是买显卡、装驱动、配 CUDA 的一整套硬仗。实际拆下来这套 ollama DeepSeek Docker Dify 的方案门槛比想象中低不少一台普通 Windows 机器8GB 内存起步跟着命令走一两个小时能跑通一个能问答、能引用自己文档的聊天界面。它解决的核心问题很具体——你有一堆 PDF、笔记、内部文档想让模型基于这些内容回答而不是靠它自己瞎编。适合谁想把资料变成可检索问答库的开发者、做课程设计的学生、需要给团队搭个内部知识助手但不想上云的人。这篇就按我实际拆包的顺序从装 ollama 到 Dify 里接上知识库把参数、命令和翻车点一次讲透。2. 装 ollama 与拉 DeepSeek环境变量和模型规格怎么定ollama 在这套链路里扮演的是「本地模型运行时」的角色它负责把 DeepSeek 这类模型下载到本地、加载进内存、对外暴露一个 HTTP 接口。Dify 本身不跑模型它只是个应用层编排工具真正干活的是 ollama 后面挂的那个模型。所以第一步必须先把 ollama 跑通再谈知识库。2.1 Windows 下安装与版本校验去 ollama 官网下载 Windows 安装包双击走完 Install 流程即可。装完别急着拉模型先验证命令是否进了 PATH。按Win R输入cmd打开命令行执行ollama --version正常会回一行版本号比如ollama version is 0.x.x。如果提示「不是内部或外部命令」说明安装时 PATH 没写进去重装一次或者手动把 ollama 的安装目录加进系统环境变量。这一步看着废话但我见过太多人卡在这里以为是安装失败其实是终端没刷新环境变量关掉 cmd 重开一次往往就好了。2.2 环境变量把模型挪出 C 盘默认情况下 ollama 会把模型存在用户目录下DeepSeek 的模型文件动辄几个 GBC 盘紧张的人必须提前改。打开「编辑系统环境变量」→「环境变量」→ 新建系统变量参数这样填变量名变量值示例说明OLLAMA_MODELSD:\ollama\models模型存放目录按自己硬盘改OLLAMA_HOST0.0.0.0:11434监听地址Dify 容器要访问时用得上OLLAMA_KEEP_ALIVE24h模型驻留内存时长避免频繁冷加载OLLAMA_MODELS指向的目录要提前建好路径里别带中文和空格这是血泪经验——带空格的路径在某些版本的加载逻辑里会出玄学问题。OLLAMA_HOST设成0.0.0.0是为了让 Docker 容器内的 Dify 能通过宿主机地址访问到 ollama只监听127.0.0.1的话容器里是够不着的。改完环境变量必须重启终端甚至重启一次 ollama 服务否则不生效。2.3 拉取 DeepSeek 模型1.5B 起步别一上来就冲大杯进 ollama 官网的 Models 页面搜deepseek-r1能看到从 1.5B 到 671B 的一串规格。选哪个不是看心情是看内存。粗略的对应关系1.5B 约需 2GB 内存7B/8B 约需 8GB14B 约需 16GB32B 往上基本要有独立显卡才谈得上流畅。课程设计、个人笔记问答这种场景1.5B 完全够用先跑通链路比追求效果重要。# 拉取并直接进入交互式对话首次会自动下载模型 ollama run deepseek-r1:1.5b回车后开始下载1.5B 大概几百 MB 到 1GB 出头几分钟能完如果你手滑选了 32B下载两三个小时是常态中途断网还得重来。下载完成后会直接进入提示符随便问一句「你是谁」验证模型能出话。这个命令行窗口不要关关掉 ollama 服务就停了Dify 那边就接不上。后面如果关了重新执行ollama run deepseek-r1:1.5b即可模型已在本地秒起。提示模型下载慢和网络环境有关跟 ollama 本身没关系。可以先拉 1.5B 把整条链路验证通再回头换大模型别在下载环节耗掉半天耐心。3. Docker 起 Difycompose 文件、端口与容器网络Dify 是这套方案里唯一需要「跑起来一个 Web 服务」的组件官方推荐用 Docker Compose 部署因为它依赖 PostgreSQL、Redis、向量数据库等一堆服务手动装能把人逼疯。Docker Desktop 在 Windows 上把这堆东西打包成容器一条命令拉起。3.1 准备源码与 Docker Desktop先把 Dify 源码拿到本地有 git 就直接克隆没有就下压缩包解压git clone https://github.com/langgenius/dify.git cd dify/docker目录里会有一个.env.example先复制成.env这是 compose 读取的配置文件# Windows cmd 下用 copyPowerShell 用 Copy-Item copy .env.example .env然后装 Docker Desktop官网下 Windows 版安装时勾选 WSL2 后端Win10/11 都支持装完点 Close and restart等托盘图标变绿说明引擎起来了。这里有个前置条件WSL2 得先启用否则 Docker Desktop 起不来报错通常是「WSL kernel version too low」按提示跑一次wsl --update即可。3.2 docker-compose up 的参数与首次启动在dify/docker目录下打开命令行在资源管理器地址栏输入cmd回车最快执行# -d 表示后台运行首次会拉取镜像耗时取决于网络 docker-compose up -d首次执行会拉 postgres、redis、weaviate、api、web 等一堆镜像几个 GB 的量网络一般的话十几分钟到半小时。拉完后docker ps能看到一串容器在跑。这里最容易翻车的是端口冲突Dify 默认 web 走 80 端口如果你本机 IIS 或别的服务占了 80容器起不来。改.env里的EXPOSE_NGINX_PORT比如改成8080然后docker-compose up -d重新拉起访问地址就变成http://127.0.0.1:8080。容器/服务默认端口作用nginxweb80前端入口浏览器访问这个api5001后端接口容器内部通信postgres5432元数据存储redis6379缓存与队列weaviate8080向量库知识库检索靠它启动完成后浏览器打开http://127.0.0.1/signin第一次会让你设管理员账号设完登录进主界面。如果页面打不开但容器都在跑先docker-compose logs nginx看日志八成是端口映射或镜像没拉全。3.3 容器访问宿主机 ollama 的地址写法这是整篇最容易卡住的一步。Dify 跑在容器里容器里的127.0.0.1指的是容器自己不是你的 Windows 宿主机所以填http://127.0.0.1:11434必然连不上。正确写法是 Docker Desktop 提供的宿主机别名http://host.docker.internal:11434前提是 ollama 的OLLAMA_HOST设成了0.0.0.0:11434只监听回环地址的话这个别名也够不着。填完点保存如果报连接失败先在宿主机浏览器开http://127.0.0.1:11434看 ollama 是否在响应再docker exec -it dify-api容器名 curl http://host.docker.internal:11434从容器里测一次两头都通才说明配置对。4. Dify 里建知识库与工作流分词、召回和模型接入Dify 跑起来只是有了个空壳真正让它变成「个人知识库」的是两件事把文档灌进去做成向量索引再把 DeepSeek 模型接进聊天应用并挂上这个知识库。4.1 创建知识库与分段策略主界面点「知识库」→「创建知识库」上传你的 PDF、Markdown、TXT。上传后进入分段设置Dify 默认给的是通用分段参数大致是参数默认值调整建议分段标识符\n\n结构化文档可改\n或按标题最大分段长度500 tokens笔记类可降到 300长文档可升到 800分段重叠50 tokens保持 10% 左右避免切断语义分段长度不是越大越好。设太大检索时召回一大段无关内容模型容易被带偏设太小一句话被切碎上下文丢失。我一般先用默认值跑一遍看解析出来的分段预览如果发现一个完整段落被拦腰截断就调大重叠或换标识符。保存后等索引完成状态变「可用」才算好解析时间跟文档量和机器配置有关几十页 PDF 几分钟正常。4.2 接入 ollama 模型供应商回到「设置」→「模型供应商」往下找到 Ollama点「添加模型」。这里要填两样模型名称和基础 URL。模型名称必须和ollama list里显示的一模一样比如deepseek-r1:1.5b少个 tag 就认不到。基础 URL 填上一节说的http://host.docker.internal:11434。# 在宿主机确认模型名和运行状态 ollama list # 输出示例deepseek-r1:1.5b xxxxxxxx 1.1 GB添加成功后供应商列表顶部会出现这个模型。如果添加时提示「模型不存在」先确认 ollama 命令行窗口还开着、ollama list能列出模型再检查 URL 末尾有没有多写斜杠。模型参数temperature、top_p可以在模型配置里调知识库问答场景建议 temperature 压到 0.3 以下减少自由发挥。4.3 工作流里挂知识库做上下文增强点「工作流」→「创建空白应用」→ 选「聊天机器人」起个名字创建。进入编排界面后在「上下文」旁边点添加选中刚建的知识库。这样每次提问Dify 会先拿问题去向量库检索相关分段拼进 prompt 再交给 DeepSeek。测试时问一个只有你文档里才有的细节比如「XX 项目的验收标准第三条是什么」看回答下方有没有引用来源。有引用且内容对得上说明检索链路通了如果模型答得泛泛而谈、没有引用多半是知识库没挂上或者分段没索引完。这一步是整个方案的价值所在——模型不再靠记忆瞎编而是基于你喂进去的资料作答。5. 避坑排查五个真实翻车现场5.1 容器里连不上 ollama报 connection refused现象Dify 添加 Ollama 模型时一直失败日志里是connection refused。原因ollama 只监听了127.0.0.1容器通过host.docker.internal访问不到。解决把OLLAMA_HOST改成0.0.0.0:11434重启 ollama 服务再从容器内curl验证一次。5.2 知识库上传后一直「索引中」现象文档传上去半天状态不变聊天时检索不到内容。原因向量库容器没起全或者 embedding 模型没配。Dify 建知识库需要 embedding 模型默认可能走外部 API本地部署得在模型供应商里配一个本地 embedding比如 ollama 拉的nomic-embed-text。解决先docker ps确认 weaviate 在跑再在知识库设置里把 embedding 模型指到本地那个。5.3 80 端口被占Dify 页面打不开现象docker-compose up -d成功但浏览器访问127.0.0.1是别的页面或 404。原因本机已有服务占用 80。解决改.env的EXPOSE_NGINX_PORT8080重新 up访问带端口号。改完记得docker-compose down再 up光 restart 有时不重新读端口映射。5.4 模型下载到一半断了重跑又从零开始现象拉 7B 以上模型时断网重新ollama run进度归零。原因ollama 的下载分片机制对断点续传支持有限大文件容易前功尽弃。解决先拉小模型验证链路大模型挑网络稳定的时段拉已经下了一半的去OLLAMA_MODELS目录看残留文件必要时清掉重来别在残缺文件上反复重试。5.5 回答不引用知识库模型自由发挥现象明明挂了知识库回答却像没看过文档。原因分段太长导致检索命中率低或者 temperature 太高。解决把最大分段长度降到 300500重叠保持 10%temperature 压到 0.3 以下再在检索设置里把「召回数量」从默认调到 35让更多相关分段进上下文。6. 进阶用 API 把知识库接进自己的程序Dify 的网页界面适合验证但真正落地往往要把这套问答能力嵌进自己的工具里。Dify 每个应用都暴露了 API在应用「访问 API」页面能拿到密钥和接口地址用 Python 调一下就能把「本地知识库 DeepSeek」变成你脚本里的一个函数。import requests API_KEY app-xxxxxxxx # Dify 应用 API 密钥 BASE_URL http://127.0.0.1/v1/chat-messages def ask_kb(question: str, user_id: str local-user): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { inputs: {}, query: question, response_mode: blocking, # 阻塞式等完整回答 user: user_id, conversation_id: , # 空表示新会话 } resp requests.post(BASE_URL, headersheaders, jsonpayload, timeout120) resp.raise_for_status() return resp.json()[answer] if __name__ __main__: print(ask_kb(根据知识库验收标准第三条是什么))这段代码的关键在三个参数response_mode用blocking适合脚本一次性拿结果要流式输出就改streaming并逐行读 SSEconversation_id传空开新会话传上次返回的 id 就能多轮对话timeout给足1.5B 模型在普通机器上答长问题十几秒很正常超时设太短会误判失败。API 地址里的端口要跟你.env里配的 nginx 端口一致改过 8080 的话这里也得跟着改。验证方法很简单先用网页界面问同一个问题确认回答和引用正常再用脚本问一遍两边答案一致说明 API 链路没问题。如果脚本报 401检查密钥有没有复制全报 404检查 BASE_URL 路径是不是/v1/chat-messages少一段都通不了。从那以后我每次搭这类本地知识库都强制自己先用 1.5B 小模型把「ollama 起服务 → Docker 起 Dify → 容器连宿主机 → 知识库索引 → API 调通」这五步走一遍全绿了再换大模型、灌正式文档。因为链路问题和小模型大模型无关先跑通再谈效果能省掉大量「到底是模型不行还是配置不对」的自我怀疑。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
