在生产环境里测量校准度

步骤 1先定下「结果」，再定指标。

校准度是「系统发出的一个数字」与「后来被证明为真的某件事」之间的比较。在离线评测里，后半截是免费的——你有标签。在生产环境里，你必须提名一个可观测事件并为它辩护，而这个提名决定了下游的一切。按可信程度排序：

• 一次确定性检查。SQL 跑通了、schema 校验通过了、测试过了、发票总额对上了。无偏、便宜、每一条都有——而它只在少数任务上存在。
• 一次人类编辑或回退。复核者改了草稿、回退了提交、推翻了分类。覆盖面广，但它是删失的：它只观测到人类看过的那些条目，而置信度徽章的全部意义，恰恰是让人类不再去看其中一部分。只用回退来算校准度，你量到的正是徽章没有在起作用的地方。
• 一个延迟的业务事件。客户重开了工单、这笔付款被拒付了、这个预约没人来。最接近你真正关心的东西，而延迟是以周计的，所以它无法闭合你的发布回路。

务实的答案是一条刻意保留的采样分支：把一个固定的小比例——通常 2–5% 就够——无论置信度说了什么都送去完整的人工复核，并在这条分支上计算校准度。它要花真金白银，而它是唯一一个不是「非随机缺失」的标签来源。其余一切都只是补充。这条分支也是让 在线评测 与你的离线数字可比、而不是「同名的另一个量」的东西。

步骤 2换一个自由参数，ECE 就会动。

期望校准误差是默认的头条指标：按置信度把条目分箱，取每个箱里「平均置信度」与「实测准确率」之差，按箱内条目数加权。它好算，而它有一个性质让它作为被跟踪的指标变得危险——分箱数量由你来选，而答案取决于它。

下面是一千条样本，按界面展示出来的置信度分组。这些值挤在整数上，因为模型口头报出的置信度就是这样：它报的是 90%、95% 和「确定」，而不是 0.873。

# 1,000 production items, grouped by displayed confidence
#   conf    n     accuracy    gap (conf - acc)
    0.70    80      0.65         +0.05
    0.80   140      0.72         +0.08
    0.90   300      0.78         +0.12
    0.95   280      0.99         -0.04
    1.00   200      0.74         +0.26

# Same data, two defensible bin counts:
  ECE, 10 equal-width bins .......... 0.092
  ECE, 20 equal-width bins .......... 0.114     (+24.3%)

# Why: at 10 bins, 0.95 and 1.00 share the top bin, where
# 280 under-confident items cancel 200 over-confident ones:
  merged bin: n=480, mean conf 0.971, accuracy 0.886

这个机制值得直说，因为它既不是噪声也不是抽样误差。ECE 对每个箱取绝对值，所以一个把「过度自信的一组」与「过度保守的一组」合并进去的箱，会把它们的相互抵消报告成校准良好。选十个箱，你量表的顶端就比它实际的样子好 24%。这件事不需要任何人心存恶意就会发生；十，正是约定俗成的默认值。

两个推论。第一，除非双方都说明了分箱方式，否则绝不要把一个 ECE 数字与别处算出的 ECE 相比——供应商的 ECE 与你的 ECE 不是同一次测量。第二，如果你要长期跟踪 ECE，就把分箱数量在代码里冻住，并把改动它当成一次指标迁移来对待，纪律与 改动评测集 相同。

步骤 3跟踪 Brier 的 reliability 项，因为平方不会相互抵消。

Brier 分数——预测概率与二值结果之差的均方——没有分箱参数，而它可以分解成三项，每一项都在叫你去修一件不同的事。在同样这一千条上：

# Brier = reliability - resolution + uncertainty
  reliability ....... 0.0194    miscalibration: how far conf is from acc
  resolution ........ 0.0135    discrimination: how far bands are from base rate
  uncertainty ....... 0.1527    irreducible: base_rate * (1 - base_rate)
  ------------------------------
  Brier ............. 0.1585    base rate (overall accuracy) 0.812

# Where the miscalibration lives: contribution to reliability
  conf 1.00 band (200 items, 20% of volume) ..... 70% of reliability

每一项回答一个独立的问题。reliability 就是校准度本身——当你展示的数字与实测准确率吻合时它会下降，而它正是一次重新校准所能修好的那一项。resolution 是区分力——当你的置信度档位真的能把容易的条目与困难的条目分开时它会上升，而它是「更好的模型」或「更好的信号」所修的那一项。uncertainty 是任务基准率的属性，你根本动不了它；这也是为什么原始的 Brier 分数在不同任务类型之间不可比。

