企业官网建设流程全解析

简介：这份资源是 Dify 平台的 GitHub 源码 zip 包，面向希望以离线方式搭建个人知识库的开发者与 AI 应用实践者，配合 Ollama 与 DeepSeek 模型即可在本地完成模型调用、知识库检索与对话流编排，适合具备一定 Python 与容器部署基础、关注数据隐私与私有化部署的中高级用户。压缩包共约 2000 个文件，以 1605 个 Python 源码与 344 个 YAML 配置为主，辅以 32 个 Markdown 文档、9 个 HTML 邮件模板及少量 JSON、Shell、SQL、XML 文件，整体约 26.31MB，覆盖后端逻辑、服务编排、说明文档与初始化脚本等模块，目录结构完整，便于按功能定位与二次开发。目前已有 3583 人学习下载。借助该源码包，读者可对照实现模型接入、知识库管理与多轮对话流程，理解 Dify 的插件化扩展与团队协同机制，并在此基础上完成本地化改造与排错调试。

1. 断网也能跑的知识库：Dify + Ollama + DeepSeek 这套组合到底解决什么问题

很多团队第一次搭内部知识库，都是先买云 API、再传文档、跑通一个问答 Demo，然后卡在第二步：文档里有合同条款、有内部规范、有客户资料，一旦要往外发请求，安全评审直接打回。这套 Dify + Ollama + DeepSeek 的离线部署方案，解决的正是这个卡点——模型推理走本地 Ollama，编排层用 Dify 的 GitHub zip 包自托管，DeepSeek 权重落在自己机器上，整条链路不出内网。适合谁？手里有一台带独显的机器、需要把几十到几百份文档变成可问答知识库、又不想把数据交给第三方的从业者。它不是一个开箱即用的产品，而是一套需要你动手拼装的自托管栈，下面按我实际拆包的顺序讲清楚每一步怎么落地、参数怎么调、哪里会翻车。

2. 拆开 Dify 的 GitHub zip 包：目录结构、依赖与启动顺序

拿到 Dify 的 GitHub zip 包，第一件事不是急着docker compose up，而是先看清它到底给了你什么。这个包本质是一个自托管编排平台，前端、后端 API、异步任务 worker、向量库、关系库、缓存全在里面，DeepSeek 和 Ollama 是外挂进来的推理层。搞不清目录职责，后面出问题你连日志该去哪个容器看都不知道。

2.1 目录职责与关键文件

解压后典型结构如下（不同版本略有差异，以你包内实际为准）：

我一般先做三件事：确认 Docker 与 Compose 版本、把.env.example复制为.env、把docker-compose.yaml里所有对外端口过一遍，避免和本机已有服务撞端口。这一步花十分钟，能省掉后面半小时的「容器起来了但页面打不开」。

2.2 启动顺序与最小验证

启动不是一条命令完事，顺序错了会出现 api 等 db、worker 等 redis 的连锁超时。常见做法是先起基础设施，再起应用层：

# 进入 docker 目录，所有 compose 命令都在这里执行 cd dify/docker # 第一步：只起数据库、缓存、向量库这些基础依赖 docker compose up -d db redis # 等健康检查通过后再起应用层，避免 api 启动时连不上库 docker compose up -d api worker web # 查看整体状态，重点看 api 和 worker 是否反复重启 docker compose ps

逻辑说明：db是 PostgreSQL，存应用元数据和知识库配置；redis做缓存和异步任务队列；向量库（常见是 Weaviate 或 Qdrant，看你包内配置）存文档切片的向量。先起这三个，是因为 api 启动时会做数据库迁移和连接探测，库没就绪它就直接退出。参数上，-d是后台运行，排查阶段建议先不加-d跑一次api，把启动日志完整看一遍，确认迁移脚本执行成功再转后台。

验证最小可用：浏览器打开http://本机IP:端口，能进初始化管理员账号页面，说明编排层通了。此时还没接模型，问答一定失败，这是正常的，下一步才处理推理层。

提示：.env里的SECRET_KEY必须改成一个随机长字符串，别用模板默认值；数据库密码同理。离线环境不代表可以裸奔，内网横向渗透一样会打这些默认口令。

3. 把 DeepSeek 接进 Ollama：模型拉取、量化选择与显存核算

