最近在业务里做 AI 决策功能时我遇到了一个非常典型的问题模型在某个问题上给出了 87% 的置信度但换一种问法同一个模型对同一事实给出的概率却掉到了 60% 左右。更麻烦的是这两个概率如果按照概率论的规则做乘法结果和模型直接给出的联合概率对不上。一开始我以为是提示词写得不好后来把问题拆开仔细测了几轮才发现这其实不是偶然现象而是 LLM 概率输出机制的一种系统性特征LLM 的输出概率看似是一个“置信度”但它并不满足我们理想中的贝叶斯信念结构。换句话说LLM 并不是始终符合贝叶斯规律的。这篇文章我想围绕“LLM 概率信念的内部不一致性”来展开先讲清楚 softmax 概率和贝叶斯信念之间的本质区别再给出一个可以操作的量化方案最后聊一聊这些现象对工程落地的实际影响。内容会比较长但每一步都会有可复现的思路和示例代码。1. 一个直觉问题LLM 的概率是从哪来的1.1 当我们说“LLM 给出 87% 置信度”时我们到底在说什么在很多大模型应用中我们习惯性地把 softmax 输出的概率当成了“模型对这件事的把握程度”。比如模型回答“明天北京下雨的概率是 87%”业务方可能直接把这个数字接入决策系统87% 足够高那就提前触发某种服务策略。但这里有一个容易被忽略的细节LLM 在回答“明天北京下雨的概率是 87%”时这 87% 本身只是模型生成文本中的一个 token 序列。真正由模型内部 softmax 产生的概率是“在给定上下文后下一个 token 是‘8’、‘7’、‘%’的概率”而不是“明天北京下雨”这个外部事件在模型内部的概率信念。换句话说模型说出来的 87%是语言层面的输出模型内部 softmax 计算出来的概率是 token 预测概率这两者都不是直接等同于“模型对外部世界的后验信念”。理解了这一点再去看 LLM 是否符合贝叶斯就会发现问题比表面上复杂得多。1.2 贝叶斯主义的理想基准概率是你的信念强度在贝叶斯思想里概率表达的是一个人或一个系统对外部世界命题的信念强度。一个理性的贝叶斯智能体对不同命题赋予的概率应该满足几条基本规则概率在 0 到 1 之间所有互斥且穷尽的事件概率之和为 1条件概率与联合概率之间满足链式法则例如 P(A, B) P(A) * P(B|A)在看到新证据之后应该按照贝叶斯公式更新信念。这些规则不是可选项而是“理性”的定义。如果一个系统给出的概率违反这些规则那它提供的就不是一个自洽的概率信念。举个例子如果模型对“A 事件发生”给出 0.8 的概率对“A 事件不发生”也给出 0.8 的概率那么无论它内部结构多复杂这套输出都不能当作概率信念来用。因为它违反了两者之和为 1 的基本公理。实际中当然不会出现这么极端的例子但温和版本的不一致非常常见同一事实在不同问法下概率不同条件概率乘积与联合概率不一致前置概率在追加证据后出现不合逻辑的变化。这些就是本文要讨论的“内部不一致性”。1.3 LLM 的概率是编码了信念还是功能输出在经典的贝叶斯模型里概率是模型的核心表示。一个朴素贝叶斯分类器告诉你某个类别的概率是 0.7是因为它真的把训练数据中的计数、先验和似然组合成了一个后验估计。但 LLM 不一样。LLM 训练目标是最大化下一个 token 的预测准确率它学到的是一套“在当前上下文条件下自然语言中下一个 token 的分布”。这个分布确实携带了大量关于世界知识的统计信息但它并不等于对每个命题的显式概率建模。打个比方一个人非常熟悉城市交通他能快速告诉你“这个时间点打车大概要多久”。但如果你让他严格评估“出租车在 5 分钟内到达的概率是 0.72且与红灯概率独立”他可能做不到。熟悉不等于有一套自洽的概率体系LLM 的“知识”和“概率输出”之间也有类似的差距。所以LLM 的 softmax 概率更准确地说是一种“功能输出”而不是“内部信念编码”。这不是说它完全不能用而是说我们在用的时候必须知道它的边界。2. 从 logits 到概率softmax 背后是一个确定性函数2.1 logits 与 softmax 的机械关系在 transformer 模型的最后一层模型会为词表中的每个 token 计算一个得分这个得分叫 logit。随后 softmax 函数把 logits 转换成一个概率分布import numpy as np def softmax(logits, temperature1.0): logits np.array(logits) / temperature exp_logits np.exp(logits - np.max(logits)) # 数值稳定处理 return exp_logits / exp_logits.sum()这个函数本身是完全确定性的。给定同样的 logits输出一定相同。温度 temperature 参数用来控制分布的尖锐程度温度越低概率越集中到最高分 token温度越高分布越平滑。但这里有一个关键认知softmax 转换只是把一组得分变成了一个概率分布它并没有增加任何“信念”的属性。就像一个打分系统把候选人分数归一化成百分比不代表这个百分比就是候选人获胜的真实概率。2.2 温度采样如何影响概率分布在实际应用中我们经常会调整温度。下面来看一个具体示例假设模型对某个位置的三个候选 token 给出了 logitslogits [2.0, 1.0, 0.1] for temp in [0.5, 1.0, 2.0]: probs softmax(logits, temperaturetemp) print(ftemperature{temp}, probs{probs.round(4)})输出大致如下temperature0.5, probs[0.6590, 0.2424, 0.0986] temperature1.0, probs[0.5424, 0.2890, 0.1686] temperature2.0, probs[0.4231, 0.3056, 0.2713]你会发现同一个模型、同一组 logits仅仅因为温度不同最高概率项从 0.66 变成了 0.42。这是采样策略导致的而不是模型对外部世界信念的变化。在做决策时如果业务系统直接读取生成文本中的“87%”或者直接读取解码时的 softmax 概率都必须明白这个数字受到温度、top-p、提示词格式等多种因素影响不是一个稳定的信念度量。2.3 概率输出与“不确定性估计”是两回事很多刚接触 LLM 的开发者会把“softmax 概率”和“不确定性估计”混为一谈。实际上两者关注的问题完全不同softmax 概率回答的是给定上下文下一个 token 是什么的概率分布不确定性估计回答的是模型对这个预测结果有多大把握这个把握是否准确。一个模型可能在所有预测上都给出 0.9 的概率但真实正确率只有 60%这说明它过度自信。这种问题属于校准calibration范畴和“概率输出是否服从贝叶斯规则”是两层问题。内不一致性更隐蔽它说的是即使模型在所有预测上都能完美校准80% 的概率对应 80% 的真实频率它在结构层面上的概率分配依然可能违反概率公理。3. 内部不一致性为什么 LLM 不符合贝叶斯规律3.1 自一致性链式检验一句话拆成两步提问为了理解 LLM 的概率内部不一致性最直接的方法是用“链式法则”做检验。概率论告诉我们一个事件 A 和一个条件事件 B 之间存在如下关系P(A, B) P(A) * P(B|A)如果模型内部的概率表示是自洽的那么无论我们用哪种方式询问模型计算出来的乘积关系都应该成立。具体来说我们可以把一句话拆解成两个问题直接问“李华毕业于清华大学”的概率是多少拆分问“李华毕业于 985 高校”的概率是多少再问“已知李华毕业于 985 高校他毕业于清华大学”的条件概率是多少如果模型具备贝叶斯一致的概率信念那么前一个概率应该约等于后两个概率的乘积。但实际测试中这种等式经常不成立而且偏差幅度相当大。3.2 条件概率乘积不等于联合概率内部不一致的表现来看一个示意性的假想结果假设我们用一个常见的开源 LLM 做测试使用统一的模板和采样参数问题形式模型给出的概率直接问“王小明住在中国”的概率0.82问“王小明住在北京”的概率0.67问“已知王小明住在北京他住在中国”的概率0.99如果模型符合贝叶斯规则那么“王小明住在中国”这一命题的概率应该等于“王小明住在北京”的概率乘以“已知在北京的前提下住在中国”的概率0.67 * 0.99 0.663但模型直接给出的概率是 0.82。0.663 和 0.82 之间有约 0.16 的偏差这个偏差远远超出合理波动范围。这就说明了一个问题模型对“王小明住在中国”的概率并不是通过对“北京”这个中间命题的概率做链式推理得到的。它更像是直接基于训练数据中“中国”和“王小明”之间的共现强度给出一个数字。模型内部没有一个统一的概率机在协调这些不同粒度的回答。3.3 预测性推理与事实回忆的信念分离更细看会发现LLM 在回答事实回忆类问题和推理类问题时概率输出遵循的规律完全不同。事实回忆类问题“北京是中国的首都吗”这类问题通常能给出较高的直接概率因为训练语料中这类表述大量出现。推理类问题“如果 A 城市是 B 国的首都那么 A 城市的人口一定比 B 国其他城市多吗”这类问题需要组合多个不确定因素模型给出的概率往往波动更大。但贝叶斯信念要求这两类问题共享同一个底层概率体系。一个问题如果可以用多种路径推导不同路径得到的概率应当一致。然而 LLM 因为训练目标只关注“给定上下文后的下一个 token”并不存在一个显式的机制来保证不同路径收敛到同一个概率值。这带来的实际影响是当我们用 LLM 做多步推理时每一步的置信度不能简单相乘。因为每一步的置信度并不是独立条件下对同一事件的估计它们可能重叠、矛盾也可能遗漏关键证据。3.4 位置、措辞与上下文对概率的扰动除了逻辑层面的不一致LLM 的概率输出还表现出对表面形式的高度敏感。同一道题改成否定句、换一种提问角度、调整选项顺序模型的概率分布都会发生明显变化。这本质上是因为模型学到的分布 P(token | context) 对 context 的每一位都非常敏感而 context 中任何一个措辞变化都会影响后续 token 的分布。举个例子如果让模型在 A、B 两个选项中选择A 排在前面往往比 A 排在后面拿到更高的概率。这种“位置偏差”已经被很多人验证过。从贝叶斯角度看选项顺序不应该影响模型对事实本身赋予的概率但 LLM 做不到。这说明 LLM 的概率输出掺杂了大量与真实信念无关的“表面结构因素”。在做不确定性评估时如果不考虑这些因素很容易高估模型的可靠性。4. 如何量化 LLM 概率信念的一致性4.1 设计一致性分数如果我们想系统性地评估一个 LLM 的概率信念一致性一个可行的方法就是构造“自一致性链式检验”并用一个统一的指标来衡量偏差。常见的做法是定义一组命题 A 和中间命题 B让模型分别给出 P(A)、P(B)、P(A|B)、P(B|A) 的估计用链式法则或贝叶斯公式来验证这些概率之间的关系定义一致性得分通常在 0 到 1 之间越接近 1 表示越一致。一个常见的一致性指标可以定义为coherence 1 - |P(A) - P(B) * P(A|B)|当偏差为 0 时coherence 1完全一致当偏差很大时coherence 接近于 0。4.2 自动化测试把一致性做成回归测试在实际工程中我建议把这种一致性检验做成模型评估流水线的一部分而不是只在研究时用。模型每次迭代后跑一遍一致性测试集可以很快发现概率结构是否发生退化。下面是一个简化的测试流程思路1. 从测试集读取命题对 (A, B) 2. 构造模板分别询问 P(A)、P(B)、P(A|B) 3. 调用模型获取归一化概率 4. 计算链式一致性分数 5. 汇总所有命题对的平均一致性 6. 输出报告标注偏差最大的命题4.3 实验流程示例Python 伪代码为了让你快速理解我提供一个可直接改造的 Python 示例框架。这里假设你已经接入了一个 LLM 的接口比如 OpenAI 兼容接口或者 Hugging Face 的 pipeline我留了接口占位。# 文件路径: coherence_check.py import json import numpy as np # 这里替换成你的模型调用封装 def ask_probability(question: str) - float: 向模型询问一个命题的概率。 示例思路把问题构造成一个二选一判断 对是和否两个 token 的概率做归一化取是的比例。 raise NotImplementedError(请替换为实际的模型调用逻辑) def coherence_score(p_a: float, p_b: float, p_a_given_b: float) - float: 链式一致性P(A) 应该约等于 P(B) * P(A|B) predicted p_b * p_a_given_b deviation abs(p_a - predicted) return max(0.0, 1.0 - deviation) def run_evaluation(test_cases): results [] for case in test_cases: a_question case[a_question] b_question case[b_question] a_given_b_question case[a_given_b_question] p_a ask_probability(a_question) p_b ask_probability(b_question) p_a_given_b ask_probability(a_given_b_question) score coherence_score(p_a, p_b, p_a_given_b) results.append({ a: a_question, p_a: p_a, p_b: p_b, p_a_given_b: p_a_given_b, coherence: score, }) avg_score np.mean([r[coherence] for r in results]) print(f平均一致性得分: {avg_score:.4f}) print( * 60) for r in sorted(results, keylambda x: x[coherence]): print(f[{r[coherence]:.4f}] A{r[a]}) return results if __name__ __main__: test_cases [ { a_question: 王小明住在中国。, b_question: 王小明住在北京。, a_given_b_question: 已知王小明住在北京那么他住在中国。, }, { a_question: Python 是一种编程语言。, b_question: Python 是一种解释型语言。, a_given_b_question: 已知 Python 是解释型语言那么 Python 是编程语言。, }, ] run_evaluation(test_cases)这段代码的核心思想是等你把ask_probability接入真实模型后就能批量计算模型在不同命题对之间的链式一致性。如果把测试集扩大到几百条就能得到一个相对稳定的量化指标。要注意的是这里的ask_probability实现方式会直接影响结果。我建议不要直接读取生成文本中的自然语言数字而是通过只让模型输出“是”或“否”再把这两个 token 的 softmax 概率拿出来归一化这样可以减少文本生成造成的额外误差。5. 现象背后的机制为什么会出现贝叶斯不一致5.1 训练目标只优化下一个词不优化信念结构LLM 的训练目标是最大化下一个 token 的似然。这个目标本质上是自回归语言建模它关心的不是“模型对命题 A 和命题 B 的概率是否满足链式法则”而是“在给定前文的情况下下一个 token 的预测是否准确”。这带来的结果就是模型学到了大量统计相关性但没有学习到概率论公理。它的概率系统是一个“统计相关性网络”而不是一个“贝叶斯网络”。你可能想问训练数据中不是有大量数学和逻辑文本吗模型难道学不到贝叶斯规则吗实际上模型能学到的是“语言中关于贝叶斯规则的描述”比如它可以写出贝叶斯公式但它内部的概率分配并不服从这个公式。就像一个人可以背诵概率论教材但在实际判断时依然会犯各种各样非理性错误。5.2 支持度与正确性分离模型记忆的是“哪个答案常见”在很多测试案例中LLM 给出高概率的答案并不是因为它推理出了正确结论而是因为训练语料中这个结论频繁出现。比如问“北京是中国的首都吗”模型给高概率是容易的因为这句话在语料中出现太多次。但如果问一个低频但真实的知识点模型即使碰巧预测对了概率也会明显偏低。这说明模型对命题的概率估计更接近“训练语料中该命题的表面支持度”而不是“在给定证据下的逻辑必然性”。这也解释了为什么会出现链式不一致中间命题“王小明住在北京”可能在语料中支持度不高所以模型给出的概率偏低但直接命题“王小明住在中国”支持度高概率偏高。两个支持度之间未必有乘法关系偏差自然就出现了。5.3 上下文工程与提示敏感性概率不稳定的深层原因从上下文学习in-context learning的角度看LLM 对 prompt 的每个词都非常敏感。模型在内部其实是在做一个非常高维的条件分布拟合只要输入稍微变化对应的条件分布就可能明显改变。这种敏感性不是 bug而是语言模型架构的天然特性。对于一个 7B 甚至更大参数的模型它的隐藏状态空间非常复杂要在所有输入变化下保持概率结构的一致性是一个极其困难的约束。而标准训练过程并没有加入这种约束所以不一致是预期内的结果。这给工程带来的启示是不要指望通过微调或者提示词优化来彻底解决概率不一致问题。提示词优化能够降低某些场景下的偏差但无法让模型变成一个严格贝叶斯系统。5.4 与经典贝叶斯近似的对比贝叶斯优化、贝叶斯推断不是一回事讨论到这里有必要澄清几组概念因为“贝叶斯”这个词在不同语境下含义差别很大贝叶斯推断利用贝叶斯公式计算后验分布 P(θ|X)用于参数估计和预测。贝叶斯优化一种黑盒函数优化方法用高斯过程等代理模型来指导超参数搜索和 LLM 概率信念没有任何直接关系。贝叶斯深度学习在神经网络权重上引入先验分布通过变分推断或 MC Dropout 估计不确定性。LLM 的 softmax 概率条件语言模型在 token 层面的输出分布是一个确定性函数的一部分不是对权重的后验推断。很多关于“LLM 是否符合贝叶斯”的讨论其实混淆了“模型输出概率”和“模型内部不确定性度量”两个层面。本文讨论的“贝叶斯一致性”指的是第一个层面模型输出的概率是否满足概率公理。至于模型内部的权重不确定性那是另一个话题。这个区分很重要。如果你在开发中只是想把“置信度”当作一个参考指标来使用那么你需要关注的是概率输出的一致性和校准如果你想对模型自身的不确定性建模那要看的是贝叶斯深度学习相关的技术路线。6. 对工程实践与 AI 可靠性的启示6.1 不要直接把置信度当作决策依据我在做系统设计时一个最深的体会是LLM 的置信度是一个“弱信号”。它可以用来排序、过滤、辅助判断但不宜作为高价值决策的唯一依据。比如在自动化客服系统中模型对某个答案的置信度是 0.87如果直接触发自动退款很可能出问题。因为这 0.87 不是贝叶斯后验概率不能理解为“87% 的概率这个方案是正确的”。更稳妥的做法是把置信度作为参考特征而不是唯一指标设置多级阈值低置信度转人工结合规则系统或检索系统交叉验证。这不是否定置信度的价值而是要求我们给它一个恰当的使用边界。6.2 校准工作不能只做 output 层面也要做结构层面很多团队已经在做校准工作比如温度缩放temperature scaling它能够让模型输出概率和真实正确率更接近。这是 output 层面的校准能解决“过度自信”的问题。但校准无法解决结构层面的不一致。一个模型可能所有输出都完美校准但它在不同问题形式下给出的概率依然矛盾。如果系统依赖概率做链式推理这种结构性矛盾会造成累积误差。所以更完整的方案是output 层面做置信度校准结构层面做一致性检验和修正prompt 层面尽量减少位置偏差、措辞偏差。三者结合才能在工程上把概率输出用得更可靠。6.3 RAG、思维链与自一致性采样工程上如何缓解不一致目前有几类工程手段可以缓解概率不一致带来的问题检索增强生成RAG让模型基于检索到的具体证据来回答而不是依靠语料中的统计支持度。证据越具体概率输出越接近真实知识结构。思维链Chain-of-Thought把一步推理拆成多步让每一步都有清晰理由。虽然不能保证贝叶斯一致但能减少“直接压缩推理导致的概率扭曲”。自一致性采样Self-Consistency同一个问题采样多次对答案做多数投票。这种方法能缓解单次采样中的随机和偏差提高整体可靠性。需要说明的是这些方法只是“缓解”不是“解决”。如果模型内部没有一个可验证的概率结构任何外围手段都无法根治错误传播。6.4 安全与合规视角当模型不确定时系统应该怎么表现在高风险场景下与其追求模型“给出准确的置信度”不如让模型在不确定时主动触发保护机制。工程上可以这样做低置信度时返回“需要人工介入”而不是硬给一个答案对关键业务动作强制要求外部验证不信任模型概率记录所有置信度与最终结果周期性回测概率质量。这种方法的核心是承认模型概率系统不完备并为这种不完备设计兜底机制。这是比单纯优化 prompt 更稳妥的生产策略。7. 未来方向与可执行建议7.1 如果你想深入可以复现什么实验如果你对这个话题感兴趣建议从一个小规模的实验开始选一个开源模型比如 Qwen、DeepSeek、Llama 系列中你能拿到 logits 的任意一个构造 100 组命题对覆盖事实回忆、常识推理、空间关系等类型用统一模板分别询问整体概率和拆分概率计算链式一致性得分画出偏差分布尝试调整温度、top-p观察一致性是否变化。这个实验不需要大量算力普通的单卡 GPU 就能完成。关键是要把模板控制好保证模型唯一变化的变量就是“推理分解方式”。7.2 什么指标值得长期跟踪在模型迭代过程中我建议除了常规的准确率、召回率之外把以下指标也纳入评估链式一致性得分衡量概率结构是否自洽位置偏差程度同一选项在不同位置时的概率差措辞敏感度同一命题用不同句式表达时的概率方差校准误差ECE衡量输出概率与真实正确率的匹配度。这些指标合在一起能比单一准确率更全面地反映模型“有多值得信任”。7.3 最后的建议如果你正在开发一个依赖 LLM 概率输出的系统我的建议很简单把 LLM 的概率当成一个高质量参考而不是精确信念值把一致性测试做成常态化回归在关键决策路径上永远保留一层外部校验。概率一致性这个话题短期内很难被训练方法完全解决但它值得每一个认真做 LLM 应用的开发者关注。毕竟一个系统敢不敢把决策权交给模型最终取决于我们对模型概率输出结构有多了解。建议你从这一篇开始搭建一个属于自己的小规模一致性测试集然后拿去跑一跑你正在用的模型。结果大概率会让你重新审视模型给出的每一个置信度。