想象你经营一家拳击俱乐部。俱乐部有一位卫冕拳王，打法稳健，是票房的保证。每个赛季都有新人慕名而来，想要抢走金腰带。但你不能让新人直接打满全场——万一对方还没练熟，既输了比赛又砸了招牌。于是教练组定下规矩：新人先从少数几场小比赛打起，只有不断证明自己，才能获得更多上场机会；直到裁判记录显示新人真正强过拳王，金腰带才易主。而被击败的老拳王不会立即消失，他被保留在训练馆，随时准备回归救场。 这套“卫冕拳王+挑战者”的运转方式，正是今天要讲的主角。在云端的服务系统里，卫冕拳王是稳定运行的主力版本，新人则是候选版本；用户的每一次请求就像一场小比赛，业务指标则是裁判打分。一场永不落幕的卫冕战，就这样支撑着 AI 服务持续进化。

岗位关联

掌握 Champion/Challenger 模型管理，让你设计出的 AI 云服务能像拳击俱乐部一样持续自我进化，是 MLOps 平台与云架构工程师的核心竞争力。

目录
  1. 可视化演示
  2. 核心概念与原理
  3. 部署架构设计
  4. 评估与晋升机制
  5. 模型迭代全周期
  6. 平台化工程实践
  7. 故障应对回滚
  8. 高级应用演进
  9. 最佳实践案例
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

三步展示Champion/Challenger模型管理：Champion生产最佳与Challenger候选对比、分桶/影子和流量分发模式、以及多臂老虎机MAB动态优化流量分配。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Champion/Challenger Champion: 生产最佳模型 Challenger: 候选新版本 真实生产流量对比 安全迭代回退风险低。

核心概念与原理

拳击俱乐部的金腰带只有一条，一定系在卫冕拳王身上。挑战者想要得到它，得先走上擂台用拳头说话。把这一幕搬到 AI 云服务里，金腰带就是线上主力模型的位置，我们把它叫做 Champion；新训练出来的候选模型叫 Challenger。两者共享线上流量，Champion 承担大部分请求，Challenger 只分到一小部分，像新拳手先打几场小比赛一样。

Champion/Challenger 模式最早流行于决策管理领域，后来被电商推荐、在线广告等大规模 AI 系统广泛采用。它的核心不是某个算法，而是一套生产治理机制：让新老模型在真实流量上持续比拼。与 A/B 测试那种“跑完就结束”的实验不同，Champion/Challenger 是 7×24 小时运转的常态机制，永远准备着一个挑战者去推翻现任冠军。

在这种机制下，线上业务指标可以看作两个模型各自表现的加权平均。挑战者的流量份额为 p，卫冕冠军的份额为 1-p，那么观测到的总体指标 y 服从下面的组合关系：

这个公式揭示了卫冕战的“安全阀”：p 足够小时，挑战者的波动几乎不会惊动全局，观众体验始终稳定；随着 p 增大，总指标逐渐暴露在新模型的真实能力之下。拳王卫冕战的安全感，就来自这种小步试探的灰度智慧。

y=p×ychallenger+(1−p)×ychampion\displaystyle y = p \times y_{\mathrm{challenger}} + (1-p) \times y_{\mathrm{champion}}
线上总体指标就像两个拳手同场竞技后的综合得分：挑战者上的场次越多，他对总分的贡献就越大，观众体验也就越取决于他的真实水平。
  1. 定义符号y 是线上观测到的整体业务指标，p 是挑战者拿到的流量比例
    y=p×ychallenger+(1−p)×ychampion\displaystyle y = p \times y_{\mathrm{challenger}} + (1-p) \times y_{\mathrm{champion}}
  2. 权重归一两个权重加起来等于 1, 总流量被完全分配到两个模型
    p+(1−p)=1\displaystyle p + (1-p) = 1
  3. 边界检验当 p=0 时挑战者不上场，总体指标退化为 Champion 的指标
    p=0⟹y=ychampion\displaystyle p=0 \Longrightarrow y = y_{\mathrm{champion}}

