企业官网建设流程全解析

简介：这份资源面向希望本地搭建个人知识库的技术爱好者与开发者，围绕 ollama、deepseek、docker 与 Dify 四件套的协同部署展开，帮助读者在 Windows 环境下完成从模型下载到知识库问答的完整链路。资源包内含 1 个 doc 文档，压缩包约 5.19MB，以图文步骤形式记录安装、环境变量配置、模型拉取、Dify 项目启动及知识库创建等关键环节，便于按图索骥对照操作。目前已有 3387 人学习，说明该方案在本地知识库搭建场景中具备一定参考价值。文档中不仅给出 ollama 安装与 deepseek-r1 模型下载的具体命令，还涉及 docker-desktop 部署 Dify、分词方式选择、聊天应用接入 ollama 接口等实操细节，并提示命令行需保持运行、模型大小影响下载时长等易踩坑点。对于熟悉容器与命令行、希望把私有文档转化为可检索问答系统的读者，可借此快速跑通流程并理解各组件分工。

1. 从一台吃灰的旧笔记本说起：ollama+deepseek+docker+Dify 到底能搭出什么

你手头可能有一台 16G 内存的旧笔记本，或者一台常年开着的迷你主机。上面跑着几个 Docker 容器，平时也就当个下载机。某天你突然想：能不能让这台机器变成一个只属于自己的知识库问答系统？文档丢进去，用自然语言问它，它从我的资料里找答案，而不是去网上瞎编。这个念头一旦冒出来，接下来要面对的就是选型问题：模型用什么、怎么跑、知识库怎么管、界面怎么来。

ollama 负责把 deepseek 模型在本地跑起来，docker 负责把 Dify 和它的依赖打包成可迁移的容器，Dify 负责把知识库、工作流和对话界面串起来。这套组合的核心价值在于：数据不出本机，模型推理不依赖外部 API，整个系统可以离线运行。适合那些对数据隐私有要求、想低成本验证 RAG 落地、或者单纯想折腾一套私有 AI 基础设施的工程师。部署教程网上很多，但真正跑通并且能稳定用的，往往卡在几个不起眼的地方。

2. 把 deepseek 塞进 ollama：模型拉取、量化选择与显存账

2.1 为什么是 ollama 而不是自己写推理服务

自己用 transformers 加载 deepseek 模型不是不行，但你要处理显存分配、量化加载、并发请求排队、模型热切换这一堆事。ollama 把这些封装成了几条命令，并且自带一个兼容 OpenAI 格式的 API 端点。对于知识库场景，你不需要训练，只需要推理，ollama 的抽象层级刚好合适。

另一个现实原因是 Dify 原生支持 ollama 作为模型供应商。你在 Dify 里填一个http://host.docker.internal:11434就能把本地模型接进去，省掉自己写适配层的功夫。常见做法是先用 ollama 把模型跑通，再在 Dify 里配置连接，这样出问题的时候能快速定位是模型层还是应用层。

2.2 拉取 deepseek 模型：命令、镜像源与离线包

ollama 默认从官方源拉取模型，国内网络环境下速度可能很慢。如果你遇到ollama下载太慢了的情况，可以配置镜像源。具体做法是设置环境变量OLLAMA_HOST和镜像地址，或者直接下载离线包手动导入。

# 拉取 deepseek-r1 的 7B 量化版本，适合 8G 显存左右的机器 ollama pull deepseek-r1:7b # 如果拉取中断，可以重复执行，ollama 支持断点续传 # 查看本地已有模型 ollama list # 运行模型进行交互测试 ollama run deepseek-r1:7b

deepseek-r1:7b是蒸馏后的量化版本，参数量小，推理速度快，适合知识库问答这种对生成质量要求不是极致高的场景。如果你的机器有 24G 显存，可以换deepseek-r1:14b或32b，但要注意 Dify 的知识库检索会额外消耗内存。参数说明：7b代表 70 亿参数，q4_K_M是默认量化级别，显存占用大约 5-6G。如果拉取时提示磁盘空间不足，检查~/.ollama/models所在分区。

提示：ollama 的模型存储路径可以通过OLLAMA_MODELS环境变量修改，建议放到空间充裕的盘符。

2.3 验证 ollama API 是否可用

模型拉下来之后，不要急着装 Dify。先用 curl 确认 API 能通，这一步能帮你排除掉后面一半的玄学问题。

# 检查 ollama 服务是否在运行 curl http://localhost:11434/api/tags # 发送一个简单的生成请求 curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "用一句话解释什么是RAG", "stream": false }'

第一个命令返回模型列表，第二个命令返回生成结果。如果第一个命令失败，说明 ollama 服务没启动，执行ollama serve或者检查系统服务。如果第二个命令超时，可能是模型加载慢，第一次调用需要把模型加载到显存，等待时间取决于磁盘速度和模型大小。stream: false表示一次性返回完整结果，方便调试；实际接入 Dify 时会用流式输出。

3. docker 部署 Dify：容器编排、端口映射与数据持久化

