企业官网建设流程全解析

简介：这套物料包围绕银河麒麟服务器V10SP1-2403环境，提供Dify与DeepSeek（本地或在线）相结合的知识库构建方案，面向需要在国产化服务器上落地大模型应用的技术人员。资源共8个文件，包含Dify 0.15.3安装包、部署所需Docker镜像压缩包、YAML编排文件，以及适配x86_64、aarch64、armv6、armv7等主流架构的docker-compose文件，整体约423MB，可满足不同硬件平台下的离线部署需求。已有1199人学习下载，具备较高的参考价值。物料内按部署阶段组织，覆盖镜像导入、编排启动、服务配置等关键环节；配合DeepSeek的本地或在线接入方式，读者可避开外网限制，在麒麟系统上完成知识库从初始化到调试验证的全流程，并掌握常见问题排查方法。这套方案尤其适合希望自主可控构建智能问答系统、又不熟悉国产化环境的工程师，能有效缩短环境搭建耗时，并沉淀多架构适配经验。

1. 银河麒麟V10SP1-2403上跑Dify+DeepSeek：这套组合解决的是知识库落地的最后一公里

银河麒麟服务器V10SP1-2403上部署Dify并接入DeepSeek，是目前信创环境里搭私有知识库最顺的一条路。Dify负责文档管理、分段、检索和应用编排，DeepSeek负责生成回答，一前一后正好覆盖RAG的完整链路。整个过程不依赖任何外部网络节点：Dify镜像、模型文件都能提前备好，再离线导入内网服务器。这篇文章适合两类人——一类是国产化环境里的实施工程师，一类是想把内部文档变成可问答服务的业务负责人。这套方案真正的门槛不在“能不能装上”，而在“装上之后检索效果是否可信并值得长期投入”，下面的内容就是绕着这个目标写的。

2. 先把底子打牢：系统检查、Docker引擎与离线物料三件事

2.1 一台机器三分钟检查：架构、内存、磁盘怎么算够用

拿到一台银河麒麟服务器，先别急着装东西。我一般会先花三分钟确认四件事：系统版本、CPU架构、内存和磁盘布局。银河麒麟V10SP1-2403这个版本号里的2403指2024年3月的服务包，命令输出里要能看到对应的构建信息。

cat /etc/os-release uname -m nproc && free -g && df -h /data

第一条命令看系统是不是银河麒麟V10SP1，第二条看架构，x86_64和aarch64在镜像选择上差别很大。第三条把CPU核数、内存（单位GB）和/data分区的磁盘空间一次性列出来，后面规划容器资源和模型文件路径都靠这三样数据。

这套组合的资源底线我建议这样估算：只跑Dify和在线API，4核8G能启动，但知识库文档一多，unstructured解析服务和多个容器同时跑起来后内存会很紧，推荐8核16G起步。如果还要在本地跑DeepSeek模型，额外加8G内存或一张16G显存的GPU卡才够用。磁盘方面，Dify本体加数据库大约占30G，知识库原始文档和向量库按两年增量预留，我一般直接分200G给/data。

2.2 安装Docker引擎：内网源安装与全离线rpm两种走法

银河麒麟V10SP1的软件源里带了Docker相关的包，内网环境下可以直接从配置好的源安装。如果服务器连内网源都没有，那就走离线rpm路线，在另一台同架构、同系统的机器上把rpm包和依赖全部下载好再拷进去。

# 方式一：内网软件源直接安装 sudo yum install -y docker-ce 2>/dev/null || sudo yum install -y docker sudo systemctl enable --now docker docker info --format '{{.ServerVersion}}' # 方式二：全离线环境用rpm包安装 sudo rpm -ivh /opt/rpm_packages/docker/*.rpm sudo systemctl enable --now docker docker info --format '{{.ServerVersion}}'

方式一的包名在不同源里有差异，有的源叫docker-ce，有的直接叫docker，所以命令里加了fallback。方式二要求rpm包和依赖按顺序安装，如果rpm命令因为依赖报错，就用rpm -ivh --nodeps先解出来再逐个处理，实践中大部分是缺containerd和runc两个底层包。最后用docker info确认ServerVersion有输出，这一步漏了后面全白搭。

2.3 离线物料准备：把Dify和模型镜像一次导出再到内网导入

Dify以docker compose方式部署，启动时会拉取apiserver、web、nginx、postgres、redis、sandbox、weaviate、unstructured等一大堆镜像。内网服务器不能直接拉取，所以必须在能联网的物料机上先把镜像全部准备好，再搬运导入。

