Lesson 11 · Demo 演示效果好, 直接全量上线 → 首周被 15% 边缘 case 打爆¶
Problem¶
- POC 演示 10 个 case, 全部完美
- CIO / 业务方非常满意, 要求"下周就全量上线"
- 供应商觉得"能过 POC 就应该能生产", 同意
- 上线第 1 周:
- 15% 边缘 case 出错 (长尾输入 / 罕见场景 / 组合复杂)
- 用户投诉飙升, 5000+ 用户中有 700+ 反馈
- 客服团队被打爆, 加班处理
- CIO 被 CEO / 业务副总裁质问
- 项目从"AI 明星"变"AI 事故"
Root Cause¶
Demo 用的是精选 case (happy path), 生产遇到长尾 / 边缘 / 罕见 / 组合场景会翻车.
- Demo 数据是筛选过的"清晰、明确、典型"输入
- 生产数据是完整分布, 含 15-20% 罕见 / 边缘 / 组合
- 就算 POC 准确率 95%, 生产也会 85% (因为分布 shift)
- 全量上线 = 15% × 大用户量 = 大量绝对错误
- 用户对 AI 的容忍度低 (见 Lesson 06 · 无溯源)
Fix¶
强制灰度 · 5% → 20% → 50% → 100%:
| 阶段 | 用户占比 | 时长 | 关键动作 |
|---|---|---|---|
| Canary | 5% | 3-7 天 | 挑早期支持者 · 收边缘 case · 观测 SLA |
| Expand | 20% | 3-7 天 | 扩大到常规用户 · 观测跨部门 |
| Half | 50% | 3-7 天 | 上线到半量 · 观察规模效应 |
| Full | 100% | 长期 | 全量, 但保持 5% "对照组" (可选) |
每档必查: - 准确率 / 命中率 / 引用准确率是否降低 - 错误 case 是否有共同模式 (chunk 边界? embedding 领域偏移?) - SLA 是否维持 (p95 延迟 / 可用性 / 错误率) - 用户投诉是否上升 - 成本是否符合预期
回滚触发条件明确: - 准确率下降 5%+ 立即回滚 - SLA 突破立即回滚 - 用户投诉 spike 立即回滚 - 30 秒内可执行回滚 (提前演练)
How to Avoid¶
- 需求阶段就写清"灰度上线策略", 不留讨价还价空间
- 合同 SLA 条款包含灰度阶段的准确率 / 延迟 / 可用性
- 观测 dashboard 提前部署 (见 Lesson 08 · Prompt 版本管理)
- 值班 SOP 生产化前演练 (真回滚一次)
- 教育业务方"AI 需要灰度, 就像所有大型系统"
- 准备 CEO 沟通模板如果业务方施压全量, 有据可依
Related cases¶
- Case 15 · CI/CD LLM Code Review — 分阶段灰度 · Code Review P50 24h → 1h
- Case 01 · 三甲医院 AW36-72B — 5 医生 → 30 → 100 → 300+
- Case 13 · 128 GPU K8s+Slurm — Canary 团队 → 半量 → 全量
Related how-tos¶
避坑成本估算: 全量翻车 = 用户信任修复 3-6 个月 + CIO / 业务方声誉损失.
下一步: 30 min 上线灰度 SOP 对齐