15 篇博文 含有标签「calibration」

候选人在系统设计题上卡住了，停顿了两秒说：“我直接写个提示词（Prompt）就行。”你资历最深的面试官写下：强烈推荐录用——这正是 2026 年优秀工程师的工作方式。你资历第二深的面试官写下：不予录用——把问题丢给聊天机器人不叫工程。同样的五个字，同样的 40 分钟面试，同一张评分表上出现了 40 分的巨大差距。

候选人并没有搞砸你的面试环（Interview Loop），是你的面试环缺乏明确的观点。复盘会中最糟糕的部分不是分歧，而是每个面试官都如此确信自己的判断是正确的，以至于会议演变成了对 AI 本身的立场投票，而不是讨论这个人是否具备交付能力。

就在你发布提示词（prompt）更改的同一周，所有评估类别的得分都提升了 6 个百分点。团队成员将其视为改动奏效的证明。三周后，有人注意到这种提升也出现在了提示词更改绝不可能触及的类别中——这是一个你专门用来检测此类情况的对照组——而且这种提升是均匀分布的，而真正的产品改进绝不会呈现出这种形态。评审模型在某个周二以相同的终端节点（endpoint）名称发布了。在你的系统变动之前，你的分数就已经变了。

这种失效模式对“大模型作为评审员”（LLM-as-a-judge）评估流水线的破坏，比文献中警告过的任何失效模式都要更隐蔽。不是偏见，不是位置效应，也不是自我偏好——这些是评审员在特定时间点的属性，你的评估设计可能已经考虑到了这些因素。真正让你栽跟头的是评审员在你没注意的时候发生了变化，而你的终端节点名称、评估代码和仪表板都在声称一切如常。测量单位在一个稳定的标签下发生了偏移。跨越迁移边界的每一次比较现在都被混淆了，你无法将差值分解为“我们的系统改进了”和“尺子的标准变宽松了”，因为你从未构建过能进行这种分解的工具。

你的综合评估分数在上个季度上升了两个百分点。没人能告诉你这究竟是系统变好了，是打分的人类群体变得更宽松了，还是你在三月份升级的评判模型开始以不同的权重衡量文本的冗长程度。数字变动了。但该数字旨在衡量的事物并不一定随之变动。

当一个评估准则同时被两个群体——人类和 LLM 评判者——阅读时，就会发生这种情况，而且这两个群体的漂移轴线和原因各不相同。综合分数将两者的运动混合在一起，除非你有一套测量方案能在其中一个变动时保持另一个固定，否则你发布的指标，其变化是无法归因于任何因素的。

你教会了 Agent 在上下文不足时说"我不知道",然后把这当成一次安全胜利。OpenAI 账单确实降了。所有人都同意这是负责任的做法。三个月后,你的客服 VP 在追问为什么人头预算偏差 40%,AI 团队里没人答得上来——因为你跟踪的指标是弃答率,而真正动起来的指标是每周工单数,而那条把它们加起来的曲线没有任何 owner。

这就是弃答税。它不是一种模型成本。它不会出现在推理账单上。它出现在下游:出现在每接住一句"我无法回答"就要排队处理的人工团队队列深度里,出现在针对人工额外补足后的上下文再跑一次的第二次模型调用里,出现在等待期间流失掉的客户身上。只看模型成本的那张账面,悄悄把它藏了起来。再加上 AI 团队负责弃答、运营团队负责队列的那道组织接缝,意味着没有人有动力去看清这件事。

你想要表现得诚实。你在智能体给出的每个答案旁边都标上了一个小小的 92%。当智能体第三次以 92% 的置信度给出错误答案后，你的用户就不再看那个数字了。他们并没有因此生气。他们只是学会了——就像人类在面对失灵信号时总会学到的那样——仪表盘上的指针并没有连接到引擎。数字还在那里。生成它需要消耗你的 token。但它不再能为任何人的决策提供参考。

这种失败模式是置信度校准（calibration）UX 研究不断重现的：呈现概率是一种信任承诺，而且这种承诺是单向的。一旦数字在用户的使用体验中被证明与正确性无关，这个分数就失去了意义——你为了展示它而投入的信任也随之崩塌。你无法在事后通过修正数字来挽回局面。这个数字现在只是个装饰品。

在每个 AI 功能的演进过程中，审阅者总会提出一个听起来很合理的问题：“我们能不能让模型告诉我们它的置信度（confidence），这样我们就可以把低置信度的回答路由给人工或备选方案？”这听起来像是一份免费保险。你在输出 schema 中添加一个 confidence 字段，模型尽职尽责地填好它，现在你就有了一个可以调节的旋钮。发布吧。

那个旋钮并不是免费的，更糟糕的是，它通常没有连接到任何实际逻辑上。置信度数字只是模型乐于生成的一个 token 序列，模型并没有义务让它具有实际意义。团队支付真实的 token 和延迟来获取它，却从不检查它是否与正确性相关，然后根据它路由生产环境的流量，就好像 “0.9” 真的代表 90% 的可靠性评估一样。它就像一个用螺栓固定在仪表盘上的压力表，但玻璃后面其实什么也没连。

这篇文章讨论了两个没人定价的成本：生成置信度字段本身的单次请求税，以及信任一个未校准的数字来做路由决策所带来的更巨大的成本。

