为什么不该向大模型索要置信度分数：LLM自评可靠性的陷阱

一个被广泛误用的做法

在构建基于大语言模型（LLM）的应用时，开发者常常希望获得一个量化的可靠性指标。一个看似直观的做法是：直接在提示词里让模型自己给出一个「置信度分数」，比如「请为你的回答给出0到100的确信程度」。这个想法很诱人——如果模型能告诉我们它有多确定，我们似乎就能据此过滤低质量的输出、触发人工复核，或者决定是否调用更强大的模型。

然而，越来越多的实践者和研究者指出：直接向LLM索要置信度分数，是一种极具误导性的做法。模型给出的这个数字，往往并不能真实反映其答案的正确概率。理解这背后的原因，对于任何认真构建生产级AI系统的团队都至关重要。

语言模型「说」出的置信度并非真实概率

生成式输出的本质：模型在「造」数字而非「算」概率

大语言模型在本质上是一个自回归的文本生成器。当你要求它输出一个「置信度：87%」时，模型并不是在进行严格的概率推理，而是在生成一段最符合训练分布的文本。换句话说，「87%」这个数字本身，只是模型认为在当前语境下最可能出现的一串token，而非对自身知识状态的真实度量。

要理解这一点，需要认识到自回归模型的核心工作方式：它逐个token地预测下一个最可能出现的词元。每一步生成时，模型会基于之前所有已生成的token计算一个概率分布，然后从中采样或选取概率最高的token。这意味着模型的每一个输出——包括数字、标点、甚至所谓的「置信度分数」——本质上都是同一个next-token prediction过程的产物。模型并没有一个独立的「元认知模块」来评估自身的知识状态，它只有一个统一的文本生成机制。当我们要求模型输出「87%」时，这个数字和模型生成「今天天气不错」在机制上没有任何区别。

这带来了一个根本性的错位：模型说出的置信度，衡量的是「这个数字看起来合理吗」，而不是「我的答案正确吗」。一个在训练数据中反复出现的错误说法，模型可能会以极高的「自信」表达出来，因为它学到了这种表达方式，而非验证了事实。

校准问题：模型的自信与实际正确率严重脱节

在机器学习中，一个模型如果是「良好校准的」（well-calibrated），那么它给出80%置信度的预测，在长期统计下应该有大约80%是正确的。校准是概率预测质量评估中的核心概念，最早广泛应用于天气预报领域——一个完美校准的天气预报系统，在所有它给出70%降雨概率的日子里，确实应该有约70%的天会下雨。衡量校准质量的常用指标包括期望校准误差（Expected Calibration Error, ECE）和可靠性图（reliability diagram）。

研究表明，经过RLHF（基于人类反馈的强化学习）微调后的对话模型，其口头表达的置信度往往严重过度自信，且校准性极差。模型倾向于给出高分数，因为在训练中「自信、肯定」的回答通常更受人类标注者青睐。

这里值得深入理解RLHF的训练机制如何系统性地导致了这一问题。在RLHF过程中，人类标注者对模型的多个回答进行排序打分，然后用这些偏好数据训练一个奖励模型（reward model），再用强化学习算法（如PPO）优化语言模型以获得更高的奖励分数。问题在于，人类标注者通常更偏好语气确定、表述自信的回答——一个犹豫不决的答案即使更诚实，也往往得分较低。这种训练信号系统性地推动模型朝着「显得自信」的方向优化，而非朝着「准确表达不确定性」的方向优化。研究者还发现，预训练阶段的模型在token级别的概率上往往具有相对较好的校准性，但经过指令微调和RLHF后，口头表达的置信度与实际正确率之间的差距会显著增大。

这意味着，一个模型报告「95%确信」的答案，实际正确率可能远低于95%。依赖这样的数字做决策，等于把系统建立在一个虚假的可靠性基础之上。

更可靠的替代方案：如何科学评估LLM输出的不确定性

如果不能直接问模型要置信度，那我们应该如何评估模型输出的可靠性？以下是几种经过验证的、更有依据的方法。

方法一：使用token级别的对数概率（logprobs）

许多模型API（如OpenAI API）会返回生成token的对数概率（logprobs）。这些数值直接来自模型的softmax输出分布，相比让模型「口头报数」，它们更接近模型的真实内部状态。

