S69：可选 Champion / Challenger 探索：小范围比较与发布科学

内容类型：预习教材（不代表已完成）
日期：2027-01-30
阶段：P2 · AI Systems Engineering 90
总路线：Day 159
周次节奏：W10 · 周六可选探索 / 补学
状态：教材已备；学习未完成

一句话定义

Champion/challenger 是让当前可用基线与一个变更明确的挑战者，在同一协议下累积可比较证据，而不是为新版本寻找一个必胜分数。

学习目标

1. 设计一次仅改变 prompt、retriever、model 或 policy 之一的小型比较。
2. 区分 champion 的生产地位、challenger 的证据地位与决定地位。
3. 设置明确停止点，只产出一条观察，不扩展为长周期调参。

核心知识

champion 不代表全面最优，只表示当前承担特定流量与责任的基线。challenger 也不一定是新模型：它可是新 prompt、不同 retrieval cutoff、新 tool routing、更严格 policy 或不同 human-review presentation。比较前应写变更假设，例如“证据优先 prompt 将减少无引用结论，但可能提高拒答和输出 token”。

比较方式有三种学习层级：offline paired使用同一组冻结样本；shadow paired使用同一真实输入的副本，但 challenger 无副作用；limited canary将少量真实流量交给 challenger。本日只需 offline 设计或本地 toy run，不授权部署和生产实验。

一次比较应保留 sample-level output，而不只保留 summary。总体平均可能隐藏三类重要样本：challenger 独有胜出、独有严重失败、两者同错。第三类尤其提醒我们：替换版本无法修复数据或任务定义本身的缺口。

机制与推导

对每个样本记 outcome ∈ {champion_win, tie, challenger_win, both_fail, scorer_error}。对多指标不必迫使用一个总分，而可先用 hard constraints：

eligible(challenger) = no_critical_regression and p95≤budget and cost≤budget

再观察 quality delta、coverage 和 uncertainty。若 challenger 不 eligible，不代表想法永久错误，只表示当前 bundle 与证据不支持 promote。同样，offline eligible 也不等于可直接 full release。

最小练习或观察

1. 选一个已熟悉的小案例，写 champion bundle 和仅一项变更的 challenger bundle。
2. 预先写一个主改善、一个可能回归、一个资源变化和一个不能被本比较证明的主张。
3. 用 5～10 个现有或合成样本设计 paired table；可只设计，不必运行。
4. 若运行，保存配置和逐样本结果；若未运行，将结果列留空。
5. 45 分钟或一条观察即停止，不因 challenger 未胜出就连续改 prompt。

常见误区与边界

• champion 与 challenger 使用不同数据、解码、tool availability 或 scorer，却声称单变量。
• 一直改 challenger 直到通过同一评估集，导致评估过拟合。
• 只保留总分，没有 both-fail 和严重回归样本。
• offline 胜出就使用“新 champion”措辞，跳过发布决定与线上证据。
• 本日是可选学习，不执行也不影响课程连续性。

系统 / 金融 / Web3 连接

金融文档案例可让 champion 用当前证据格式，challenger 只增加“每个结论必须引用 source id”，观察引用正确与拒答的取舍。Web3 可比较两个交易预览模板，但工具保持为只读 simulation，不请求签名或广播。

自检问题

1. champion 为什么不等于理论最优？
2. challenger 的变更假设应包含哪三类预测？
3. both-fail 样本为什么比简单 tie 更值得研究？
4. offline eligible 与可发布之间还缺什么？

专业课程对齐

• MLflow Documentation：精读 experiment tracking、model registry 与 aliases，学习如何保存比较身份与逐次运行证据。
• Full Stack Deep Learning：精读 experiment management、testing 与 deployment，映射 offline experiment 与 production decision 的分界。
• Google SRE Book：选读 canarying releases 与 monitoring，理解 challenger 进入真实暴露后的 stop/rollback 要求。

深入学习提示

先用 MLflow 思路确保比较可追溯，再用 FSDL 检查评估设计，SRE 只用于想象下一阶段的运行边界。当比较结果不清晰时，优先保留“当前证据不足”，不加运行或改指标追求胜者。

学后填写区

• champion / challenger 唯一差异：
• 预测的改善、回归与资源变化：
• 实际观察（未运行留空）：
• 不能外推的结论：
• 停止理由：