部署架构设计

老拳王的场馆已经固定，挑战者要进场较量，就得在舞台上动些手脚。AI 云服务里同样如此：不能把新模型直接塞进生产链路，而是要在入口处搭建一个“分流器”，让请求按比例流向两座擂台。

部署上通常将模型服务抽象为两个独立端点，由网关根据流量切分策略把请求路由到 Champion 或 Challenger。常见做法是“小步慢走，逐步放大”：挑战者从 5% 到 10% 流量起步，观察指标稳定后再上调。这背后是一条平滑的流量增长曲线：

除了流量比例，还要保证两边的“赛场条件”一致：请求特征版本统一、上下文纯净、缓存策略相同。否则就像拳手在倾斜的擂台上比赛，赢了也不作数。

这个公式像教练手中的“出场计划表”：新拳手第一周只打两场，第二周三场，慢慢加量，但绝不允许他直接打满整个赛季。只要按这个节奏走，拳迷的体验不会因为新人的失误而崩盘。

pt=min⁡(pmax⁡,p0×γt)\displaystyle p_t = \min(p_{\max}, p_0 \times \gamma^t)
  1. 初始份额$p_0$ 是挑战者的初始流量占比，通常取 5%-10%
    p0=0.05∼0.10\displaystyle p_0 = 0.05 \sim 0.10
  2. 增长因子$\gamma$ 控制流量放大速度，一般取略大于 1 的常数
    γ=1.01∼1.05\displaystyle \gamma = 1.01 \sim 1.05
  3. 封顶保护$p_{\max}$ 是最大流量上限，防止挑战者占比过大
    pt=min⁡(pmax⁡,p0×γt)\displaystyle p_t = \min(p_{\max}, p_0 \times \gamma^t)

评估与晋升机制

拳击比赛能不能换腰带，裁判说了算，教练和观众说的都不算。在模型治理里，裁判就是一套评估体系：一组业务指标、一份统计检验、一个自动晋升开关。

业务指标要选“拳迷真正在意的东西”：转化率、成交额、用户留存、推荐点击率。技术指标如延迟、错误率也不能忽视，它们决定了拳手在台上是否“动作变形”。只看均值还不够——小样本下领先几个百分点可能是运气。于是需要统计显著性检验，最常见的做法是比例 z 检验：

当 z 值超过 1.96，意味着挑战者优势“赢过噪音”的概率超过 95%。此时平台自动切换金腰带——新拳王上位，旧拳王进入历史版本库。整套流程不需要人拍脑袋，裁判记录自己说话。

z=p^c−p^hp^(1−p^)(1nc+1nh)\displaystyle z = \frac{\hat{p}_c - \hat{p}_h}{\sqrt{\hat{p}(1-\hat{p})(\frac{1}{n_c}+\frac{1}{n_h})}}
  1. 样本比例$\hat{p}_c$ 和 $\hat{p}_h$ 分别是挑战者与卫冕冠军在各自流量上的胜率估计
    p^c=xcnc,p^h=xhnh\displaystyle \hat{p}_c = \frac{x_c}{n_c}, \quad \hat{p}_h = \frac{x_h}{n_h}
  2. 合并比例$\hat{p}$ 是把两组样本合并后的总体胜率，用于估计标准误
    p^=xc+xhnc+nh\displaystyle \hat{p} = \frac{x_c + x_h}{n_c + n_h}
  3. 计算 z 值差值除以标准误，得到检验统计量，与 1.96 比较可判断是否显著
    z=p^c−p^hp^(1−p^)(1nc+1nh)\displaystyle z = \frac{\hat{p}_c - \hat{p}_h}{\sqrt{\hat{p}(1-\hat{p})(\frac{1}{n_c}+\frac{1}{n_h})}}

模型迭代全周期

拳手从训练营走向擂台，最后退役，是一条完整生命线。Champion/Challenger 模型管理同样覆盖模型的“一生”：训练注册、灰度观察、退役保留。

