先说结论：模型说「我有 90% 把握」，这句话本身没有信息量

在把大模型接进业务流程时，很多人会自然地想到一个优雅的设计：让模型在给出答案的同时，附上一个 0 到 1 的置信度分数。分数高就自动放行，分数低就转人工审核。

这个设计在直觉上非常合理，工程上也极其省事——不用额外训练模型，不用搭建复杂管线，改一句提示词就完事。

但它几乎总是失效的。原因不在于模型「不够聪明」，而在于大模型输出的置信度，本质上是一段生成的文本，而不是一个经过校准的概率。

问题一：这个数字是「编」出来的，不是「算」出来的

当你在提示词里写「请给出你对答案的置信度（0-1）」，模型做的事情是：根据上下文预测下一个 token。它输出 0.85，和你让它输出「很好」没有本质区别——都是语言生成的结果。

真正的置信度应该来自模型对自身输出分布的统计，比如各个 token 的对数概率。而自然语言里随口报出的数字，跟模型内部的不确定性之间没有可靠的映射关系。

换句话说，你拿到的不是「模型有多确定」，而是「模型认为一个确定的模型会报出什么数字」。

问题二：校准极差，而且系统性偏高

即便退一步，假设这个数字多少反映了一些内部状态，它也是严重未校准的。

实践中常见的现象是：模型在完全答错的问题上，依然会给出 0.9 以上的高置信度。这在模型「幻觉」时尤其明显——编造得越流畅，自评分数往往越高。

这带来一个非常糟糕的后果：你原本想用置信度做安全阀，结果它恰好在你最需要它的场景下失灵。低质量答案被高分数放行，风险反而被放大了。

问题三：同一个问题，分数会漂移

置信度分数对提示词的措辞、上下文顺序、甚至温度参数都高度敏感。

同一道题，你把「请给出置信度」改成「请评估你的答案可靠性」，分数可能从 0.7 跳到 0.95。加一句「如果你不确定请说明」，整体分数又会系统性下移。

这意味着你无法设定一个稳定的阈值。今天调好的 0.8 分界线，明天换个模型版本、改一段系统提示，就全乱了。