用LLM做置信度评分，为何是个坏主意？

在AI应用开发中，让大语言模型（LLM）为自己的回答提供置信度评分，看似是一个优雅的解决方案：模型既生成答案，又评估答案的可靠性。然而，Hacker News上的一篇讨论指出，这种做法存在根本性缺陷。

为什么置信度评分如此诱人？

在构建基于LLM的应用时，开发者常常需要判断模型输出的可信程度。无论是构建客服机器人、医疗咨询助手还是代码生成工具，知道“模型有多确定”似乎能帮助系统决定是否采纳答案或转交人工。

直觉上，让LLM自己给出一个0到1的置信度分数，是最直接的方法。模型已经理解了问题，再让它评估自己的回答，似乎顺理成章。但问题恰恰藏在这种直觉背后。

LLM置信度评分的根本缺陷

1. 模型缺乏真正的“自知之明”

LLM本质上是基于概率分布生成文本的系统，它们并没有内省的机制来准确判断自己是否“知道”某个事实。当模型输出一个置信度分数时，这个分数本身也是生成的文本，并不比答案本身更可靠。

换言之，模型可以自信地给出错误答案，同时给出高分；也可以正确回答却给出低分。这种不一致性源于模型训练目标——预测下一个词，而非校准不确定性。

2. 校准问题普遍存在

研究表明，LLM的置信度分数往往校准不佳。模型倾向于过度自信，尤其是在训练数据覆盖不足的领域。一个模型可能对从未见过的问题给出0.9的置信度，仅仅因为它在训练中学会了“回答时要显得确定”。

这种过度自信在关键应用中是危险的。如果系统依赖置信度分数来决定是否将问题升级给人工，那么低质量的自动回答可能因为虚高的分数而被放行。

校准（Calibration） 是概率预测中的核心概念，指模型给出的置信度与其实际准确率的吻合程度。一个完美校准的模型，在宣称“置信度0.8”的所有样本中，应当恰好有80%是正确的。衡量校准的常用指标包括期望校准误差（ECE） 和可靠性图（Reliability Diagram）：后者将预测概率分桶，对比每个桶内的平均置信度与真实准确率，曲线越接近对角线说明校准越好。LLM的校准问题有其结构性根源：预训练目标是最小化下一个词的交叉熵，而非输出可信的概率估计；RLHF对齐又进一步放大了“显得确定”的表达倾向。此外，模型面对分布外问题时，其内部概率分布往往过于平坦或过于尖锐，导致置信度系统性偏高。这解释了为何单纯读取模型自报的分数难以作为决策依据。

3. 评分与答案的循环依赖

当要求LLM评估自己的输出时，评分过程与答案生成共享相同的模型参数和知识缺陷。如果模型在某个知识点上存在错误认知，它同样会在评分时低估该错误。这种循环依赖使得置信度评分无法提供独立于答案的验证信号。

更可靠的替代方案

使用外部验证机制

与其依赖模型自评，不如引入外部信号。例如，对于事实性问题，可以通过检索增强生成（RAG）将答案与权威来源比对；对于代码生成，可以运行测试用例来验证正确性。这些方法提供了独立于模型判断的客观反馈。

检索增强生成（RAG） 是一种将外部知识库检索与LLM生成相结合的技术架构：系统先根据用户问题从文档库中检索相关片段，再将这些片段作为上下文注入提示词，由模型基于检索到的证据作答。在置信度评估场景中，RAG的价值在于它提供了独立于模型参数的“事实锚点”——可以将模型答案与检索到的权威文本做蕴含判断或事实比对，若答案无法在证据中找到支撑，即视为低置信。相比之下，运行测试用例验证代码则属于执行式验证，其反馈来自程序运行的真实结果，与模型的任何主观判断完全解耦。两类方法的共同点在于引入了模型之外的信息源，从而打破“模型自评”的闭环，为置信度提供可追溯、可审计的依据。

多模型交叉验证

让多个不同的模型分别回答同一问题，比较答案的一致性。如果多个模型给出相似答案，置信度自然较高；如果分歧明显，则提示问题可能不确定。这种方法虽然成本更高，但避开了单一模型自评的陷阱。

基于logprob的置信度估计

一些API提供token级别的对数概率（logprob），可以基于这些概率计算答案的统计置信度。虽然这也不是完美的校准，但它至少反映了模型生成过程中的真实概率分布，而非二次生成的评分。

logprob（对数概率） 是语言模型对每个候选token输出的原始概率取自然对数后的值。例如某token概率为0.9时，其logprob约为-0.105；概率为0.01时约为-4.605，数值越接近0表示模型越有把握。与让模型“再写一个置信度数字”不同，logprob是模型前向计算中直接产生的分布信息，未经二次生成，因此更能反映模型在生成该答案时的真实不确定性。实践中可对答案中各token的logprob取平均或几何平均，得到序列级置信度；也可计算答案的困惑度（perplexity），即logprob均值的指数，作为整体确定性度量。需要注意，logprob衡量的是“生成这个token有多顺”，并不等同于“这个事实有多正确”——模型完全可能流畅而高概率地生成一个错误陈述，因此它仍是相对信号而非绝对保证。

实践中的权衡

Hacker News的讨论也提醒我们，完全否定LLM置信度评分的价值可能过于绝对。在低风险场景中，比如内容推荐或草稿生成，模型自评的置信度可以作为粗略的参考信号。但在涉及安全、医疗、金融等高风险决策时，必须引入更严格的验证流程。

关键在于理解置信度评分的本质：它只是一个提示，而非保证。开发者应当将其视为众多信号之一，并结合其他验证手段共同使用。

结语

用LLM做置信度评分之所以是个坏主意，核心在于模型无法可靠地评估自身的不确定性。这种自评机制看似方便，却可能带来虚假的安全感。更稳健的做法是建立外部的、独立的验证路径，让置信度评估脱离模型自身的知识局限。

对于AI应用开发者而言，这提醒我们：在追求自动化的同时，不要忘记为关键决策保留可验证的锚点。