# 在联网物料机上执行：从compose文件解析镜像列表并逐一导出 cd /opt/dify docker compose config --images > /tmp/image-list.txt mkdir -p /opt/offline_images while read img; do name=$(echo "$img" | tr '/:' '__') docker pull "$img" && docker save "$img" -o "/opt/offline_images/${name}.tar" done < /tmp/image-list.txt # 在内网服务器上执行：批量导入所有镜像 for f in /opt/offline_images/*.tar; do docker load -i "$f" done

这个脚本的关键在docker compose config --images，它会把compose文件里用到的所有镜像精确列出来，不需要手工维护清单。脚本循环里拉取失败会自动跳过，所以导入完成后一定要用docker images核对镜像数量，缺哪个单独补哪个。这里有个经验：镜像tar包体积很大，拷到内网时用pigz压缩能省将近一半传输时间，但要注意源和目标机器都要有pigz命令。整个物料准备阶段，生产服务器完全不接触外部网络，所有依赖都以tar包形式进入内网。

3. 部署Dify平台：从compose配置到首次登录的完整动作

3.1 拿到Dify代码包并生成环境变量：SECRET_KEY与数据库密码必须改

Dify的部署包是一个包含docker-compose.yaml和.env.example的目录结构，物料阶段把它一起打包带进内网。解压后放到/opt/dify，第一步不是启动，而是生成密钥和改数据库密码。默认的.env文件里有大量弱密码和固定SECRET_KEY，直接启动等于把管理后台裸奔在局域网里。

cd /opt/dify cp .env.example .env # 生成随机密钥并追加到.env echo "SECRET_KEY=$(openssl rand -hex 32)" >> .env # 替换数据库密码 sed -i 's/^POSTGRES_PASSWORD=.*/POSTGRES_PASSWORD=ChangeMe_Dify_2024/' .env sed -i 's/^DB_PASSWORD=.*/DB_PASSWORD=ChangeMe_Dify_2024/' .env

openssl rand -hex 32生成64位随机十六进制串，这个密钥用于会话签名和敏感信息加密，固定值等于没有。sed替换时注意一定要用^锚定行首，否则会误伤其他含POSTGRES_PASSWORD字样的行。数据库密码建议手动指定一个符合长度要求的强密码，不要用命令行再随机一次，免得写进shell历史里。.env改完以后chmod 600，因为里面存的是生产环境的敏感信息。

3.2 docker compose启动与健康检查：先看/api/health再进界面

镜像导入完成后，启动本身只是一个命令的事，真正的麻烦在于确认所有服务都健康。Dify的api容器依赖postgres、redis、sandbox三个服务，weaviate和unstructured启动稍慢，所以第一次启动后要等一段时间再做健康检查。

cd /opt/dify docker compose up -d sleep 30 docker compose ps curl -s http://127.0.0.1/health

docker compose up -d是后台拉起所有服务，sleep 30是等待数据库初始化和迁移脚本跑完。docker compose ps如果看到api和web两个容器处于Up状态但restart次数在增加，说明依赖没起来，用docker compose logs -f api看具体报错。curl的/health接口是Dify自带的健康检查端点，返回pong字符串才算正常。真实环境里有个反复出现的问题：默认nginx监听80端口，服务器上如果已有其他Web服务占用了80，容器会一直重启，需要在.env里把EXPOSE_NGINX_PORT改成8080之类的空闲端口再重启。

3.3 初始化管理员账号：页面安装流程与登录限流的坑

Dify首次访问会在浏览器里走一个安装向导：设置管理员邮箱和密码、确认系统名称。这一步完成后进入登录页，理论上账号密码就是刚才设置的，但很多人在这个环节翻车。有一个常见提示是“too many incorrect password attempts, please try again later”，这是因为连续输错密码触发了登录限流。遇到这个提示不要继续试，等待一段时间让锁定期过去，或者重启api容器临时解除状态。这个锁的目的就是防止暴力破解，不是故障，别去改配置文件绕过它。

如果安装向导页面因为网络原因反复加载不出来，可以用命令行方式初始化。常见做法是在api容器里执行初始化命令，不同版本的命令入口略有差异，执行前先docker compose ps确认api容器名，再进容器看flask命令列表。我的习惯是优先用网页向导，网页走不通才用命令兜底，因为命令行方式还要处理初始化脚本的日志输出，不如页面直观。

4. 接入DeepSeek：在线API与本地模型各走各的路

4.1 在线API接入：用OpenAI兼容接口挂上DeepSeek

DeepSeek的在线API走的是OpenAI兼容协议，而Dify内置了OpenAI兼容接口的供应商类型，两边一接就能通。这个兼容性省掉了写自定义供应商插件的工作，是这套方案里最省心的一个环节。在Dify控制台进入“设置-模型供应商”，找到OpenAI-API-compatible这一类，新建一个供应商实例。