3.1 Dify 的 docker compose 结构拆解

Dify 官方提供了 docker compose 文件，里面包含 api、worker、web、db、redis、weaviate 等容器。api 负责后端逻辑，worker 处理异步任务比如文档索引，web 是前端界面，db 是 PostgreSQL 存元数据，redis 做缓存和队列，weaviate 是向量数据库。理解这个结构很重要，因为后面排查问题时你需要知道是哪个容器挂了。

# docker-compose.yml 关键片段，只保留核心配置 services: api: image: langgenius/dify-api:latest environment: - MODE=api - DB_HOST=db - REDIS_HOST=redis - VECTOR_STORE=weaviate ports: - "5001:5001" depends_on: - db - redis worker: image: langgenius/dify-api:latest environment: - MODE=worker depends_on: - db - redis web: image: langgenius/dify-web:latest ports: - "3000:3000" db: image: postgres:15-alpine volumes: - ./volumes/db:/var/lib/postgresql/data redis: image: redis:6-alpine volumes: - ./volumes/redis:/data weaviate: image: semitechnologies/weaviate:1.19.0 volumes: - ./volumes/weaviate:/var/lib/weaviate

MODE=api和MODE=worker让同一个镜像跑不同角色，这是 Dify 的设计。端口映射方面，web 的 3000 是你访问界面的端口，api 的 5001 是后端接口。数据持久化通过 volumes 挂载到宿主机，这样容器删了数据还在。depends_on只保证启动顺序，不保证服务就绪，所以第一次启动时 api 可能会因为 db 没准备好而重启几次，这是正常的。

3.2 启动顺序与常见启动失败

直接docker compose up -d有时候会翻车，因为容器启动速度不一样。稳妥的做法是先起基础服务，再起应用层。

# 第一步：只启动数据库和缓存 docker compose up -d db redis weaviate # 等待 10 秒左右，让数据库完成初始化 sleep 10 # 第二步：启动 api 和 worker docker compose up -d api worker # 第三步：启动前端 docker compose up -d web # 查看所有容器状态 docker compose ps

如果docker compose ps显示某个容器不断重启，用docker compose logs <服务名>看日志。常见错误是 db 容器初始化失败，日志里会出现database system is ready to accept connections之后又报错，通常是 volumes 目录权限问题。解决方法是删掉./volumes/db重新来，或者手动修改目录权限。

注意：如果你之前装过其他 PostgreSQL 占用了 5432 端口，Dify 的 db 容器会启动失败。检查docker ps有没有端口冲突。

3.3 把 ollama 接入 Dify 的模型配置

Dify 启动后，登录管理后台，在「设置」→「模型供应商」里找到 ollama。填写模型名称deepseek-r1:7b，基础 URL 填http://host.docker.internal:11434。这个地址是 docker 容器访问宿主机的特殊域名，Linux 下可能需要换成宿主机的实际 IP。

# Linux 下查看 docker 网桥地址 ip addr show docker0 | grep inet # 如果 host.docker.internal 不生效，在 docker-compose.yml 的 api 服务下加一行 extra_hosts: - "host.docker.internal:host-gateway"

加完extra_hosts后需要docker compose up -d api重建容器。配置完成后点「测试」按钮，如果返回模型列表说明连接成功。如果报dify an error occurred during credentials validation，先确认 ollama 服务在宿主机上curl http://localhost:11434/api/tags能通，再确认容器内curl http://host.docker.internal:11434/api/tags能通。两层都通但 Dify 还报错，检查模型名称是否和ollama list输出完全一致，大小写和标签都不能错。

4. 知识库流水线：文档上传、分段、向量化与检索调参

4.1 文档上传后的处理流程

在 Dify 里创建知识库，上传文档。支持 PDF、Word、Markdown、TXT 等格式。上传后 Dify 会做几件事：提取文本、按规则分段、调用 embedding 模型把每段转成向量、存入 weaviate。这个流程叫dify知识库流水线，每一步都有参数可以调。

分段是关键。分得太碎，检索时召回的内容不完整；分得太大，向量语义被稀释，检索精度下降。Dify 默认按字符数分段，一般设 500-1000 字符，重叠 50-100 字符。对于技术文档，按标题层级分段效果更好，但需要文档本身结构清晰。

4.2 embedding 模型的选择与 ollama 的配合

Dify 默认用 OpenAI 的 embedding 模型，但你要离线运行，就得换成本地的。ollama 支持nomic-embed-text等 embedding 模型。

# 拉取 embedding 模型 ollama pull nomic-embed-text # 在 Dify 模型供应商里配置 embedding 模型 # 模型名称：nomic-embed-text # 基础 URL：http://host.docker.internal:11434

配置好后，在知识库设置里选择这个 embedding 模型。注意：embedding 模型一旦选定，已经索引的文档不能直接换模型，换了之后向量维度不匹配，必须重新索引。所以建知识库之前先想好用什么 embedding 模型。

4.3 检索参数怎么调：Top K、Score 阈值与重排序

