2. Champion 与 Challenger 的角色定义：线上稳定模型 vs 实验候选模型，生命周期管理

在 Champion/Challenger 体系中，Champion 与 Challenger 并非简单的“新旧模型”关系，而是承载着完全不同的运维角色与实验使命。理解两者的定义、职责边界以及生命周期管理规则，是搭建可靠对比框架的第一步。

2.1 角色核心差异

2.2 生命周期管理流程

每个模型角色都遵循清晰的生命周期阶段，从创建到退役形成闭环。下图展示了 Champion 与 Challenger 的并行生命周期路径：

2.3 生命周期阶段详解

Champion 生命周期

1. 线上稳定运行： Champion 承载 100% 生产流量，所有业务指标处于基线水平。此阶段禁止直接修改模型参数，仅允许通过配置开关调整后处理逻辑。
2. 灰度晋升 / 热修复： 当 Challenger 通过验证后，以灰度方式逐步替换 Champion（如 1% → 5% → 20% → 100%）。紧急 bug 修复可直接走热修复通道，但需在 24 小时内补全实验报告。
3. 异常自动回滚： 监控系统检测到核心指标（如转化率、响应时间）下降超过阈值时，自动触发回滚至上一个稳定版本，并通知值班人员。
4. 退役 / 归档： 当 Champion 被新模型完全替代后，进入归档状态。归档模型保留推理代码与配置，但不再接收流量，用于历史回溯与审计。

Challenger 生命周期

1. 实验候选创建： 基于 Champion 基线进行模型结构调整、特征工程或超参数调优，生成 Challenger 版本。每个 Challenger 必须关联唯一的实验 ID 和版本标签。
2. 小流量实验： 分配 1%–20% 流量进行 A/B 测试。实验期间记录所有预测结果、特征分布及业务反馈，确保数据可回溯。
3. 评估 / 晋升决策： 统计显著性检验通过（p-value < 0.05）且业务指标提升 ≥ 1% 时，进入晋升评审。若实验失败，直接标记为“淘汰”。
4. 晋升 / 淘汰： 晋升的 Challenger 成为新的 Champion，进入灰度替换流程；淘汰的 Challenger 保留实验数据后清理模型文件，释放资源。

2.4 角色转换与冲突处理

在实际运营中，可能出现多个 Challenger 同时竞争晋升，或 Champion 突发异常需要紧急替换的情况。下表列出了常见场景及处理策略：

2.5 生命周期状态机

为了更清晰地展示状态流转，下图以状态机形式呈现 Champion 与 Challenger 的核心状态及转换条件：

2.6 角色定义清单

在实际项目中，建议使用以下清单来明确每个模型实例的角色归属：

• 模型 ID： 全局唯一标识，格式如 champion_v3.2.1_20250301 或 challenger_exp042_lr0.001。
• 角色标签： 显式标记 champion 或 challenger，禁止混淆。
• 流量分配： Champion 默认 100%，Challenger 必须 ≤ 20%。
• 实验窗口： Challenger 需记录开始时间、结束时间、目标指标。
• 晋升条件： 明确列出统计显著性阈值、业务提升幅度、稳定性要求。
• 回滚预案： 每个 Champion 必须关联至少一个可回滚的上一版本 ID。