核心数据涉密不敢上云？手把手教你搭建企业本地知识库，安全私密零泄露风险！

很多企业的朋友问我：公司有大量研发代码、财务报表、合同协议以及客户名单，想用大模型做智能问答，但一想到要把这些核心资产上传到第三方公有云，合规部门和老板直接亮红灯。

公有云 API 的调用协议里，数据传输和存储即便承诺“不用于模型训练”，只要数据出了内网，物理层面就存在中间人攻击、日志留存甚至服务商内部权限失控的漏洞。解决这个问题的办法很干脆：彻底断网，在本地服务器运行整套 RAG（检索增强生成）系统。数据不经过公网，模型运行在本地显卡上，从根源上截断外泄风险。

搭建这套系统不需要从零写代码，目前开源社区的成熟组件已经能直接拼装出生产级系统。我用几个团队的实际落地经验，把硬件选型、软件架构、具体步骤和踩坑点完整梳理出来。

一、 核心架构与工具选型

本地知识库的核心是 RAG 架构。它的运转逻辑很简单：你问一个问题，系统先去本地向量数据库里检索出相关的文档段落，然后把这些段落连同你的问题一起塞给本地大模型，让模型根据参考资料总结回答。

整套系统包含四个核心层：

1.模型推理引擎：负责在本地加载并运行模型。

2.大语言模型（LLM）与向量模型（Embedding）：LLM 负责理解和回答；Embedding 负责把文档切片变成数字向量。

3.向量数据库：存储并检索文档切片。

4.知识库前端与编排系统：提供可视化界面、上传文档、设置切分规则、管理权限。

关于前端与编排工具，目前市面上有三个主流选择。企业环境不要盲目跟风，直接看下面这张对比表格：

对于绝大多数需要企业协同的团队，Dify + Ollama 是平衡度最好的方案。它不仅界面友好，还自带 API 接口，方便后续打通企业微信或飞书。

二、 硬件配置基准

本地知识库不同于纯文本闲聊。知识库在检索出文档后，会一次性向模型输入数千甚至上万字（Context Window 膨胀），这会导致显存占用急剧上升。很多人按网上纯聊天的显存去买显卡，导入知识库一问就报 OOM（显存溢出）。

结合 2024 至 2025 年主流开源模型的表现，企业硬件配置建议如下：

避坑要点：

•优先看显存，不要只看算力。显卡显存不够，模型必须部分卸载到系统内存（CPU 运算），速度会直接暴跌 10 倍以上。

•Embedding 模型必须常驻显存。很多人只给大模型预留了显存，忽略了文本向量化模型也要占 1-2G 显存。

•纯内网机房不要用消费级无风扇外壳。高并发下显卡满载发热巨大，务必保证服务器机箱风道通畅。

三、 离线环境搭建实操步骤

很多涉密服务器处于物理拔网线的纯内网环境。这里按照完全断网的逻辑，分为四步操作。

第一步：在外网机器拉取镜像与模型

先在可以联网的机器上准备好安装包：

1.下载 Ollama 安装包或离线 Docker 镜像：

docker pull ollama/ollama:latest
docker save ollama/ollama:latest -o ollama.tar

2.运行 Ollama 容器，下载需要的模型文件：

ollama run qwen2.5:14b
ollama run bge-m3

下载完成后，进入 Ollama 存储目录（Linux 下通常在 `/usr/share/ollama/.ollama/models` 或 `~/.ollama/models`），把整个模型文件夹打包。

3.下载 Dify 官方源码包：

在 GitHub 下载 Dify 的最新 Release 源码包，并提前把 `docker-compose.yaml` 里依赖的 PostgreSQL、Redis、Weaviate 等容器镜像全部拉取并导出为 `.tar` 文件。

第二步：内网导入并启动 Ollama

通过安全移动介质（如通过合规审批的专用 U 盘）将安装包导入内网服务器。

1.导入镜像并挂载 GPU 启动 Ollama：

docker load -i ollama.tar
docker run -d --gpus=all -v /data/ollama:/root/.ollama -p 11434:11434 --name ollama --restart always ollama/ollama

2.把第一步打包的模型文件解压到宿主机的 `/data/ollama` 对应目录下。

3.验证模型加载：

执行 `docker exec -it ollama ollama list`，如果终端正常输出了 `qwen2.5:14b` 和 `bge-m3`，说明推理服务就绪。

