第 1 章：先写发布决定，再选择指标

1.1 把发布对象拆开

一个 AI 应用版本至少包含代码、提示模板、模型标识与参数、检索配置、数据快照、工具权限和评分器。只保存模型名字，无法解释为什么同一个名字在两次运行中得出不同结果。供应商服务可能变化，索引也可能在后台更新。

发布记录应能够回答：这次比较的是哪两个完整配置？哪个字段发生变化？哪些外部状态没有被固定？如果变更同时包含新模型、新提示和新文档，就只能评估整体结果，不能凭总分把收益归功于其中一个因素。

随书报告保存候选脚本哈希、流水线哈希、数据与答案哈希、候选 ID 和变更位置。它没有提供真实供应商快照保证；这个缺口必须在接入真实系统时补上。

1.2 四种不同的结论

一次结果可以支持“修复了已知反例”“没有发现指定回归”“在这组样本上平均提高”，也可能为更广使用范围提供统计证据。这几句话的强度不同。修复一个反例并不证明整个产品改善；未检出回归也不代表风险为零。

本书小实验主要支持前两类结论，并演示第三类的计算。它没有代表性业务样本，因此不会把区间下界大于零解释为真实用户总体必然获益。NIST AI RMF 的测量功能强调评测上下文、方法、限制与不确定性；它不是一张通过某个分数即可取得的认证证书。[S1]

1.3 先规定什么会阻止发布

可以把门槛分成三部分。第一部分是不可被平均值抵消的约束，例如修改了保护文件。第二部分是样本与运行完整性，例如有未执行样本、未知消耗或未解决争议。第三部分才是允许的任务质量变化与不确定区间。

本实验采用保守的样本级规则：新出现的任务或表达合同回归会阻止发布；候选安全失败、未完成配对、待审样本也会阻止发布；按项目计算的区间下界不能低于演示用的 -0.05。这个数字是教学政策，不是通用业务标准。

门槛允许与基线保持相当的版本，不要求每次发布都严格提高。安全修补、依赖升级或运维简化也可能有价值，条件是其质量代价满足事先约定。相反，平均分提高不能豁免明确的越权或重要功能损失。

1.4 决定也需要责任人

自动流水线负责按固定规则计算，业务负责人决定范围与风险容忍度，数据与评分维护者解释证据缺口。三种责任不能全部交给一个模型裁判。人工例外若被允许，应记录批准人、理由、影响范围与到期时间，不能通过临时改阈值让旧报告看似通过。

练习。 选择一次你最近做过的提示或检索更新，写出发布对象、候选变更、两项不可平均的约束、一个可接受退化范围和回退版本。先不要写“准确率越高越好”；明确哪一种失败会真正伤害使用者。