S65 · 总 Day 155教材已备 ≠ 学习已完成

S65：最小 Release Record：记录 Candidate、Baseline、Metrics 与 Decision

Release record 是一份不可混淆“发布了什么、与什么比、看到什么、谁在什么假设下做了什么决定”的小型可追溯记录。

2027-01-26

内容类型：预习教材（不代表已完成）
日期：2027-01-26
阶段：P2 · AI Systems Engineering 90
总路线：Day 155
周次节奏：W10 · 周二最小实现
状态：教材已备；学习未完成

一句话定义

Release record 是一份不可混淆“发布了什么、与什么比、看到什么、谁在什么假设下做了什么决定”的小型可追溯记录。

学习目标

设计一个同时适合 JSON 和 Markdown 的最小 release schema。
区分 artifact identity、evaluation evidence、decision rule、decision outcome 和 post-release observation。
使记录支持复现与回滚，但不伪造未运行指标或审批。

核心知识

release record 至少有五组信息。Identity 包含 record id、created_at、owner 和 environment；Baseline/Candidate 包含 model、prompt、retrieval corpus/index、tool schema、policy、runtime 的版本或 hash；Evaluation 包含 dataset/slice version、metric definition、result reference、sample count 和运行环境；Decision 包含 proposed action、actual decision、decision owner、reason、exceptions 和 expiry；Recovery 包含 rollback target、state compatibility、monitoring window 与 stop signals。

指标必须携带定义。accuracy=0.91 没有 dataset version、slice、scorer version、拒答处理与置信范围时几乎无法解释。AI release 还要区分 deterministic metric、LLM-judge metric、human review 与 delayed business outcome，因为它们的证据强度、成本与漂移方式不同。

record 应支持“未执行”状态。当 eval 未运行时，result: null 加 status: planned 比填预期分数更可靠；当决定未做时，decision: pending 不能被 proposed decision 替代。记录不是工作流程引擎，它可引用外部 run、approval 和 incident，而不必将全部数据复制进一个巨大 JSON。

机制与推导

一个最小结构可表达为：

{
  "releaseId": "planned-demo-001",
  "baseline": {"bundleHash": "..."},
  "candidate": {"bundleHash": "...", "change": "prompt-v2"},
  "evidence": [{"runId": null, "status": "planned", "metricSpec": "quality-v1"}],
  "decision": {"status": "pending", "owner": "learning-role"},
  "rollback": {"bundleHash": "...", "compatibility": "to-review"}
}

对比的关键不是存两个分，而是存 delta = candidate - baseline 的定义和不确定性。若质量上升而 p95 与成本变差，record 应并列取舍，而不将它们压成一个综合分。决定与证据分开，使后续能问：当时数据是什么，为何仍选择 promote/hold/rollback？

最小练习或观察

使用虚构 baseline/candidate，只让 candidate 改一项，例如 prompt version。
先写 metric spec：名称、方向、单位、slice、阈值、scorer 和不支持的结论。
生成一份 JSON 或 Markdown record，将所有未运行字段显式设为 planned/null。
用两个场景检查 schema：评估结果冲突；发布后需回滚到相容 bundle。
不要提交、发布或修改现有进度；产出仅是学习用记录示例。

常见误区与边界

只记 candidate model name，忽略 prompt、index、tool 和 policy 也改了。
保存截图或平均分，没有 run id、评分定义和 slice。
把 proposed、approved、deployed 和 observed 混成一个 status。
在未运行时填入预期质量或伪造 approver。
record 只提供追溯结构，不自动保证数据、scorer 或决策正确。

系统 / 金融 / Web3 连接

金融发布记录可将高风险案件、语言、产品与客户类型作为 slices，且把人工覆核容量作为 release constraint。Web3 agent 记录还要锁定 chain id、RPC/provider、contract allowlist、transaction simulation 版本和 signing policy；回滚 model 不能撤销已广播交易，因此要分开软件 rollback 与业务 remediation。

自检问题

baseline/candidate 的最小身份为什么不只是 model id？
metric value 缺少哪些元数据就不可解释？
proposed decision 与 actual decision 为什么要分开？
哪些回滚信息必须在发布前准备？

专业课程对齐

MLflow Documentation：精读 tracking runs、artifacts、model registry、aliases 和 tags，映射 release record 中的 identity/evidence 字段。
Full Stack Deep Learning：精读 experiment management、testing 与 deployment 相关课题，检查从实验到发布的证据丢失点。
OpenTelemetry Documentation：选读 traces、metrics、logs 与 resource attributes，用 correlation/release id 将记录与线上观察关联，不在 record 中复制所有 telemetry。

深入学习提示

先读 MLflow 的实体边界，再用 FSDL 检查端到端生命周期，最后用 OTel 连接发布后证据。练习时重点不是把 schema 做大，而是从一个决策反向问：半年后能否重建当时比较的两个系统、指标定义与决策理由？

学后填写区

release record 路径：
baseline / candidate bundle：
metric specs 与状态：
decision / owner / reason：
rollback 与尚缺证据：