不确定性统计——测试运行是样本，不是判决
prompt 程序的输出是从某个分布里抽出的一个样本，所以单次运行无论成功还是失败都证明不了什么。主流做法把每一次评测都当作一个采样问题来处理：
- n 次运行打分：每个 golden case 跑 3–5 次；报告通过率（pass rate）或 pass@k（"在 k 次尝试里至少成功一次"——适用于生产环境里存在重试循环的场景；没有重试循环就用朴素的通过率）。Agent 按轨迹（trajectory）享受同样的处理——任务完成率，附带置信区间。
- 先显著，后报警：只有跌破一个噪声阈值（例如通过率下降超过 5 个百分点，或做一次二项检验）才宣布出现回归——否则 CI 会为采样噪声狼来了，团队学会的就是无视它。
- 方差本身就是一个指标：两个均值质量相同但方差不同的 prompt 并不等价——方差更大的那个尾部表现更差。要跟踪离散度，不能只看中心值。
- 能确定性就用确定性：为了让确定性的打分器好用，用 temperature 0 / 固定种子；但不要伪造出生产路径根本不具备的稳定性——如果生产环境跑在 temperature 0.7，评测也该在 0.7 上跑，并用统计方法处理。
记录在案的坑：双重随机采样——一个随机的系统被一个随机的裁判打分。这正是 scorer-panel 要限制 LLM 裁判占比、并要求裁判做校准的原因；当两层都是随机的，n 必须在两边同时提高，否则那些数字只是摆设。
与 um 的关系： um 目前跑的是单次审计——每一轮一个生成器抽样、一个审计者抽样。观察到的"审计者深度方差"（一个审计者能抓住的问题，另外两个同级的都放过了）正是这篇笔记讲的现象换了个名字；um 目前的修法是结构性的（多审计者小组、按履历记分），而不是统计性的（n 次运行）。两者都有效，统计方法每单位置信度更便宜，小组能抓到质地不同的疏漏。成熟的技术栈两者都要用。
来源：evals 主流实践（pass@k 惯例、评测框架文档，2026-07 现状核查）