第 13 章：运行完整质量流水线

13.1 准备与执行

代码要求 Python 3.10+，没有第三方运行依赖、真实模型密钥或联网调用。请从仓库根目录执行：

python3 -m unittest discover -s tests -v
python3 -m lab.demo

本版实跑 17 项测试通过。demo 创建 lab/evidence/，保存三份完整比较与 summary.json。它不是只运行三个评分函数：每条任务、每个候选都会进入新的临时工作区，由独立 Python 子进程生成真实响应与文件，再由父进程验收。

lab/data/manifest.json 记录训练资料 6 条、开发 8 条、验收 12 条。正常使用不需要重新生成数据；python3 -m lab.make_data 是维护命令，会重建数据文件及版本清单。修改样本后应正式更新版本说明，不能只靠重算哈希掩盖改变。

13.2 看一份成功比较

下面节选自 prompt_v2 的实际摘要：

{
  "candidate": "prompt_v2",
  "cases": 12,
  "statistics": {
    "paired_groups": 6,
    "difference": 0.25,
    "percentile_interval_95": [0.08333333333333333, 0.4166666666666667],
    "seed": 17,
    "resamples": 2000
  },
  "gate": {"passed": true, "reasons": [], "policy": "fixture-gate-v1"},
  "failure_count": 0
}

这表示请求归一化替身修复了已知的数字提取问题，且满足当前合成验收门槛。报告同时标注没有真实模型调用、隔离不是 OS 沙箱、小样本不是总体研究。展示正区间时不能把这些限制裁掉。

完整报告里的每一行都包含 baseline 和 candidate。选取一条带 Ticket 的文件任务，对照初始配置、指令中的工单号、目标值与两边产物哈希，可以看出究竟修复了什么，而非只读总分。

13.3 看两份失败比较

检索变体的九条失败包含六条新出现的回答回归和三条基线已有的文件失败。不要把 failure_count 直接当作新增回归数。生成器变体十二条任务都没有满足最终任务合同，但一些回复仍通过最低表达检查。

完整 demo 自身应当正常退出，因为它验证了这两个缺陷确实被拒绝。若你删除某个重要评分条件，导致坏候选通过，demo 的断言反而会失败。

13.4 只分析一个候选

python3 -m lab.pipeline --candidate prompt_v2 --split acceptance \
  --output /tmp/quality-prompt.json --require-pass

命令保存完整报告，并把发布决定映射为进程退出状态。将候选改为 retrieval_v2，应该得到报告和退出码 2。把 split 改为 dev，即使修复表现不错，也会被验收范围检查拒绝。

如果报 dataset_hash_mismatch，先核查数据是否被改动，不要立即跳过验证。若候选超时，查看单项 reason 和未知预留，而不是将它改写为普通答案错误。若缺少某个样本 ID，核查清单、过滤与标签完整性。

13.5 改参数应保留比较依据

可以先将预算降到 1，检查所有计划任务仍在报告中、没有消耗被伪造、门槛拒绝不完整配对。再恢复预算，运行原候选，确认先前拒绝没有修改数据或候选状态。

不要为了复制书中的时间戳或 wall_ms 而调程序。真正应稳定的是数据哈希、候选逻辑、样本级判定与固定 seed 下的演示统计。运行环境差异应被记录，而非藏起来。