配置完后先点“保存”，Dify会发起一次模型调用做验证。验证通过后，还要在“设置-系统模型”里把deepseek-chat设为默认推理模型，不然创建应用时模型下拉框里不会自动出现它。在线API的好处是回答质量高、响应快，代价是每次问答都有token费用，且服务器必须能访问DeepSeek的API域名。内网环境如果连API都访问不了，就走下一节的本地模型路线。

4.2 本地模型接入：Ollama加载蒸馏版DeepSeek

本地模型的常见做法是用Ollama做推理服务，Dify的模型供应商里直接有Ollama类型。Ollama的安装包也走离线rpm路线，装好后把模型文件放进Ollama的模型目录。DeepSeek的蒸馏版本有多个量级，知识库问答场景我通常推荐7B或8B这个尺寸，回答质量能看，CPU推理大概每秒几个token，配一张16G显存的卡能到可用水平。1.5B太小，答非所问的概率高；14B以上对内存和算力要求陡增，内网服务器不一定扛得住。

# 内网服务器上启动Ollama服务 sudo systemctl enable --now ollama ollama serve & # 确认模型已被Ollama识别（模型文件已提前放入 ~/.ollama/models） ollama list

在Dify的模型供应商里添加Ollama时，Base URL要填http://<服务器内网IP>:11434，这里有个典型的坑：Dify跑在Docker容器里，容器内访问宿主机不能用localhost，要用宿主机的内网IP。模型名称要填Ollama里显示的名字，比如deepseek-r1的蒸馏版，填错了会在验证时报模型不存在。

本地模型跑起来之后有个容易被忽略的问题：知识库的向量化也需要embedding模型。很多人配好了对话模型，导入知识库文档时却报embedding模型不可用。常见做法是在Ollama里再拉一个bge-m3这样的embedding模型，在Dify的embedding模型配置里指向它。对话模型和embedding模型是可以分开配的，这一点在配置系统模型时要注意区分。

4.3 供应商配置最容易翻车的三个点：模型名、地址、密钥

模型供应商配置里反馈最直接的报错是“An error occurred during credentials validation”，遇到这个先不要怀疑Dify装坏了。排错路径很固定：先在命令行用curl直接调DeepSeek API，能通就说明网络和密钥没问题。

curl -s -X POST https://api.deepseek.com/chat/completions \ -H "Authorization: Bearer $DEEPSEEK_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-chat","messages":[{"role":"user","content":"test"}]}'

curl命令能正常返回JSON，问题就出在Dify侧的配置上，重点查三项：Base URL末尾是否多了斜杠、API Key是否带了引号、模型名称是否写错。curl都连不通的，先查服务器时间是否正确，系统时间漂移会导致SSL证书校验失败，这是内网服务器很常见的现象；再确认出口网络策略是否允许访问该域名。另外，Ollama本地供应商报验证失败时，直接在服务器上curl http://127.0.0.1:11434/api/tags看服务是否响应，能响应再查Dify容器到宿主机的网络是否打通。

这里我的建议是：在线和本地两个供应商可以同时配置，不用二选一。在线API模型跑日常问答，本地模型兜底离线场景，在Dify的不同应用里分别指定模型即可。这套双供应商策略在信创环境里非常实用，因为网络策略随时可能调整，你不想在模型供应商这一层被卡死。

5. 构建知识库与排雷实录：分段、检索策略与五个高频坑

5.1 把文档送进知识库：分段参数和索引方式怎么设

知识库构建的核心不是上传文档，而是分段。Dify把文档切成chunk，每个chunk向量化后存入向量库，问答时检索相关chunk送给大模型。分段参数直接决定检索的粒度：分段太大，一个chunk里塞了太多不相关内容，检索召回后噪声大；分段太小，语义被切碎，关键信息散落在多个chunk里。

索引方式这里多说一句：Dify提供“高质量”和“经济”两种，高质量模式会对每个chunk做向量化，检索时按语义相似度匹配，这是RAG知识库的基本形态；经济模式只做关键词索引，适合临时验证流程，不适合正式知识库。首次导入大批量文档时，embedding会比较耗时，这是正常的，不是卡死。导入过程中遇到解析失败的文件，Dify界面会在文档列表里标出失败原因，这个状态要在后续维护里定期清理。

5.2 把知识库挂到应用上：混合检索与提示词的组合

知识库建好后要创建一个“聊天助手”类型的应用，在应用编排页面里关联刚才的知识库。关联之后还要选检索策略，Dify提供向量检索、全文检索、混合检索三种。向量检索认语义但可能漏掉精确术语，全文检索认关键词但抓不住同义表达，混合检索把两者结合起来再统一排序。知识库场景我基本只用混合检索，它通常是性价比最高的选择。

