2. 核心概念解析：Champion模型、Challenger模型、模型版本、模型基线、模型回滚、模型淘汰策略
在Champion Challenger模型管理体系（以下简称CC体系）中，六个核心概念构成了模型全生命周期管理的骨架。理解这些概念的定义、职责和相互关系，是落地模型治理的第一步。本章从实战视角逐一拆解，并给出每个概念在工程系统中的映射方式。
2.1 六大核心概念总览
下表从定义、职责、生命周期状态三个维度，对六个概念进行横向对比，便于快速建立全局认知。
| 概念 | 定义 | 核心职责 | 生命周期状态 |
|---|---|---|---|
| Champion模型 | 当前在线服务中表现最优、承担生产流量的主模型 | 稳定处理线上请求，作为业务效果的基准 | Active（活跃） |
| Challenger模型 | 待验证的新模型或候选模型，与Champion进行对比实验 | 在隔离环境中验证性能，争取替代Champion | Experimenting（实验）→ Candidate（候选） |
| 模型版本 | 模型在训练、发布、迭代过程中的唯一快照标识 | 提供可追溯的模型制品，支持回滚和复现 | Created → Validated → Deployed → Retired |
| 模型基线 | 用于衡量模型效果的最低可接受标准 | 定义Champion必须满足的硬性指标阈值 | Baseline（固定参照） |
| 模型回滚 | 当新模型出现异常时，将服务切换回历史稳定版本的操作 | 保障服务连续性，降低故障影响范围 | Rollback（临时状态） |
| 模型淘汰策略 | 决定何时以及如何将旧模型移出服务体系的规则集合 | 控制模型版本数量，避免资源浪费和版本混乱 | Retired（已淘汰） |
2.2 Champion模型与Challenger模型
Champion与Challenger是CC体系中最核心的一对概念，它们之间是竞争替代关系，而非并行共存关系。
- Champion模型：当前生产环境中唯一承担100%或指定比例流量的主模型。它必须通过严格的离线评估和在线A/B测试，且持续满足基线指标。Champion一旦被选定，即进入“保护期”，非必要不轻易替换。
- Challenger模型：一个或多个待验证的候选模型。Challenger通过影子部署（Shadow Deployment）或流量分桶（Traffic Bucket）与Champion进行对比。只有当Challenger在统计显著水平上全面超越Champion，且通过业务验收后，才能晋升为新的Champion。
实战建议： 建议同时维护不超过3个活跃Challenger。过多的Challenger会分散评估资源，增加实验噪声。每个Challenger应有明确的实验目标和截止时间，避免“僵尸实验”长期占用计算资源。
2.3 模型版本与模型基线
模型版本和模型基线是CC体系中的数据基础设施，它们为Champion和Challenger的对比提供了可量化的标尺。
模型版本
每个模型版本对应一次完整的训练-验证-发布流程。版本号通常采用语义化版本（如 v2.1.0）或时间戳+哈希（如 20250321_a3f2c1）的命名方式。版本管理需要记录以下元数据：
- 模型架构与超参数
- 训练数据集指纹（Dataset Fingerprint）
- 评估指标快照（AUC、准确率、延迟等）
- 模型文件存储路径（如S3、HDFS）
- 部署时间与部署人
模型基线
基线不是某个具体的模型版本，而是一组硬性指标阈值。例如：
- 离线AUC ≥ 0.85
- 在线点击率（CTR）不低于Champion的95%
- P99推理延迟 ≤ 50ms
- 内存占用 ≤ 2GB
任何Challenger在晋升前，必须同时满足所有基线指标。基线本身也会随着业务目标的变化而调整，但调整频率不应高于季度级别。
2.4 模型回滚机制
模型回滚是CC体系中的安全网。当新晋升的Champion出现性能下降、数据漂移或系统异常时，回滚机制能够快速将服务切换回上一个稳定版本。
回滚操作分为三个等级：
- 自动回滚：监控系统检测到关键指标（如错误率、延迟）超过预设阈值时，自动触发回滚，无需人工介入。
- 半自动回滚：系统发出告警并推荐回滚版本，由值班工程师确认后执行。
- 手动回滚：在紧急故障或复杂场景下，由模型管理员手动指定回滚目标版本。
注意： 回滚不是万能药。频繁回滚说明模型发布流程或评估体系存在缺陷。建议每次回滚后都进行根因分析（RCA），并将结论更新到模型基线或评估标准中。
2.5 模型淘汰策略
模型淘汰策略决定了旧模型何时以及如何退出服务。缺乏淘汰策略会导致模型仓库膨胀、版本混乱，甚至出现“幽灵模型”占用线上资源。
常见的淘汰触发条件包括：
- 时间触发：模型上线超过指定有效期（如90天）后自动进入淘汰流程。
- 性能触发：模型连续N个评估周期低于基线阈值。
- 版本触发：新Champion稳定运行超过一定时间后，旧Champion自动降级并进入淘汰队列。
淘汰流程通常包含三个阶段：
- 标记（Mark）：将模型状态标记为“待淘汰”，停止新流量接入。
- 观察（Observe）：保留模型实例但不再接收流量，观察一段时间（如7天）确认无异常。
- 清理（Clean）：删除模型文件、释放计算资源、归档元数据。
2.6 核心概念关系图
下图展示了六个核心概念之间的动态关系，以及它们在模型生命周期中的流转路径。
2.7 概念间的协作流程
在实际的模型管理平台中，六个概念通过以下流程串联成一个闭环：
- 定义基线：业务方与算法团队共同制定模型基线指标。
- 注册版本：每次训练完成后，将模型制品注册为新的版本，并记录评估指标。
- 创建Challenger：从候选版本中挑选一个或多个作为Challenger，部署到实验环境。
- 对比实验：Challenger与当前Champion进行A/B测试或影子对比。
- 晋升或淘汰：若Challenger超越基线且优于Champion，则晋升为新Champion；否则标记为失败并进入淘汰队列。
- 回滚准备：每次Champion变更时，自动记录前一个Champion版本作为回滚目标。
- 淘汰清理：定期执行淘汰策略，清理过期版本和失败的Challenger。
关键原则： 整个流程中，模型基线是唯一的评判标准，模型版本是唯一的操作对象，Champion是唯一的在线服务主体。任何偏离这三条原则的操作，都应触发人工审核。