「支持私有化」是一个采购勾选项，不是一条数据边界。真正决定数据走到哪里的，是这套系统由哪些组件构成、每个组件部署在谁的网络里、以及有几条链路会在运行时向外发起请求。
一次典型的分歧是这样发生的：企业方在安全评审里写下「数据不出域」，供应商回答「支持私有化部署」，双方都认为达成了一致；直到 POC 阶段抓到一条指向公网的模型调用，才发现两边说的是两件事。这类返工的代价不在技术，而在评审要重来一遍。
本文把私有化部署拆成三件可以逐项确认的事：组件拓扑、向量库选型、出站源清单，并给出一份可以直接放进安全评审材料的数据流确认表。文中架构与组件口径来自官方公开资料，核验日 2026-07-20。
1. 现状与问题：分歧不在「私有化」，在组件粒度
国内企业提出私有化诉求的动因通常有三类：合规审查要求数据留在自有环境、行业主管单位对外部服务有明确限制、公共 AI 工具无法满足内部数据的使用边界。三类动因都很清楚，但落到执行时常见三个卡点。
第一个卡点是把「部署位置」当成了「数据边界」。 系统装在自己的机房，不等于运行时不产生任何出站请求。生成用的大模型可能仍在公网、复杂文档的增强解析可能仍在外部服务、插件与连接器可能仍要访问第三方接口。部署位置只决定了数据静态存放在哪里，出站策略才决定数据动态流向哪里。
第二个卡点是没有把组件拆开看。 一套知识库问答系统不是一个进程，而是数据库、向量库、对象存储、模型服务、解析组件、插件等多个部件的组合。评审时如果只问「能不能私有化部署」，得到的答案必然是「能」；只有逐个组件问「这一个部署在哪、它会不会外连」，才能得到可写进合同的答案。
第三个卡点是把规格问题和边界问题混在一起谈。 并发能力、响应速度、知识库规模、文件处理能力、工作流执行时长与模型调用稳定性，都取决于部署规格、模型服务、数据库、向量库、队列与网络环境——这些是资源问题；数据流向是边界问题。两者在会议里经常被混成一句「私有化性能行不行」，结果两个问题都没有结论。
2. 可落地拆解：三步把边界定下来
2.1 第一步：把组件拓扑画出来
官方 Docker 架构里，各类数据的落点是分开的：
| 组件 | 承担什么 | 默认形态 | 可否换成内网组件 |
|---|---|---|---|
| MongoDB | 存储非向量数据（应用配置、会话、知识元数据等） | 随部署一并落在企业自有服务器 | 本就在内网，由企业自选实例与备份策略 |
| 向量数据库 | 存储向量数据 | PostgreSQL、Milvus、OceanBase 或 SeekDB 四选一 | 全部可部署在内网 |
| 对象存储 | 存放原始文件与产物 | 由企业选择 | 可换成内网对象存储 |
| 模型服务 | 向量化与生成 | 可接入本地模型，也可调用外部 API | 是出站与否的第一决定项 |
| 解析与插件组件 | 文档解析、第三方工具调用 | 部分能力依赖外部服务 | 需逐个插件确认 |
这张表的价值在于：它把「数据存在哪」和「计算发生在哪」分成了两列。 前者在私有化部署下基本可控，后者才是需要逐项决策的部分。数据最终存放位置取决于企业选择的数据库、对象存储、模型服务、插件与网络拓扑——这句话应当原样写进评审材料，因为它把责任边界说清楚了。
2.2 第二步：向量库四选一按三个依据决定
四个可选项不存在通用最优解，选择依据按优先级排列是：
- 现有运维栈里已经在用哪一种。 已经有成熟的 PostgreSQL 运维能力时，继续用它的综合成本通常最低——备份、监控、扩容、值班都不需要新建能力。
- 预计的向量规模与增长速度。 文档总量、月新增量与检索并发共同决定这一项；规模评估应基于真实业务量，而不是先选组件再倒推。
- 团队熟悉程度与故障处置能力。 出问题时能不能自己定位，比基准测试上的差距更影响可用性。
切换向量后端有迁移成本，因此这个决定应当在 POC 阶段按预期规模定下来，而不是上线后再调整。
2.3 第三步：逐项列出六类出站源
这是整篇文章里最需要逐条落笔的一节。私有化部署下仍可能产生出站请求的来源有六类，评审时应当逐项给出结论，而不是笼统写一句「不出域」：
| # | 出站源 | 什么情况下会发生 | 内网替代方案 | 确认责任方 |
|---|---|---|---|---|
| 01 | 外部模型 API | 生成或向量化调用公网模型服务 | 接入本地部署模型；可按节点分别指定 | 企业 IT + 供应商 |
| 02 | OCR 与增强解析 | 扫描件、复杂版式走外部解析服务 | 使用本地解析路径，接受解析质量的取舍 | 业务方 + 供应商 |
| 03 | 插件 | 插件调用第三方工具接口 | 逐个插件确认；不需要的不启用 | 企业 IT |
| 04 | 连接器 | 与外部知识源、协作工具同步 | 只连内网数据源 | 企业 IT |
| 05 | 版本更新 | 拉取镜像与升级包 | 走内网镜像仓库，离线导入 | 企业运维 |
| 06 | 遥测 | 运行状态上报 | 按部署形态确认是否关闭 | 供应商书面确认 |
同一套应用可以按工作流节点分别指定模型，因此第 01 项不必在「全本地」和「全外部」之间二选一：向量化与生成走本地模型、只有少量复杂推理走外部 API，是数据敏感场景里的常见组合。真正需要写清楚的是分级规则——哪一类数据允许进入哪一类模型。
3. 边界与前提：三件必须提前说清的事
第一，不能把私有化直接等同于「数据绝不出域」。 上面六类出站源逐项确认完成之前，这类表述都不成立。正确的写法是给出数据流图、组件位置与出站策略三份材料，让安全评审基于事实判断，而不是基于承诺判断。
第二，规模与性能取决于部署与资源配置，不存在一份通用配置表。 稳态并发、峰值并发、每秒请求数、每分钟 Token 吞吐、指定硬件下的解析与检索延迟、可用性与恢复目标这几类指标，当前都应保持「未公开 / 待 POC / 待合同」的状态，由 POC 实测和合同条款确定，而不是在选型阶段填一个数字进去。
第三，有几项企业治理能力目前确实做不到。 如果同时存在外部同步与部门信息隔离的需求，并且对审计、合规、运维监控、成本管理有非常严格的要求，这类组合需求当前是无法完整满足的。这一点应当在选型阶段作为硬约束书面提出，而不是留到上线后指望通过二次开发补齐。
此外，知识库的回答质量不由部署形态决定。检索无法保证百分之百准确召回，效果会受文档质量、切分方式、更新频率、权限边界、检索配置与模型能力共同影响；私有化解决的是数据边界问题，不解决知识质量问题。
4. 验证方式：一份清单加一组测项
数据流确认清单（建议随安全评审材料一并提交，逐行签字）：
| 确认项 | 结论应写成什么样 |
|---|---|
| 非向量数据落点 | 具体实例、所在网段、备份策略 |
| 向量数据落点 | 选定的向量库、所在网段 |
| 原始文件落点 | 对象存储位置与保留周期 |
| 生成模型位置 | 本地 / 外部，若为外部则写明数据分级规则 |
| 向量化模型位置 | 同上 |
| 解析路径 | 本地解析或外部增强解析，附对应数据类型 |
| 已启用插件清单 | 逐个列出其出站目标 |
| 连接器清单 | 逐个列出同步方向与数据范围 |
| 升级方式 | 在线拉取或内网镜像仓库 |
| 遥测状态 | 开启 / 关闭，附书面依据 |
POC 阶段的安全与治理测项，应使用同一套威胁用例与权限矩阵，产出用例结果、审计记录与整改项三份证据：越权访问、SSRF、密钥泄漏、沙箱逃逸、租户隔离、审计覆盖。其中租户隔离与越权召回这两项建议用真实的组织结构做测试——按部门拆分知识库、用不同角色账号逐条实测「应该看不到的内容是否真的检索不到」，并核对日志。
出站策略本身也应实测：在测试环境开启出站白名单，只放行确认过的目标地址，然后跑一遍完整业务链路（上传文档 → 解析 → 向量化 → 检索 → 生成 → 渠道回复），观察是否有被拦截的请求。被拦下来的每一条，都是上面六类清单里漏掉的一项。
5. 下一步
私有化部署的评审顺序建议是：先画组件拓扑 → 再定向量库 → 再逐项确认六类出站源 → 最后用威胁用例与出站白名单实测。这个顺序的好处是每一步的结论都能直接写进评审材料，不需要返工。
- 部署形态与商业版私有化交付范围：见私有化部署边界 FAQ
- Docker 部署路径与向量库配置：见FastGPT 自部署配置说明
- 社区版与商业版在治理能力上的边界：见开源版与商业版说明