提示词部分不要写得太复杂，我常用的模板是：你是一个企业知识库助手，只能依据提供的知识库内容回答，如果知识库中没有相关信息，直接说明不知道，不要编造。给大模型划清边界比堆砌指令更有效。另外，把TopK设为3到5之间，也就是每次检索召回3到5个chunk，太少容易漏答案，太多会把噪声喂给模型。Dify还提供Rerank能力，在检索后对chunk做二次排序，数据量大了以后这一步会明显提升答案准确率，有条件就开。

5.3 高频踩坑记录：五个现象、原因分析与解决办法

第一个坑是SSL证书校验错误。现象：在Dify里测试模型供应商或解析文档时，日志里出现certificate verify failed。原因排查下来通常是两类：服务器系统时间漂移导致证书有效期判断失败，或是系统缺少CA证书。解决方法是先ntpdate同步时间并配置好ntp服务，再安装ca-certificates并执行update-ca-trust。内网服务器长期不开机时间会越走越偏，这个问题在信创环境里发生率很高。

第二个坑是unstructured解析服务报错。现象：上传PDF或docx后文件一直处于pending或failed状态，日志提示“unstructured api url is not configured for doc file processing”。原因很直白：unstructured这个容器没起来，或者.env里没配置它的API地址。解决方法是确认unstructured镜像已导入且容器处于Up状态，在.env里检查UNSTRUCTURED_API_URL相关配置，然后重启api容器让配置生效。

第三个坑是文件入库成功但chunk数为0。现象：文档显示已入库，但点进去发现0分段，问答完全检索不到内容。原因通常是扫描版PDF——整页是图片没有文字层，解析器什么也分不出来；还有一种可能是自定义了分段标识符设成了文档里不存在的字符。解决方法是先对扫描版PDF做OCR转成带文字层的文件再导入，分段标识符用默认的\n\n先跑通，不要一上来就改高级设置。

第四个坑是检索答非所问。现象：问题明明在知识库里有答案，模型却回答了一通无关内容。原因分两种：embedding模型配置失败导致向量索引没建起来，问答时用的其实是空库；或者分段过长导致每个chunk包含太多噪音。解决方法是先到系统模型里确认embedding模型正常，再进知识库设置里把最大分段长度从500调到300，重新分段后重新嵌入。这一步排查通常能解决七八成“答非所问”的问题。

第五个坑是管理后台登录被锁。现象：连续输错密码后出现“too many incorrect password attempts, please try again later.”。原因就是登录限流触发，不属于故障。解决方法是停止尝试，等待锁定期重置。如果管理员密码彻底忘了，在api容器里通过数据库命令重置用户密码是常见做法，操作前先备份数据库，这个动作本身就是后悔药。

6. 知识库验收技巧：上线前做一次20问压测

6.1 用脚本批量问20个问题，把回答导出来人工打分

知识库能不能上线，不看出自谁的推荐，只看检索回答质量。我每次搭建完都会做一轮20问压测：从文档里挑出20个有标准答案的问题，用脚本批量调用应用API，把回答导出来人工逐条评分。这个环节不能省，因为RAG的效果玄学成分不少，不压测就上线等于把风险往后甩。

import requests import time APP_API_KEY = "app-xxxxxxxxxxxxxxxx" BASE_URL = "http://127.0.0.1:80/v1/chat-messages" questions = [ "服务器默认管理员账号是什么？", "密码重置的流程分几步？", # 继续补充到20条 ] for i, q in enumerate(questions, 1): resp = requests.post( BASE_URL, headers={"Authorization": f"Bearer {APP_API_KEY}"}, json={"query": q, "response_mode": "blocking", "user": "qa_test"}, timeout=120, ) ans = resp.json().get("answer", "") print(f"Q{i}: {q}\nA: {ans}\n" + "-" * 60) time.sleep(2) # 避免触发应用限流

脚本的关键是response_mode选blocking模式，同步拿到完整回答再落盘。20个问题跑完后按“完全答对、部分答对、答非所问”三档打分，完全答对率达到70%以上才建议上线。如果大量问题处于部分答对档，优先调整分段长度和TopK参数，不要一上来就换模型——换了模型只改变表述风格，检索不到正确答案的问题依旧存在。

6.2 维护习惯：小批量验证再全量导入

上线之后的维护比部署更考验习惯。我的做法是每次新增文档都先导一个样本进一个临时知识库，验证检索能命中再全量导入正式库。这个习惯是从一次失败教训里来的：曾一次性导入了超过五千份PDF，结果近一半是扫描件，整个知识库的检索质量被拉低，最后只能重新清洗数据。扫描件先进OCR、表格先转文本，是入库前的基本纪律。定期检查Dify里解析失败的任务列表，把失败文件单独处理而不是放任不管，知识库的检索质量才能维持住。这套方案值不值得做，我的答案是在国产化服务器上还没有比它更顺的路线；沉下心把分段和检索这两个环节调到可用状态，回报是看得见的。希望帮到你。

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