2. 基础知识

在进入基准模型与Challenger的对照验证实战之前，必须先建立一套共同语言。很多团队在验证阶段出现争议，并非模型本身有问题，而是对“基准”“Challenger”“对照”“显著性”等术语理解不一致，导致结论无法对齐。本节把后续章节反复使用的概念一次性讲清楚，并给出典型应用场景，帮助你判断什么时候该做对照验证、做到什么程度才算有效。

一、核心概念：基准模型与Challenger

基准模型（Baseline Model）是当前正在生产环境运行、被组织认可为“默认正确”的模型版本。它不一定是最优模型，但一定是当前业务决策、报表口径、风控策略所依赖的参照物。基准模型的核心价值在于“稳定性”和“可解释性”，它是所有变更的起点。

Challenger模型是候选替代方案，通常由新算法、新特征、新训练数据或新超参数产生。Challenger的使命是证明自己比基准更好，或者至少在某些关键指标上不劣于基准。它不直接上线，而是先进入对照验证流程。

两者之间的关系不是“新旧”关系，而是“参照与被检验”的关系。一个Challenger可能来自不同团队、不同技术栈，甚至不同业务假设。对照验证的本质，是在同一评价框架下，用可复现的方式回答一个问题：替换基准后，业务结果会变好、变坏，还是不变？

二、常见术语与指标口径

对照验证涉及大量术语，以下清单按“数据—模型—评估—决策”四层组织，建议在项目启动会上逐项对齐口径。

其中最容易混淆的是“主指标”与“护栏指标”。主指标决定“要不要换”，护栏指标决定“能不能换”。例如推荐场景中，主指标可能是点击率，但护栏指标必须包含推理延迟和内容多样性；如果点击率提升但延迟翻倍，替换决策通常会被否决。

三、方法流程：对照验证的标准步骤

对照验证不是一次性跑分，而是一个闭环流程。标准步骤可归纳为六步：

1. 定义目标与假设：明确要验证的业务假设，例如“新特征能提升风控KS至少0.02”。
2. 冻结基准：固定基准模型版本、特征版本、预处理逻辑，记录版本号与哈希。
3. 样本对齐与切分：按时间或用户维度切分，确保两者评估样本完全一致。
4. 并行推理：基准与Challenger在同一批样本上分别输出预测结果。
5. 指标计算与显著性检验：计算主指标、护栏指标，并做置信区间或假设检验。
6. 决策与归档：根据预设阈值决定替换、回退或继续观察，并归档全部配置与日志。

以下是一个典型的对照验证配置片段，用于记录基准与Challenger的版本信息：

validation:
  window: "2024-05-01 ~ 2024-05-31"
  baseline:
    model_id: "risk_baseline_v3.2"
    feature_set: "fs_20240415"
    hash: "a1b2c3d4"
  challenger:
    model_id: "risk_challenger_v4.0"
    feature_set: "fs_20240510"
    hash: "e5f6g7h8"
  metrics:
    primary: "ks"
    guardrails: ["latency_p99", "psi", "fairness_gap"]
  decision:
    min_improvement: 0.02
    max_latency_ms: 120

这段配置的价值在于“可复现”。任何一次对照验证，只要保留这份配置和对应日志，就能在数月后重新还原结论。缺少版本记录的验证，等于没有验证。

四、应用场景与常见误区

对照验证适用于以下典型场景：

• 模型迭代上线：新版本替换旧版本前的强制关卡。
• 特征工程变更：新增或替换特征后，验证是否带来真实增益。
• 算法切换：从逻辑回归切换到梯度提升树或深度学习模型。
• 供应商选型：对比自研模型与第三方模型的效果与成本。
• 策略调优：风控阈值、推荐权重等业务策略调整。

复盘时建议追问三个问题：验证窗口是否覆盖完整业务周期？主指标与护栏指标是否都达标？结论是否可被独立复现？如果三个问题都能给出肯定回答，对照验证才算真正完成。