GPT-4 在用自身置信度评分区分正确答案与错误答案时，AUROC 仅约为 62%——这几乎与随机猜测（50%）相差无几。无论正确与否，模型的表达都同样自信流畅。如果你构建的生产系统默认高置信度响应是可靠的，那你实际上在依赖一个近乎随机的信号。

这就是知识边界信号问题，它处于绝大多数真实 LLM 质量故障的核心。模型不知道自己不知道什么——更准确地说，它内部其实知道，却无法可靠地表达出来。工程挑战不在于让模型拒绝得更多，而在于设计能将不确定性转化为可操作信号的系统，同时又不让产品体验显得残缺。

LLM-as-judge 是解放生产力的关键，它让评估覆盖率在不增加人工评分团队的情况下扩大了 10 倍。问题在于，这种解放效果在评分范围内并非均匀分布。裁判与人类的一致性在分布的“模糊中间地带”（muddy middle）最高——即那些没人会去纠结的答案——而在决定功能是发布、回滚还是在凌晨两点触发告警的关键长尾输出上，这种一致性会发生崩溃。在没人满意的评分范围内，仪表盘上的图表却始终保持绿色。

这就是 LLM 裁判的天花板：一种具有非均匀误差分布的测量工具，而团队却将其解读为一个单一的数字。与人类 80% 的总体一致性是大多数供应商在页面上打出的标题；这同时也是让团队在裁判信息量最低的地方最信任裁判的数字。

你的模型可以拥有一种能力，在关键时刻，这种能力比你发布的任何其他行为升级都更有价值：能够说“我没有可靠的答案”并且是认真的。不是那种基于关键词匹配的安全拒绝。也不是模型在处理争议性话题时，从 RLHF 中学到的那种模棱两可的坏习惯 (hedging tic)。而是真正的能力——一种经过校准的弃权 (calibrated abstention)，仅当且仅当模型的内部证据不支持生成自信的回答时才会触发。

你永远不会偶然获得这种能力。LLM 技术栈中的每一个默认设置都在反向推动。

一个回归告警在周一早晨响了。你的留出评估集的忠实度（Faithfulness）在周末从 0.86 掉到了 0.78。没人发布新模型，没人动过提示词，也没人改过检索索引。值班工程师花了三个小时排查才发现，唯一改变的是裁判模型——自动评估器静默滚动到了一个更新的快照，它捕捉到了旧版本放过的细微委婉语。同样的答案，同样的模型，更低的分数。真实的数字，虚假的回归。

这就是评估困境：随着你的 LLM-as-judge（以 LLM 作为裁判）变得更敏锐，你在固定系统上的得分会下滑，而那个本应检测回归的仪表盘开始制造回归。没注意到这一点的团队会花上几个季度去追逐完全存在于“尺子”里的“质量偏移”。

大多数生产环境中的 AI 功能在发布时只带有一个置信度阈值。在阈值之上，模型给出回答；在阈值之下，用户会得到一句生硬的“我不确定”。这个单一的数值同时承担着两个完全不同的任务，这就是为什么即便你对已回答查询的准确率看起来不错，但信任度指标却已经连续两个季度下滑的原因。

正确的设计至少应该有两个切分点。一个“弃权”（abstain）阈值设在低位：低于该值时，模型拒绝回答，因为此时保持沉默比给出任何答案都更有价值。一个“升级”（escalate）阈值设在中间：在两个切分点之间，系统将案例交给人工审核员，而不是直接将其丢弃。将它们合并成一个刻度盘，你发布的产品在出错时和不确定时会让人感到同样无用——在用户只需打开另一个标签页就能找到免费替代品的市场中，这是最糟糕的处境。

这并不是什么新鲜想法。拒绝选项分类器（reject-option classifier）的文献自 20 世纪 70 年代以来就一直在主张拆分阈值，将“歧义”拒绝（输入介于已知类别之间）与“距离”拒绝（输入远离任何训练数据）区分开来。生产环境中的 AI 团队总是在以惨痛的方式重新学习这一教训，通常是在首次发布大约六个月后，当支持队列中挤满了询问“这玩意儿是坏了还是怎么了”的人时。

一个团队发布了一次提示词重构（prompt refactor）。离线评估显示准确率提高了三个百分点。产品经理（PM）在 Slack 上发布了图表。两周后，支持工单激增，出现了一个没有任何仪表盘记录的模式：用户信任了他们不该信任的答案，并据此采取了行动，结果蒙受了损失。模型比以前更准确了，但对模型的信任却变差了。

这就是“校准崩溃”（calibration collapse）。模型的置信度不再与其错误率相匹配，但由于准确率数字上升了，团队认为他们发布了一个成功的更新。其实不然。他们发布的是一个更加“自信地犯错”的系统，而用户——他们是根据模型的语气（含糊表达、确定性、拒绝回答）而不是他们从未见过的准确率数字来校准信任的——现在在那些被误导后果最严重的查询中被误导了。

准确率（Accuracy）和校准（Calibration）是独立的维度。你可以改变其中一个而不影响另一个。你可以在提高一个的同时摧毁另一个。大多数团队只测量第一个维度并以此为基准发布产品，而大语言模型（LLM）系统中的大多数生产事故都发生在第二个维度上。