第三步：部署 Dify 企业知识库平台

1.解压 Dify 源码，进入 `docker` 目录：

cd dify/docker
cp .env.example .env

2.修改 `.env` 文件。将不需要的外网接入项关闭。如果内网有自定义端口，在这里做好修改。

3.导入 Dify 的一整套离线镜像包后，启动容器集群：

docker compose up -d

启动后，访问服务器内网 IP（如 `http://192.168.1.100`），初始化管理员账号和密码。

第四步：模型接入与知识库配置

登录 Dify 控制台，进行核心配置：

1.配置模型供应商：

•点击右上角头像 -> 设置 -> 模型供应商 -> 选择 Ollama。

•添加 LLM：模型名称填 `qwen2.5:14b`，基础 URL 填 `http://:11434`。

•添加 Embedding：模型类型选 Text Embedding，模型名称填 `bge-m3`，基础 URL 同样填 Ollama 地址。

2.创建知识库并上传数据：

•切换到 知识库 菜单，点击 创建知识库。

•上传公司内部的 PDF、Word 或 Markdown 文档。

•关键设置（直接影响检索质量）：

•分段规则：选择“自定义分段”。分段最大长度建议设为 500 至 800 tokens，重叠长度（Overlap）设为 10%（约 50-80 tokens）。重叠区间能保证上下文在被截断时不丢失主谓宾语。

•检索模式：建议选择 混合检索（Hybrid Search）。混合检索结合了关键字检索（BM25）和语义检索（Vector），对专业术语、合同编号这类生僻词的匹配非常精准。

3.构建问答应用：

•在 工作室 菜单创建“聊天助手”。

•在“上下文”一栏关联刚才建好的知识库。

•系统提示词（Prompt）中加上约束规则：“只根据上下文信息回答问题。如果上下文中没有提及，请直接回答‘知识库中未包含此信息’，严禁自行编造。”这一句能压制大模型的幻觉。

三、 必须注意的四个“深水坑”

搭建起来只是完成了 30%，实际使用中如果不注意以下四点，系统很快会变成“不可用”的摆设：

1.垃圾进，垃圾出（文档清洗比换模型更重要）：

很多人直接把扫描件 PDF 或排版混乱的 Excel 扔进知识库，结果模型满嘴胡话。大模型不是神仙，OCR 识别错位的字符、多余的页眉页脚、跨页拆碎的表格，向量化后都会变成无序噪音。在上传前，必须先将文档清理为整洁的 Markdown 格式。如果涉及大量报表，先转成结构清晰的 CSV 或 Markdown 表格，检索准确率会直线提高。

2.Top-K 与相似度阈值不要设得太极端：

Dify 允许设置检索召回的段落数（Top-K）和相似度过滤分值。

•如果 Top-K 设得太大（比如取 10 段），送进模型的杂质太多，模型容易注意力分散，甚至直接把关键信息忽略掉。

•如果相似度阈值设得过高（比如 0.85 以上），经常会导致“明明文档里有，系统却说查不到”。建议初始阈值设在 0.5 到 0.6 之间测试，Top-K 保持在 3 到 5。

3.权限与网络隔离必须做到操作系统层：

知识库跑在内网，不代表内部员工都能看所有资料。财务报表、薪酬数据不能让全体研发看到。

•在 Dify 中，必须按部门建立独立的工作空间和知识库，严禁把所有文档堆进一个大池子。

•宿主机层面，部署了向量库和数据库的服务器只对办公网段开放 Web 端口（如 80/443），SSH 管理端口（22）和 Ollama API 端口（11434）必须用防火墙做 IP 白名单限制，防止内网其他机器未授权调用。

4.备份机制直接关乎数据存亡：

本地部署意味着你自己就是运维。Docker 容器一旦损坏或挂载卷误删，积累的索引和聊天记录全没了。

•必须写定时脚本，每天凌晨将 PostgreSQL（存元数据）、向量库存储目录（存索引）做异地冷备。

•原始文档必须保留独立的归档文件系统，不要依赖知识库内部的文件提取功能。

按照这套方案搭建，整套链路不经过任何公网节点，既保住了核心数据的绝对安全，又让团队能用到 AI 的检索和总结能力。先拿一台带 4090 的废旧机器或新采购的工控机跑起来，验证完效果再平滑扩容，是最稳妥的推进路径。