简介：这是一份围绕ollama、deepseek、docker与Dify四款开源工具搭建个人知识库的实操教程，适读于具备基础命令行经验、希望将本地知识库与开源大模型打通的中高级开发者和科研人员。资源包为单个doc文档，共1个文件，仅5.19MB，内容以图文步骤、命令示例、环境变量配置与截图说明为主，轻巧实用；已有3395人学习下载。教程从Ollama官网获取安装包开始，逐一覆盖安装校验、模型存放路径与系统环境变量设置、在官方模型库中选择并下载DeepSeek-R1（如1.5b参数版本）、保持命令行运行以加载模型等关键前置环节；随后进入Docker Desktop安装与Dify开源项目源码获取，通过docker-compose up -d启动服务并完成网页端账号初始化。在浏览器端，详细演示了创建知识库、设置分词方式、上传文档解析为向量库，以及建立聊天应用、接入http://host.docker.internal:11434的Ollama接口并绑定DeepSeek模型的全过程，并给出重启后重新加载模型的备用命令。文档还专门标注了命令行不可关闭、模型下载时间可能较长等易错提醒，可作为个人知识库部署的速查手册。
1. 从零部署个人知识库：Ollama 拉模型、Docker 装 Dify，一条命令链讲清楚
本地知识库这套组合拳，说白了就是让大模型跑在自己电脑上，再把文档喂给它做问答。我用 Ollama 做模型运行时、DeepSeek 做推理模型、Docker 把 Dify 编排平台装进容器，全程不依赖在线 API Key，文档和模型权重都留在本机，适合内部资料问答、论文检索、个人笔记复盘这类场景。新手不需要先啃算法理论，只要按顺序完成安装、下载、配置、接入四步，就能看到带知识引用的对话效果。这篇部署教程会把每一步的命令、参数和踩坑点都写明白，照着走一遍基本能通。
2. Ollama 安装与 DeepSeek 模型下载：把大模型跑在本机的第一步
2.1 Ollama 在整套架构中承担什么角色
很多人第一次接触这套链路，容易把 Ollama 和模型本身搞混。Ollama 不是搜索引擎，也不负责训练模型，它的核心职能是模型下载器和运行时：你执行 ollama run deepseek-r1:1.5b ，它负责从仓库拉取权重，加载进内存，对外暴露一个本地推理接口。真正做语义理解和文本生成的是 DeepSeek 模型，Ollama 只负责把这个模型伺候好。
我倾向选 Ollama 的原因有几个。第一，安装成本低，Windows 下有个安装包就能装完，命令自动注册到系统环境变量；第二，模型管理集中，权重文件放在统一目录，用命令就能随时切换不同尺寸的模型，后续想升级到 7B 或 14B 版本，改动成本很小；第三，接口足够简单，默认监听 11434 端口，Dify 只需要填一个 HTTP 地址就能对接，中间不需要写任何胶水代码。对比直接用 Python 的 transformers 库加载模型，Ollama 把依赖冲突、CUDA 版本适配这些烦心事都挡在门外，对没有专门机器学习环境的人来说友好得多。
2.2 Windows 安装与环境验证
Windows 上的安装流程比较直接。从官方网站下载 Windows 版本的安装包，双击运行后一路 Next 到底，安装程序会自动完成 Ollama 可执行文件的注册。这里有个小细节：如果系统之前装过旧版本，建议先把旧版卸载干净再装新版，否则可能遇到版本冲突。
安装完成后，按 Win+R 打开运行框，输入 cmd 回车，在命令行里执行：
ollama --version
正常输出类似 ollama version 0.x.x 的版本号即安装成功。如果提示 不是内部或外部命令 ，大概率是 PATH 环境变量没刷新，关闭命令行窗口重新打开一次。打开后还识别不到，就得手动检查安装目录是否已经被加到 PATH 中。
经验不足的话，这一步容易忽略一个验证动作，我每次都会顺手执行：
ollama list
在没有下载任何模型之前，这条命令返回空列表但不报错，说明运行时环境正常。如果连这条命令都报错，问题出在安装本身，先排查安装包和权限再往下走。
2.3 环境变量配置：模型存放位置和监听地址不能省
安装完直接用的默认配置，其实有个隐患：模型权重默认放在 C 盘用户目录下，DeepSeek 这类模型动辄几个 GB，C 盘空间紧的话很快会被占满。更关键的是第二个问题——Dify 跑在 Docker 容器里，容器内访问宿主机需要特定机制，如果 Ollama 只监听本地回环地址，容器里根本连接不到。
所以装完 Ollama 的第一件事，就是设置环境变量。右键“此电脑”进入属性，选择“高级系统设置”，在环境变量面板中新建以下两个变量：
OLLAMA_MODELS=D:\ollama\models
OLLAMA_HOST=0.0.0.0:11434
第一个变量把模型权重重定向到 D 盘，路径按自己的硬盘规划来；第二个变量让 Ollama 监听所有网络接口，而不只是默认的 127.0.0.1。这一步决定了 Docker 容器里的 Dify 能否连通模型服务，不少部署翻车案例最后追到根因，就出在这里。
保存之后，必须重新打开命令行窗口，新增的环境变量才会生效。怎么确认配置生效？拉取一次模型后，到 D:\ollama\models 目录下看是否生成文件，生成了就说明重定向成功。
2.4 拉取 DeepSeek 模型并保持运行
模型选型建议从 deepseek-r1:1.5b 开始，严格说是先跑通链路再说。1.5B 参数量的模型下载体积小，对内存要求低，普通办公电脑也能流畅跑；一上来就拉 14B 甚至更大尺寸，下载时间动辄几小时，中途网络一抖就前功尽弃。等链路通了，再根据实际硬件水平升级模型版本。
我在命令行执行：
ollama run deepseek-r1:1.5b
这条命令第一次执行时会先拉取模型权重，拉完自动进入交互式对话界面。在对话界面输入“你好，请介绍一下你自己”之类的问题，如果能得到成段的回复，说明模型已经正常加载。
这里必须强调一个关键操作：这个命令行窗口不能关。窗口一旦关闭，模型从内存释放，后面 Dify 所有调用都会失败。如果中途把窗口关了，再需要时执行同样的命令，因为权重已下载过，会直接跳过拉取阶段，快速回到交互界面，不用重新下载。
3. Docker 部署 Dify：给知识库搭建应用运行环境
3.1 Dify 为什么要跑在容器里
Dify 是一个开源的应用编排平台，提供知识库管理、模型接入、聊天应用编排这些能力，相当于给模型和用户之间加了一层好用的外壳。整个项目包含多个后端服务、API 网关和前端页面，手动一个个装依赖、配环境，在 Windows 上不是不能做，但会很折腾。Docker 的出现把这件事简化为一次命令：项目官方已经写好了容器编排配置，镜像、依赖、网络全部定义清楚，只需要拉取并启动。
目录结构上，项目源码里有个 docker 文件夹，里面的 docker-compose.yaml 定义了整套服务编排。Dify 真正跑起来需要的镜像不止一个，包括 API 服务、数据库、向量存储、Worker 等，全部由 Docker 统一调度管理。Dify 项目运行起来之后在浏览器访问网页端口，就能进入操作界面。
3.2 Docker Desktop 安装与配套检查
要在 Windows 上跑 Linux 容器，绕不开 Docker Desktop 加 WSL2 的组合。安装 Docker Desktop 本身不难，官网下载 Windows 安装包，双击安装后启动，软件会提示开启 WSL2 集成。
如果启动时提示 WSL 内核版本过旧，不能跳过，直接到命令行执行升级：
wsl --update
wsl --status
第一条是拉取最新 WSL 内核，第二条确认当前状态。升级完成后重启 Docker Desktop，右下角图标变为绿色运行态，才说明环境就绪。这里建议装完用一句话验证 Docker 是否可用——在命令行执行 docker version ，能同时输出 Client 和 Server 两段信息就正常，只有 Client 没有 Server 说明 Docker 引擎还没起来。
3.3 获取 Dify 源码并准备配置文件
Dify 项目是通过源码加容器编排的方式分发的，获取源码有两种方式。本机装了 Git 就直接克隆，没装 Git 就去官网下载 ZIP 包解压，两种方式得到的目录结构一致。
以 Git 方式为例，在空目录中执行：
git clone https://github.com/langgenius/dify.git
cd dify/docker
进入到 docker 目录后，需要先做一件必须做的事——复制环境变量模板：
cp .env.example .env
.env.example 是官方提供的模板，包含了数据库连接、密钥、服务端口等默认配置。复制成 .env 后，docker compose 才能读到完整配置。默认配置多数可以直接用，但有几项需要检查： DIFY_PORT 对应网页访问端口，如果 80 被占用就改成别的端口。
3.4 启动容器并完成网页初始化
在 docker 目录下执行启动命令：
docker compose up -d
第一次执行会从镜像仓库拉取所有依赖镜像，这个过程耗时较长，取决于网络状况和镜像体积。出现“Pulling”字样时是在拉镜像，出现“Started”或者“Running”时代表容器已经启动。等待期间可以关注一下下载进度，中途中断时重新执行同一条命令即可，已拉取的层不会重复下载，不用慌。
启动完成后验证容器状态：
docker compose ps
主要服务都处于 running 状态，再打开浏览器访问 http://127.0.0.1/signin 。首次访问会引导设置管理员邮箱和密码，这是 Dify 系统的主账号，保存好后面登录全靠它。初始化完成之后就会进入首页功能区，左侧能看到知识库、应用、模型供应商这些菜单。
4. 知识库搭建与 DeepSeek 接入：实现带知识引用的问答闭环
4.1 创建知识库：文本分段与索引方式选对是关键
在 Dify 主页找到知识库模块，点击创建知识库，上传需要检索的文档。支持的文件格式大致覆盖主流办公文档，上传后进入分段设置界面。
Dify 默认会按一定长度把文本切成多个段落，每个段落会被嵌入成向量保存。分段的参数直接影响检索效果：分段太长，一个问题可能涉及多个主题，检索时上下文混乱；分段太短，单条信息不完整，模型缺少上下文。我一般按这个表调整：
| 参数 | 默认值 | 我的建议 |
|---|---|---|
| 分段长度 | 500 token | 中文文档设 300-500 |
| 分段重叠 | 50 token | 50 到 100 |
| 索引方式 | 向量检索 | 混合检索 |
分段重叠是一个容易被忽略的参数，它的作用是让相邻段落之间保留部分重合内容，避免一个完整意思被硬生生切开。中文文档如果切成 200 token 一段，重叠值我通常会调高一些，因为中文字的信息密度比英文高，段落间上下文关联更强。
索引方式里，向量检索适合语义匹配，全文检索适合关键词精确命中，混合检索就是两者折中。做内部资料问答的场景，我建议直接选混合，效果最稳。保存后 Dify 会执行解析和入库，文档量不大时几十秒就完成。
4.2 接入 Ollama 模型供应商：网络地址的最大坑
知识库建好了，还需要把模型接进来。在 Dify 界面的设置里进入模型供应商页面，往下找 Ollama 供应商，点击添加模型。
这里唯一需要填的是 API 地址——也是最容易出错的地方。很多人直接填 http://127.0.0.1:11434 ，结果测试连接失败。原因在于 Dify 跑在容器里，容器内访问 127.0.0.1 指向的是容器自己，不是宿主机。Docker Desktop 在 Windows 下提供了 host.docker.internal 这个特殊域名，专门用于容器访问宿主机，正确填法是：
http://host.docker.internal:11434
这个地址指向的就是宿主机的 Ollama 服务。填完之后保存，界面上就会列出 Ollama 中已有的模型，选择 deepseek-r1:1.5b 即可。
4.3 创建聊天应用并绑定知识库
模型接入之后再组装聊天界面。在 Dify 中点击创建应用，选择聊天助手类型，输入应用名称进入编排界面。页面左侧显示应用配置，模型选择下拉框里就能看到刚才添加的 deepseek-r1:1.5b。
要识别知识库内容，还需要把知识库挂到上下文里。找到上下文区域的添加按钮，选择创建好的知识库，保存后多轮对话时模型就能参考文档内容回答。完成配置后，在右侧测试面板可以直接提问：先问“你是谁”测试基础对话能力，再问一个知识库文档里才有答案的问题，如果回答中引用了知识库给出的内容、而不是模型胡编的内容，链路就通了。
5. 避坑与常见问题：Ollama 加 Dify 部署中最容易翻车的五个场景
5.1 模型能对话，但 Dify 测试报连接错误
现象：命令行里 Ollama 对话正常，Dify 测试时提示 Connection error 或 ECONNREFUSED 。
原因：模型供应商填的地址是 http://127.0.0.1:11434 ，容器内部这个地址指向容器自己，而 Ollama 跑在宿主机上。另外，如果忘了设置 OLLAMA_HOST=0.0.0.0:11434 ，即使地址改成 host.docker.internal 也会被拒之门外。
解决：把地址改成 http://host.docker.internal:11434 ，并确认环境变量已生效。改完后重启一次命令行窗口再启动模型，让新的监听配置生效。
5.2 模型下载到一半就中断
现象： ollama run deepseek-r1:1.5b 拉取权重时卡在 90% 左右，过一会儿报错退出。
原因：模型权重体积大，网络不稳定导致连接中断。有些网络环境下镜像源响应慢，也会触发客户端超时。
解决：重新执行同一条命令，已下载的部分会断点续传。网络高峰时段就换个时间再做。下载前先确认 OLLAMA_MODELS 指向的磁盘剩余空间足够，放一个 4GB 的模型至少留出 10GB 空间。
5.3 回答问题完全不引用知识库内容
现象：上传文档后提问，模型回答的是通用知识，跟文档内容毫无关系。
原因：最常见的是知识库没有添加到上下文中，把应用界面里的上下文区域点开检查一遍；另一种可能是知识库命中了错误的分段，分段太长导致信息和问题不匹配。
解决：确认上下文已绑定知识库。如果绑定了也不引用，回知识库设置里看分段长度，改成 300 token 左右重新切分。测试时用文档里的完整句子提问，关键词太短容易检索到不相关段落。
5.4 Docker 启动后首页一直打不开
现象： docker compose up -d 执行完，访问 http://127.0.0.1/signin 一直转圈或提示拒绝连接。
原因：端口冲突的概率最高，系统里已有其他服务占用了 80 端口；另一种可能是某个依赖容器启动失败，比如镜像没有完整拉取下来。
解决：先看容器状态，执行 docker compose ps 检查异常容器，再用 docker compose logs 看具体报错。端口被占用就修改 .env 里的 DIFY_PORT ，改完后重新执行 docker compose up -d 让配置生效。
5.5 回答内容重复或像胡言乱语
现象：对话内容不稳定，同一问题问两次答案差异很大，偶尔出现内容重复。
原因：1.5B 模型能力确实有限，但更直接的诱因是采样参数没调——Dify 默认的温度参数偏高，模型在生成时随机性过强，知识库场景追求的是稳定准确的输出。
解决：在模型配置里把温度调低到 0.3 左右，Top P 设为 0.8，限制最大 Token 数避免超长生成。这样回答会更收敛，细节在下一章展开。
6. 验证与进阶：把参数调到能用，再确认知识库真的生效
6.1 用三组问题完成链路验证
部署完成后，建议按下面的顺序做一遍完整验证，而不是只问一两个问题就完事：
| 问题类型 | 示例 | 期望结果 |
|---|---|---|
| 基础对话 | 你是谁 | 模型正常回复 |
| 知识库事实 | 文档中提到的具体数据或结论 | 回答能对应上文档内容 |
| 多轮追问 | 接着上一个问题继续问细节 | 对话有上下文连贯性 |
我在实际验证时发现，多轮追问是最容易暴露问题的环节。只答对一次不代表链路真正通，第二、第三轮还能引用到知识库内容，才算稳定。出现第二轮回答漂移的情况，优先检查上下文配置里是否勾选了多轮对话记忆功能。
6.2 参数调整对回答质量的直接影响
知识库问答和创意写作不同，它需要的是稳定、克制、可复现的输出。Dify 模型配置界面提供了 Temperature、Top P、Max Tokens 几个常用参数，我经过几轮对比测试后给出以下参考值：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| Temperature | 0.3 | 值越低回答越稳定 |
| Top P | 0.7 | 控制候选范围 |
| Max Tokens | 最大化 | 长文档回答不被截断 |
Temperature 调低后，模型在采样时会偏好概率更高的词，幻觉现象会明显减少。结合 DeepSeek 1.5B 的实际情况，温度超过 0.6 就容易出现说话不可控的情况。调参没有绝对标准，可以从 0.3 起步，回答太平淡就稍微上调到 0.4，不要一次性跳到 0.8 以上再来回折腾。
6.3 把这个工具变成日常习惯
从这轮部署中我养成了一个习惯：每次部署知识库服务，不管用什么开源组件，都强制走一遍验证清单——环境变量是否生效、模型进程是否常驻、端口是否可从容器内访问、测试问题是否覆盖基础对话和知识引用两类。清单看起来简单，但每次都能提前拦下问题。特别是端口监听地址，看起来是个小配置，在容器化部署场景里就是最典型的卡点。
整套链路跑通之后，还可以把模型升级到 7B 版本感受一下区别：执行 ollama pull deepseek-r1:7b ，再回 Dify 里添加新模型，对话质量会有肉眼可见的提升。希望这篇部署教程帮到你，少走一段弯路。
2286
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
