9 篇博文 含有标签「calibration」

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）系统中的大多数生产事故都发生在第二个维度上。

一个用户询问你的助手，“我该如何杀死一个挂起的 Python 进程？”结果收到了一个关于暴力的礼貌拒绝。另一个用户问，“谁获得了 2003 年诺贝尔物理学奖？”结果得到了一个自信编造的名字。这两个回答都来自同一个模型，都通过了你的安全审核，并且到周一都会出现在你的支持收件箱里。令人沮丧的是，这并不是两个独立的故障，也不是两个独立的修复方案。它们是同一个失败：你的模型被训练成识别拒绝模板，而不是识别它实际上不应该回答的内容。

整个行业花了三年时间让模型拒绝违反政策的请求。但几乎没有花时间教它们拒绝那些无法可靠回答的问题。结果是拒绝能力的方向出现了偏差：在表面模式（如 “kill”、“exploit”、“bypass”）上得到了大量强化，但在认知状态（如 “我不知道那是谁”）上几乎没有训练。当你只优化一个方向时，你得到的模型会对错误的问题说“不”，同时对错误的问题说“是”，而且通常发生在同一次对话中。

在生产环境的 AI 部署中，有一种模式反复出现，与用户直觉背道而驰。当模型说"我不确定"时，用户倾向于再次核查；当模型自信地给出答案时，用户则倾向于信任它。问题在于，前沿大语言模型恰恰在最可能出错的领域表现得最为自信。

这并非边缘失效模式。当被要求生成估算任务的 99% 置信区间时，模型实际覆盖真实值的比例仅约为 65%。主要生产模型的预期校准误差（ECE）从 0.108 到 0.726 不等——存在显著的错误校准，且在医疗、法律、金融等高风险垂直领域可量化地更差。危险之处不在于不准确本身，而在于这种倒置关系：同样的模型在通用知识任务上表现出合理的校准，却在错误代价最高的任务上变得自信而系统性地出错。

你的模型说“我非常有信心”，但 40% 的时间都是错的。这不叫幻觉——这是校准失败，而且在生产环境中，这是一个更难检测、衡量和修复的问题。

幻觉占据了所有媒体头条。但过度自信的错误答案往往更危险：模型以极高的表达置信度生成一个看似合理、流利的回答，而下游消费者完全收不到任何异常信号。幻觉检测器、RAG 依据性检查和事实核查流水线都有助于处理凭空捏造的内容。但对于模型知道事实却对其确定性存在系统性错误校准的情况，这些手段几乎无能为力。

大多数发布基于 LLM 功能的团队都将置信度视为事后才考虑的事情。这篇文章将探讨为什么校准会失败、如何衡量它，以及在生产环境中真正能改善这一指标的设计模式。