简介：这份PDF资料面向希望在本地搭建AI知识库的开发者与AI应用爱好者，围绕DeepSeek大模型与Dify开源平台，提供一套无需深厚技术背景即可上手的本地部署方案，覆盖从环境变量配置、Ollama与Docker安装，到大模型拉取、Dify配置运行的完整链路。资源包共1个PDF文件，大小约1.47MB，内容以图文步骤形式呈现，便于对照操作与快速检索。目前已有2344人学习下载，说明该方案在本地化AI知识库场景中具有较高关注度。读者可从中获得系统环境变量设置、deepseek-r1与bge-m3模型拉取、Docker镜像配置、Dify应用创建及知识库接入等关键环节的实操指引，适合想低成本构建私有知识库、减少云端依赖的技术人员参考。
1. 从零搭一套本地知识库：DeepSeek 加 Dify 到底能解决什么
很多人第一次听到“本地部署知识库”，脑子里浮现的是机房、显卡阵列和一堆看不懂的配置文件。实际情况是，一台装了 Windows 11 的普通开发机，配合 Ollama、Docker 和 Dify 这三样东西，就能把 DeepSeek 大模型和私有文档检索跑起来。这套方案的核心价值在于：你的文档不出本机，模型推理也在本机完成，适合那些对数据流向敏感、又不想从零写 RAG 管线的团队。
我拆这套组合的逻辑很简单。Ollama 负责把 DeepSeek-R1 和 bge-m3 这两个模型拉下来并暴露成 API，Docker 负责把 Dify 的一堆依赖服务打包运行，Dify 则提供知识库创建、分段索引、向量检索和对话应用的完整界面。三者各管一段，拼起来就是一条从文档上传到问答输出的闭环。适合谁？手里有大量内部文档、想快速验证 RAG 效果、又不想把数据传到外部接口的开发者。下面按实际落地顺序拆开讲。
2. 环境变量与 Ollama 安装：模型存哪、怎么拉
2.1 先定模型存储路径，别等 C 盘爆了再后悔
Ollama 默认把模型下载到系统盘的用户目录下。DeepSeek-R1 的 8B 版本量化后大约 5GB 上下，bge-m3 也要 1GB 多，再加上后续可能拉的其他模型，C 盘空间会被迅速吃掉。所以第一步不是装软件，而是先把OLLAMA_MODELS这个环境变量设好。
操作路径是：右击“我的电脑”→“属性”→“高级系统设置”→“环境变量”。在“系统变量”区域点“新建”，变量名填OLLAMA_MODELS，变量值填一个你规划好的目录，比如E:\Ai\Ollama3。这个目录要提前建好，不要指望软件帮你创建。设完之后重启系统，让环境变量生效。
提示：环境变量分“用户变量”和“系统变量”两块。如果你只在自己账户下用，设用户变量也行；但如果 Docker 里的服务也要读这个路径，建议设系统变量，避免权限和可见性问题。
重启之后可以验证一下。打开命令行输入echo %OLLAMA_MODELS%，如果回显的是你设的路径，说明生效了。这一步看着简单，但后面模型拉取失败、找不到模型文件的情况，十有八九是这里没配对。
2.2 Ollama 安装与 DeepSeek-R1 拉取
Ollama 的安装没什么可说的，官网下载OllamaSetup.exe，双击、点 Install、等它自动完成。安装完之后它会在后台起一个服务，监听 11434 端口，这个端口后面 Dify 要连。
拉模型之前先确认版本。打开命令行输入ollama -v，能看到版本号就说明安装成功。然后去 Ollama 的模型库页面搜deepseek-r1，根据自己机器的内存和显存选型号。8B 版本对硬件要求相对友好，16GB 内存的机器能跑起来；如果配置更高，可以选 14B 或 32B，但推理速度会明显下降。
选好之后复制对应的命令，在命令行里执行：
ollama run deepseek-r1:8b这条命令做两件事：先从远端拉取模型文件，然后直接进入交互模式。拉取时间取决于网络和磁盘速度，8B 模型大概几个 GB，耐心等进度条走完。进入交互界面后随便问一句，比如“你好，介绍一下你自己”，能正常回复就说明模型跑通了。退出交互按Ctrl+C，再按Ctrl+D。
接着拉 embedding 模型。知识库的向量检索需要把文档切块后转成向量，这个活由 embedding 模型干。bge-m3 是常用的多语言 embedding 模型，拉取命令是：
ollama pull bge-m3注意这里用的是pull而不是run，因为 embedding 模型不需要交互对话，拉下来备用就行。两个模型都拉完之后，用ollama list检查：
ollama list输出里应该能看到deepseek-r1:8b和bge-m3两行，以及它们的大小和修改时间。如果只有一行或者报错，回到上一步检查环境变量和网络。确认无误后关掉命令行窗口，Ollama 的服务会继续在后台运行。
3. Docker 配置与 Dify 拉取：镜像加速和 .env 改动
3.1 Docker Desktop 安装与镜像源配置
Dify 依赖多个服务——API 服务、Worker、PostgreSQL、Redis、Weaviate 等，手动一个个装不现实，用 Docker Compose 一把拉起是最省事的做法。去 Docker 官网下载 Docker Desktop for Windows，双击安装包，一路默认选项走完。安装完成后启动 Docker Desktop，第一次启动会提示你接受服务条款，接受即可。
接下来改两个配置。第一个是镜像存储位置。Docker 默认把镜像存在 C 盘，Dify 那一套镜像加起来好几个 GB，C 盘紧张的话最好挪走。路径是 Settings → Resources → Advanced → Disk image location，改成你规划好的目录，比如D:\Docker\DockerDesktopWSL。
第二个是镜像加速地址。在 Settings → Docker Engine 里，把配置改成下面这样：
{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "registry-mirrors": ["https://hub.rat.dev"] }defaultKeepStorage控制构建缓存的上限，20GB 是个折中值，太小会导致频繁清理缓存拖慢构建，太大占磁盘。registry-mirrors指定镜像拉取的加速地址，国内直连 Docker Hub 经常超时，配一个可用的镜像源能省很多等待时间。改完点 Apply & Restart，Docker 会重启生效。
注意：镜像源地址不是一成不变的，不同时间段可用的源可能不同。如果拉取时提示连接失败，先换一个源试试，不要死磕一个地址。
3.2 Dify 源码下载与 .env 关键改动
Dify 的源码包从 GitHub 下载 zip 就行，解压到 D 盘或 E 盘，文件夹命名为dify。进入dify/docker目录，找到.env.example文件，把它复制一份改名为.env。这个.env是 Docker Compose 读取的环境变量文件，所有服务配置都从这里来。
用记事本打开.env，拉到文件末尾，追加两行：
# 启用自定义模型 CUSTOM_MODEL_ENABLED=true # 指定 Ollama 的 API 地址 OLLAMA_API_BASE_URL=host.docker.internal:11434第一行CUSTOM_MODEL_ENABLED=true是让 Dify 允许接入自定义模型供应商，不设的话模型列表里可能看不到 Ollama 选项。第二行是关键：Dify 跑在 Docker 容器里，Ollama 跑在宿主机上，容器内访问宿主机需要用host.docker.internal这个特殊域名，端口 11434 是 Ollama 的默认监听端口。如果你改过 Ollama 的端口，这里要同步改。
保存关闭后，在docker文件夹空白处右击，“在终端中打开”，会弹出 PowerShell 窗口。执行：
docker compose up -d-d表示后台运行。这条命令会拉取所有依赖镜像并启动容器，第一次执行时间比较长，取决于镜像源速度和网络状况。执行过程中如果某个镜像拉取失败，终端会报错并停止，这时候检查镜像源配置，或者单独docker pull那个镜像再重试。
全部拉取完成后，用docker compose ps看一下容器状态，所有服务都显示running或healthy才算正常。如果有容器反复重启，用docker compose logs <服务名>看日志定位问题。
4. Dify 初始化与知识库创建：模型接入和检索配置
4.1 管理员账户设置与 Ollama 模型接入
容器全部起来之后，浏览器打开http://127.0.0.1/install，能看到 Dify 的初始化页面就说明服务正常。设置管理员邮箱和密码，登录进去。
接下来接模型。点右上角账户 → 设置 → 模型供应商，找到 Ollama，点“添加模型”。这里要填几个东西：模型名称、基础 URL、模型类型。模型名称必须和ollama list里显示的完全一致，比如deepseek-r1:8b，大小写和冒号都不能错。基础 URL 填http://host.docker.internal:11434，模型类型选 LLM。其他参数保持默认，点保存。
然后再添加一次，这次模型类型选 Text Embedding，模型名称填bge-m3。两个模型都添加成功后，在模型供应商列表里能看到 Ollama 下面挂着两个模型。
提示：如果保存时报连接错误，先确认 Ollama 服务是否在运行。可以在宿主机浏览器访问
http://127.0.0.1:11434，能看到 Ollama 的返回信息就说明服务正常。如果宿主机能访问但 Dify 里报错，多半是host.docker.internal没解析对，检查 Docker Desktop 的网络设置。
4.2 知识库创建与分段参数选择
回到 Dify 主界面，先创建一个聊天助手应用：点“聊天助手”→“创建空白应用”，填应用名称，创建。然后去“知识库”→“创建知识库”，数据源选“导入已有文本”，上传你的文档文件。Dify 支持 txt、md、pdf、docx 等格式，但 pdf 的解析质量取决于文件本身是否是可选中文本，扫描件需要先做 OCR。
上传后进入分段设置。分段模式选“通用”，索引方式选“高质量”，检索设置选“向量检索”。这三个选项的组合逻辑是：通用分段按固定字符数切块，高质量索引会调用 embedding 模型把每个块转成向量，向量检索则在问答时把用户问题也转成向量，然后找最相似的块作为上下文。
分段参数里比较关键的是 chunk size 和 overlap。chunk size 控制每块的最大字符数，太小会导致上下文不完整，太大会稀释检索精度。一般中文文档设 500 到 800 字符比较合适。overlap 是相邻块之间的重叠字符数，设 chunk size 的 10% 到 20% 能避免关键信息被切断。这些参数没有绝对最优值，跟文档类型和问答粒度有关，建议先用默认值跑一轮，看检索结果再调。
保存并处理之后，Dify 会逐个块调用 bge-m3 生成向量并存入向量库。处理时间取决于文档数量和 embedding 模型的速度。处理完成后，回到聊天助手应用，在“上下文”里添加刚才创建的知识库，然后就可以在对话框里提问了。问一个文档里明确写过的问题，看回答是否引用了正确的内容。如果回答泛泛而谈或者答非所问，回到知识库检查分段和检索设置。
5. 避坑排查：部署过程中最容易翻车的五个点
5.1 模型拉取卡住或报错
现象：执行ollama run deepseek-r1:8b后进度条长时间不动，或者直接报网络错误。
原因：Ollama 的模型仓库在境外，网络不稳定时拉取会中断。另外如果OLLAMA_MODELS指向的目录没有写入权限，也会导致下载失败。
解决：先确认环境变量指向的目录存在且有写入权限。网络问题可以多试几次，Ollama 支持断点续传，中断后重新执行同一条命令会从断点继续。如果反复失败，检查系统代理设置是否干扰了 Ollama 的连接。
5.2 Docker 镜像拉取超时
现象：docker compose up -d执行到一半卡住，终端提示pull access denied或context deadline exceeded。
原因：Docker Hub 直连不稳定，或者配置的镜像源暂时不可用。
解决：换一个镜像源地址，改完 Docker Engine 配置后 Apply & Restart。如果换了源还是不行，可以尝试在非高峰时段拉取。另外确认 Docker Desktop 已经登录（匿名拉取有速率限制），登录后配额会宽松一些。
5.3 Dify 里添加 Ollama 模型时报连接失败
现象：在 Dify 模型供应商页面填完信息点保存，提示无法连接到 Ollama 服务。
原因：最常见的是OLLAMA_API_BASE_URL写错，或者 Ollama 服务没有监听在0.0.0.0而是只监听了127.0.0.1，导致容器内访问不到。
解决：先在宿主机浏览器访问http://127.0.0.1:11434确认 Ollama 正常。然后在 Docker 容器内测试连通性：docker exec -it docker-api-1 curl http://host.docker.internal:11434。如果容器内访问不通，检查 Ollama 的启动参数，Windows 版默认监听所有接口，一般不需要额外配置。如果还是不通，把OLLAMA_API_BASE_URL改成宿主机的局域网 IP 试试。
5.4 知识库检索结果不相关
现象：文档明明写了某个内容，但提问时模型回答“没有找到相关信息”或者引用了错误的段落。
原因：分段参数不合理导致关键信息被切碎，或者 embedding 模型对某些领域文本的语义捕捉不够准。
解决：先调大 chunk size 和 overlap，让每个块包含更完整的语义单元。如果文档有明确的章节结构，可以改用自定义分段，按标题切分。另外检查检索时的 top K 设置，默认值可能偏小，适当调大能提高召回率，但也会引入更多噪声，需要权衡。
5.5 容器反复重启或服务不可用
现象：docker compose ps显示某个容器状态是restarting，或者 Dify 页面打不开。
原因：资源不足（内存或磁盘）、端口冲突、或者.env配置有误。
解决：先看日志docker compose logs <服务名>，日志里通常会写明失败原因。如果是内存不够，关掉一些不必要的容器或增加 Docker Desktop 的内存分配。端口冲突的话检查 80 端口是否被其他程序占用，Dify 默认用 80 端口，被占的话改.env里的EXPOSE_NGINX_PORT。
6. 进阶技巧：用 API 把知识库接进自己的工具链
Dify 不只是一个网页聊天界面，它每个应用都暴露了 API。在应用页面左侧点“访问 API”，能看到 API 文档和密钥。这意味着你可以把知识库问答能力嵌到自己的脚本、内部工具或者自动化流程里，不用每次都打开浏览器。
调用方式很简单，用 Python 的 requests 库就能跑通：
import requests # Dify 应用的 API 地址和密钥，从应用页面获取 API_URL = "http://127.0.0.1/v1/chat-messages" API_KEY = "your-app-api-key" headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } payload = { "inputs": {}, "query": "文档里提到的部署步骤有哪些？", "response_mode": "blocking", # blocking 表示等完整回复，streaming 是流式 "user": "user-001" # 用户标识，用于区分会话 } response = requests.post(API_URL, headers=headers, json=payload) print(response.json())response_mode选blocking时接口会等模型生成完再返回，适合脚本调用；选streaming则逐字返回，适合做打字机效果的前端。user字段用来区分不同用户的会话上下文，同一个 user 的连续提问会保留对话历史。返回的 JSON 里answer字段就是模型的回复，metadata里能看到引用了哪些知识库片段。
我一般会把这个调用封装成一个函数，加上超时和重试，然后接到内部的文档查询机器人或者自动化报告流程里。这样知识库就不只是一个孤立的网页应用，而是变成了一个可编程的能力节点。
提示：API 密钥在应用页面可以重置，如果泄露了及时换掉。另外 Dify 的 API 默认没有鉴权以外的访问控制，如果要把服务暴露到局域网之外，前面最好加一层反向代理做认证。
从那以后我每次部署完 Dify，都会先用 API 跑一轮回归测试，确认模型接入、知识库检索和回复生成三个环节都正常，再交给其他人用。这个习惯帮我省了不少“网页上能用但接口报错”的排查时间。希望帮到你。
本文还有配套的精品资源，点击获取