知识库建好后，在应用编排里加一个「知识检索」节点。核心参数有三个：Top K、Score 阈值、重排序模型。

Top K 设 3 表示每次检索返回最相关的 3 个片段，塞进 prompt 里让模型基于这些片段回答。Score 阈值 0.5 表示相似度低于 0.5 的片段直接丢弃。重排序模型可以用bge-reranker系列，ollama 也支持，但会额外消耗算力。如果发现模型回答时经常说「根据提供的资料无法回答」，先把 Score 阈值降到 0.3 试试，可能是过滤太狠了。

提示：dify工作流 上下文超长通常是因为 Top K 太大或者分段太长，导致塞进模型的 token 数超过模型上下文窗口。deepseek-r1:7b 的上下文是 64K，但实际使用时建议控制在 8K 以内，留出空间给系统提示和对话历史。

5. 避坑与排查：那些让部署教程翻车的细节

5.1 现象：Dify 页面能打开但模型测试报 SSL 错误

原因：Dify 的 api 容器在请求 ollama 时走了 HTTPS，但 ollama 默认是 HTTP。或者你配置的 URL 带了https://前缀。

解决：检查模型供应商配置里的基础 URL，确保是http://而不是https://。如果 Dify 强制 HTTPS，在docker-compose.yml的 api 服务环境变量里加CONSOLE_API_URL和CONSOLE_WEB_URL用 http 协议。dify ssl错误多数是协议写错导致的。

5.2 现象：文档上传后一直显示「索引中」，worker 日志报连接 weaviate 失败

原因：weaviate 容器没起来，或者 api/worker 容器里的VECTOR_STORE环境变量和实际使用的向量库不一致。

解决：docker compose ps确认 weaviate 状态，如果没起来看日志。确认docker-compose.yml里 api 和 worker 的VECTOR_STORE都设成了weaviate。如果之前用过其他向量库，volumes 里的数据可能冲突，删掉./volumes/weaviate重新初始化。

5.3 现象：ollama 拉取模型到一半卡住，进度条不动

原因：网络波动导致下载中断，或者磁盘空间不足。

解决：先df -h检查磁盘。如果空间够，Ctrl+C 中断后重新ollama pull，ollama 支持断点续传。如果反复卡在同一个位置，换镜像源或者用离线包。ollama离线安装包可以从其他机器拷贝~/.ollama/models目录过来，放到相同路径即可。

5.4 现象：Dify 对话时响应极慢，每次要等十几秒

原因：模型第一次加载到显存需要时间，或者 Top K 设太大导致检索和生成都很慢。

解决：第一次调用慢是正常的，后续会快。如果一直慢，检查ollama ps看模型是否常驻显存。如果显存不够，模型会在内存和显存之间反复交换。降低 Top K，换更小的模型，或者加显存。docker stats可以看容器资源占用，确认不是 Dify 本身在抢资源。

5.5 现象：重启电脑后 Dify 打不开，容器全部退出

原因：docker 服务没设置开机自启，或者容器没有设置 restart 策略。

解决：docker compose up -d重新启动。长期方案是在docker-compose.yml里给每个服务加restart: unless-stopped，这样 docker 服务启动后容器会自动起来。另外确认 docker desktop 或 docker daemon 本身设置了开机启动。

6. 让知识库真正好用：分段策略微调与检索效果验证

部署跑通只是第一步，真正决定这套系统好不好用的是知识库的检索质量。我自己的习惯是，每建一个知识库，先拿 10 个典型问题做一轮测试，记录哪些问题答对了、哪些答错了、哪些答非所问。然后针对性地调分段和检索参数，而不是凭感觉瞎调。

分段策略上，技术文档我一般按 Markdown 标题切，每个二级标题下的内容作为一个独立片段，如果超过 800 字符再按段落切。产品手册按章节切，每章一个片段。FAQ 类文档按问答对切，一问一答作为一个片段。这样切出来的片段语义完整，检索时命中率高。

验证检索效果有个笨办法但很管用：在 Dify 的知识库页面用「召回测试」功能，输入一个问题，看返回的片段是不是你期望的那些。如果返回的片段不相关，先别怪模型，大概率是分段或 embedding 的问题。把不相关的片段拿出来看，是不是被切碎了，或者混入了无关内容。调整分段后重新索引，再测。

还有一个容易忽略的点：deepseek 模型本身有很强的推理能力，但知识库问答场景下，你要在系统提示里明确告诉它「只根据提供的资料回答，不要编造」。我一般会写：「你是一个知识库助手，请严格基于以下资料回答问题。如果资料中没有相关信息，直接说不知道，不要尝试用你的通用知识补充。」这句话能显著降低幻觉率。

最后说一个我踩过的坑：不要一次性把所有文档都丢进去。先传一小部分，跑通流程，确认检索效果，再批量上传。批量上传时 worker 会排队处理，如果文档很多，索引时间可能很长，期间 Dify 的响应会变慢。分批上传，每批传完等索引完成再传下一批，这样出问题也容易定位是哪批文档的锅。

希望帮到你。

本文还有配套的精品资源，点击获取