在线评估——上线后运行的测试套件
离线评估采样的是一个冻结的分布；生产环境才是那个活的分布。主流的部署后这一层由三部分组成：
- 影子/金丝雀发布（Shadow / canary rollout）。 改动过的 prompt 先跑在影子模式（在真实流量上执行，输出被记录但不展示给用户），或者金丝雀模式（面向 5% 的用户），在全量上线之前用线上指标与在位者（incumbent）比较。离线评估赢得的是"可以上线"的资格；金丝雀赢得的是"可以留下"的资格。
- 抽样在线打分 + 漂移告警。 生产输出中 1%–10% 会被 scorer-panel 的裁判异步打分；这个分数会变成一条被监控的时间序列。一旦趋势出现断裂就触发告警——这是唯一能探测到供应商悄悄换底层模型这种失效模式的烟雾报警器：你的 prompt 没变，但它底下的模型变了。分数的绝对值仍然不重要，重要的是导数。
- 隐式信号反馈。 显式评分既稀疏又有偏；诚实的信号是行为性的：用户有没有复制输出、在使用前编辑了多少（编辑距离 ≈ 质量的反指标）、重试率、放弃率。这些信号会同时回流为监控数据和 golden-set 的更新素材。
与 um 的关系： 这一层对应 um 的 T4——竞技场本身——只有一处结构性差异：um 的"生产指标"是平台裁判的输出（留存、回复、平台期信号）流入 ledger 的 metric 组件，它对应金丝雀的机制是分阶段的信任阶梯（dry-run → 逐个 artifact 审批 → 自动）。um 可以整段搬过去用的东西是：漂移告警——对软裁判分数（mid_score、register 标记）做一条时间序列，这既能捕捉平台情绪的变化，也能捕捉 machine 自身子 agent 之下悄悄发生的模型更换。主流可以从 um 这边学到的东西是：把隐式信号绑定到内容寻址的 artifact 上，让反馈可以可证地指向精确上线的那些字节。
来源：evals 主流实践（canary/shadow 惯例、在线打分 + 漂移监控，2026-07 现状核查）