从技术角度看，在Transformer架构中，模型最后一层会输出一个logits向量，其维度等于词表大小（通常为数万到十几万）。对这个向量施加softmax函数后，得到每个token被选中的概率分布。对数概率就是对这个概率取自然对数——例如，如果某个token的生成概率是0.95，其logprob约为-0.05；如果概率是0.01，logprob约为-4.6。logprob越接近0，说明模型对该token的选择越确定。在实际应用中，开发者可以观察答案中关键token（如实体名称、数字）的logprob值——如果关键token的logprob很低（绝对值很大），说明模型在该位置的生成决策并不确定，可能需要额外验证。OpenAI API还允许返回每个位置top-k个候选token及其logprobs，这为分析模型的内部「犹豫」提供了窗口。

通过分析关键token的概率分布，可以更客观地估计不确定性。需要注意的是，logprobs也需要经过校准处理才能转化为有意义的概率，但它至少是模型计算过程的真实产物，而非一段生成的文本表演。

方法二：一致性采样（Self-Consistency）

另一种被广泛验证的方法是多次采样。对同一个问题，用较高的温度参数（temperature）让模型生成多个独立的答案，然后观察答案之间的一致程度：

高一致性：如果模型反复给出相同答案，说明该答案更稳健可信
低一致性：如果每次结果都不同，则说明模型实际上处于高度不确定的状态——无论它自己声称多么「自信」

这种方法的理论直觉来源于集成学习（ensemble methods）：多个独立预测的共识通常比单一预测更可靠。在LLM场景中，通过设置较高的temperature参数（如0.7-1.0），模型在每次采样时会探索不同的推理路径。Temperature参数控制softmax分布的「尖锐度」——temperature越高，概率分布越平坦，采样的随机性越大。2022年Google Research的论文首次系统性地提出了这一方法，并在数学推理和常识问答任务上展示了显著的效果提升。实践中，通常采样5-20次即可获得较好的一致性估计，但这需要权衡API调用成本和延迟。

这种方法的核心优势在于，它用模型的行为而非模型的自述来衡量不确定性。

方法三：外部验证与检索增强生成（RAG）

真正的可靠性往往需要模型之外的机制来保障。通过检索增强生成（RAG）为答案提供可溯源的依据，或引入独立的验证模型对答案进行事实核查，都比依赖模型的自我评估更加可靠。

RAG的典型架构包含三个阶段：首先将用户查询转化为向量表示（通常使用专门的embedding模型），然后在外部知识库中检索最相关的文档片段（使用向量相似度搜索，如余弦相似度或内积），最后将检索到的内容作为上下文注入到模型的提示词中。这种方法的可靠性优势在于：模型的回答有了可溯源的依据——我们可以检查模型引用的原始文档是否支持其结论。此外，RAG还能缓解模型的「幻觉」问题，因为模型被引导从给定证据中推导答案，而非完全依赖参数化记忆中可能过时或错误的信息。

核心原则是：让模型的输出接受外部世界的检验，而不是让它自己给自己打分。

对系统设计的启示

这个话题虽小，却触及了当前LLM应用开发中一个普遍存在的认知误区：我们倾向于把模型拟人化，假设它像人类专家一样了解自己知识的边界。但事实是，模型对「我不知道」的表达能力，本身也是被训练出来的行为模式，而非真正的内省结果。

对于工程实践，这意味着：

不要在关键决策路径中使用模型自报的置信度，这些数字不具备统计意义上的可靠性
优先采用基于logprobs、一致性采样等有计算依据的不确定性度量
对高风险场景，始终引入外部验证或人工兜底机制
在评估系统可靠性时，用真实数据集测量实际的校准曲线，而非相信模型的自我陈述

结语

「不要向LLM索要置信度分数」这条建议，背后是对生成式模型工作机制的深刻理解。大语言模型擅长产生流畅、合理的文本，但流畅并不等于正确，自信更不等于可靠。构建值得信赖的AI系统，需要我们放弃对模型自我评估的天真信任，转而依靠更严格、更可验证的不确定性度量方法。在AI日益深入关键业务的今天，这种严谨态度不可或缺。