作业11：企业 AI 平台白皮书
文档性质：从「技术执行」到「技术决策」的毕业作品。对内给 CTO/CEO 要资源，对外可作作品集，对团队可作入职教材。
篇幅：约 10～15 页（按 A4 正文估算）。
环境依据：已在
192.168.110.207+ GPU116.62.10.183落地的内部智能体平台（Dify 1.16.1、vLLM Qwen3.6-27B、Xinference bge-m3 / rerank、Weaviate、Langfuse、Prometheus/Grafana）。数据说明：第三章 ROI、第五章部分金额为管理层口径的模拟测算，已标注；SLA 与 Trace 能力来自实装。
HTML：
docs/html_cursor/作业11_企业AI平台白皮书_cursor.html
配套阅读：使用手册（作业 10）、SLA 大盘（作业 8）、排错 SOP、安装手册与专题合集。
目录
1. 平台架构全景
1.1 建设目标
建设一套内网可控的企业 AI 应用平台：制度问答、客服分流、运维助手走同一底座；模型、知识、追踪、SLA 全部可审计。不把核心业务数据默认送公网大模型。
当前已跑通的主线：
部署 Dify → 接入自托管 Langfuse → 知识库开启 Rerank → 工具/工作流作业 → SLA 大盘与经营汇报模版 → 使用手册。
1.2 部署拓扑（实装）
┌─ 业务浏览器 / 业务系统 API
▼
192.168.110.207（应用与检索）
┌──────────────────────────────────┐
│ Dify 1.16.1 控制台 :80 │
│ Xinference bge-m3 / rerank :9997│
│ Weaviate 向量（socat :8088） │
│ Langfuse Trace :3000 │
│ Prometheus :9092 Grafana :3001 │
│ SLA Exporter :8781 │
└──────────────┬───────────────────┘
│ OpenAI 兼容 /v1
▼
116.62.10.183（推理）
┌──────────────────────────────────┐
│ vLLM 容器 vllm-qwen3.6-27b │
│ 模型 qwen3.6-27b :8000 │
│ GPU H20 共享 │
└──────────────────────────────────┘应用编排在 207；重推理在 GPU 机。Embedding / Rerank 当前走 207 CPU 上的 Xinference，避免与 27B 抢同一张卡。
1.3 运行时数据流（知识库问答）
用户问句
→ Dify Agent（快照：模型、Prompt、知识库、工具）
→ bge-m3 向量召回（Weaviate）
→ bge-reranker-v2-m3 精排（Top-K=5）
→ Qwen 生成（vLLM）
→ 流式回写浏览器
→ Langfuse 记 Trace / Token
→ SLA Exporter 汇总可用性与延迟新 Agent 的真实配置在 快照 + 草稿，不是旧版 app_model_configs。这是架构级事实：只改知识库页、不改快照，对话行为不会变。
1.4 已落地能力栈
| 层 | 能力 | 代表产物 |
|---|---|---|
| 应用 | Agent / Workflow | 行政问答、客服意图路由、巡检/健康检查/自愈 |
| 知识 | 入库、命中测试、Rerank | 播城内部行政管理知识库 |
| 模型 | 对话 + Embedding + Rerank | Qwen3.6-27B、bge-m3、bge-reranker-v2-m3 |
| 观测 | Trace、周报、SLA、经营 PPT | Langfuse、作业 6/8/9 |
| 治理 | 使用手册、红线、排错 SOP | 作业 10、SOP、本白皮书 |
2. 核心技术选型与理由
题目常见组合是 vLLM / Dify / Milvus / Langfuse。本平台 推理与编排、观测与之对齐；向量库实装为 Weaviate（Dify 默认栈），下面说明为什么，以及何时再上 Milvus。
2.1 Dify：应用编排而不是自研 Chat UI
| 决策 | 理由 |
|---|---|
| 选 Dify 1.16 | 知识库、Agent、工具、Workflow 一体，业务能在工作室迭代 |
| 不自研对话壳 | 省掉鉴权、流式、引用展示、工作区；把工程时间留给模型接入和排障 |
| 接受「新 Agent」复杂度 | 快照/草稿分离是成本，但换来与旧聊天助手隔离；用 dify_api.py 补齐 UI 没有的开关 |
风险：点「发布」可能把 max_tokens 写空——已写进使用手册口诀和专题十一。这是选型后必须治理的产品缺陷，不是否定 Dify。
2.2 vLLM + Qwen3.6-27B：内网推理
| 决策 | 理由 |
|---|---|
| vLLM 而非单机 Transformers 服务 | 连续批处理、OpenAI 兼容 /v1，Dify 用 OpenAI 供应商即可接入 |
| 27B 级 Qwen | 制度问答需要长上下文与指令遵循；过小模型引用条款不稳定 |
| 独立 GPU 机 | 与 Dify/Weaviate 隔离，避免 API 机 OOM；H20 适合该量级 |
代价：单卡故障即全站生成失败。已用健康检查 Agent（作业 5）和 OOM 自愈（作业 7）做最低闭环，路线图里仍要第二副本。
2.3 向量库：Weaviate 实装，Milvus 作为扩展选项
| Weaviate（现状） | Milvus（常见选型） | |
|---|---|---|
| 与 Dify | 官方 docker 栈默认，接入成本最低 | 需改检索后端与运维手册 |
| 运维 | 本环境踩过 IPv4→[::] 套接字问题，用 socat 中继固定 | 集群与磁盘规划更「数仓化」 |
| 规模 | 适合当前制度库体量与并发 | 文档量/QPS 上一个数量级时更合适 |
结论： 现阶段用 Weaviate 是正确的「先跑通」。白皮书不假装已经上了 Milvus。当知识库分片、多租户隔离、检索 QPS 明显打满 207 时，再单独立项 Weaviate → Milvus（或云检索），而不是现在推翻 Dify。
Embedding 用 bge-m3（多语种、与中文制度匹配），精排用 bge-reranker-v2-m3：召回解决「有没有」，Rerank 解决「排第几」。加班费 300% 条款从「答含糊」到「能引用公式」，来自 Rerank 而不是换更大模型。
2.4 Langfuse：默认可观测
没有 Trace，成本、幻觉、工具是否调用都无法向管理层解释。Langfuse 自托管在 207:3000，与 Dify 共存且不占 80。新 Agent 工作室没有「监测」菜单，必须 API 打开 Tracing——这是平台规范，不是可选项。
2.5 其它组件一句话
| 组件 | 为何留下 |
|---|---|
| Xinference | 在 207 CPU 上 launch embedding/rerank，与 vLLM 进程隔离 |
| Prometheus + Grafana | 作业 8 给领导看 SLA；端口避开 MinIO 9090/9091 |
| 钉钉机器人 | 周报与自愈通知，进入现有运维群，不另建 IM |
3. 关键指标与 ROI
下列经营数字为 模拟口径（与作业 9 PPT 模版一致），用于董事会级讨论；平台侧请求量/Token 可从 Langfuse 刷新。
3.1 平台 SLA 目标（已上大盘）
| 指标 | 目标 | 监控 |
|---|---|---|
| 平台可用性 | ≥ 99.9% | Prometheus + 健康检查 |
| 首 Token P99 | ≤ 2s | Langfuse / SLA Exporter |
| 完整响应 P99 | ≤ 10s | 同上（剔除超长超时样本） |
| 知识库抽检准确率 | ≥ 85%（目标抬到 90%） | 人工 + LLM-as-Judge |
| 故障恢复 MTTR | ≤ 30 min | 工单 / 自愈记录 |
大盘：http://192.168.110.207:3001/d/ai-platform-sla。
3.2 业务价值（模拟）
| 场景 | 改造前 | 改造后 | 口径 |
|---|---|---|---|
| 客服效率 | 人肉翻制度 + 工单全量进人工 | 意图路由自动解决常规单 | +32% 人效 |
| 研发/运维排障 | 搜文档、问老人 | 助手 + Shell/巡检工具（受控） | +28% 编码/排障效率 |
| 制度检索 | 平均 15 分钟 | 对话 约 8 秒 出引用 | 知识工作者等待时间 |
假设行政+客服相关岗位 40 人、人均年负担成本 25 万、可被助手影响的时间占比 15%，人效提升按 30% 计：
年度粗算节约 ≈ 40 × 25 万 × 15% × 30% = 45 万元。 该公式供财务复核，不是审计结论。
3.3 质量与风险指标（应纳入季度会）
| 指标 | 建议阈值 | 动作 |
|---|---|---|
| 命中测试 Top-1 与金标条款一致率 | ≥ 80% | 低于则补文档或调 Rerank |
| 用户点「无用」占比 | < 8% | 抽样改 Prompt / 库 |
| vLLM waiting > 0 的时段占比 | < 5% | 限流或第二副本 |
| 超长 Trace（>30s）占比 | 下降趋势 | 排除后看真实 P99 |
4. 安全与合规方案
4.1 原则
数据默认不出内网。 生成内容不替代盖章制度。工具默认最小权限。
4.2 控制措施
| 域 | 措施 |
|---|---|
| 网络 | 控制台、Langfuse、Grafana 仅内网；GPU 推理口不对公网暴露 |
| 身份 | 一人一号；禁用共享管理员；离职关号 |
| 密钥 | 应用 API Key、模型 Bearer、Langfuse SK 只放服务器环境变量 |
| 知识库 | 无脱敏证件/薪酬密表；过期制度必须下线 |
| 应用 | Shell / 任意 HTTP 默认关；写操作（重启容器、建工单）要场景审批 |
| 提示词 | 拒绝「忽略以上规则」；涉薪酬处分走线下 |
| 审计 | Langfuse 保留问答与工具 Span；user 字段用业务系统稳定 ID |
细则见作业 10 第七章。白皮书层面对 CTO 的承诺是：可关停、可追溯、可把数据留在 207/GPU 机房。
4.3 合规缺口（如实披露）
- 尚未做正式等保/密评材料，需法务与安全部立项。
- Langfuse/Dify 日志保留周期未与公司档案制度对齐。
- 单机房，无异地灾备。见第六章与第八章。
5. 成本核算与优化策略
5.1 现状成本结构（数量级，模拟）
| 项 | 年化（万元，模拟） | 说明 |
|---|---|---|
| GPU 服务器折旧/云资源 | 18～35 | 视 H20 摊销年限 |
| 207 应用机 | 3～6 | Dify 全家桶 + 向量 |
| 电费与机房 | 4～8 | 推理占比高 |
| 人力（运维 0.5～1 人） | 15～30 | 含值班 |
| 合计 | 约 40～80 | 未含业务侧知识库更新人力 |
对比第三章 45 万级人效粗算，在 40 人规模上账可以打平到略正；若只服务 10 人则必须砍 GPU 档或提高复用（多部门共平台）。
5.2 已采用的优化杠杆
| 杠杆 | 做法 | 本环境 |
|---|---|---|
| 量化 | vLLM 侧 KV/权重量化，降显存与时延 | 按 GPU 手册持续评估 |
| 缓存 | 少打满 64K 上下文；重复制度问答可前缀缓存 | 规范 Prompt 与附件大小 |
| 模型降级 | 作业 4：日预算告警 + 超阈值降 max_tokens / 廉价模型名 | 防账单型打满 |
| 检索减负 | Rerank Top-K=5，避免把 20 段垃圾送进 27B | 已验收 |
作业 9 模版将上述三项合计写成 季度节省 18 万元 的占位，供汇报替换。真实节省以财务认定的 GPU 利用率与 Token 账单为准。
5.3 推荐的财务制度
- 每个应用有「日 Token 预算」责任人。
- 压测禁止走生产 Key。
- 季度对照：Langfuse Token × 单价 vs 人效问卷。
6. 运维 SOP 与故障应急预案
6.1 日常 SOP
接到「搜不到 / 答偏 / 很慢」：
- 问清应用名、原话、是否全员。
- 一次只查一层：命中测试 → 快照绑库 → vLLM 排队 → max_tokens。
- 禁止先重启 Dify + vLLM + Xinference。
- 修完用同一句原话回归，并看 Langfuse。
标准流程见《企业 AI 助手排错 SOP》。组件探测表见作业 10 第八章。
6.2 应急分级
| 级别 | 现象 | 动作 | RTO 目标 |
|---|---|---|---|
| P1 | 全员无法生成（vLLM 挂、OOM） | 作业 7 检测+重启；失败则切只读公告 | ≤ 30 min |
| P2 | 知识库全空/检索失败 | 查 bge-m3 launch、Weaviate 中继 :8088 | ≤ 1 h |
| P3 | 单应用答偏 | 不升级为平台故障；改库/Prompt/快照 | 当日 |
| P4 | 大盘黄、P99 抖动 | 看超时样本占比；不立刻扩容 | 观察 24 h |
6.3 预案清单（当前缺口一并列出）
| 预案 | 现状 | 12 个月内 |
|---|---|---|
| vLLM 进程恢复 | 自愈 Agent + 人工 SSH | 第二 vLLM 副本 + VIP/反代 |
| Xinference 实例丢失 | 重启后需 relaunch | 写成 systemd/compose 依赖 |
| Weaviate 异常 | socat 中继 + 专题六 | 监控 :8088，磁盘水位告警 |
| 机房断电 | 无 | 冷备配置与知识库导出 |
| 密钥泄漏 | 人工轮换 | 强制过期与审计邮件 |
回滚原则：改快照前导出 JSON；Dify 镜像升级先在窗口期；知识库重建前保留原 collection。
7. 培训体系与推广计划
7.1 教材分层
| 听众 | 教材 | 时长 |
|---|---|---|
| 全员 | 作业 10 第二、六、七章 | 45 分钟 |
| 知识库管理员 | 作业 10 第三章 + 命中测试实操 | 2 小时 |
| 应用搭建者 | 专题十五 + Prompt 规范 + 「不要点发布」 | 半天 |
| 运维 | SOP + 专题十四 + 作业 5/7/8 | 1 天 |
| 管理层 | 作业 9 PPT + 本白皮书第 3、5、8 章 | 20 分钟 |
新成员入职：白皮书（为何这样建）→ 使用手册（怎么用）→ 跟一次命中测试 → 看一张 Langfuse Trace。
7.2 推广节奏（建议）
| 阶段 | 时间 | 动作 |
|---|---|---|
| 试点 | 月 1～2 | 行政问答 + 一个客服队列，周会看「无用」率 |
| 扩面 | 月 3～6 | 再接入 1～2 个部门库；API 给一个业务系统 |
| 固化 | 月 7～12 | SLA 进周会；预算到部门；安全部过红线检查 |
推广失败的典型原因是「只发链接不培训」和「知识库不更新」。推广 KPI 应是 周活跃对话人数 和 制度更新时效，不是助手个数。
8. 未来 12 个月演进路线图
Q1（0～3 月） 稳态
· SLA 99.9% 进周会；抽检准确率 ≥ 85%
· 知识库更新接口人制度
· 完成密钥盘点与 API 接入规范
Q2（4～6 月） 容量与高可用
· waiting 长期 >0 则上第二 vLLM
· Xinference launch 持久化
· 评估 Embedding 上 GPU（路径 B）
Q3（7～9 月） 产品化
· 1 条生产业务 API 正式 SLA
· 成本分账到部门 Token
· 启动等保/安全测评材料
Q4（10～12 月） 架构升级窗口
· 若检索成为瓶颈：Milvus/云检索预研与 POC
· 冷备与配置即代码
· 复盘 ROI，决定是否上更强模型或小模型分流明确不做的事： 未治理数据前接公网大模型当默认；未评审就给全员 Shell；用本白皮书替代等保报告。
9. 给决策层的结论与资源请求
9.1 结论
- 内网智能体平台已经 可演示、可观测、可交给业务试用，不是 PPT 架构。
- 技术栈选择匹配阶段：Dify 加速应用、vLLM 保证内网推理、Weaviate 先跑通、Langfuse 让成本可见。Milvus 是规模上来之后的选项。
- 最大风险是 单卡推理 与 知识库腐烂，不是缺一个更时髦的框架。
9.2 请求（供审批勾选）
| 优先级 | 请求 | 用途 |
|---|---|---|
| P0 | 维持现 GPU + 运维 0.5 人周 | 不停服 |
| P1 | 第二推理副本或明确限流策略预算 | P1 故障 RTO |
| P1 | 各部门知识库接口人（非外包兼职） | 准确率 |
| P2 | 安全/等保立项 | 第七章缺口 |
| P2 | 财务确认 Token 单价与分账 | 第五章可审计 |
9.3 作品与教材索引
| 用途 | 打开 |
|---|---|
| 本白皮书 | 作业11_企业AI平台白皮书_cursor.html |
| 使用手册 | 作业10_企业AI平台使用手册_cursor.html |
| 经营幻灯片 | 作业9_AI平台经营汇报幻灯片_cursor.html |
| SLA | Grafana :3001/d/ai-platform-sla |
| 总入口 | 内部智能体搭建_文档索引首页_cursor.html |
*版本：与 207 实装同步。ROI 数字为模拟测算，替换前请财务复核。*