Dify 只是壳，真正回答问题的是 DeepSeek。Ollama 负责把模型权重加载成可调用的本地服务，Dify 通过 OpenAI 兼容接口去调它。这一层的核心矛盾只有一个：显存够不够，以及在这个约束下选哪个量化版本。

3.1 模型拉取与量化档位选择

Ollama 拉模型是一条命令，但选哪个 tag 决定了你能不能跑起来：

# 拉取 DeepSeek 的对话模型，具体 tag 以 Ollama 模型库实际提供的为准 ollama pull deepseek-r1:7b # 拉完后本地跑一次，确认模型能正常加载并响应 ollama run deepseek-r1:7b "用一句话说明什么是向量检索" # 查看已拉取的模型列表和体积 ollama list

逻辑说明：pull把权重下载到本地模型目录，run做一次冒烟测试，能出结果说明推理链路本身没问题。参数选择上，7B 级别在 8GB 显存上做 4bit 量化基本能跑，14B 建议 16GB 以上，32B 及以上没有 24GB 显存别硬上——不是跑不动，是上下文一长就 OOM，知识库场景恰恰上下文很长。我一般会先按显存的一半估算可用模型规模，留出余量给向量检索和系统本身。

3.2 让 Ollama 对 Dify 可见

Ollama 默认只监听127.0.0.1，而 Dify 的 api 容器在另一个网络命名空间里，直接连会失败。需要让它监听所有网卡，并确认端口可达：

# 设置 Ollama 监听地址，使其可被同网段容器访问 export OLLAMA_HOST=0.0.0.0:11434 # 以服务方式重启（具体命令取决于你的安装方式） systemctl restart ollama # 从宿主机验证接口可用，返回模型列表即成功 curl http://127.0.0.1:11434/api/tags

逻辑说明：OLLAMA_HOST决定绑定地址，改成0.0.0.0后容器才能通过宿主机 IP 访问。/api/tags是 Ollama 的模型列表接口，返回 JSON 里有你刚拉的模型名，说明服务正常。如果 Dify 容器里curl不通这个地址，八成是容器网络模式问题——docker-compose.yaml里 api 服务若用默认 bridge 网络，访问宿主机要用host.docker.internal或宿主机实际内网 IP，别写127.0.0.1，那指向容器自己。

注意：把OLLAMA_HOST开到0.0.0.0意味着同网段任何机器都能调你的模型，内网也要配合防火墙限制来源，只放行 Dify 所在网段。

4. 在 Dify 里配模型与知识库：从文档切片到检索命中

编排层和推理层都通了，剩下的是把两者接起来，并把文档变成可检索的知识。这一步的成败不在「能不能上传」，而在切片参数和检索参数配得对不对——配错了，模型再强也答非所问。

4.1 配置 Ollama 模型供应商

进入 Dify 后台，模型供应商里选 Ollama，填基础地址和模型名：

模型类型：LLM 基础 URL：http://宿主机内网IP:11434 模型名称：deepseek-r1:7b 上下文长度：按模型实际支持填，别虚标

逻辑说明：基础 URL 必须是 Dify 容器能访问到的地址，不是浏览器能访问的地址，这两者经常不是一回事。模型名称要和ollama list里完全一致，大小写、tag 都不能错。上下文长度填大了会浪费显存，填小了长文档会被截断，按模型真实上限填。配完点「测试」，能返回内容才算接通；报连接超时就去查上一节的网络问题，报模型不存在就回去核对 tag。

4.2 知识库切片与检索参数

上传文档后，Dify 会做解析、切片、向量化。关键参数就几个，但每个都影响命中率：

我一般先用默认值跑一批真实问题，看召回结果里有没有正确片段，再针对性调分段长度。中文文档尤其要注意：按字符切会把一句话拦腰截断，条件允许时优先按段落或标题切。向量化这一步也走本地模型，如果 Dify 默认的 embedding 模型需要联网下载，记得提前把 embedding 模型也拉到本地并在供应商里配好，否则上传文档时会卡在「索引中」不动。

提示：知识库建好后先拿十个你已知答案的问题做回归，命中率低于预期先调检索参数，别急着换更大的模型——多数「答不准」是检索没召回，不是模型不会答。

5. 避坑与排查：离线部署最容易翻车的五个地方