新模型先离线训练并做回放评估，达标后进入模型注册表，获得一个版本号。从这一刻起，它成为 Challenger，以小流量进入线上灰度阶段。灰度期间平台持续采集指标，像拳手在训练赛中积累实战经验。如果数据不足就下结论，很容易被随机波动欺骗，所以需要估算最小样本量：

晋升后的老冠军不会立刻被遗忘。它会以历史版本的身份留在模型库中，继续接收少量探针流量，并作为回滚的备选。就像退役拳王留在训练馆当陪练——队伍需要时，他随时可以重新披挂上阵。

n=(zα/2+zβ)2×2σ2δ2\displaystyle n = \frac{(z_{\alpha/2}+z_\beta)^2 \times 2\sigma^2}{\delta^2}
  1. 置信水平$z_{\alpha/2}$ 对应置信水平，95% 置信时取 1.96
    z0.025=1.96\displaystyle z_{0.025} = 1.96
  2. 统计功效$z_\beta$ 对应检验功效，80% 功效时约 0.84
    zβ≈0.84\displaystyle z_\beta \approx 0.84
  3. 样本量估算$\delta$ 是最小可检测差异，差异越小所需样本越大
    n=(zα/2+zβ)2×2σ2δ2\displaystyle n = \frac{(z_{\alpha/2}+z_\beta)^2 \times 2\sigma^2}{\delta^2}

平台化工程实践

只有拳手和教练还不够，一场联赛背后需要赛事运营公司：场地、转播、后勤、医疗。在 AI 云服务里，这家“运营公司”就是 MLOps 平台。

平台能力的第一块是云原生部署：模型容器化、Kubernetes 弹性伸缩、服务网格负责流量路由。第二块是模型注册与治理：每个模型有唯一的版本号、负责人、上线状态、评估记录，谁都能查清“这位拳手是怎么打上来的”。第三块是多环境管理：开发、测试、生产环境复用同一套 Champion/Challenger 逻辑，避免“训练场赢球、正式赛输人”。

这些模块组合起来，整体可用性也能用加权公式描述：

赛事运营公司把规则、场馆、后勤全部标准化，拳手才能专心比赛。平台层把 Champion/Challenger 变成类似 CI/CD 的流水线能力，算法工程师只需要提交模型，剩下的“排兵布阵”交给平台。

A=p×Ah+(1−p)×Ac\displaystyle A = p \times A_h + (1-p) \times A_c
  1. 可用性定义$A_h$ 与 $A_c$ 分别是挑战者服务和卫冕冠军服务的可用性
    Ah,Ac∈(0,1)\displaystyle A_h, A_c \in (0,1)
  2. 加权组合整体可用性按流量占比加权，挑战者流量越大越影响整体
    A=p×Ah+(1−p)×Ac\displaystyle A = p \times A_h + (1-p) \times A_c
  3. 工程含义挑战者可用性偏低时，小流量 p 能有效保护整体
    A≈Ac(p≪1)\displaystyle A \approx A_c \quad (p \ll 1)

故障应对回滚

拳击比赛也有爆冷：挑战者可能是在训练营里用错误方法练出来的，或者比赛当天状态异常。模型世界里，最常见的“爆冷”是数据漂移——线上输入分布变了，模型在训练场上的招式全部失灵。

PSI（群体稳定性指数）是检测数据漂移的常用工具。它把特征分成 k 个桶，比较实际流量分布和训练基准分布之间的偏差：

当 PSI 超限或错误率、超时率快速飙升，平台不会等人工处理，而是自动“一键回滚”：新拳王立即停赛，流量切回上一代冠军。这就是雪崩回滚机制。同时熔断降级——部分非关键请求直接返回缓存结果，保证核心服务不停摆。

