简介《DeepSeekDify本地部署知识库》是一份面向大模型应用初学者与个人开发者的实操型PDF文档聚焦在Windows环境下搭建可离线运行的AI知识库适合希望绕开复杂云端配置、快速理解本地部署链路的读者。文档围绕系统环境变量、Ollama模型管理、DeepSeek-R1与bge-m3拉取、Docker镜像配置以及Dify平台安装与知识库创建展开配有界面截图与关键配置说明可帮助读者建立从模型运行到应用接入的完整认知。资源包共1个PDF文件大小约1.47MB轻量便于查阅和随查随用。目前已有2349人学习说明该主题在AI知识库落地场景中关注度较高。读者可从中获得本地部署的整体流程框架、常见环境配置要点与模型接入Dify的排错思路并据此复现一套可对话、可挂载知识库的本地AI应用适合作为入门实践与部署清单参考。1. 从一台 16G 内存的办公机说起DeepSeekDify 本地知识库到底解决什么有个做工程投标的朋友问过我一个很实际的问题几百份历史标书、技术规范、验收报告能不能直接丢给在线大模型去问答案通常是不能卡点不在模型能力而在数据出不了内网。DeepSeekDify 这套本地部署知识库方案要解决的就是这件事——模型权重、向量库、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_HOST0.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 给上下文和运行时。下表是我在几台不同配置机器上实际跑下来的经验区间不是官方指标仅供参考模型档位权重大小Q4 量化建议内存典型体验deepseek-r1:1.5b约 1.1GB8GB能跑回答偏短复杂推理吃力deepseek-r1:7b / 8b约 4.7-5.2GB16GB办公机甜点档中文问答可用deepseek-r1:14b约 9GB32GB明显更稳CPU 推理会慢到难以忍受deepseek-r1:32b约 20GB48GB 以上需要独立显卡否则别试8B 这一档是大多数人应该选的起点16G 内存的机器能塞下纯 CPU 推理时首 token 大概几秒到十几秒可以接受。如果你有 8GB 以上显存的独立显卡Ollama 会自动把部分层 offload 到 GPU速度提升非常明显这个不需要手动配置。拉取命令很直接# 拉取对话模型run 会自动触发 pull 再进入交互式会话 ollama run deepseek-r1:8b # 交互式会话里问一句测试退出用 /bye或者 CtrlC 中断、CtrlD 发送 EOF # 退出后拉取向量模型这个模型不产出对话只做 embedding ollama pull bge-m3 # 最后确认两个模型都在 ollama listollama 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 restartDocker 会重启一次引擎。验证 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_ENABLEDtrue # 告诉 Dify 后端Ollama 的 API 在哪个地址 OLLAMA_API_BASE_URLhttp://host.docker.internal:11434第一行CUSTOM_MODEL_ENABLEDtrue决定模型供应商列表里能不能加 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_PORT8080之后改用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、dbPostgreSQL、redis、向量库默认 weaviate、sandbox、ssrf_proxy、nginx 这些镜像加起来几个 GB网络差的时候十几分钟很正常。中途 CtrlC 不会损坏什么重新执行会断点续传已完成的层。docker compose ps是最有用的诊断命令。健康状态下每一行都是 Updb 和 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点添加模型。这里要加两次一次加对话模型一次加向量模型。对话模型的填写项字段填写值说明模型名称deepseek-r1:8b必须和ollama list输出完全一致含 tag基础 URLhttp://host.docker.internal:11434容器内访问宿主机的固定域名模型类型Chat对话模型选这项上下文长度4096 或 8192按模型实际支持填填大了会被截断模型最大 token2048单次回复上限按需要调向量模型同样走 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-5Score 阈值填 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。原因权重文件是分片下载的中途某个分片连接断开后重试逻辑不一定能接上另一种情况是目标磁盘剩余空间不足写入失败但不立刻报错。解决先 CtrlC 中断检查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_HOST0.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 和阈值最后才动提示词。下面这组是我在技术文档类语料上对比出来的可以作为起点参数保守值激进值适用场景最大分段长度300 tokens800 tokens条目型文档用 300叙述型用 800分段重叠3080长句多的文档加大重叠TopK36问题宽泛时加大精确问答保持 3Score 阈值0.50.35召回不足时降低噪声多时提高改参数的验证方法不能靠感觉好像好了一点。我一般会准备一组 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: fBearer {API_KEY}, Content-Type: application/json, }, json{ inputs: {}, query: case[q], response_mode: blocking, # 阻塞模式方便脚本直接拿结果 conversation_id: , user: regression-test, }, timeout120, ) 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 次之阈值最后微调。还有一个容易被忽略的调试入口——对话界面右侧的引用面板它直接告诉你这次召回了哪几段、相似度多少。命中率上不去的时候先看面板里召回的分段是不是本来就无关如果召回的段落本身是对的但答案错了那是提示词或模型的问题别再去动分段了。从那以后我每次改检索参数都会先把这十几条问答跑一遍绝不靠随手问两个问题就下结论——人脑记不住上一版的细微差别只有数字记得住。希望这套流程能帮你少走几晚弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 13:30:45 · 阅读 1.2k DeepSeek+Dify本地知识库部署与检索调优避坑指南
简介《DeepSeekDify本地部署知识库》是一份面向大模型应用初学者与个人开发者的实操型PDF文档聚焦在Windows环境下搭建可离线运行的AI知识库适合希望绕开复杂云端配置、快速理解本地部署链路的读者。文档围绕系统环境变量、Ollama模型管理、DeepSeek-R1与bge-m3拉取、Docker镜像配置以及Dify平台安装与知识库创建展开配有界面截图与关键配置说明可帮助读者建立从模型运行到应用接入的完整认知。资源包共1个PDF文件大小约1.47MB轻量便于查阅和随查随用。目前已有2349人学习说明该主题在AI知识库落地场景中关注度较高。读者可从中获得本地部署的整体流程框架、常见环境配置要点与模型接入Dify的排错思路并据此复现一套可对话、可挂载知识库的本地AI应用适合作为入门实践与部署清单参考。1. 从一台 16G 内存的办公机说起DeepSeekDify 本地知识库到底解决什么有个做工程投标的朋友问过我一个很实际的问题几百份历史标书、技术规范、验收报告能不能直接丢给在线大模型去问答案通常是不能卡点不在模型能力而在数据出不了内网。DeepSeekDify 这套本地部署知识库方案要解决的就是这件事——模型权重、向量库、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_HOST0.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 给上下文和运行时。下表是我在几台不同配置机器上实际跑下来的经验区间不是官方指标仅供参考模型档位权重大小Q4 量化建议内存典型体验deepseek-r1:1.5b约 1.1GB8GB能跑回答偏短复杂推理吃力deepseek-r1:7b / 8b约 4.7-5.2GB16GB办公机甜点档中文问答可用deepseek-r1:14b约 9GB32GB明显更稳CPU 推理会慢到难以忍受deepseek-r1:32b约 20GB48GB 以上需要独立显卡否则别试8B 这一档是大多数人应该选的起点16G 内存的机器能塞下纯 CPU 推理时首 token 大概几秒到十几秒可以接受。如果你有 8GB 以上显存的独立显卡Ollama 会自动把部分层 offload 到 GPU速度提升非常明显这个不需要手动配置。拉取命令很直接# 拉取对话模型run 会自动触发 pull 再进入交互式会话 ollama run deepseek-r1:8b # 交互式会话里问一句测试退出用 /bye或者 CtrlC 中断、CtrlD 发送 EOF # 退出后拉取向量模型这个模型不产出对话只做 embedding ollama pull bge-m3 # 最后确认两个模型都在 ollama listollama 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 restartDocker 会重启一次引擎。验证 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_ENABLEDtrue # 告诉 Dify 后端Ollama 的 API 在哪个地址 OLLAMA_API_BASE_URLhttp://host.docker.internal:11434第一行CUSTOM_MODEL_ENABLEDtrue决定模型供应商列表里能不能加 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_PORT8080之后改用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、dbPostgreSQL、redis、向量库默认 weaviate、sandbox、ssrf_proxy、nginx 这些镜像加起来几个 GB网络差的时候十几分钟很正常。中途 CtrlC 不会损坏什么重新执行会断点续传已完成的层。docker compose ps是最有用的诊断命令。健康状态下每一行都是 Updb 和 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点添加模型。这里要加两次一次加对话模型一次加向量模型。对话模型的填写项字段填写值说明模型名称deepseek-r1:8b必须和ollama list输出完全一致含 tag基础 URLhttp://host.docker.internal:11434容器内访问宿主机的固定域名模型类型Chat对话模型选这项上下文长度4096 或 8192按模型实际支持填填大了会被截断模型最大 token2048单次回复上限按需要调向量模型同样走 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-5Score 阈值填 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。原因权重文件是分片下载的中途某个分片连接断开后重试逻辑不一定能接上另一种情况是目标磁盘剩余空间不足写入失败但不立刻报错。解决先 CtrlC 中断检查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_HOST0.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 和阈值最后才动提示词。下面这组是我在技术文档类语料上对比出来的可以作为起点参数保守值激进值适用场景最大分段长度300 tokens800 tokens条目型文档用 300叙述型用 800分段重叠3080长句多的文档加大重叠TopK36问题宽泛时加大精确问答保持 3Score 阈值0.50.35召回不足时降低噪声多时提高改参数的验证方法不能靠感觉好像好了一点。我一般会准备一组 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: fBearer {API_KEY}, Content-Type: application/json, }, json{ inputs: {}, query: case[q], response_mode: blocking, # 阻塞模式方便脚本直接拿结果 conversation_id: , user: regression-test, }, timeout120, ) 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 次之阈值最后微调。还有一个容易被忽略的调试入口——对话界面右侧的引用面板它直接告诉你这次召回了哪几段、相似度多少。命中率上不去的时候先看面板里召回的分段是不是本来就无关如果召回的段落本身是对的但答案错了那是提示词或模型的问题别再去动分段了。从那以后我每次改检索参数都会先把这十几条问答跑一遍绝不靠随手问两个问题就下结论——人脑记不住上一版的细微差别只有数字记得住。希望这套流程能帮你少走几晚弯路。本文还有配套的精品资源点击获取