跳转到主要内容

置信度分数税:为什么询问模型它有多确定比直接出错成本更高

阅读需 2 分钟Tian PanTian Pan

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

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

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

那个看起来免费的字段

先从那个容易被忽略的部分开始,因为它在单次请求中很小,在宏观统计中又不可见。

在你的输出 schema 中添加 confidence 并不是一种元数据标注(metadata annotation)。它是一个生成任务。模型生成这些 token 的方式与生成答案的方式完全相同,而其中的每个组成部分都有成本:

  • 每个请求的输出 token。 无论答案是否真的不确定,都会生成置信度字段。一个每月处理 1,000 万次请求的功能需要支付 1,000 万个置信度字段的费用,其中包括那 900 多万个模型本来就会答对、而你根本不会去看那个数字的请求。
  • 指令的 Prompt token。 告诉模型进行自我评估需要指令文本,而且好的置信度提示词(prompting)不是一句话就能搞定的。关于口头置信度(verbalized confidence)的研究表明,数字的可靠性在很大程度上取决于你如何询问——校准较好的提示方法涉及概率框架的措辞、详细的描述和 few-shot 示例。这些示例在每次调用中都会消耗 prompt token。
  • 一个你并未要求的推理前导。 模型通常会先通过推理来证明置信度得分的合理性。这种辩证过程处于响应的关键路径上。如果你的功能是流式传输的,用户就必须等待它。
  • 对自信的绝大多数请求产生的延迟。 这笔税在帮助最小的地方支付得最重:在模型正确且自信的大部分请求中,你花费了 token 和毫秒数来生成一个不会触发任何动作的数字。

这一切都不会出现在账单明细中。它表现为略高一点的 token 账单、略差一点的 p95 延迟,以及增加了一个字段的 schema。诚实的核算方法是单次请求成本乘以总交易量:置信度字段是对自信的绝大多数征收的一种税,用来资助对不确定尾部的路由。这种交换是否值得是一个现实的问题——但如果你把这个字段的定价设为零,你就无法回答它。

Schema 的变更并非中立

还有一个更微妙的成本,即使是细心的团队也会错过。在结构化输出中添加一个字段不仅仅是追加数据——它可能会改变答案本身。

LLM 是从左到右生成的。从功能上讲,输出 schema 的结构和顺序是模型在编写时所依赖的 prompt 的一部分。这并非理论上的担忧。从业者记录过一些案例,仅仅将一个输出字段重命名(例如将 final_choice 改为 answer),就让任务准确率从个位数飙升到 90% 以上。字段的顺序也很重要:事实证明,将推理字段放在答案字段之前与之后相比,会使准确率波动好几个百分点,因为模型要么在做出承诺之前先思考,要么在之后进行合理化。

现在把一个 confidence 字段扔进那个 schema。它应该放在哪?如果它出现在答案之前,你就要求模型在生成它理应自信的内容之前先承诺一个置信水平——这是不连贯的,并且会扰乱随后的答案。如果它出现在答案之后,模型已经生成了答案,现在只是在对一段它无法修改的文本描述一个数字。无论哪种方式,你为了获得置信度信号而发布的 schema,都已经显著改变了你真正关心的主要输出的分布。

结论令人不安:测量置信度的行为并不是被动读取。它是一种干预。在你假设该字段仅具观察性之前,你应该对“含置信度字段的 schema”和“不含置信度字段的 schema”的答案质量进行 A/B 测试。

你买来的数字可能根本没有校准

这是一个比其他成本都大的成本。假设你已经交了税,字段已填充,你准备好进行路由了。路由的整个前提是 “0.9” 意味着接近 “90% 的时间是正确的”。但事实几乎从未如此。

模型陈述的置信度是由训练分布中措辞与正确性之间的相关性所塑造的 token 序列。它不是概率估算。它只是训练数据中一个听起来很自信的回答长什么样。关于这一点的实证记录非常直接:

  • 关于口头置信度(verbalized confidence)的研究发现,即使是强大的模型,区分正确答案和错误答案的能力也仅略高于随机——ROC 曲线下面积(AUC-ROC)在 60 左右,而 50 代表掷硬币。
  • 模型会系统性地将自报的置信度聚集在量表的顶端。它们会不断报告 90–100% 的置信度,包括在错误的答案上,而这些高置信度区间的实际准确率远低于该水平线。
  • 校准误差(Calibration error)随模型不同而波动巨大。最近的评估测量显示,某个前沿模型在正确率仅为 25% 的情况下,预期校准误差(ECE)超过了 0.7——这种置信度信号本质上就是噪声——而在同样的基准测试中,其他模型的校准效果要好 3 到 4 倍。你不能想当然;你必须针对特定模型和特定任务进行测量。
会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

过度宣称陷阱:当“歪打正着”摧毁 AI 产品信任

当 AI 系统通过虚构的推理链得出正确答案时,检查工作的资深用户会永久失去信任 —— 这比系统直接出错导致信任崩塌的速度还要快。

insider
ai-engineering
阅读需 10 分钟

LLM 伪造问题:当模型为错误答案构建出令人信服的论据

LLM 不只会幻觉事实——它们还会伪造推理。伪造问题是指模型先做决定再进行解释,以选择性忽略证据为基础构建出听起来合理的综合分析。

insider
llm
阅读需 8 分钟

那个你从未进行过负载测试的备用模型

配置好的备用模型只能证明你的路由机制有效 —— 却无法证明你的应用是否能在次要模型的输出下生存。本文探讨了为什么名义上的备用方案在真实流量下会失败,以及如何在供应商出故障前先行测试你的故障转移机制。

insider
llm
阅读需 13 分钟

拒绝还是上报:置信度门控 AI 中的双阈值问题

单个置信度阈值将“拒绝”和“上报”这两个截然不同的决策强行合并为一个数字,而这种妥协正是导致你的信任度指标持续下滑的原因,即便在准确率看起来还不错的情况下也是如此。

insider
llm
阅读需 11 分钟

429 错误背后的惊群效应:速率限制是一个分布式系统问题

不带抖动的指数退避会组织你的重试集群而不是将其消解 —— 随之而来的是同步的 429 浪潮、重试放大和亚稳态故障。本文将探讨为什么 LLM 速率限制需要抖动、重试预算,以及你原本没打算构建的客户端调度器。

insider
ai-engineering