PSI=∑i=1k(ai−ei)×ln⁡aiei\displaystyle \mathrm{PSI} = \sum_{i=1}^{k} (a_i - e_i) \times \ln\frac{a_i}{e_i}
  1. 分箱对比将特征按分位点分成 k 桶，$a_i$ 是实际占比，$e_i$ 是预期占比
    i∈{1,2,…,k}\displaystyle i \in \{1,2,\dots,k\}
  2. 逐桶偏差每个桶计算差异乘对数比，方向一致的偏差会放大信号
    di=(ai−ei)×ln⁡aiei\displaystyle d_i = (a_i - e_i) \times \ln\frac{a_i}{e_i}
  3. 求和判级所有桶偏差相加得到 PSI, 通常超过 0.25 即触发告警
    PSI=∑i=1kdi\displaystyle \mathrm{PSI} = \sum_{i=1}^{k} d_i

高级应用演进

当挑战者不止一个，比赛就从“一场卫冕战”升级为“锦标赛制”。多个候选模型同时进入挑战池，各自获得一小份流量，谁表现好谁获得更多上场机会。

多挑战者并行能大幅提升迭代效率，但也带来新问题：如何把有限的流量最优地分配给多个候选？强化学习中的多臂老虎机算法给出了答案，其中 UCB（置信上界）策略最常用：

这个公式像智能教练：比赛打得多的拳手按真实战绩安排场次，比赛打得少的新人先多给几次亮相机会，但不让任何人长期霸占压轴场。锦标赛制与金丝雀发布结合后，新版本可以“先走一小节，再走一大步”，发布的每一步都被数据背书。

at=arg⁡max⁡i(xˉi+2ln⁡tni)\displaystyle a_t = \arg\max_{i} \left( \bar{x}_i + \sqrt{\frac{2\ln t}{n_i}} \right)
  1. 平均收益$\bar{x}_i$ 是候选 i 目前的平均表现，代表“已知道的实力”
    xˉi=1ni∑j=1niri,j\displaystyle \bar{x}_i = \frac{1}{n_i}\sum_{j=1}^{n_i} r_{i,j}
  2. 探索项$\sqrt{2\ln t / n_i}$ 是置信上界，被验证越少的候选获得越大探索补偿
    explore=2ln⁡tni\displaystyle \text{explore} = \sqrt{\frac{2\ln t}{n_i}}
  3. 选择规则每轮选择“已知实力+探索补偿”最大的候选
    at=arg⁡max⁡i(xˉi+2ln⁡tni)\displaystyle a_t = \arg\max_{i} \left( \bar{x}_i + \sqrt{\frac{2\ln t}{n_i}} \right)

最佳实践案例

金牌教练的军规，是从无数次成败里摔打出来的。Champion/Challenger 的最佳实践同样如此。

某电商推荐系统采用该模式后，一个月内完成三个版本迭代，点击率累计提升 12%，而线上风险事件为零。它的第一要义是“业务指标为北极星”：点击率提升但转化率下降，就是不晋升；延迟增加但收益显著提升，才考虑晋升并配合扩容。第二要义是“小流量快速验证”：挑战者从 5% 流量起步，48 小时内就能拿到统计显著的结论，不必等一周。第三要义是“三方团队协作”：算法团队负责出模型，平台团队负责建机制，业务团队负责定义指标，各司其职。

选模型时可以用综合决策分数：

这些军规背后都是同一个道理：卫冕战既要敢于换人，也要敬畏风险。冠军不是永恒不变的，但每一次交接都要有数据支撑、有回滚后路、有团队共识。

score=w1×business+w2×stability\displaystyle \text{score} = w_1 \times \text{business} + w_2 \times \text{stability}
  1. 权重归一$w_1$ 与 $w_2$ 分别代表业务指标和稳定性指标的权重，两者和为 1
    w1+w2=1\displaystyle w_1 + w_2 = 1
  2. 加权评分业务表现与稳定性表现各自标准化后加权求和
    score=w1×business+w2×stability\displaystyle \text{score} = w_1 \times \text{business} + w_2 \times \text{stability}
  3. 双重门槛综合分达标且单项不低于最低线，才允许晋升
    pass  ⟺  (score≥θ)∧(business≥θb)\displaystyle \text{pass} \iff (\text{score} \ge \theta) \land (\text{business} \ge \theta_b)

