S64：EvalOps 发布生命周期：Offline→Shadow→Canary→Release / Rollback

内容类型：预习教材（不代表已完成）
日期：2027-01-25
阶段：P2 · AI Systems Engineering 90
总路线：Day 154
周次节奏：W10 · 周一概念与阅读
状态：教材已备；学习未完成

一句话定义

AI release lifecycle 是将 model、prompt、retrieval、tool、policy 和 runtime 的组合变更，通过逐步扩大真实度与暴露面的证据链，从离线候选变成可控发布或可恢复回滚。

学习目标

1. 分清 offline eval、shadow、canary、full release 和 rollback 各自能与不能回答的问题。
2. 把一次发布识别为多个 artifact 和配置的 immutable bundle，而不只是模型版本。
3. 为每个阶段定义 evidence、exposure、decision owner、stop signal 和 rollback target。

核心知识

Offline eval 在冻结数据与可重复环境中比较 candidate/baseline，适合检查已知能力、回归、边界例和成本估算。它不能复制真实流量组成、排队、工具不稳定、人类行为或长延迟 outcome。

Shadow mode 把候选路径接到复制的生产输入，但不让其输出影响用户或下游。它能观察真实 input mix、latency、tool compatibility 和 disagreement，但如果没有真实副作用，便无法完全重现可写工具、人类反馈与后续行为。Shadow 还必须遵守数据 purpose、retention 和 provider egress 边界。

Canary 让少量受控流量真正使用 candidate，用 blast radius 换取线上证据。分流不应只靠随机比例；还需考虑 risk tier、tenant、地域、通道、会话粘性和人工支持容量。扩大 canary 前需同时看质量、错误、延迟、成本、拒答、人工升级与安全信号。

Release / rollback 是有 owner 的决定，不是某个指标自动触发的真理。rollback target 应在发布前准备，并包含相容的模型、prompt、索引、tool schema、policy 与 state migration。仅回滚模型可能让旧模型遇到新 prompt 或新 schema，造成第二次故障。

机制与推导

把 release unit 写为：

R = hash(model, adapter, prompt, retriever, index, tool_schema, policy, runtime, eval_set)

阶段暴露可简化为 E_0=0 的 offline、无业务效应的 shadow、0<E_c<1 的 canary 与全量。扩大条件不应是单一平均分，可写成：

promote if quality≥q_min and safety≥s_min and p95≤l_max and unit_cost≤c_max and no critical incident

这些阈值是预先声明的决策辅助，不能消除 judge drift、outcome lag 和样本选择偏差。回滚时还要检查 irreversible side effects 和已写入的 state，因为代码恢复不等于业务影响自动撤销。

最小练习或观察

1. 选一个文档助手或 wallet agent 案例，定义 baseline 与一个单变更 candidate。
2. 画 offline→shadow→canary 1%→10%→release 与每一步的 rollback 箭头。
3. 每阶段填 input、可观测信号、不可观测风险、owner、最长观察时间和 stop condition。
4. 写 release bundle 的最小版本字段和一个与其相容的 rollback bundle。
5. 不运行现有脚本也可完成设计；未观察就不填通过结果。

常见误区与边界

• offline score 较高就跳过 shadow/canary，忽略运行时与人机交互风险。
• shadow 调用真实发送或写入工具，使“影子”实际产生副作用。
• canary 只看全局平均，掩盖高风险群体或长尾故障。
• 回滚只指向旧 model id，没有处理 schema、index、policy 与 state 兼容。
• 本日只建立发布思维，不构成生产发布审批或可靠性认证。

系统 / 金融 / Web3 连接

银行中的 canary 不宜首先暴露高金额、脆弱客户或法定报送。可先在低风险只读摘要上观察，再依人工容量扩大。Web3 agent 的 shadow 可生成交易预览但不请求签名；canary 即使小流量也要限制合约 allowlist、金额、chain id 和过期时间。

自检问题

1. offline、shadow 和 canary 各引入了什么新证据？
2. 为什么 release unit 应超过 model id？
3. shadow 没有用户副作用时，哪些风险仍不可观察？
4. 什么情况下“回滚成功”仍未恢复业务状态？

专业课程对齐

• Full Stack Deep Learning：精读 deployment、testing、monitoring 与 continual learning 相关课题，映射各发布阶段的工程证据。
• MLflow Documentation：精读 tracking、model registry、aliases/tags 和 deployment 边界，用于设计 release bundle 与 baseline/candidate 追溯。
• Google SRE Book：选读 canarying releases、monitoring 和 handling overload，把渐进暴露与 error budget、rollback 联系起来。

深入学习提示

先用 FSDL 建立端到端地图，再用 MLflow 设计版本证据，最后用 SRE 检查扩量和停止。对每个阶段必须写一条“本阶段看不见什么”，这比列更多指标更能阻止证据越级。

学后填写区

• baseline / candidate：
• release bundle 字段：
• 发布路径与每阶段证据：
• stop / rollback 条件：
• 尚不可观测的风险：