要把 reliability 而不是 ECE 当成被跟踪的数字，理由就在上面那道算术里：它对每一个预测值取平方，所以符号相反的误差是相加而不是抵消。这也是它能把这里真正要紧的发现浮出水面的原因——总校准误差的 70% 坐在系统自称「确定」的那 20% 条目上。任何分箱数量下的 ECE 都不会告诉你这件事；它是一个按档位计的量，你必须按档位去报。

步骤 4按档位报带符号的偏差，并把它读成一份复核预算。

一个合计数字会藏住方向，而方向决定修法：过度自信需要加摩擦，过度保守需要减摩擦。请报带符号的平均偏差（这里整体是 +0.092），并按档位、按任务类别分别报，因为合计值是两个相反问题的加权平均。

这张档位表还会告诉你复核者的注意力正被浪费在哪里，而这是运维负责人真正会据此行动的那一版报告。取 STEP 2 里最高的两档：

• 0.95 档：280 条，准确率 99%——2.8 个错误。全量复核它的代价是每找出一个缺陷要读 100 次。
• 1.00 档：200 条，准确率 74%——52 个错误。全量复核它的代价是每个缺陷 3.8 次，效率高 26 倍。

几乎每个产品做的都是反过来的事，因为被标上「确定」的那一档，正是界面压制确认步骤的那一档。这种倒置不是复核者的纪律问题，而是由展示层制造出来的。信任侧的论证在 为信任而设计，而那道吞吐量算术——错配的复核会在抵达真正需要它的那一步之前就把预算耗尽——在 监督容量。

在相信其中任何一个数字之前，先分段。一条覆盖全部流量的校准曲线可以看起来漂亮，而它里面的每一段都在往相反方向严重失准；这就是普通的聚合陷阱，而要紧的分段是任务类别、输入语言、租户与模型版本。如果你已经有了 失败分类与分诊 里的那套分类法，任务类别就是免费的。

步骤 5去校准展示层，而不是模型。

你不需要重新训练任何东西来修 reliability。你需要的是一个从原始信号到展示数字的单调映射，用你那条采样分支上记录下来的数据对去拟合——有几千条带标签条目时用保序回归，只有几百条时用 Platt 缩放。在留出数据上拟合它、给它一个与模型并列的版本号，并在模型或提示词任一改变时重新拟合，因为一次校准只对它所拟合的那个系统有效。请把「未固定的供应商默认值」视为使这次校准失效的事件：见 未固定的供应商默认值。

然后再决定界面上到底显示什么——这与你算出了什么是两个独立的决定。三种状态几乎总是胜过一个百分比，而真正有用的那第三种状态，正是大多数产品省掉的那一个：

• 查过了，而且成立——一个校验器跑了并且通过了。背后是实质依据，而不是模型对自己的看法。
• 查过了，但不成立——校验器跑了但失败了，或者引文并不支持那个论断。
• 没查——这一条没有可用的校验器，或者校验器自己出错了。这就是会被悄悄塞进另外两种状态里的那一个，而这种塞法，正是一个徽章开始说谎的方式。

TruffleHog 的结果模型正是这个区分的干净实现——verified、unverified、unknown，其中 unknown 的意思是「校验本身失败了」，而不是「这个发现被驳回了」。它是一个安全工具而不是智能体界面，而它仍然是「诚实的置信度展示」现有最好的参照——因为那个团队被迫明确说出自己查了什么、又没查什么。

步骤 6一个校准度监控该为什么事呼人。

校准度会在没有任何东西损坏的情况下漂移：输入构成变了、一个带着更难文档的租户上线了、某个供应商改了一个默认值。所以监控不是可选的，而它应当对四件事告警——其中三件根本不是校准度数字。

• 最高档位的带符号偏差越过一个由复核预算、而不是由一个整数定出的阈值。这一个对应的是「用户正在被误导」。
• 标签覆盖率下降。如果采样分支停止产出标签——复核者积压了、队列被改路了、某个开关被关了——下游的每一个校准数字都会悄悄冻结在它最后一个好值上。请为标签的缺席告警，就像 监控完整性 为一条合成发现的缺席告警那样。
• 展示置信度自身的分布偏移。如果落在最高档的条目占比跳了，说明上游有东西变了，而你拟合好的映射此刻正被用在它拟合范围之外。
• 校准的年龄。一个针对已不再服务的模型版本拟合出的映射，是一项过期的控制措施。请为这个不匹配呼人，而不是为它产出的数字呼人。

要避开的陷阱是「在滚动窗口上自动重新拟合」。如果标签是非随机缺失的——而在任何「压制复核」的策略下它就是——那么一次夜间重拟合会向着「人类恰好还在看的那些条目」的置信度分布收敛，而那个分布正在偏离徽章被展示给的那个总体。请只在采样分支上、刻意地重新拟合，并把这次改动当成一次模型改动来评审。