AI 应用场景

电商推荐系统的流量守卫战

阶段：模型在线推理与服务治理

解决的问题：推荐模型每周都有新训练结果，传统方式“大版本月度替换”风险高、反馈慢，通常要出事才回滚。Champion/Challenger 把新模型做成挑战者，用 10% 流量试跑 48 小时，指标提升则自动晋升，让模型跟上用户兴趣的实时变化。

具体案例：某电商首页 Feed 流，新模型在挑战期点击率提升 3.2%，但延迟增加 20ms，平台结合“点击率+延迟”综合打分后谨慎晋升，并保留昨日模型用于随时回滚。

智能客服大模型路由

阶段：大模型服务灰度发布与评测

解决的问题：微调后的大模型回答质量高但偶有“幻觉”，直接全量上线风险极大。用挑战者模式让微调模型处理 5% 客服会话，人工质检评分高于 Champion 且拒绝率不升高时逐步放量。

具体案例：某银行智能客服，微调模型在 5% 流量下工单满意度提升 8%，但“答非所问”比例同步上升。系统识别到该指标恶化后触发回滚，团队调整 prompt 与上下文压缩策略，第二轮挑战才顺利晋升。

在线广告 CTR 预估快速迭代

阶段：训练-验证-发布的闭环

解决的问题：广告模型需要快速加入新特征，但一次实验失误可能直接冲击广告收入。Champion/Challenger 机制让候选模型在独立流量桶内验证，挣到数据才放量。

具体案例：某广告平台每天新增多个候选模型，利用“锦标赛制”并行测试，UCB 算法自动把有限流量分配给最有潜力的候选，一周内筛选出下一任 Champion，迭代效率提升 3 倍。

Python 演示

python61 行
import mathimport random class ChampionChallengerManager:    def __init__(self, real_champion=0.55, real_challenger=0.58):        self.real_rates = {"champion": real_champion, "challenger": real_challenger}        self.wins = {"champion": 0, "challenger": 0}        self.trials = {"champion": 0, "challenger": 0}        self.share = 0.1  # challenger gets 10% traffic        self.warmup = 800  # minimum samples before z-test     def sample(self, model):        p = self.real_rates[model]        return 1 if random.random() < p else 0     def run_traffic(self, n):        for _ in range(n):            if random.random() < self.share:                model = "challenger"            else:                model = "champion"            outcome = self.sample(model)            self.trials[model] += 1            self.wins[model] += outcome     def z_test(self):        nc = self.trials["challenger"]        nh = self.trials["champion"]        if nc < self.warmup or nh < self.warmup:            return None        pc = self.wins["challenger"] / nc        ph = self.wins["champion"] / nh        p = (self.wins["challenger"] + self.wins["champion"]) / (nc + nh)        denom = math.sqrt(p * (1 - p) * (1.0 / nc + 1.0 / nh))        if denom == 0:            return None        return (pc - ph) / denom     def maybe_promote(self, threshold=1.96):        z = self.z_test()        if z is None or z <= threshold:            return False        self.real_rates["champion"] = self.real_rates["challenger"]        self.wins = {"champion": 0, "challenger": 0}        self.trials = {"champion": 0, "challenger": 0}        self.share = 0.1        return True if __name__ == "__main__":    random.seed(42)    manager = ChampionChallengerManager()    total = 0    for cycle in range(50):        manager.run_traffic(1000)        total += 1000        if manager.maybe_promote():            print("Round {}: Challenger promoted to new Champion!".format(total))            break    else:        z = manager.z_test()        print("No promotion after 50 rounds, z = {:.4f}".format(z if z is not None else 0))
目的：用简单模拟器演示 Champion/Challenger 流量分配、样本采集、z 检验与自动晋升的完整闭环。
  1. self.share = 0.1挑战者初始只拿 10% 的“比赛场次”，模拟小流量起步。
  2. if random.random() < self.share:每个请求按份额随机决定流向，等价于网关的流量路由。
  3. self.trials[model] += 1每场“比赛”都记录样本量，为显著性检验积累证据。
  4. denom = math.sqrt(p * (1 - p) * (1.0 / nc + 1.0 / nh))计算标准误，对应 z 检验公式的分母。
  5. return (pc - ph) / denom返回 z 统计量，判断挑战者相对冠军的优势是否可信。
  6. if z is None or z <= threshold:样本不足或优势不显著时，挑战者继续留在挑战池。
  7. self.real_rates["champion"] = self.real_rates["challenger"]挑战者胜出，金腰带正式易主。

