加载中...
加载中...
置信度校准检查的是「模型说 90% 确定时是否真对了 90%」——GPT-4 在 RLHF 之后 ECE 从 0.007 涨到 0.074,语义熵把幻觉检测 AUROC 拉到 0.790,而推理模型在无解问题上比非推理模型平均少弃答 24%;把「有多自信」变成可测量、可回归、能驱动弃答的指标,才是 Agent 上线前该补的一课。
Agent 说「我确定」的时候到底有多确定?置信度校准(Calibration)就是检查模型自报的 90% 置信度是否真的对应 90% 正确率——GPT-4 在 RLHF 之后 ECE 从 0.007 涨到约 0.074(劣化约十倍),推理模型在无解问题上比非推理模型平均少弃答 24%。这一期讲怎么把「模型有多自信」变成一个可测量、可回归、并且能直接驱动「弃答 / 转人工」的工程指标。
测试一:先量基线——你的 Agent 到底过自信多少
指标:ECE(目标小于 0.10)、overconfidence gap = 平均置信度 − 实际准确率(正值即过自信)、AUROC(区分对错的能力,大于 0.7 才算可用)。
工具:netcal(https://github.com/EFS-OpenSource/calibration-framework)。
测试二:三路置信度同源对照,别只测一种
指标:三路 AUROC / AURAC 对比、各自的成本倍率(采样次数与 token 增量)、在困难题上的表现差。
工具:uqlm(https://github.com/cvs-health/uqlm)的 BlackBoxUQ,scorers 可选 semantic_negentropy、semantic_sets_confidence、noncontradiction、exact_match、cosine_sim、entailment;语义熵官方复现代码 jlko/semantic_uncertainty(https://github.com/jlko/semantic_uncertainty)。
测试三:过自信的两种典型病灶
指标:90-100% 桶的 overconfidence gap、高置信度错误率(置信度不低于 90% 却答错的占比)。
工具:netcal 的 ReliabilityDiagram + pandas 分桶统计。
测试四:风险-覆盖曲线,把弃答阈值算出来而不是拍出来
指标:AURAC、coverage@accuracy≥95%、弃答率、误拒率(本来能答对却被弃答的比例)。
工具:AbstentionBench(https://github.com/facebookresearch/AbstentionBench),含 20 个数据集、3.5 万条以上无解问题、自带经人工校验的 LLM 裁判(与人工一致率 88%)。
测试五:Conformal 覆盖率验证——要写进准出条件就靠这个
指标:经验覆盖率与目标覆盖率(如 90%)的偏差(目标在正负 2 个百分点内)、平均预测集大小、弃答比例。
工具:参考 Learning Conformal Abstention Policies(https://arxiv.org/abs/2502.06884),多选与分类任务可用 LAC、APS 两类构造方式。
测试六:Agent 轨迹级校准——这一步最容易被漏掉
指标:分段 ECE(后期明显高于前期即为后期过自信)、轨迹成功率预测误差、轨迹级 ECE 与单步 ECE 的差(差越大说明「平均一下」掩盖了问题)。
工具:从 LangSmith / Langfuse 导出 trace,自建 Python 脚本按 horizon 分桶;报告协议参考 Uncertainty Quantification for LLM Agents 综述(https://arxiv.org/abs/2609.07395)提出的 TC-ECE。
测试七:注入攻击会不会污染置信度(安全交叉项)
指标:置信度抬升幅度(百分点)、注入后的高置信度错误率、拒答率变化。
要点:自报置信度和被选动作出自同一段上下文,注入内容可以同时影响两者;多次采样也不一定救得回来——如果注入内容影响到了所有样本,就会形成「虚假一致」。所以置信度信号本身也必须纳入红队测试范围。
测试八:一个几乎零成本的校准技巧
指标:ECE 下降幅度、AUROC 变化。
依据:ACL 2026 Findings 的所有权偏差研究(https://aclanthology.org/2026.findings-acl.1570/)——模型对自己答案的置信度比同样的用户输入答案平均高出最多 26%,把答案改写成用户输入形式即可显著降低过自信、校准改善最多 26%,不需要重新训练。
坑点一:把「准确率」当成「可信度」。团队常拿准确率 92% 汇报,但没人知道那 8% 错在哪里、模型当时有多自信。结果是「高置信度答错」直接送到柜面。做法:准确率、ECE、AUROC、高置信度错误率四个数字一起上报,缺一个都不足以判断能不能上线。
坑点二:把「自报置信度更准还是更差」当定论引用。两个方向都有论文:一边是 Xiong 等人(ICLR 2024)发现自报置信度严重过自信、平均 ECE 超过 0.377;另一边是 EMNLP 2023 的结论——对 ChatGPT / GPT-4 / Claude 这类 RLHF 模型,自报置信度反而比模型条件概率(logprob)校准得更好,ECE 相对降低约 50%。差别在于比较基线不同:自报比 logprob 好,但绝对值仍然过自信。做法:在你的模型、你的数据上三路都测一遍,不要直接引用别人的数字下结论。
坑点三:用单步校准推出轨迹可靠。每步 95% 不等于 20 步 95%,而且步骤误差相关会让连乘近似偏高;同时「把所有轨迹平均」会把后期过自信抹平,看起来一切正常。做法:按步数分段统计 ECE,并且单独报告轨迹级指标。
坑点四:置信度阈值一拍脑袋定。阈值定太低,大量错误答案照常输出;定太高,误拒率飙升,业务方直接拒绝上线。做法:阈值必须来自风险-覆盖曲线上的业务可接受点,并与误拒率一起过评审。另外采样类方法(语义熵、self-consistency)会让推理成本涨 5-10 倍,必须先把每次请求的额外开销算清,再决定用在哪些环节——通常只用在不可逆动作前的关键节点。
坑点五:把置信度当安全防线。间接注入能同时抬高「被选中的动作」和「自报的置信度」,采样也不一定救得回来(所有样本被同一段注入影响即形成虚假一致)。置信度是可靠性的度量,不是防护措施,防护要靠数据流控制与人工确认分支。
「分享到微信」:手机浏览器打开时一键调起系统分享面板,选择微信即可分享到朋友圈或聊天。电脑上回退为复制文案。
暂无留言,来说两句吧