2. 基础知识
2.1 核心概念：从“全量切换”到“渐进式发布”
在传统软件部署中，新版本通常一次性替换旧版本，所有用户流量瞬间切换到新系统。这种“全量发布”模式在模型迭代场景下风险极高：一旦新模型存在数据分布偏移、推理性能劣化或接口协议不兼容，影响范围将是全部线上请求，且回滚过程同样粗暴——直接切回旧版本，可能造成服务中断或状态不一致。
灰度发布（Gray Release / Canary Release）的核心思想是：将新版本先部署到一小部分流量或用户群体中，在真实业务环境下验证其稳定性与效果，再逐步扩大流量比例，直至全量覆盖。对于AI模型而言，灰度发布不仅是工程部署策略，更是模型质量保障体系的关键一环——它让模型在“实验室离线评估”与“全量生产环境”之间多了一道真实流量的检验闸门。
关键区别：传统发布关注“系统可用性”，而AI模型灰度发布额外关注“模型效果一致性”。即使服务不报错，新模型也可能在特定样本上表现异常（如误判、偏见放大），灰度阶段正是捕捉这类问题的窗口。
2.2 关键术语与三种典型策略
AI模型发布领域常将以下术语混用，但它们在流量调度、资源占用和验证目标上存在本质差异。理解这些差异是选择发布策略的前提。
2.2.1 金丝雀发布（Canary Release）
名称源自“煤矿中的金丝雀”——先让少量“探路者”承受风险。具体做法是：将新模型部署到独立实例或Pod中，路由层按比例（如5%）将真实请求转发至新模型，其余请求仍由旧模型处理。验证通过后，逐步调高比例（10% → 30% → 70% → 100%）。
- 核心特征：新旧版本同时在线，共享同一套路由入口，流量比例可动态调整。
- 适用场景：在线推理服务、推荐系统、风控模型等需要实时反馈的业务。
- 优势：细粒度控制，可随时暂停或回退；真实流量验证，无需构造仿真数据。
- 劣势：需要路由组件支持权重分配；新旧版本共存期间需维护两套资源。
2.2.2 蓝绿部署（Blue-Green Deployment）
准备两套完全独立的环境：蓝环境（当前生产版本）与绿环境（新版本）。发布时一次性将路由从蓝切到绿，若出现问题则立即切回蓝环境。与金丝雀不同，蓝绿部署不涉及流量比例渐变，而是“全量切换+快速回退”。
- 核心特征：两套环境始终就绪，切换瞬间完成（秒级），回滚同样迅速。
- 适用场景：模型版本间差异巨大（如算法架构完全重写）、对回滚速度要求极高的核心链路。
- 优势：切换逻辑简单，无需复杂路由权重；回滚只需再次切换DNS或负载均衡器。
- 劣势：资源成本翻倍；若新模型存在数据污染（如训练数据泄露），切换后可能立即影响全量用户。
2.2.3 A/B测试（A/B Testing）
严格来说，A/B测试并非发布策略，而是效果评估方法。它将用户随机分为两组，分别由旧模型（对照组）和新模型（实验组）服务，通过统计检验判断新模型是否在业务指标（如点击率、转化率、满意度）上显著优于旧模型。A/B测试常与金丝雀发布结合：先通过金丝雀发布保证系统稳定，再通过A/B测试验证业务效果。
| 维度 | 金丝雀发布 | 蓝绿部署 | A/B测试 |
|---|---|---|---|
| 核心目标 | 降低发布风险 | 快速切换与回退 | 验证效果差异 |
| 流量分配 | 按比例渐进 | 全量切换 | 按用户/请求随机分组 |
| 新旧共存时长 | 分钟~小时级 | 秒级切换 | 天~周级 |
| 资源开销 | 中（需额外实例） | 高（双环境常驻） | 中（需分流与日志） |
| 回滚方式 | 调低新版本流量比例 | 切回蓝环境 | 终止实验组 |
| 典型应用 | 在线推荐、语音识别 | 核心交易链路 | 搜索排序、广告模型 |
2.3 适用场景与选择决策
面对具体业务，不应机械套用某种策略，而应基于风险容忍度、资源成本、验证需求三个维度综合判断。以下给出典型场景的决策参考：
- 场景一：智能客服意图识别模型升级——新模型在离线测试中准确率提升3%，但担心特定话术误判。推荐金丝雀发布：先分配5%流量，重点监控“转人工率”和“用户满意度”，逐步放量。
- 场景二：金融风控模型架构重构——从逻辑回归升级为深度学习模型，特征工程完全改变。推荐蓝绿部署：提前准备完整环境，在业务低峰期切换，一旦发现异常率上升立即切回。
- 场景三：电商推荐算法调参——仅调整了排序权重，希望验证是否提升GMV。推荐A/B测试：设置实验组与对照组，运行1~2周收集足够样本，进行显著性检验。
- 场景四：图像识别模型新增类别——需要验证新类别识别准确率且不影响原有类别。推荐金丝雀+监控：按地域灰度（如先开放华东区），对比新旧模型在各类别上的置信度分布。
实践建议：三种策略并非互斥。成熟团队通常采用“金丝雀发布 + A/B测试”组合：先以金丝雀方式小流量验证系统稳定性（无报错、延迟达标），再在稳定流量段开启A/B实验验证业务效果，最后逐步放量至全量。
2.4 常见误区与复盘要点
在讲授灰度发布时，学员常陷入以下认知偏差，这些误区在实际事故中代价高昂：
误区一：将“灰度发布”等同于“A/B测试”。灰度发布解决的是“新版本是否安全”，A/B测试解决的是“新版本是否更好”。前者关注错误率、延迟、资源占用；后者关注业务指标。用A/B测试的指标（如点击率）来判断是否继续灰度，可能忽略系统稳定性风险；反之，仅凭系统稳定就全量发布，可能让业务效果更差的模型上线。
误区二：忽略“数据一致性”问题。在灰度期间，同一用户可能有时被路由到旧模型、有时被路由到新模型。对于有状态服务（如多轮对话、会话推荐），这会导致体验割裂。解决方案包括：按用户ID哈希进行会话粘滞（同一用户始终路由到同一版本），或在模型层面对输入输出做兼容处理。
复盘案例：某内容推荐团队将新模型灰度至50%流量后，整体点击率上升2%，于是直接放量至100%。次日发现“冷启动用户”的留存率下降5%——因为新模型过度依赖用户历史行为，对新用户推荐质量差。复盘结论：灰度验证指标过于单一，仅关注了整体点击率，未按用户分群（新用户/老用户）拆分监控。改进措施：在灰度阶段设置多维指标看板，包括整体指标、分群指标、长尾内容曝光量等，并设定“一票否决”条件（如任一关键分群指标下降超过阈值则自动回滚）。
另一个常见工程误区是回滚预案设计滞后。许多团队在灰度前未准备“一键回滚”脚本，当新模型出现异常时，手动调整路由权重耗时过长，导致故障扩大。正确的做法是：在灰度发布前，预先编写并测试回滚脚本，确保能在1分钟内将流量全部切回旧版本。回滚不仅是“切换流量”，还需考虑模型缓存、特征存储等依赖组件的状态回退。
最后需要强调的是，灰度发布不是终点，而是模型生命周期管理的一个环节。灰度结束后，应保留完整的发布记录（时间、流量比例、监控指标、决策依据），形成可追溯的发布档案。这些数据不仅用于审计，更是后续模型迭代时的重要参考——例如，通过历史灰度数据可以总结出“哪些类型的改动风险更高”“哪些监控指标最敏感”，从而优化未来的发布策略。