常见误区

误区“不就是把 A/B 测试换了个名字？跑完一轮，写个报告，选个赢家就完事了。”

正解A/B 测试是一次性实验，跑完就结束；Champion/Challenger 是生产环境里常驻的治理机制，它连着监控、回滚、自动晋升，是模型持续运营的一部分。用拳击类比，A/B 测试是打一场友谊赛定胜负，Champion/Challenger 则是每周都要打的联赛，联赛的目的是让组织永远保持最强阵容。

为何常见：两者都是流量切分对比，表面看起来一样，所以容易混淆。

误区“给挑战者 50% 流量，一天就能出结果，多快好省！”

正解流量越大，挑战者一旦表现差，受害的用户就越多。而且统计上，超过一定样本量后，继续放大流量对结论速度的提升十分有限。主流实践是从 5%～10% 起步，逐步放大，上限一般控制在 30%～50%，保证整体体验的安全边际。

为何常见：人总是想尽快看到结果，忽略了风险控制。

误区“点击率涨了 2%，马上切换！延迟涨一点无所谓。”

正解点击率涨了但收入降了，转化率高但超时率飙升，都会让整体业务受损。晋升要看业务指标与技术指标的综合评分，不能只盯一个数。拳手拳速快了但防守漏人，照样会输掉腰带。

为何常见：单一指标最容易计算和对比，综合评估需要更多工程投入。

误区“样本量才 1000，挑战者均值高 0.5%，我就宣布它赢了。”

正解均值的差异可能只是随机波动。需要用 z 检验或置信区间确认差异在统计上显著，比如 \|z\|>1.96，否则很容易把噪音当真信号。裁判必须看清回放慢动作，不能凭感觉举牌。

为何常见：人对概率不敏感，看到数字高就倾向于相信。

误区“赢了就赢了，旧的删掉释放存储。”

正解旧冠军要保留为历史版本，至少留存一个发布周期。一旦新模型上线后出现数据漂移或故障，可以一键回滚。老拳王留在训练馆当陪练，不是浪费资源，而是队伍的保险单。

为何常见：只看到磁盘成本，低估了回滚路径的价值。

面试题

Q1. 在 Champion/Challenger 模式中，挑战者初期最合适的流量份额是？

单选题 · easy

  • A.50%对半分流量
  • B.5%到15%小流量← 正确答案
  • C.90%大流量验证
  • D.100%全量替换

答案：B。挑战者初期应小流量起步（5%-15%），这样即使模型出错影响面也可控。50% 风险和成本都很高，90% 或全量替换更是本末倒置——那就不叫挑战者了。小流量试探，逐步放量，是这类机制的核心原则。

Q2. Champion/Challenger 与 A/B 测试最大的区别是？

单选题 · easy

  • A.前者离线后者在线
  • B.前者持续运行后者一次性← 正确答案
  • C.两者完全相同无区别
  • D.前者指标更少更简单

答案：B。A/B 测试通常是一次性实验，跑完出报告就结束；Champion/Challenger 是常驻生产环境的治理机制，持续监控、自动晋升、随时回滚。它像联赛而不像友谊赛，所以选 B。

