简介一份面向入门用户的DeepSeekDify本地部署实操教程以PDF图文形式完整演示在Windows 11环境下搭建AI知识库的全过程适合没有Linux基础、希望低成本构建私有化AI问答体系的个人开发者或小团队。资源包含1个PDF文件大小1.47MB虽体量精简但覆盖系统环境变量设置、Ollama安装与模型拉取、Docker Desktop镜像配置、Dify开源平台部署及知识库创建等关键环节并附有命令示例与界面截图。已有2338人学习浏览。教程重点解决了本地模型存储位置规划、deepseek-r1与bge-m3模型选择、Ollama API地址配置等常见痛点通过文档中的ollama list、docker compose up -d等命令输出对照读者按顺序操作即可避免踩坑最终在http://127.0.0.1/install完成管理员配置并创建专属知识库问答助手实现大模型与文档问答的本地落地。步骤编排清晰从零开始引导尤其适合首次接触本地大模型的用户。1. 本地部署知识库不是大厂专利DeepSeek 与 Dify 的自由组合很多团队最早接触本地部署知识库都是从「用 Dify 搭一个能回答内部文档问题的应用」开始的。Dify 负责把知识库、工作流、模型统一编排在一起DeepSeek 负责理解问题、生成答案整套系统跑在你自己的服务器甚至一台 16G 显存的电脑上。数据不出内网成本按电费算而不是按 token 算这恰是本地部署大语言模型最让从业者心动的地方。你要面对的已经不是「能不能做」而是「怎么把每个环节配到能稳定跑生产」。这篇文章按我实际部署的顺序来写模型侧怎么跑、Dify 怎么接、知识库怎么建、哪些坑必须躲。2. 模型侧先落地用 Ollama 把 DeepSeek 跑在本地2.1 为什么选 Ollama 而不是直接跑 Python 推理常见做法是先用 Ollama 托管模型。DeepSeek 的权重可以从模型社区直接下载但裸用 Python 推理要自己处理显存分配、并发队列、上下文窗口管理这些坑没必要在起步阶段踩。Ollama 把模型加载、量化、API 服务封装成一条命令默认暴露一个兼容 OpenAI 格式的 HTTP 接口Dify 接它就像接一个远程模型服务省掉中间层开发。另一个理由是 Ollama 的量化机制。DeepSeek 这类大模型原始权重动辄十几 GBOllama 会自动拉取量化后的版本显存占用能降到一半左右。这对本地部署场景几乎是决定性的——一张 16G 显存的消费级显卡可以跑 14B 量化模型换作原始权重早就爆显存了。2.2 最小启动命令# 安装完成后直接拉模型7b 和 14b 是知识库场景最常用的两个档位 ollama pull deepseek-r1:7b ollama pull deepseek-r1:14b # 后台启动服务默认监听 11434 端口 ollama serve拉取时间取决于网络带宽模型文件几个 GB 到十几个 GB 不等。ollama serve启动后可以用ollama ps查看当前加载了哪些模型用curl http://localhost:11434/v1/models验证 API 是否就绪。注意ollama serve默认只监听本机如果 Dify 跑在同一台机器就够用想从局域网内其他机器接入需要设置环境变量OLLAMA_HOST0.0.0.0再重启服务。2.3 不同参数量怎么选显存与效果对照模型规格量化后体积建议最低显存适用场景deepseek-r1:1.5b约 1.1GB4GB 集成显卡可跑简单问答、原型验证deepseek-r1:7b约 4.7GB8GB中等复杂度的文档问答deepseek-r1:14b约 9GB16GB多数企业知识库场景deepseek-r1:32b约 20GB32GB 以上高精度要求、长文本推理我一般会建议先从 7b 起步跑通整条 Dify 流水线确认知识库检索和提示词逻辑没问题再切 14b 提升回答质量。直接上 32b 容易碰到显存不足导致服务崩溃排错成本会淹没掉收益。Ollama 还支持通过修改OLLAMA_NUM_PARALLEL控制并发请求数显存紧张时设为 1避免多个请求同时把模型多个副本塞进显存。3. Dify 部署与模型接入从 Docker Compose 到 Ollama Provider3.1 标准部署路径Dify 官方推荐用 Docker Compose 部署整套编排文件里已经包含了 PostgreSQL、Redis、API 服务、Worker 和前端。我的习惯是先去 Dify 项目仓库把发布版源码拉下来进入docker目录执行部署git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d启动后浏览器访问http://服务器IP/install走初始化向导。第一次部署最重要的一件事是修改.env里的SECRET_KEY不改成随机值就直接暴露在生产网络等于把管理后台的钥匙挂在门口。Dify 依赖的 PostgreSQL 和 Redis 数据目录默认在 Docker volume 里备份时把整个dify/docker/volumes目录一并拷走即可。3.2 Dify 里把 Ollama 注册成模型供应商Dify 的模型层逻辑是「供应商 模型类型」。Ollama 在 Dify 里被识别为一个供应商分别提供LLM、Text Embedding、Rerank三类模型能力。进入「设置 - 模型供应商 - Ollama」填三项API 地址、模型名称、模型类型。# 先确认模型已经拉到本地 ollama list # 再用 curl 验证 API 连通性Dify 里填的地址要和这个能通 curl http://Ollama宿主机IP:11434/v1/modelsAPI 地址这里有个必须注意的点Dify 容器要访问的不是localhost因为localhost在 Docker 容器内部指向的是容器自己。正确写法是用宿主机 IP比如http://192.168.1.100:11434如果 Dify 和 Ollama 都在同一台机器也可以用http://host.docker.internal:11434但 Linux 环境下host.docker.internal不一定默认可用后面避坑章单独讲。LLM 配置里模型名要和ollama list输出的名称完全一致比如deepseek-r1:14b。Embedding 模型我推荐用bge-m3这是目前中文知识库场景里效果与资源消耗平衡得比较好的开源模型可以在 Ollama 里直接拉取。Rerank 模型可选配先不填也能跑后续调优再补。3.3 配置完怎么验证是通的在 Dify 的模型供应商页面点「测试」系统会发一个最小请求到模型服务。如果提示连接失败多半是网络互通问题如果提示模型不存在多半是模型名写错。测试通过后去「设置 - 模型供应商」里把 Ollama 的 LLM 和 Embedding 标记为「默认模型」这一步容易漏——不设默认创建应用时模型下拉里会一直提示无可用模型。4. 知识库流水线拆分、向量化、检索与提示词组装4.1 知识库在 Dify 里的数据流向Dify 的知识库功能本质上是一条 RAG 流水线上传文档 → 文本拆分 → 向量化 → 存入数据库 → 用户提问时召回相关片段 → 拼进提示词 → 交给大模型生成回答。知识库在 Dify 里的界面叫「知识库」创建后可以上传多个文档每个文档会被拆分成若干段每段单独向量化。检索时不是整个文档拿去匹配而是用向量相似度找出最相关的几个分段。这一步理解到位后面调参数就有方向。检索质量主要由三件事决定拆分粒度是否合适、向量模型是否匹配语种、检索方式是否适合文档类型。Dify 的参数面板里每一项都有对应的调整入口下面分别说。4.2 文档拆分分段长度、重叠与分隔符上传文档后Dify 会按设定的分段规则把文档切成多个片段。默认自动分段对短文档够用但对技术文档、规章制度这类结构化的内容我更推荐自定义分段分段长度设为 300500 字符。太大了答案会混入无关内容太小了上下文信息不足大模型回答时没有足够依据。分段重叠设为 5080 字符。避免把一句话从中间切碎导致关键信息被腰斩。分隔符优先选换行符和 Markdown 标题让切分位置落在语义边界上。Dify 支持在知识库里针对单个文档重新分段不用重建知识库。这个能力很实用——前期分段参数没调好直接改文档的分段设置重新索引就行。4.3 Embedding 模型与检索模式的参数设置知识库详情页的「检索设置」里核心参数是检索模式和 TopK。检索模式有向量检索、全文检索、混合检索等选项。我一般选混合检索向量检索负责语义匹配全文检索负责关键词精确匹配两者结果合并后去重再排序。这个设置在文档中含有大量产品型号、编号、专业名词时尤其重要单靠向量搜索经常漏掉精确匹配。TopK 控制取多少个片段送给大模型。默认 3 偏低知识库内容多时可以调到 58。数值越大回答时依据越充分但提示词会被无关内容污染。配合分数阈值使用更稳Dify 里有 Score 阈值参数不同版本名称略有差异设为 0.40.6 之间比较合理。阈值太低一堆弱相关片段被塞进提示词阈值太高严格过滤后经常召回为空。4.4 创建一个最小可用应用Chatflow 的组装知识库准备好后在 Dify 里创建一个「Chatflow」类型应用。Chatflow 比普通聊天应用多了一个可视化的节点编排界面可以在用户提问之后插入「知识检索」节点再把检索结果和原始问题拼起来发给大模型。操作路径是新建应用 → 选 Chatflow → 画布中拖入「知识检索」节点 → 选择刚建好的知识库 → 把检索节点输出接回 LLM 节点 → LLM 节点选用 Ollama 提供商下的 DeepSeek 模型。这里最容易踩的坑是忘了在提示词里约束「只依据检索到的内容回答」导致大模型在没有相关知识时强行编造。一个能直接用的系统提示词模板你是企业内部知识库助手。你只能依据系统提供的检索片段来回答用户问题。 当检索片段不足以支撑答案时直接回答“知识库中没有找到相关信息”不要编造。 回答时如果引用了某个文档标注来源文档名称。Dify 的 Chatflow 里可以把「知识检索」节点的输出配置在提示词变量中推荐以「以下是检索到的文档内容」开头让模型明确感知输入里哪部分是检索结果、哪部分是用户问题回答的稳定性会明显提升。5. 常见问题与避坑Dify 连不上模型、命中率低、向量化卡死5.1 Dify 容器连不上 Ollama 服务现象Dify 模型供应商测试时提示「Connection refused」或者超时。原因Dify 跑在 Docker 容器里容器内访问localhost指向的是容器自己访问不到宿主机上监听的 Ollama。Linux 环境下host.docker.internal这个域名默认不会自动映射到宿主机。解决在 Dify 的docker-compose.yaml里给 API 容器加extra_hosts或者直接把 Ollama 的 API 地址填成宿主机局域网 IP。推荐前者services: api: extra_hosts: - host.docker.internal:host-gateway改完重新docker compose up -d让配置生效。这个坑几乎每个本地部署 Dify 的人都会遇到先确认网络互通比查其他原因省时间。5.2 知识库命中率低回答永远像在猜现象上传了文档应用也建好了问一个文档里明确写着的事实回答却含糊不清或者答非所问。原因第一是分段太粗一个片段塞进几千字向量化后语义被稀释检索时相关度上不去第二是检索模式用默认的向量检索没有开混合检索第三是 TopK 和分数阈值没配合好要么召回太少要么召回太多噪声。解决回到知识库设置把分段长度调到 500 以内并加分段重叠检索模式切到混合检索TopK 调到 5 以上分数阈值先设 0.5 再逐步下调。每改一次就回应用里用同一句话测试观察召回内容的变化。调这个参数组合确实带点玄学成分但按这个顺序调绝大多数情况下能解决。5.3 Ollama 显存不够直接崩溃现象模型服务刚才还好好的问答到一半突然报错ollama ps显示模型被重新加载或者日志里出现CUDA out of memory。原因Ollama 默认会同时加载多个请求需要的模型副本。知识库场景里用户每发一个问题Dify 会同时调用 embedding 模型和 LLM显存小的机器直接爆掉。解决设置环境变量限制 Ollama 的并发行为OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1分别限制同一模型的最大并行请求数以及同时驻留显存的模型数量。这样虽然会排队但服务不会崩。显存实在太紧就把 LLM 换成 7b 量化版embedding 换成更小的 bge-small。5.4 向量化过程卡住不结束现象上传文档后「等待索引」状态持续很久日志显示 embedding API 调用超时。原因embedding 模型用的 CPU 推理速度极慢尤其是bge-m3这个体量的模型纯 CPU 跑一个长文档要好几分钟。另一种情况是 embedding 模型的并发请求把 Ollama 堵死了。解决确认 Ollama 日志里 embedding 请求是否在排队。如果是 CPU 推理慢换成 GPU 跑或者选更轻量的 embedding 模型如果是并发问题检查是不是把 embedding 请求并发数调得太大Dify 的设置里可以限制 embedding 并发。5.5 Ollama 的 SSL 错误现象Dify 测试模型连接时提示 SSL 相关错误。原因Dify 里有的版本默认会用 HTTPS 前缀去拼接供应商 API 地址而本地 Ollama 只提供 HTTP 服务。还有一种情况是 Ollama 的 API 地址被填成https://打头Dify 按 HTTPS 握手但 Ollama 那边根本没有 TLS 层。解决把 API Base 地址明确写成http://IP:11434不要用https。这个错误本身不难解只是隐藏得深第一次遇到很容易以为是证书问题往错误方向排查半天。6. 把问答做准的关键一步Rerank 重排序与命中测试6.1 为什么召回结果看起来相关答案却不靠谱向量检索返回的 TopK 片段排序依据只是向量相似度并不完全等于「对当前问题的有用程度」。文档里经常存在多个片段讲同一件事或者一段话包含多层信息相似度排名和真实答案质量之间常常错位。这时候需要在知识检索节点后加一个重排序Rerank步骤让一个专门的模型基于「问题 片段」重新打分排序。Dify 的知识检索节点里「重排序」选项可以直接打开。模型可以在 Ollama 里拉一个 rerank 模型也可以先在 Dify 的模型供应商里配好后再选。重排序会额外消耗一次模型调用但知识库答案的质量提升非常明显尤其是文档量上了几十份之后属于性价比最高的调优手段。6.2 用命中测试代替反复试错Dify 的知识库详情页里有「召回测试」入口可以输入一个真实业务问题直接查看系统召回哪些片段以及各片段的相似度分数。这是调试知识库最有效的手段比反复在应用聊天窗口里试答案直观得多。我一般会准备 10 个覆盖不同文档内容的真实问题逐个跑一遍命中测试观察两个指标相似度分数是否整体偏低说明分段或 embedding 没对齐。召回的片段位置是否集中在某几篇文档说明其余文档内容没被有效命中。命中测试暴露的问题按上一章的排查顺序去改先调分段再调检索模式最后调阈值。改完一轮重新测试记录每轮分数变化。6.3 两个常用但容易被忽略的验证角度第一是「否定类问题」的测试——故意问一个知识库里不存在的内容看系统是否诚实地表示不知道。很多配置里大模型会强行从稀疏的检索结果里编造答案这种问题在提示词里明确约束可以缓解。第二是「答案溯源」测试——要求回答中标注来源文档名称如果模型经常从文档 A 的内容回答却标注文档 B 的来源说明检索上下文在提示词里没有足够清晰的边界标记。回看我自己跑过的知识库项目最血泪的经验是刚开始图省事把分数阈值直接设成 0想着「反正 TopK 会截断」结果大量弱相关片段被喂给模型回答质量反而更差。后来老老实实把阈值从 0.6 往低调配合命中测试逐步找到平衡点才算稳定下来。本地部署知识库这条路工具都是现成的真正的工夫都花在参数调校和文档梳理上。希望这篇能帮你少走我走过的弯路。本文还有配套的精品资源点击获取