这套栈的坑集中在「网络可见性」和「资源竞争」两类，下面五条是我踩过或见别人踩过的，按现象、原因、解决写清楚。

5.1 容器起来了但页面 502

现象：docker compose ps显示容器都在跑，浏览器访问报 502 或连接被拒。原因：web 容器依赖 api，api 启动时数据库迁移失败会反复重启，web 反向代理找不到上游。解决：docker compose logs api看迁移报错，多数是.env里数据库连接串和 compose 里的服务名不一致，或 db 还没健康就起了 api。按第 2 节的顺序重起，并给 db 加健康检查依赖。

5.2 模型测试通过但问答超时

现象：供应商测试能返回，实际对话转圈很久后报超时。原因：7B 模型在 CPU 上推理，或显存不足触发内存交换，首 token 延迟极高。解决：nvidia-smi看显存占用，确认模型真的加载在 GPU 上；Ollama 日志里会写明用的是 GPU 还是 CPU。显存不够就换更小的量化档，别指望调大超时参数能救。

5.3 文档一直卡在索引中

现象：上传成功，状态永远「索引中」。原因：embedding 模型没配或需要联网下载权重，worker 拿不到模型就阻塞。解决：确认 embedding 供应商已配成本地可用模型，docker compose logs worker里能看到具体报错；离线环境提前把 embedding 权重准备好。

5.4 检索结果总是答非所问

现象：文档明明有答案，模型却编。原因：分段太长导致一个切片混了多个主题，或 Top K 太小没召回正确片段。解决：把分段长度降到 500 左右、重叠加到 80，Top K 提到 5，重新索引后再测。别忽略解析质量，扫描版 PDF 没做 OCR 的话，切出来全是乱码。

5.5 重启后知识库配置丢失

现象：机器重启，知识库还在但模型配置没了。原因：.env或卷挂载没持久化，容器重建后配置回到初始状态。解决：确认docker/volumes/正确挂载到宿主机目录，.env纳入版本管理（脱敏后），别把配置只留在容器里。

6. 进阶：用一套脚本把「起服务—验模型—测检索」串成可重复流程

单次部署成功不算本事，能重复部署、能快速定位是哪一层坏了才算。我习惯把验证拆成三段脚本，每次改配置后按顺序跑一遍，哪段红了一眼就知道问题在哪。

#!/usr/bin/env bash # 三段式自检：基础设施 -> 模型推理 -> 检索链路 set -e # 第一段：容器健康状态，任何非 running 直接退出 cd dify/docker docker compose ps --format '{{.Name}} {{.State}}' | grep -v running && exit 1 # 第二段：Ollama 模型可用性，返回内容非空才算过 resp=$(curl -s http://127.0.0.1:11434/api/generate \ -d '{"model":"deepseek-r1:7b","prompt":"ping","stream":false}') echo "$resp" | grep -q '"response"' || exit 2 # 第三段：从容器内部访问 Ollama，验证跨网络可达 docker compose exec -T api curl -s http://宿主机内网IP:11434/api/tags \ | grep -q 'deepseek' || exit 3 echo "all checks passed"

逻辑说明：第一段用grep -v running反向筛选，有任何容器不在 running 状态就失败，退出码 1 表示编排层问题。第二段直接打 Ollama 的生成接口，stream:false让它一次性返回，便于脚本判断，退出码 2 表示推理层问题。第三段最关键，从 api 容器内部去访问 Ollama，验证的是容器网络视角下的可达性——这一步过了，Dify 里配模型基本不会失败，退出码 3 表示网络配置问题。三段退出码分开，排错时不用猜。

参数上，-T关掉伪终端分配，脚本里必须加，否则exec在某些环境会报错。宿主机 IP 建议写成变量从环境读取，别硬编码，换机器时只改一处。

还有一个容易被忽略的验证点：知识库检索质量要单独测，不能只看对话能不能出字。我的习惯是准备一份「问题—标准答案片段」的小清单，每次调完切片参数就跑一遍，看 Top K 里有没有标准片段。这个清单不用长，十个问题足够暴露分段长度和阈值的问题。从那以后我每次改完切片或换模型，都强制走一遍这三段脚本加检索回归，再动线上知识库——省下的不是时间，是「明明改了配置却说不清哪里变差」的糊涂账。希望帮到你。

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