简介这份PDF文档面向希望零基础完成大模型与AI知识库本地部署的开发者和AI爱好者围绕DeepSeek与Dify的组合方案解决私有化知识库搭建门槛高、流程繁琐的问题。资源包共1个PDF文件大小约1.47MB内容以图文步骤形式呈现涵盖系统环境变量设置、Ollama软件下载安装、DeepSeek-R1与bge-m3模型的拉取、Docker安装与镜像配置以及Dify开源平台的下载、配置与运行全流程。读者可据此在Windows 11环境下逐步完成从环境准备到知识库创建、聊天助手配置的完整操作获得一套可复用的本地部署思路与排错参考。目前已有2337人学习下载适合需要快速上手私有化AI知识库的中初级用户参考。1. 为什么我宁愿在 Windows 11 上折腾 DeepSeekDify也不把文档丢进在线知识库去年底我把一批内部技术文档传到某在线知识库结果一次误操作把整个索引重建了原始分段全乱。从那以后我开始认真考虑本地部署知识库这件事。DeepSeekDify 这套组合的核心思路是用 Ollama 在本地跑 DeepSeek-R1 推理模型和 bge-m3 向量模型用 Docker 拉起 Dify 应用平台最终在浏览器里得到一个完全离线的 RAG 知识库。整个过程不需要写一行代码但涉及环境变量、模型拉取、容器编排、API 地址映射四个环节任何一个环节的配置偏差都会导致后面“模型连不上”或“知识库检索为空”。这篇笔记面向的是手上有 Windows 11 机器、想把内部文档做成可问答知识库的从业者也适合刚接触本地大模型部署、想找一个完整可复现路径的新手。下面按实际操作的顺序拆开讲每一步都标注了我踩过的坑和参数含义。2. 环境变量与 Ollama 安装模型存哪里、怎么拉2.1 先设 OLLAMA_MODELS别等 C 盘爆了再后悔Ollama 默认把模型文件放在 C 盘用户目录下DeepSeek-R1 的 8B 版本量化后大约 4.9GBbge-m3 大约 1.2GB加上后续可能拉取的其他模型C 盘空间会迅速吃紧。所以第一步不是装软件而是改模型存储路径。操作路径右击“我的电脑”→“属性”→“高级系统设置”→“环境变量”→ 在“用户变量”或“系统变量”区域新建。变量名变量值示例说明OLLAMA_MODELSE:\Ai\Ollama3模型文件的落盘目录需提前建好文件夹设置完成后必须重启系统否则 Ollama 安装后仍会读取默认路径。这个坑我踩过先装 Ollama 再设环境变量结果模型已经下到 C 盘只能手动迁移。常见做法是先把环境变量配好、重启一次再进入安装环节。2.2 Ollama 安装与 DeepSeek-R1 模型拉取从 Ollama 官网下载OllamaSetup.exe双击后点击 Install安装程序会自动完成。安装完成后 Ollama 会常驻系统托盘提供http://localhost:11434的本地 API 服务。接下来拉取推理模型。打开https://ollama.com/search搜索deepseek-r1根据机器配置选版本。8B 版本对显存要求相对友好量化后约 4.9GB16GB 内存的机器可以跑如果机器配置更高可以考虑 14B 或 32B但响应速度会明显下降。# 按 WinR 输入 cmd 打开命令行粘贴以下命令拉取 DeepSeek-R1 8B ollama run deepseek-r1:8b # 拉取完成后会进入交互对话界面输入任意问题测试 # 测试没问题后按 CtrlC 退出对话再按 CtrlD 退出模型ollama run的逻辑是先检查本地是否已有该模型没有则从 registry 拉取拉取完成后直接加载并进入交互模式。这里有个细节CtrlC是中断当前生成CtrlD才是退出模型加载。如果只按CtrlC就以为退出了模型仍占用内存。2.3 拉取 bge-m3 向量模型并验证知识库的检索质量取决于 embedding 模型。Dify 的知识库流程需要把文档分段后转成向量bge-m3 支持多语言且对中文友好是本地部署场景下比较稳妥的选择。# 拉取 bge-m3 向量模型 ollama pull bge-m3 # 查看本地已下载的模型列表确认两个模型都在 ollama listollama pull只下载不加载适合提前把模型准备好。ollama list的输出包含模型名称、ID、大小和修改时间后面在 Dify 里配置模型时需要用到模型名称这一列。如果ollama list里看不到 deepseek-r1:8b 或 bge-m3说明拉取没成功需要检查网络或磁盘空间。注意Ollama 的服务端口默认是 11434如果这个端口被其他程序占用Ollama 启动时会报错。可以用netstat -ano | findstr 11434检查端口占用情况。3. Docker Desktop 安装与镜像配置容器跑起来的前置条件3.1 安装 Docker Desktop 并改镜像存储位置Dify 的社区版通过 Docker Compose 编排多个容器API、Worker、Web、PostgreSQL、Redis、Weaviate 等所以 Docker 是必装项。从 Docker 官网下载Docker Desktop Installer.exe双击后自动安装。安装完成后打开 Docker Desktop进入 Settings → Resources → Advanced把 Disk image location 改到非系统盘比如D:\Docker\DockerDesktopWSL。这个设置决定了所有容器镜像和卷的存储位置不改的话 C 盘会被迅速占满。3.2 配置 registry-mirrors 加速镜像拉取Docker Hub 的镜像拉取在国内网络环境下经常超时。在 Docker Desktop 的 Settings → Docker Engine 里用以下配置覆盖原有内容{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, experimental: false, registry-mirrors: [https://hub.rat.dev] }registry-mirrors指定镜像加速地址defaultKeepStorage控制构建缓存上限20GB 对 Dify 的镜像依赖来说够用。配置完成后点击 Apply restartDocker 会重启生效。这里有个常见翻车点如果 JSON 格式写错比如多了一个逗号Docker 会启动失败并弹窗报错需要检查括号和引号是否匹配。提示如果docker compose up -d拉取镜像时仍然很慢可以先把 Docker Desktop 退出确认配置已保存后再重新打开让镜像加速配置完全生效。4. Dify 源码包配置与容器编排从 .env 到 docker compose up4.1 下载 Dify 并配置 .env 文件从https://github.com/langgenius/dify/archive/refs/heads/main.zip下载源码包解压到 D 盘或 E 盘文件夹命名为dify。进入dify/docker目录找到.env.example文件复制一份并重命名为.env。这个文件是 Docker Compose 的环境变量来源Dify 的所有服务都从这里读取配置。用记事本打开.env拉到文件末尾追加以下内容# 启用自定义模型 CUSTOM_MODEL_ENABLEDtrue # 指定 Ollama 的 API 地址根据部署环境调整 IP OLLAMA_API_BASE_URLhost.docker.internal:11434CUSTOM_MODEL_ENABLEDtrue是让 Dify 允许接入自定义模型供应商不加这一行在模型供应商列表里看不到 Ollama 选项。OLLAMA_API_BASE_URL是关键参数Dify 跑在 Docker 容器里Ollama 跑在宿主机上容器内的localhost指向容器自身而不是宿主机所以必须用host.docker.internal这个特殊域名来访问宿主机的服务。如果这里填了127.0.0.1Dify 会报连接拒绝。4.2 启动容器并验证服务状态在dify/docker目录下右击空白处选择“在终端中打开”执行# 后台启动所有 Dify 依赖服务 docker compose up -d # 查看容器运行状态确认所有服务都是 Up 状态 docker compose psdocker compose up -d会依次拉取 PostgreSQL、Redis、Weaviate、Dify API、Worker、Web 等镜像并启动容器。首次执行需要下载大量镜像时间取决于网络速度。docker compose ps的输出中如果某个容器显示Exit或Restarting说明该服务启动失败需要用docker compose logs 服务名查看日志。常见问题是 PostgreSQL 容器启动失败多数是因为端口 5432 被宿主机上已有的 PostgreSQL 占用。解决办法是修改.env里的EXPOSE_POSTGRES_PORT或直接停掉宿主机的 PostgreSQL 服务。注意Dify 的 Web 服务默认映射到宿主机的 80 端口。如果 80 端口被 IIS 或其他 Web 服务占用需要在.env里修改EXPOSE_NGINX_PORT为其他端口比如 8080。5. Dify 初始化与模型接入从管理员账号到知识库问答5.1 初始化管理员账号并登录容器全部启动后打开浏览器访问http://127.0.0.1/install。如果能看到 Dify 的初始化页面说明容器编排成功。设置管理员邮箱和密码后登录进入 Dify 主界面。如果页面打不开先检查docker compose ps里 Web 容器是否正常运行再确认 80 端口是否被占用。另一个常见情况是浏览器缓存了旧的重定向换一个无痕窗口访问通常能解决。5.2 在 Dify 中接入 Ollama 的 LLM 和 Embedding 模型登录后点击右上角账号 → 设置 → 模型供应商找到 Ollama点击“添加模型”。这里需要填三个关键参数参数填写内容说明模型名称deepseek-r1:8b必须与ollama list输出的名称完全一致基础 URLhttp://host.docker.internal:11434容器内访问宿主机的 Ollama 服务模型类型LLM对话推理模型选 LLM保存后再添加一个模型模型类型选 Text Embedding模型名称填bge-m3基础 URL 同上。两个模型都添加成功后在模型供应商列表里能看到 Ollama 下面有两条记录。这里最容易翻车的地方是模型名称写错。ollama list输出的名称是deepseek-r1:8b如果写成deepseek-r1或deepseek-r1-8bDify 会报模型不存在。另一个坑是基础 URL 用了localhost或127.0.0.1容器内无法回连宿主机必须用host.docker.internal。5.3 创建知识库并接入聊天助手回到 Dify 主界面先创建聊天助手应用点击“聊天助手”→“创建空白应用”→ 填写应用名称 → 创建。然后创建知识库点击“知识库”→“创建知识库”→ 选择数据源“导入已有文本”→ 上传文本文件 → 下一步。分段设置选“通用”索引方式选“高质量”检索设置选“向量检索”点击“保存并处理”。Dify 会调用 bge-m3 把文档分段转成向量存入 Weaviate。处理完成后回到聊天助手应用在上下文里点击“添加”选择刚才创建的知识库。此时就可以在聊天助手的对话框里提问了。如果回答内容引用了知识库里的文档片段说明 RAG 流程已经跑通。如果回答与文档无关检查知识库是否处理完成、上下文是否添加成功、检索设置是否为向量检索。6. 避坑与排查模型连不上、知识库检索为空、容器反复重启6.1 Ollama 模型在 Dify 里显示连接失败现象在 Dify 模型供应商里添加 Ollama 模型后点击保存报“credentials validation failed”或连接超时。原因Dify 容器内无法通过localhost访问宿主机的 Ollama 服务或者 Ollama 没有监听在0.0.0.0。解决确认.env里OLLAMA_API_BASE_URLhost.docker.internal:11434并且在 Dify 模型配置的基础 URL 里也填这个地址。如果仍然不通在宿主机命令行执行ollama serve确认服务在运行然后用curl http://localhost:11434/api/tags测试 Ollama API 是否可达。6.2 知识库上传文档后检索不到内容现象文档上传并显示“处理完成”但聊天助手回答时完全不引用知识库内容。原因索引方式选了“经济”而不是“高质量”或者 embedding 模型没有正确配置。解决删除知识库重新创建索引方式必须选“高质量”检索设置选“向量检索”。确认 Dify 模型供应商里 Text Embedding 类型的 bge-m3 已添加且状态正常。如果 bge-m3 模型没拉取成功ollama list里看不到它Dify 处理文档时会静默失败。6.3 docker compose up -d 后部分容器反复重启现象docker compose ps显示某个容器状态为 RestartingWeb 页面无法访问。原因端口冲突或环境变量缺失。最常见的是 5432PostgreSQL或 6379Redis被宿主机已有服务占用。解决用docker compose logs 服务名查看具体报错。如果是端口冲突修改.env里对应的EXPOSE_*_PORT变量然后docker compose down再docker compose up -d。如果是环境变量缺失检查.env文件是否从.env.example正确复制以及追加的内容是否在文件末尾且没有语法错误。6.4 模型拉取到一半中断ollama list 里显示不完整现象ollama pull过程中网络中断重新拉取时提示模型已存在但实际不可用。原因Ollama 的模型文件是分片下载的中断后可能留下不完整的分片。解决执行ollama rm deepseek-r1:8b删除不完整的模型再重新ollama pull。如果磁盘空间不足也会导致拉取中断检查 OLLAMA_MODELS 指向的磁盘剩余空间。6.5 Dify 页面能打开但登录后一直转圈现象http://127.0.0.1/install能打开设置管理员账号后登录页面卡在加载状态。原因Dify 的 API 容器和 Web 容器之间的网络通信异常或者数据库迁移未完成。解决查看docker compose logs api和docker compose logs worker确认没有数据库连接错误。首次启动时 API 容器需要执行数据库迁移如果迁移失败会一直重试。等待几分钟后刷新页面如果仍然不行docker compose down后重新docker compose up -d让迁移重新执行。7. 进阶技巧用 ollama list 和 docker compose logs 做日常巡检跑通整套流程之后日常维护其实就两件事确认模型在、确认容器在。我养成了一个习惯每次重启机器后先跑一遍下面这组命令三十秒内就能判断整套环境是否健康。# 检查 Ollama 模型列表确认 deepseek-r1:8b 和 bge-m3 都在 ollama list # 检查 Dify 容器状态确认所有服务都是 Up cd /d E:\dify\docker docker compose ps # 如果某个容器状态异常查看最近 50 行日志 docker compose logs --tail50 apiollama list的输出里重点看两列NAME 和 SIZE。如果 SIZE 显示为 0 或异常小说明模型文件损坏需要ollama rm后重新拉取。docker compose ps的输出里重点看 STATUS 列Up后面跟的时间表示容器已运行时长如果某个容器频繁重启这个时间会一直很小。还有一个容易被忽略的点Dify 的知识库索引存在 Weaviate 容器里如果 Weaviate 容器被删除知识库的向量数据会丢失。所以docker compose down时不要加-v参数-v会删除数据卷。我一般只在升级 Dify 版本时才动容器平时不轻易执行down。另外如果后续想换更大的 DeepSeek 模型比如从 8B 换到 14B只需要ollama pull deepseek-r1:14b然后在 Dify 模型供应商里把 LLM 的模型名称改成deepseek-r1:14b即可不需要重新配置知识库。Embedding 模型不建议频繁更换因为换 embedding 模型意味着所有文档的向量需要重新计算知识库要重建。从那以后我每次重启开发机都强制走一遍ollama listdocker compose ps这套巡检确认模型和容器都在线再开始干活。希望帮到你。本文还有配套的精品资源点击获取 Windows 11 本地部署 DeepSeek+Dify 离线 RAG 知识库实战
简介这份PDF文档面向希望零基础完成大模型与AI知识库本地部署的开发者和AI爱好者围绕DeepSeek与Dify的组合方案解决私有化知识库搭建门槛高、流程繁琐的问题。资源包共1个PDF文件大小约1.47MB内容以图文步骤形式呈现涵盖系统环境变量设置、Ollama软件下载安装、DeepSeek-R1与bge-m3模型的拉取、Docker安装与镜像配置以及Dify开源平台的下载、配置与运行全流程。读者可据此在Windows 11环境下逐步完成从环境准备到知识库创建、聊天助手配置的完整操作获得一套可复用的本地部署思路与排错参考。目前已有2337人学习下载适合需要快速上手私有化AI知识库的中初级用户参考。1. 为什么我宁愿在 Windows 11 上折腾 DeepSeekDify也不把文档丢进在线知识库去年底我把一批内部技术文档传到某在线知识库结果一次误操作把整个索引重建了原始分段全乱。从那以后我开始认真考虑本地部署知识库这件事。DeepSeekDify 这套组合的核心思路是用 Ollama 在本地跑 DeepSeek-R1 推理模型和 bge-m3 向量模型用 Docker 拉起 Dify 应用平台最终在浏览器里得到一个完全离线的 RAG 知识库。整个过程不需要写一行代码但涉及环境变量、模型拉取、容器编排、API 地址映射四个环节任何一个环节的配置偏差都会导致后面“模型连不上”或“知识库检索为空”。这篇笔记面向的是手上有 Windows 11 机器、想把内部文档做成可问答知识库的从业者也适合刚接触本地大模型部署、想找一个完整可复现路径的新手。下面按实际操作的顺序拆开讲每一步都标注了我踩过的坑和参数含义。2. 环境变量与 Ollama 安装模型存哪里、怎么拉2.1 先设 OLLAMA_MODELS别等 C 盘爆了再后悔Ollama 默认把模型文件放在 C 盘用户目录下DeepSeek-R1 的 8B 版本量化后大约 4.9GBbge-m3 大约 1.2GB加上后续可能拉取的其他模型C 盘空间会迅速吃紧。所以第一步不是装软件而是改模型存储路径。操作路径右击“我的电脑”→“属性”→“高级系统设置”→“环境变量”→ 在“用户变量”或“系统变量”区域新建。变量名变量值示例说明OLLAMA_MODELSE:\Ai\Ollama3模型文件的落盘目录需提前建好文件夹设置完成后必须重启系统否则 Ollama 安装后仍会读取默认路径。这个坑我踩过先装 Ollama 再设环境变量结果模型已经下到 C 盘只能手动迁移。常见做法是先把环境变量配好、重启一次再进入安装环节。2.2 Ollama 安装与 DeepSeek-R1 模型拉取从 Ollama 官网下载OllamaSetup.exe双击后点击 Install安装程序会自动完成。安装完成后 Ollama 会常驻系统托盘提供http://localhost:11434的本地 API 服务。接下来拉取推理模型。打开https://ollama.com/search搜索deepseek-r1根据机器配置选版本。8B 版本对显存要求相对友好量化后约 4.9GB16GB 内存的机器可以跑如果机器配置更高可以考虑 14B 或 32B但响应速度会明显下降。# 按 WinR 输入 cmd 打开命令行粘贴以下命令拉取 DeepSeek-R1 8B ollama run deepseek-r1:8b # 拉取完成后会进入交互对话界面输入任意问题测试 # 测试没问题后按 CtrlC 退出对话再按 CtrlD 退出模型ollama run的逻辑是先检查本地是否已有该模型没有则从 registry 拉取拉取完成后直接加载并进入交互模式。这里有个细节CtrlC是中断当前生成CtrlD才是退出模型加载。如果只按CtrlC就以为退出了模型仍占用内存。2.3 拉取 bge-m3 向量模型并验证知识库的检索质量取决于 embedding 模型。Dify 的知识库流程需要把文档分段后转成向量bge-m3 支持多语言且对中文友好是本地部署场景下比较稳妥的选择。# 拉取 bge-m3 向量模型 ollama pull bge-m3 # 查看本地已下载的模型列表确认两个模型都在 ollama listollama pull只下载不加载适合提前把模型准备好。ollama list的输出包含模型名称、ID、大小和修改时间后面在 Dify 里配置模型时需要用到模型名称这一列。如果ollama list里看不到 deepseek-r1:8b 或 bge-m3说明拉取没成功需要检查网络或磁盘空间。注意Ollama 的服务端口默认是 11434如果这个端口被其他程序占用Ollama 启动时会报错。可以用netstat -ano | findstr 11434检查端口占用情况。3. Docker Desktop 安装与镜像配置容器跑起来的前置条件3.1 安装 Docker Desktop 并改镜像存储位置Dify 的社区版通过 Docker Compose 编排多个容器API、Worker、Web、PostgreSQL、Redis、Weaviate 等所以 Docker 是必装项。从 Docker 官网下载Docker Desktop Installer.exe双击后自动安装。安装完成后打开 Docker Desktop进入 Settings → Resources → Advanced把 Disk image location 改到非系统盘比如D:\Docker\DockerDesktopWSL。这个设置决定了所有容器镜像和卷的存储位置不改的话 C 盘会被迅速占满。3.2 配置 registry-mirrors 加速镜像拉取Docker Hub 的镜像拉取在国内网络环境下经常超时。在 Docker Desktop 的 Settings → Docker Engine 里用以下配置覆盖原有内容{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, experimental: false, registry-mirrors: [https://hub.rat.dev] }registry-mirrors指定镜像加速地址defaultKeepStorage控制构建缓存上限20GB 对 Dify 的镜像依赖来说够用。配置完成后点击 Apply restartDocker 会重启生效。这里有个常见翻车点如果 JSON 格式写错比如多了一个逗号Docker 会启动失败并弹窗报错需要检查括号和引号是否匹配。提示如果docker compose up -d拉取镜像时仍然很慢可以先把 Docker Desktop 退出确认配置已保存后再重新打开让镜像加速配置完全生效。4. Dify 源码包配置与容器编排从 .env 到 docker compose up4.1 下载 Dify 并配置 .env 文件从https://github.com/langgenius/dify/archive/refs/heads/main.zip下载源码包解压到 D 盘或 E 盘文件夹命名为dify。进入dify/docker目录找到.env.example文件复制一份并重命名为.env。这个文件是 Docker Compose 的环境变量来源Dify 的所有服务都从这里读取配置。用记事本打开.env拉到文件末尾追加以下内容# 启用自定义模型 CUSTOM_MODEL_ENABLEDtrue # 指定 Ollama 的 API 地址根据部署环境调整 IP OLLAMA_API_BASE_URLhost.docker.internal:11434CUSTOM_MODEL_ENABLEDtrue是让 Dify 允许接入自定义模型供应商不加这一行在模型供应商列表里看不到 Ollama 选项。OLLAMA_API_BASE_URL是关键参数Dify 跑在 Docker 容器里Ollama 跑在宿主机上容器内的localhost指向容器自身而不是宿主机所以必须用host.docker.internal这个特殊域名来访问宿主机的服务。如果这里填了127.0.0.1Dify 会报连接拒绝。4.2 启动容器并验证服务状态在dify/docker目录下右击空白处选择“在终端中打开”执行# 后台启动所有 Dify 依赖服务 docker compose up -d # 查看容器运行状态确认所有服务都是 Up 状态 docker compose psdocker compose up -d会依次拉取 PostgreSQL、Redis、Weaviate、Dify API、Worker、Web 等镜像并启动容器。首次执行需要下载大量镜像时间取决于网络速度。docker compose ps的输出中如果某个容器显示Exit或Restarting说明该服务启动失败需要用docker compose logs 服务名查看日志。常见问题是 PostgreSQL 容器启动失败多数是因为端口 5432 被宿主机上已有的 PostgreSQL 占用。解决办法是修改.env里的EXPOSE_POSTGRES_PORT或直接停掉宿主机的 PostgreSQL 服务。注意Dify 的 Web 服务默认映射到宿主机的 80 端口。如果 80 端口被 IIS 或其他 Web 服务占用需要在.env里修改EXPOSE_NGINX_PORT为其他端口比如 8080。5. Dify 初始化与模型接入从管理员账号到知识库问答5.1 初始化管理员账号并登录容器全部启动后打开浏览器访问http://127.0.0.1/install。如果能看到 Dify 的初始化页面说明容器编排成功。设置管理员邮箱和密码后登录进入 Dify 主界面。如果页面打不开先检查docker compose ps里 Web 容器是否正常运行再确认 80 端口是否被占用。另一个常见情况是浏览器缓存了旧的重定向换一个无痕窗口访问通常能解决。5.2 在 Dify 中接入 Ollama 的 LLM 和 Embedding 模型登录后点击右上角账号 → 设置 → 模型供应商找到 Ollama点击“添加模型”。这里需要填三个关键参数参数填写内容说明模型名称deepseek-r1:8b必须与ollama list输出的名称完全一致基础 URLhttp://host.docker.internal:11434容器内访问宿主机的 Ollama 服务模型类型LLM对话推理模型选 LLM保存后再添加一个模型模型类型选 Text Embedding模型名称填bge-m3基础 URL 同上。两个模型都添加成功后在模型供应商列表里能看到 Ollama 下面有两条记录。这里最容易翻车的地方是模型名称写错。ollama list输出的名称是deepseek-r1:8b如果写成deepseek-r1或deepseek-r1-8bDify 会报模型不存在。另一个坑是基础 URL 用了localhost或127.0.0.1容器内无法回连宿主机必须用host.docker.internal。5.3 创建知识库并接入聊天助手回到 Dify 主界面先创建聊天助手应用点击“聊天助手”→“创建空白应用”→ 填写应用名称 → 创建。然后创建知识库点击“知识库”→“创建知识库”→ 选择数据源“导入已有文本”→ 上传文本文件 → 下一步。分段设置选“通用”索引方式选“高质量”检索设置选“向量检索”点击“保存并处理”。Dify 会调用 bge-m3 把文档分段转成向量存入 Weaviate。处理完成后回到聊天助手应用在上下文里点击“添加”选择刚才创建的知识库。此时就可以在聊天助手的对话框里提问了。如果回答内容引用了知识库里的文档片段说明 RAG 流程已经跑通。如果回答与文档无关检查知识库是否处理完成、上下文是否添加成功、检索设置是否为向量检索。6. 避坑与排查模型连不上、知识库检索为空、容器反复重启6.1 Ollama 模型在 Dify 里显示连接失败现象在 Dify 模型供应商里添加 Ollama 模型后点击保存报“credentials validation failed”或连接超时。原因Dify 容器内无法通过localhost访问宿主机的 Ollama 服务或者 Ollama 没有监听在0.0.0.0。解决确认.env里OLLAMA_API_BASE_URLhost.docker.internal:11434并且在 Dify 模型配置的基础 URL 里也填这个地址。如果仍然不通在宿主机命令行执行ollama serve确认服务在运行然后用curl http://localhost:11434/api/tags测试 Ollama API 是否可达。6.2 知识库上传文档后检索不到内容现象文档上传并显示“处理完成”但聊天助手回答时完全不引用知识库内容。原因索引方式选了“经济”而不是“高质量”或者 embedding 模型没有正确配置。解决删除知识库重新创建索引方式必须选“高质量”检索设置选“向量检索”。确认 Dify 模型供应商里 Text Embedding 类型的 bge-m3 已添加且状态正常。如果 bge-m3 模型没拉取成功ollama list里看不到它Dify 处理文档时会静默失败。6.3 docker compose up -d 后部分容器反复重启现象docker compose ps显示某个容器状态为 RestartingWeb 页面无法访问。原因端口冲突或环境变量缺失。最常见的是 5432PostgreSQL或 6379Redis被宿主机已有服务占用。解决用docker compose logs 服务名查看具体报错。如果是端口冲突修改.env里对应的EXPOSE_*_PORT变量然后docker compose down再docker compose up -d。如果是环境变量缺失检查.env文件是否从.env.example正确复制以及追加的内容是否在文件末尾且没有语法错误。6.4 模型拉取到一半中断ollama list 里显示不完整现象ollama pull过程中网络中断重新拉取时提示模型已存在但实际不可用。原因Ollama 的模型文件是分片下载的中断后可能留下不完整的分片。解决执行ollama rm deepseek-r1:8b删除不完整的模型再重新ollama pull。如果磁盘空间不足也会导致拉取中断检查 OLLAMA_MODELS 指向的磁盘剩余空间。6.5 Dify 页面能打开但登录后一直转圈现象http://127.0.0.1/install能打开设置管理员账号后登录页面卡在加载状态。原因Dify 的 API 容器和 Web 容器之间的网络通信异常或者数据库迁移未完成。解决查看docker compose logs api和docker compose logs worker确认没有数据库连接错误。首次启动时 API 容器需要执行数据库迁移如果迁移失败会一直重试。等待几分钟后刷新页面如果仍然不行docker compose down后重新docker compose up -d让迁移重新执行。7. 进阶技巧用 ollama list 和 docker compose logs 做日常巡检跑通整套流程之后日常维护其实就两件事确认模型在、确认容器在。我养成了一个习惯每次重启机器后先跑一遍下面这组命令三十秒内就能判断整套环境是否健康。# 检查 Ollama 模型列表确认 deepseek-r1:8b 和 bge-m3 都在 ollama list # 检查 Dify 容器状态确认所有服务都是 Up cd /d E:\dify\docker docker compose ps # 如果某个容器状态异常查看最近 50 行日志 docker compose logs --tail50 apiollama list的输出里重点看两列NAME 和 SIZE。如果 SIZE 显示为 0 或异常小说明模型文件损坏需要ollama rm后重新拉取。docker compose ps的输出里重点看 STATUS 列Up后面跟的时间表示容器已运行时长如果某个容器频繁重启这个时间会一直很小。还有一个容易被忽略的点Dify 的知识库索引存在 Weaviate 容器里如果 Weaviate 容器被删除知识库的向量数据会丢失。所以docker compose down时不要加-v参数-v会删除数据卷。我一般只在升级 Dify 版本时才动容器平时不轻易执行down。另外如果后续想换更大的 DeepSeek 模型比如从 8B 换到 14B只需要ollama pull deepseek-r1:14b然后在 Dify 模型供应商里把 LLM 的模型名称改成deepseek-r1:14b即可不需要重新配置知识库。Embedding 模型不建议频繁更换因为换 embedding 模型意味着所有文档的向量需要重新计算知识库要重建。从那以后我每次重启开发机都强制走一遍ollama listdocker compose ps这套巡检确认模型和容器都在线再开始干活。希望帮到你。本文还有配套的精品资源点击获取 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
