第 16 章：把评测维护成产品能力
质量交付不会在一次发布之后结束。用户、文档、任务与模型服务会变化，旧样本会过期，评分器也可能暴露新的盲点。一个长期有用的评测系统需要清楚的数据维护、运行与发布责任。
16.1 让失败进入正确的数据阶段
线上问题先保存受控的现场与最小复现，确认授权和隐私处理后进入开发回归。用它修复系统以后，它已经是开发知识，不宜继续称为隐藏验收题。重要能力可以追加新的独立场景作为后续确认。
失败分类应服务下一步动作：标签错就修数据；产物不符合目标就查候选与执行；引用失效就查资料和检索；评分误判就校准验收；预算拒绝就补运行计划。不要把所有问题都变成一句“提示不够强”。
16.2 更新评分器与数据都有迁移成本
当政策事实发生变化，旧报告可能仍然正确描述当时合同，但不再适用于当前业务。应保留时间与版本，明确重评范围。重评旧产物可以帮助研究变化，却不等于旧候选在新世界里已经重新执行成功。
评分器升级也应先跑固定反例与历史产物，解释分数变化。删除一种检查可能让失败减少；新增检查可能让旧报告变差。两者都不应直接归因为模型变化。
16.3 质量系统也有安全与可用性要求
生产化需要持久任务队列、可靠产物存储、访问控制、候选隔离、运行配额、审计与恢复。报告签名与审批身份属于另一层保证，不能由一个 SHA-256 字符串自动提供。
随书代码用单进程、临时目录和合作式候选，适合在个人环境与 CI 里复现列明行为。它没有多节点调度、敌对代码沙箱、认证审查门户或真实费用对账。设计生产服务时，应对这些缺口分别立项，而不是把演示脚本直接开放到公网。
16.4 建立简短而完整的交付包
一次候选交付至少应包含：使用范围与变更说明，数据与参考版本，评分器及候选指纹，完整逐样本比较，统计方法和限制，预算与异常情况，待审和裁决记录，发布门槛与最终决定，以及实际部署和回退配置。
本书自身也沿这条链路交付。Markdown 同时生成网页与 EPUB；校验器逐章比较正文、链接、搜索和代码包；浏览器检查全部章节的手机布局、主题与无 JavaScript 阅读；EPUBCheck 检查格式。它们各有范围，不能用格式通过替代事实或实验审阅。
16.5 一个可以继续扩展的结业任务
选择一个真实但可以合法使用的小场景，建立来源清楚的训练资料、开发与验收切分。先保留确定性基线，再增加一个受控变化。用独立产物证据验收，制作至少三种能骗过旧评分器的反例，保存逐样本配对变化。
接着定义独立单位与估计对象，说明当前数据不足以支持哪些结论；为预算拒绝、超时、未知与人工争议写清停止规则。只有门槛确实能拒绝坏候选，交付包又能解释失败，才允许进入下一阶段真实模型实验。
这项任务的完成标准不是得到一个更高的平均数，而是其他开发者能够重现一次修复、一种回归和一个被正确阻止的发布，并明确知道仍有哪些保证没有建立。