Q3. 挑战者点击率比卫冕冠军高 2% 但样本量很小，你该怎么做？

单选题 · mid

  • A.直接切换节省时间
  • B.立刻回滚旧版本
  • C.增大样本量再检验← 正确答案
  • D.停止线上推理服务

答案：C。小样本下的均值差异可能是随机波动，正确做法是继续积累流量，直到样本量足以支撑统计显著性检验。直接切换是赌博，回滚是未晋升就先认输，停服更不现实。

Q4. 流量公式 p_t = min(p_max, p_0 × γ^t) 中 γ 表示？

单选题 · mid

  • A.流量初始份额
  • B.流量增长速度← 正确答案
  • C.流量上限阈值
  • D.统计显著水平

答案：B。γ 是大于 1 的放大因子，控制挑战者流量的增长速度。p_0 是初始份额，p_max 是流量上限，显著性水平与流量增长无关。γ 越大，放量越快，风险也越大。

Q5. 晋升挑战者之前应核查哪些条件？

多选题 · mid

  • A.业务指标显著更优← 正确答案
  • B.样本量达到要求← 正确答案
  • C.延迟错误率达标← 正确答案
  • D.训练时间最短

答案：ABC。晋升要经过三重把关：业务指标显著优于冠军、样本量足够支撑统计结论、技术指标不恶化。训练时间短不是晋升理由，效果和稳定性才是。三者缺失任何一个，晋升都可能翻车。

Q6. PSI 群体稳定性指数主要用于？

单选题 · hard

  • A.检测数据分布漂移← 正确答案
  • B.提升模型训练速度
  • C.压缩模型存储空间
  • D.增加特征数量

答案：A。PSI 通过比较实际流量分布与训练基准分布的差异来检测数据漂移，通常超过 0.25 触发告警。它与训练速度、存储、特征数量无直接关系，是 Champion/Challenger 故障防线里的关键一环。

Q7. 新挑战者晋升为冠军后，旧冠军应如何处理？

单选题 · mid

  • A.立即删除释放资源
  • B.保留为历史版本回滚← 正确答案
  • C.继续接收一半流量
  • D.不再监控直接遗忘

答案：B。旧冠军要保留为历史版本，用于快速回滚和版本对比。马上删除等于拆掉安全网；继续接收一半流量的旧冠军会干扰新冠军的主导地位；不再监控也不合理，历史版本同样需要可观测性。

Q8. 多挑战者并行锦标赛制的优势包括？

多选题 · hard

  • A.一次可验证多个候选← 正确答案
  • B.更快筛选最优模型← 正确答案
  • C.完全不消耗线上流量
  • D.分散单挑战者风险← 正确答案

答案：ABD。多挑战者并行可以同时验证多个候选模型，像一个多分支的锦标赛，能更快筛出最优者，也避免了“押注单一挑战者”的集中风险。但它必然消耗线上流量，不可能不产生成本，所以 C 错误。

Q9. 下面哪个是 Champion/Challenger 的正确比喻？

单选题 · easy

  • A.把数据存入单一数据库
  • B.每个月重装一次系统
  • C.拳王与挑战者的卫冕战← 正确答案
  • D.用一台服务器托管全部

答案：C。Champion/Challenger 的精髓正是“卫冕拳王+挑战者”的持续对抗：老模型守擂，新模型攻擂，数据决定腰带归属。其他选项讲的是存储、部署或更新操作，没有体现新旧模型竞争治理的关系。

Q10. 平台化实践还常常需要哪些云能力配合？

多选题 · mid

  • A.模型注册与版本管理← 正确答案
  • B.网关流量按比例路由← 正确答案
  • C.自动扩缩容保障资源← 正确答案
  • D.完全关闭日志监控

答案：ABC。模型注册表管理版本和治理信息，网关负责流量切分，自动扩缩容保障两侧服务的资源弹性，三者共同支撑 Champion/Challenger 稳定运行。关闭监控等于蒙眼比赛，在线服务永远需要日志与指标。