你模型的置信度分数只是一种感觉，而非概率

这里还有一个关于温度的更隐蔽的陷阱。人们认为将温度降至零会使模型“更可靠”，因为它变得具有确定性。确定性并不等同于正确性。温度为零的模型会自信且重复地每一次都给出相同的虚假引用，因为这种编造遵循了其训练数据中的概率模式。低温并不能减少幻觉；它只是让幻觉保持一致。

三种置信度，皆非完美​

当人们说“置信度”时，通常指的是三种不同的东西，了解你所掌握的是哪一种是有价值的。

• 语言化置信度（Verbalized confidence） 是当你问“你的置信度是多少，0 到 100？”时模型写出的数字。它是最直观的，也是最容易被操纵的。它往往趋于饱和——模型喜欢说 0.9 或 1.0——这使得它作为排序信号几乎毫无用处，因为所有结果都挤在顶端。

• 基于 Logprob 的置信度（Logprob-derived confidence） 来自模型在生成时分配的 token 概率。它感觉更“内在”且诚实，但它衡量的是模型对措辞的信心，而不是对事实的信心。模型可以对发射哪些 token 高度确定，但对现实世界的理解却完全错误。反直觉的是，对于经过指令微调的模型，语言化数字有时比 logprobs 校准得更好——而对于经过大量 RL 微调的模型，有时则更差。这里没有绝对的赢家。

• 集成一致性置信度（Ensemble-agreement confidence） 多次询问同一个问题（或跨多个模型询问），并衡量答案的一致程度。这是三种方法中最不无用的一种，也是我们拥有的最可靠的不确定性方法的基础。

最后一类才是真正的信号所在。由 Farquhar 及其同事引入的语义熵（Semantic entropy）会采样多个响应，将含义相同的响应聚类（无论具体措辞如何），并计算这些含义簇的熵。高熵——模型每次都说出真正不同的内容——是胡乱猜测的强力指标。SelfCheckGPT 也基于同样的原理：多次采样并衡量相互一致性。因为这些方法观察的是跨样本的行为，而不是信任单一的内省报告，所以它们避开了整个“置信度即感觉”的问题。

但即使是集成一致性也有一个你必须尊重的失败模式：如果模型始终幻觉出同一个错误答案，那么通过一致性衡量，它看起来会高度自信，因为所有样本都相互吻合。一致性衡量的是稳定性，而不是真理。当错误是系统性的——即模型在训练期间学到的错误事实——样本会愉快地收敛于此。

不要用学生自己的笔来批改作业​

以上所有失败的共通点都是一样的：你在让模型给自己的工作打分，然后又信任这个分数。校准失效了，激励机制倾向于过度自信，甚至更好的内部信号也只能衡量稳定性，而不是正确性。因此，修复方法不是写一个更好的提示词来提取置信度。修复方法是完全停止让高风险决策通过模型的自我评估。

相反，要基于外部验证设置门控。在触发退款之前，将引用的政策条款与实际的政策文档进行核对 —— 这应该是检索查找，而不是自我报告。在 SQL 运行之前，根据 schema 进行校验，并在沙箱中以只读方式运行。在答案发送给用户之前，运行一个低成本的确定性规则，或者使用第二个独立的模型，其任务是寻找你担心的特定错误。验证器不需要很聪明；它必须 独立于 产生答案的推理过程，这样它的错误才不会与生成器的错误相关联。

这将置信度从一个你设定阈值的标量，重新定义为一个你通过工程构建的流水线。在你真正需要数值门控的地方 —— 例如转交给人工处理，或决定是否弃权 —— 不要盲目相信模型的数字。在你自己的任务上构建可靠性图表：记录预测结果及其声明的置信度，标记结果，并查看在 你的系统 中 “0.9” 是否真的代表 90%。如果不是，你可以事后重新校准这些数字，或者完全放弃口头化的置信度，转而采用基于采样的信号，如语义熵。共形预测（Conformal-prediction）方法则更进一步，将原始的不确定性转换为带有实际覆盖保证的集合 —— 这是一个你可以为之背书的概率，而不是一个由模型讲述出来的概率。

实践原则很简单：将任何模型自述的置信度视为未经标记的特征，绝不要将其视为概率。在你信任某个阈值之前，先衡量校准度。对于任何涉及金钱交易、发送消息或触及生产环境的操作，都要设置一个模型无法通过“狡辩”蒙混过关的检查门控 —— 因为它总是乐于给你 0.95 这个数字，甚至直到它编造出一个从未存在过的政策条款的那一刻，它依然会这么提供给你。