简介这份资源面向希望本地搭建个人知识库的技术爱好者与开发者围绕 ollama、deepseek、docker 与 Dify 四件套的协同部署展开帮助读者在 Windows 环境下完成从模型下载到知识库问答的完整链路。资源包内含 1 个 doc 文档压缩包约 5.19MB以图文步骤形式记录安装、环境变量配置、模型拉取、Dify 项目启动及知识库创建等关键环节便于按图索骥对照操作。目前已有 3387 人学习说明该方案在本地知识库搭建场景中具备一定参考价值。文档中不仅给出 ollama 安装与 deepseek-r1 模型下载的具体命令还涉及 docker-desktop 部署 Dify、分词方式选择、聊天应用接入 ollama 接口等实操细节并提示命令行需保持运行、模型大小影响下载时长等易踩坑点。对于熟悉容器与命令行、希望把私有文档转化为可检索问答系统的读者可借此快速跑通流程并理解各组件分工。1. 从一台吃灰的旧笔记本说起ollamadeepseekdockerDify 到底能搭出什么你手头可能有一台 16G 内存的旧笔记本或者一台常年开着的迷你主机。上面跑着几个 Docker 容器平时也就当个下载机。某天你突然想能不能让这台机器变成一个只属于自己的知识库问答系统文档丢进去用自然语言问它它从我的资料里找答案而不是去网上瞎编。这个念头一旦冒出来接下来要面对的就是选型问题模型用什么、怎么跑、知识库怎么管、界面怎么来。ollama 负责把 deepseek 模型在本地跑起来docker 负责把 Dify 和它的依赖打包成可迁移的容器Dify 负责把知识库、工作流和对话界面串起来。这套组合的核心价值在于数据不出本机模型推理不依赖外部 API整个系统可以离线运行。适合那些对数据隐私有要求、想低成本验证 RAG 落地、或者单纯想折腾一套私有 AI 基础设施的工程师。部署教程网上很多但真正跑通并且能稳定用的往往卡在几个不起眼的地方。2. 把 deepseek 塞进 ollama模型拉取、量化选择与显存账2.1 为什么是 ollama 而不是自己写推理服务自己用 transformers 加载 deepseek 模型不是不行但你要处理显存分配、量化加载、并发请求排队、模型热切换这一堆事。ollama 把这些封装成了几条命令并且自带一个兼容 OpenAI 格式的 API 端点。对于知识库场景你不需要训练只需要推理ollama 的抽象层级刚好合适。另一个现实原因是 Dify 原生支持 ollama 作为模型供应商。你在 Dify 里填一个http://host.docker.internal:11434就能把本地模型接进去省掉自己写适配层的功夫。常见做法是先用 ollama 把模型跑通再在 Dify 里配置连接这样出问题的时候能快速定位是模型层还是应用层。2.2 拉取 deepseek 模型命令、镜像源与离线包ollama 默认从官方源拉取模型国内网络环境下速度可能很慢。如果你遇到ollama下载太慢了的情况可以配置镜像源。具体做法是设置环境变量OLLAMA_HOST和镜像地址或者直接下载离线包手动导入。# 拉取 deepseek-r1 的 7B 量化版本适合 8G 显存左右的机器 ollama pull deepseek-r1:7b # 如果拉取中断可以重复执行ollama 支持断点续传 # 查看本地已有模型 ollama list # 运行模型进行交互测试 ollama run deepseek-r1:7bdeepseek-r1:7b是蒸馏后的量化版本参数量小推理速度快适合知识库问答这种对生成质量要求不是极致高的场景。如果你的机器有 24G 显存可以换deepseek-r1:14b或32b但要注意 Dify 的知识库检索会额外消耗内存。参数说明7b代表 70 亿参数q4_K_M是默认量化级别显存占用大约 5-6G。如果拉取时提示磁盘空间不足检查~/.ollama/models所在分区。提示ollama 的模型存储路径可以通过OLLAMA_MODELS环境变量修改建议放到空间充裕的盘符。2.3 验证 ollama API 是否可用模型拉下来之后不要急着装 Dify。先用 curl 确认 API 能通这一步能帮你排除掉后面一半的玄学问题。# 检查 ollama 服务是否在运行 curl http://localhost:11434/api/tags # 发送一个简单的生成请求 curl http://localhost:11434/api/generate -d { model: deepseek-r1:7b, prompt: 用一句话解释什么是RAG, stream: false }第一个命令返回模型列表第二个命令返回生成结果。如果第一个命令失败说明 ollama 服务没启动执行ollama serve或者检查系统服务。如果第二个命令超时可能是模型加载慢第一次调用需要把模型加载到显存等待时间取决于磁盘速度和模型大小。stream: false表示一次性返回完整结果方便调试实际接入 Dify 时会用流式输出。3. docker 部署 Dify容器编排、端口映射与数据持久化3.1 Dify 的 docker compose 结构拆解Dify 官方提供了 docker compose 文件里面包含 api、worker、web、db、redis、weaviate 等容器。api 负责后端逻辑worker 处理异步任务比如文档索引web 是前端界面db 是 PostgreSQL 存元数据redis 做缓存和队列weaviate 是向量数据库。理解这个结构很重要因为后面排查问题时你需要知道是哪个容器挂了。# docker-compose.yml 关键片段只保留核心配置 services: api: image: langgenius/dify-api:latest environment: - MODEapi - DB_HOSTdb - REDIS_HOSTredis - VECTOR_STOREweaviate ports: - 5001:5001 depends_on: - db - redis worker: image: langgenius/dify-api:latest environment: - MODEworker depends_on: - db - redis web: image: langgenius/dify-web:latest ports: - 3000:3000 db: image: postgres:15-alpine volumes: - ./volumes/db:/var/lib/postgresql/data redis: image: redis:6-alpine volumes: - ./volumes/redis:/data weaviate: image: semitechnologies/weaviate:1.19.0 volumes: - ./volumes/weaviate:/var/lib/weaviateMODEapi和MODEworker让同一个镜像跑不同角色这是 Dify 的设计。端口映射方面web 的 3000 是你访问界面的端口api 的 5001 是后端接口。数据持久化通过 volumes 挂载到宿主机这样容器删了数据还在。depends_on只保证启动顺序不保证服务就绪所以第一次启动时 api 可能会因为 db 没准备好而重启几次这是正常的。3.2 启动顺序与常见启动失败直接docker compose up -d有时候会翻车因为容器启动速度不一样。稳妥的做法是先起基础服务再起应用层。# 第一步只启动数据库和缓存 docker compose up -d db redis weaviate # 等待 10 秒左右让数据库完成初始化 sleep 10 # 第二步启动 api 和 worker docker compose up -d api worker # 第三步启动前端 docker compose up -d web # 查看所有容器状态 docker compose ps如果docker compose ps显示某个容器不断重启用docker compose logs 服务名看日志。常见错误是 db 容器初始化失败日志里会出现database system is ready to accept connections之后又报错通常是 volumes 目录权限问题。解决方法是删掉./volumes/db重新来或者手动修改目录权限。注意如果你之前装过其他 PostgreSQL 占用了 5432 端口Dify 的 db 容器会启动失败。检查docker ps有没有端口冲突。3.3 把 ollama 接入 Dify 的模型配置Dify 启动后登录管理后台在「设置」→「模型供应商」里找到 ollama。填写模型名称deepseek-r1:7b基础 URL 填http://host.docker.internal:11434。这个地址是 docker 容器访问宿主机的特殊域名Linux 下可能需要换成宿主机的实际 IP。# Linux 下查看 docker 网桥地址 ip addr show docker0 | grep inet # 如果 host.docker.internal 不生效在 docker-compose.yml 的 api 服务下加一行 extra_hosts: - host.docker.internal:host-gateway加完extra_hosts后需要docker compose up -d api重建容器。配置完成后点「测试」按钮如果返回模型列表说明连接成功。如果报dify an error occurred during credentials validation先确认 ollama 服务在宿主机上curl http://localhost:11434/api/tags能通再确认容器内curl http://host.docker.internal:11434/api/tags能通。两层都通但 Dify 还报错检查模型名称是否和ollama list输出完全一致大小写和标签都不能错。4. 知识库流水线文档上传、分段、向量化与检索调参4.1 文档上传后的处理流程在 Dify 里创建知识库上传文档。支持 PDF、Word、Markdown、TXT 等格式。上传后 Dify 会做几件事提取文本、按规则分段、调用 embedding 模型把每段转成向量、存入 weaviate。这个流程叫dify知识库流水线每一步都有参数可以调。分段是关键。分得太碎检索时召回的内容不完整分得太大向量语义被稀释检索精度下降。Dify 默认按字符数分段一般设 500-1000 字符重叠 50-100 字符。对于技术文档按标题层级分段效果更好但需要文档本身结构清晰。4.2 embedding 模型的选择与 ollama 的配合Dify 默认用 OpenAI 的 embedding 模型但你要离线运行就得换成本地的。ollama 支持nomic-embed-text等 embedding 模型。# 拉取 embedding 模型 ollama pull nomic-embed-text # 在 Dify 模型供应商里配置 embedding 模型 # 模型名称nomic-embed-text # 基础 URLhttp://host.docker.internal:11434配置好后在知识库设置里选择这个 embedding 模型。注意embedding 模型一旦选定已经索引的文档不能直接换模型换了之后向量维度不匹配必须重新索引。所以建知识库之前先想好用什么 embedding 模型。4.3 检索参数怎么调Top K、Score 阈值与重排序知识库建好后在应用编排里加一个「知识检索」节点。核心参数有三个Top K、Score 阈值、重排序模型。参数作用建议值调整方向Top K召回多少条相关片段3-5调大召回多但噪声多Score 阈值过滤低相关度结果0.5-0.7调高精度升但召回降重排序对召回结果二次排序开启提升精度但增加延迟Top K 设 3 表示每次检索返回最相关的 3 个片段塞进 prompt 里让模型基于这些片段回答。Score 阈值 0.5 表示相似度低于 0.5 的片段直接丢弃。重排序模型可以用bge-reranker系列ollama 也支持但会额外消耗算力。如果发现模型回答时经常说「根据提供的资料无法回答」先把 Score 阈值降到 0.3 试试可能是过滤太狠了。提示dify工作流 上下文超长通常是因为 Top K 太大或者分段太长导致塞进模型的 token 数超过模型上下文窗口。deepseek-r1:7b 的上下文是 64K但实际使用时建议控制在 8K 以内留出空间给系统提示和对话历史。5. 避坑与排查那些让部署教程翻车的细节5.1 现象Dify 页面能打开但模型测试报 SSL 错误原因Dify 的 api 容器在请求 ollama 时走了 HTTPS但 ollama 默认是 HTTP。或者你配置的 URL 带了https://前缀。解决检查模型供应商配置里的基础 URL确保是http://而不是https://。如果 Dify 强制 HTTPS在docker-compose.yml的 api 服务环境变量里加CONSOLE_API_URL和CONSOLE_WEB_URL用 http 协议。dify ssl错误多数是协议写错导致的。5.2 现象文档上传后一直显示「索引中」worker 日志报连接 weaviate 失败原因weaviate 容器没起来或者 api/worker 容器里的VECTOR_STORE环境变量和实际使用的向量库不一致。解决docker compose ps确认 weaviate 状态如果没起来看日志。确认docker-compose.yml里 api 和 worker 的VECTOR_STORE都设成了weaviate。如果之前用过其他向量库volumes 里的数据可能冲突删掉./volumes/weaviate重新初始化。5.3 现象ollama 拉取模型到一半卡住进度条不动原因网络波动导致下载中断或者磁盘空间不足。解决先df -h检查磁盘。如果空间够CtrlC 中断后重新ollama pullollama 支持断点续传。如果反复卡在同一个位置换镜像源或者用离线包。ollama离线安装包可以从其他机器拷贝~/.ollama/models目录过来放到相同路径即可。5.4 现象Dify 对话时响应极慢每次要等十几秒原因模型第一次加载到显存需要时间或者 Top K 设太大导致检索和生成都很慢。解决第一次调用慢是正常的后续会快。如果一直慢检查ollama ps看模型是否常驻显存。如果显存不够模型会在内存和显存之间反复交换。降低 Top K换更小的模型或者加显存。docker stats可以看容器资源占用确认不是 Dify 本身在抢资源。5.5 现象重启电脑后 Dify 打不开容器全部退出原因docker 服务没设置开机自启或者容器没有设置 restart 策略。解决docker compose up -d重新启动。长期方案是在docker-compose.yml里给每个服务加restart: unless-stopped这样 docker 服务启动后容器会自动起来。另外确认 docker desktop 或 docker daemon 本身设置了开机启动。6. 让知识库真正好用分段策略微调与检索效果验证部署跑通只是第一步真正决定这套系统好不好用的是知识库的检索质量。我自己的习惯是每建一个知识库先拿 10 个典型问题做一轮测试记录哪些问题答对了、哪些答错了、哪些答非所问。然后针对性地调分段和检索参数而不是凭感觉瞎调。分段策略上技术文档我一般按 Markdown 标题切每个二级标题下的内容作为一个独立片段如果超过 800 字符再按段落切。产品手册按章节切每章一个片段。FAQ 类文档按问答对切一问一答作为一个片段。这样切出来的片段语义完整检索时命中率高。验证检索效果有个笨办法但很管用在 Dify 的知识库页面用「召回测试」功能输入一个问题看返回的片段是不是你期望的那些。如果返回的片段不相关先别怪模型大概率是分段或 embedding 的问题。把不相关的片段拿出来看是不是被切碎了或者混入了无关内容。调整分段后重新索引再测。还有一个容易忽略的点deepseek 模型本身有很强的推理能力但知识库问答场景下你要在系统提示里明确告诉它「只根据提供的资料回答不要编造」。我一般会写「你是一个知识库助手请严格基于以下资料回答问题。如果资料中没有相关信息直接说不知道不要尝试用你的通用知识补充。」这句话能显著降低幻觉率。最后说一个我踩过的坑不要一次性把所有文档都丢进去。先传一小部分跑通流程确认检索效果再批量上传。批量上传时 worker 会排队处理如果文档很多索引时间可能很长期间 Dify 的响应会变慢。分批上传每批传完等索引完成再传下一批这样出问题也容易定位是哪批文档的锅。希望帮到你。本文还有配套的精品资源点击获取