Dify + Ollama + DeepSeek 离线知识库搭建实战

简介这是一份Dify项目GitHub源码压缩包面向希望在本地离线环境搭建个人知识库的开发者与AI应用爱好者。基于Dify、Ollama与DeepSeek的组合可完成从模型管理、知识库构建、工作流编排到应用发布的全流程配置适合已有一定基础、需要私有化部署或规避云端依赖的技术人员。资源共2000个文件以Python源码和YAML配置为主辅以Markdown说明文档、HTML邮件模板与JSON配置等其中py文件承载后端业务逻辑yaml文件用于服务与工作流定义目录结构清晰便于按模块二次开发整体约26.31MB。目前已有3579人学习下载。压缩包内包含完整的Dify平台代码与部署所需配置读者可结合Ollama与DeepSeek模型接入实践对比Open-WebUI、AnythingLLM等工具的差异理解纯聊天界面、文档知识库问答与复杂工作流编排的不同侧重点快速搭建并扩展个人离线知识库系统是本地化AI应用开发的一份高质量参考。 说实话我一开始也没想到一个完全跑在本地、不依赖任何云端的个人知识库能用 Dify Ollama DeepSeek 这套组合轻松搭起来。整个流程走下来——从 GitHub 上把 Dify 的 zip 包拖下来到 Ollama 里跑起 DeepSeek 模型再到知识库真正上线可用——前后不到半天。你要是有数据隐私方面的顾虑或者公司内部要做离线部署那这篇实操记录应该能帮你少踩不少坑。我先把结论放在最前面这套方案的灵魂就是“全离线”。DeepSeek 模型通过 Ollama 跑在本机Dify 平台负责知识库管理、检索增强和对话编排所有数据和请求全部留在本地不依赖任何外部 API。适合对数据敏感的个人用户、中小企业内部知识管理以及想在内网环境里复现一套“类 ChatGPT 知识库”方案的技术爱好者。你不需要有多高的深度学习基础跟着步骤走就能成。1. 方案选型为什么非得是这三件套1.1 场景痛点与需求拆解我当初的需求其实特别简单手头有一批 PDF、Markdown 文档和内部技术资料散落在各个文件夹里想搜个东西得翻半天。我想要的不是传统的关键词搜索而是那种“用大白话提问、它帮我定位答案、顺便还能用上下文总结归纳”的智能问答。说白了就是想要一个私人定制的知识库助手。第一版方案想过直接用云端大模型 API把文档传到第三方平台去做检索增强。但我手里的资料有一部分涉及内部配置和客户信息放到云上始终心里不踏实。而且一旦断网或者 API 配额用完整个系统就瘫了。这让我把优先级明确成了三条数据绝对不外传所有处理和存储都在本机完成离线可用部署完成后不依赖外网也能稳定跑技术栈尽量成熟社区活跃出了问题能找到人问。基于这三条方案就逐渐收敛到了 Dify Ollama DeepSeek 的组合上。1.2 组件选型逻辑为什么选 DeepSeek 而不选别的模型原因很实在。DeepSeek 系列模型在中文理解和推理上表现扎实在开源模型里属于第一梯队而且它家在 Ollama 生态里有现成的蒸馏版模型可以直接拉下来用。对于个人知识库这种偏文本理解、语义检索和归纳总结的场景DeepSeek-R1 蒸馏版完全够用不需要动辄几百 GB 的超大模型。为什么用 Ollama 来跑模型这个更不用纠结。Ollama 把模型下载、运行、接口暴露这三件事压缩成了一两个命令天然就是干这个的。你不需要自己去处理 Python 环境、CUDA 依赖、模型权重格式转换这一堆破事装在机器上、拉好模型、默认监听 11434 端口完事。Dify 则是整个系统的“总装车间”。它自带知识库管理、文档分块、向量检索、可视化的对话工作流还能一键接入 Ollama 这种本地模型源。不用 Dify 的话你得自己拿 LangChain、向量数据库和前端页面拼一套系统出来那工作量完全不是一个量级的。Dify 的意义就在于把知识库应用从“开发项目”降维成了“配置项目”。这里再补一句我在选型时特别关注的细节Dify 的知识库模块支持多种检索模式能够对接本地 Embedding 模型这直接决定了离线知识库能不能闭环。很多类似的平台要么只支持云端 Embedding要么本地化配置特别折腾Dify 这块做得比较省心。2. 离线部署实战从零开始装环境2.1 硬件与系统环境准备先说结论如果你只是想跑一个个人用的知识库16GB 内存、4 核 CPU、一块 50GB 空闲磁盘的机器就够用了。如果模型要上 14B 或者更大的量级内存建议 32GB 起步。注意这里说的内存是物理内存不是显卡显存。Ollama 在没有 GPU 的机器上会用 CPU 推理只要你把模型量级控制在合理范围内体验不会太差。我自己测试的机器是一台 16GB 内存的小主机跑 7B 量化模型单轮问答大概 5 到 10 秒出结果完全在可接受范围。操作系统方面Windows 和 Linux 都行但前提是必须装好 Docker。Dify 官方推荐的部署方式就是 Docker Compose它把后端 API、Worker、PostgreSQL、Redis、Nginx 这些组件全部编排在一起一条命令就能拉起整个平台。如果你用的是 Linux 服务器建议 Docker Engine 版本在 20.10 以上Compose 插件也要装好。Windows 用户推荐 Docker Desktop安装完成后记得在设置里把资源配额调高一点不然容器很容易因为内存不够被杀掉。提示部署前先用docker version和docker compose version确认环境没问题。这里踩坑的人非常多Docker 没起来就急着跑 Dify最后日志里全是连接报错浪费大量时间排查。2.2 Ollama 的离线安装与模型准备Ollama 的安装分两种情况。如果你所在的机器能联网最简单的办法是直接从官网下载对应系统的安装包Windows 是 exe 安装包Linux 是一段 curl 脚本或者 rpm/deb 包。装完以后在终端执行ollama serve把服务拉起来或者直接让它作为后台服务常驻运行。如果完全是内网离线环境就需要在有网机器上提前下载好安装包和模型文件再拷贝进去。模型这块有点特殊Ollama 的模型默认存储在~/.ollama/models目录下你可以在有网的机器上先用ollama pull deepseek-r1:7b拉取目标模型然后把整个models目录打包带到内网机器上解压到相同路径即可。再或者你可以直接去 Hugging Face 或 ModelScope 上手动下载 GGUF 格式的模型权重放到 Ollama 的模型目录里并用ollama create命令导入。这种手动方式更灵活适合对模型版本有特定要求的场景。DeepSeek 官方在 Ollama 仓库中提供的模型名以deepseek-r1和deepseek-v2系列为主。个人用的话我推荐从deepseek-r1:1.5b或者deepseek-r1:7b开始。1.5B 响应快但对复杂问题的推理能力稍弱7B 在速度和回答质量之间比较均衡是目前最主流的选择。你可以在本机执行ollama list确认哪些模型已经可用。2.3 Dify 的 GitHub zip 包安装流程Dify 的安装我推荐走源码包方式因为能直接拿到最近的版本和完整的 Docker 编排文件。去 GitHub 上找 Dify 官方仓库在 Code 页面点击 Download ZIP把整个仓库源码包下载到服务器上。这个包大概几十 MB里面已经带好了docker目录和.env配置文件模板。拿到 zip 包后先解压然后在根目录下执行unzip dify-main.zip cd dify-main/docker cp .env.example .env这里说一句.env是整个系统的核心配置。你要重点检查几个变量SECRET_KEY必须改成一个随机字符串POSTGRES_PASSWORD和REDIS_PASSWORD建议也换成强密码EXPOSE_NGINX_PORT默认是 80如果端口被占可以改成 8080 之类的高位端口。改完后直接执行docker compose up -d这一步会拉取 Dify 相关的所有镜像并启动容器。首次执行的时候镜像比较大耗时取决于网络状况耐心等就行。启动完成后访问http://服务器IP:端口/install设置管理员账号密码整个平台就活了。有一点很有必要提醒如果你所在环境完全断网、连 Docker Hub 都访问不了那在部署机执行docker compose up之前需要提前在有网机器上用docker pull把镜像一个个拉下来再用docker save导出为 tar 文件拷贝到内网机器上通过docker load导入。Dify 的镜像数量不少建议写个脚本统一处理逐个手动操作会非常痛苦。2.4 初始化配置中的关键细节Dify 装完以后先进管理后台把系统设置过一遍。语言切成中文邮箱如果有 SMTP 服务可以配置没有就跳过不影响核心功能。这里值得多花两分钟的是模型供应商设置因为后面所有对话和知识库Embedding都依赖这一环。Dify 支持几十种模型供应商你要找的是 Ollama。在“设置 → 模型供应商 → 添加新的供应商”里直接搜 Ollama点进去以后填入 API Endpoint。这里有一个非常经典的坑Dify 跑在 Docker 容器里而 Ollama 通常跑在宿主机上所以你不能填http://localhost:11434因为容器内部的 localhost 指的是容器自己不是宿主机。正确的做法取决于你的部署环境如果是 Linux 服务器填http://宿主机IP:11434例如http://192.168.1.100:11434如果是 Docker DesktopMac/Windows填http://host.docker.internal:11434如果你用的是 Docker Compose 网络且把 Ollama 也容器化部署了填服务名加端口例如http://ollama:11434。配置完以后Dify 会自动拉取 Ollama 上已有的模型列表你只需要勾选可用的模型并设置上下文长度和最大 Token 数。3. 串联三件套模型接入与知识库构建3.1 在 Dify 工作流中接入 Ollama 模型模型接入不只是填个地址就完事。Dify 在对话型应用里会让你为每个模型指定具体的参数上下文窗口大小、Temperature、Top P、最大 Token 数等。这里我建议 Temperature 设到 0.5 以下知识库问答场景追求的是准确和稳定随机性太高容易答非所问。上下文窗口要根据你的硬件来定7B 模型配 4096 的上下文比较稳妥。填入并验证通过后你可以先在 Dify 的“提示词编排”页面里做一个最简单的聊天助手不要挂知识库先直接对话试一下确认 Dify 和 Ollama 之间的链路是通的。这里分享一个我试过的快捷验证方式在终端直接对 Ollama 发请求确认模型本身没有问题curl http://localhost:11434/api/chat -d { model: deepseek-r1:7b, messages: [{role: user, content: 你是谁}] }这条通以后再去排查 Dify 的问题你能把故障范围缩小一半。3.2 准备知识库上传文档、分块与索引链路通了以后就要开始做正事了把文档喂给系统。在 Dify 的“知识库”页面点创建输入名称后进入文档上传界面。Dify 支持 TXT、Markdown、PDF、DOCX、HTML 等常见格式你可以一次拖入多个文件也可以上传一个文件夹的压缩包。上传之后有一个很关键的设置项分块规则。为什么会强调分块因为大模型和向量检索都不是直接处理整篇文档的。系统会把文档切成长度合适的文本片段每一段单独做 Embedding 向量化用户提问时先在向量库里检索到最相关的片段再拼进 Prompt 里喂给模型。分块太大检索到的东西不够精确还容易超 Token 限制分块太小语义可能被截断上下文信息丢失。我实测下来通用技术文档用 Dify 默认的分块大小500 字符左右、重叠 50 字符就能有不错的检索效果。如果你的文档里表格特别多可以把分块调小到 300 左右减少跨块截断带来的信息丢失。分块之后系统会提示选择 Embedding 模型这个环节必须选 Ollama 里的向量模型。你在 Ollama 上要提前拉一个 Embedding 模型推荐bge-m3或者nomic-embed-text。Embedding 模型负责把文本转成向量决定了检索阶段能不能找到相关内容。如果不配这一步知识库的召回率会非常感人——不是搜不到就是搜出来的内容驴唇不对马嘴。这是离线方案里最容易出问题的地方因为很多教程默认你用的是云端 Embedding API一到离线环境就翻车。索引创建完成后Dify 会显示文档的处理状态。千万等状态变成“完成”再开始下游操作不然它检索阶段会查不到任何内容。3.3 搭建问答应用并验证效果知识库准备妥当以后进“应用”页面创建一个聊天助手类型的应用在提示词编排界面的右上角点“添加上下文”把刚建好的知识库挂进去。这时Dify 会自动为知识库启用检索增强生成流程用户提问进来以后先检索相关文档片段再把提问和片段一起交给 DeepSeek 模型做整合回答。建议在“上下文”设置里把检索模式切成“混合检索”同时开启 Rerank 重排序。混合检索的好处是它能同时用向量语义和关键词匹配来找内容对一些专业术语、编号、代码片段等可能有奇效。首次提问时系统会多花一两秒做检索这是正常现象不要急着判定系统出了问题。验证标准我给你一个比较笨但很有效的办法故意问你知识库里某一篇文档里的细节问题比如“某某模块的默认超时时间是多久”如果答案能和原文对上、并且附带引用来源说明整条链路已经闭环了。如果它答不出来或者胡说八道不要急着怀疑模型能力绝大多数情况是检索环节没召回相关内容去检查分块设置和文档质量比换模型更有效。4. 实战排雷常见问题、优化手段与经验心得4.1 高频问题速查表我把自己部署过程中遇到过的、以及在技术社区里被问烂的问题整理成了一张速查表你照着排查效率会高很多。问题现象可能原因解决方法Dify 页面一直转圈进不去容器没启动或 Nginx 端口被占用检查docker compose ps状态换端口后重启对话时提示模型连接失败Ollama 地址填错或服务未启动确认宿主机与容器的网络关系curl 测试 Ollama 接口知识库显示“索引失败”Embedding 模型未配置或模型拉取失败在 Ollama 里重新pullEmbedding 模型检查模型名是否匹配问答答非所问检索不到内容分块大小不合理、文档格式识别差调小分块长度把 PDF/扫描件转成文本后再上传响应速度特别慢模型量化等级太高或内存不足换更小的模型如 1.5B/3B或增加 swap容器频繁重启内存配额不足Docker Desktop 里调高内存限制清理无用的容器镜像Dify 的容器很多排查容器状态可以重点看这几个docker compose logs -f api能看后端处理日志docker compose logs -f worker能看知识库索引任务的进度docker compose logs -f web看前端页面相关的错误。出现问题时别手忙脚乱地重启所有容器先定位是哪个组件的问题再动手。4.2 系统资源占用与体验优化整套系统跑起来以后资源大户其实不是 Dify而是 Ollama 加载的大模型。Ollama 有个特性模型首次被调用时加载进内存之后的请求都会复用这个常驻进程这保证了响应速度但也意味着内存占用不会自动降下来。如果你内存紧张可以在 Ollama 的启动参数里设置OLLAMA_MAX_LOADED_MODELS1和OLLAMA_KEEP_ALIVE0后者表示每次请求完自动释放模型缺点是下一次调用要重新加载速度会慢一些。为了提升日常使用体验我有两个小技巧强烈推荐。第一个是文档预处理扫描版的 PDF 直接丢给知识库检索效果通常很差最好先用 OCR 工具转成文字再上传。第二个是提问话术不要把知识库当成搜索引擎输入几个关键词尽量用自然、完整的句子描述你要找的内容检索的命中率会明显提升。这个特性跟 Dify 的混合检索结合以后效果尤其明显。4.3 离线方案的边界与后续扩展最后聊聊这套方案的边界。DeepSeek 蒸馏版模型在通用知识问答上表现出色但在处理高度专业、行话密集的领域文档时仍然需要知识库本身的质量足够好。如果你的文档本身信息密度低、表述模糊再强的模型也救不回来。用好这套系统最核心的工作其实是“喂什么文档”而不是“用什么模型”。Dify 的扩展能力也为后续升级留足了空间。等你跑熟了这套离线链路可以考虑试试它的工作流编排把知识库问答、联网搜索、条件分支组合成更复杂的自动化流程或者接入更多本地模型针对不同任务分配合适的模型这些都是水到渠成的事。我在实际部署中还有一个体会这套方案之所以让我觉得“稳”是因为每一个组件都足够专注——Ollama 管模型Dify 管应用DeepSeek 管能力输出职责分明出问题的时候能很快定位。你如果也想搞一套离线知识库我建议不要一上来就折腾各种自定义插件和高级编排先把基础链路跑通让一个简单问答真正运转起来再一步一步往上加功能。这样搭出来的系统以后维护起来会轻松得多。本文还有配套的精品资源点击获取