大语言模型概率输出为何不自洽？内部一致性量化方法

如果你正在搭建一个需要模型“自评概率”的智能系统比如让大语言模型从几个候选答案里挑一个最可能的并输出置信度那你可能已经遇到过这种场面同一道题换一种问法模型给出的概率从 0.7 变成了 0.4再换一种又变成 0.6。把互补事件放在一起加甚至可以得到 1.2。这不是“模型有点飘”而是一个值得认真对待的技术问题。LLM 并非始终符合贝叶斯。它输出的概率数字很多时候不是一套自洽的信念体系更像是一段“看起来很合理”的文本。真正重要的不是追问“模型知不知道答案”而是设计一套方法去量化它内部概率信念到底有多不一致。这篇文章想把这层逻辑拆开讲清楚。1. 先理解贝叶斯意义上的“理性”到底要求什么1.1 概率不只是“置信数字”而是一套公理约束很多人把“概率”理解成“一个从 0 到 1 的分数”。但在贝叶斯统计里概率远不止一个数字。它是一套带着约束条件的信念体系必须满足几条基本规则非负性、归一性、可加性。非负性很好理解概率不能小于 0。归一性意味着整个事件空间的总概率是 1。可加性更关键如果 A 和 B 是互斥事件那么 P(A∪B) P(A) P(B)。由这些公理继续推导还会得到全概率公式和贝叶斯定理P(A) P(A∩B) P(A∩¬B)P(A|B) P(A∩B) / P(B)这套规则的价值不在于让数学家觉得优雅而在于它保证“信念”之间不会互相打架。如果一个人相信明天下雨的概率是 0.7那他就不能同时相信明天不下雨的概率是 0.5。因为这两个事件是互补的概率相加必须等于 1。任何违反这些约束的数字都不能被称为“概率”只能算是某种“得分”。所以当我们讨论一个模型是否“符合贝叶斯”时不是在问它会不会用贝叶斯公式做题而是在问它给出的概率数字是否构成一个内部相容的信念系统1.2 LLM 说你有多肯定和贝叶斯后验是两回事大语言模型在生成文本时确实会产生概率。自回归语言模型每一步都在计算下一个 token 的分布理论上你也能让模型生成“A 方案胜出的概率是 0.7”这样的句子。但这和贝叶斯后验是完全不同的两件事。贝叶斯后验是在给定完整证据和明确假设后通过模型结构计算出来的分布。它天然满足概率公理因为计算过程本身就是从联合分布推导出来的。而 LLM 输出“0.7”这个数字本质上是模型根据 prompt 预测到的下一个 token 序列。模型并不是在执行一次全局概率计算而是在决定“人类在这种情况下通常希望我说出什么数字”。它有可能受到训练数据、prompt 措辞、选项顺序、few-shot 示例甚至标点符号的影响。模型没有一套显式的“事件空间”也没有在生成“0.7”之前检查过它与“0.3”是否互补。因此第一个需要建立的认知是LLM 输出的概率数字是一种表面置信度表达不等同于贝叶斯信念。检验这种表面置信度是否靠谱不能只看单个数字而要看它在不同问法、不同关系之间是否保持一致。2. LLM 很容易露出“不贝叶斯”的马脚2.1 常见不一致互补事件、边缘概率和条件概率在实际测试中LLM 的内部不一致通常集中在三类关系上。第一类是互补事件。你问模型“事件 A 发生的概率是多少”它说 0.7你再问“事件 A 不发生的概率是多少”它说 0.5。两个数字加起来是 1.2。这说明模型不是在表达一套统一的概率信念而是在分别生成两个单点问题的答案。第二类是边缘概率。事件 A 的概率应该等于“A 且 B”的概率加上“A 且非 B”的概率。但如果你分别问模型这三个问题很可能得到 0.8、0.5、0.3前两个加起来的 0.8 和最后结果刚好契合这是运气更多时候答案是 0.8、0.6、0.3加总之后是 0.9明显偏离。第三类是条件概率之间的关系。贝叶斯定理要求 P(A∩B) P(A)×P(B|A)。如果你直接问联合概率再分别问边缘概率和条件概率模型给出的数字大概率不满足这个等式有时偏差还相当大。下面这张表可以直观看出常见的不一致类型检测类型需要比较的概率一致性要求LLM 常见表现互补事件P(A)、P(¬A)P(A)P(¬A)1两项和明显偏离 1边缘概率P(A)、P(A∩B)、P(A∩¬B)P(A)P(A∩B)P(A∩¬B)分解后加总对不上条件关系P(A∩B)、P(A)、P(BA)P(A∩B)P(A)P(B表述不变性同一事实的不同问法相同证据下概率稳定换措辞、换顺序后跳变2.2 一个简单的内部一致性检测框架你不需要做一个完整的研究项目也能对模型做一次“内部一致性体检”。我建议按下面这套最小框架来跑定义一个事件空间。比如“明天会下雨”“明天不会下雨”两个事件互斥且穷尽。设计多组提问。分别问 P(A)、P(¬A)再扩展到一个相关事件 B比如“明天最高气温超过 30 度”问 P(A∩B)、P(¬A∩B) 等。保持输出格式一致。让模型只输出一个 0 到 1 之间的数字不要输出解释减少解析噪声。固定解码参数。温度设为 0固定随机种子如果 API 不支持 seed至少用相同的温度与 top-p 重复多次再取均值。计算偏差指标。对每一组关系计算偏差绝对值再对多个事件取平均。这个过程并不复杂但能很有效地暴露问题。我个人的经验是越是在“开放性事件”上模型的不一致性越明显而在常识性、训练数据中出现频率很高的场景里模型可能因为记忆作用“碰巧”表现得好一点。注意温度调到 0 并不等于完全消除随机性。部分推理后端在并行计算或不同硬件上仍可能产生微小差异。为了测“信念”本身建议每个问题至少重复 3 到 5 次。3. 为什么会不一致机制层面的三条解释3.1 目标函数只优化局部词元不优化整体概率分布大语言模型训练时的核心目标是最大化下一个 token 的预测概率。它的输出层 softmax 只会保证“当前词表里所有 token 的概率之和等于 1”。这个归一化只发生在单步词元层面并不会对整个句子、整个事件空间做全局归一化。所以模型可以很自然地认为“A 的概率是 0.7”“A 不发生的概率是 0.5”因为这两个数字分别来自两次不同的前向计算softmax 每次都正常工作没有任何机制去检查两次计算结果之间的关系。更关键的是自回归生成是有累积误差的。前面的 token 生成会影响后面的 token但每一步都只是在局部做贪心采样。你很难把最终生成“0.7”这个过程理解为一次完整的贝叶斯推断。它更像是在做“基于当前上下文的局部模式匹配”。3.2 上下文表面形式会改变信念而不是被当作唯一证据贝叶斯理性有一个隐含要求给定相同的证据信念应该相同。但在 LLM 这里“证据”和“表面形式”是混在一起的。你换一个同义词调整一下选项顺序或者把“概率”改成“可能性”模型内部的 token 分布都会发生变化。这种现象在很多模型上都存在。并不是说模型“不知道”两个问题是等价的而是在它的训练目标里没有“保证语义等价输入产生相同概率输出”这一项。这个问题的本质是LLM 的输入空间是词元序列不是结构化的事件空间。模型没有显式地把“明天会下雨”和“明天不会下雨”识别为互补事件。它能生成合理的句子是因为它学会了语言上的关联而不是因为它掌握了一个概率分布表。3.3 校准与一致性被混为一谈还有一个更容易误导人的情况模型在校准指标上表现不错但内部一致性依然很糟糕。校准衡量的是“频率意义”当模型说 100 个样本里有 70% 的概率为真时最终真的有 70% 左右为真那它就是校准良好的。这是一个关于“长期频率”的属性。但“一致性”是另一回事它要求概率数字之间满足逻辑关系。一个模型可以做到“说过 0.7 的事件大约 70% 为真”同时却在同一个数据集上给出 P(A)P(¬A)1.2。校准不能保证一致性一致性也不能替代校准。很多团队在评估 LLM 置信度时只看 calibration 曲线觉得模型“挺自信的”“置信度可信”。但到了真实任务里一旦需要多步推理或跨事件比较内部不一致就会立刻变成决策误差。校准解决的是“这个数字是否符合长期频率”一致性解决的是“这套数字本身是否自洽”。两个维度都要看。如果只关注“校准好”而忽略“内部一致”很容易把一套自相矛盾的概率输出当成可靠信号使用。4. 如何量化从直觉到可执行的评测流程4.1 设计一个最小评测集量化内部一致性第一步是设计评测集。不需要很大但结构要完整。我建议至少包含四个模块互补事件对至少 10 组例如“某股票明天上涨 / 不涨”“某模型回答正确 / 不正确”。边缘概率分解至少 5 组每个事件再搭配一个相关事件 B检查 P(A) 是否等于 P(A∩B)P(A∩¬B)。条件概率关系至少 5 组包含常见的“疾病与阳性检测”“候选产品与用户偏好”这类场景。表述变体对同一事件设计 3 到 5 种等价问法检查概率波动幅度。评测问题时要尽量保证事件空间定义清晰。避免“可能”“也许”这类模糊词否则模型更容易输出中间概率但你分不清它是真的认为概率中等还是因为措辞不确定。4.2 指标怎么算怎么判断“不合格”可以用以下几类指标来量化不一致度互补偏差|P(A) P(¬A) - 1|理想值 0越大越不一致。边缘偏差|P(A) - (P(A∩B) P(A∩¬B))|理想值 0。条件偏差|P(A∩B) - P(A)×P(B|A)|理想值 0。表述波动同一事件多种问法输出概率的标准差理想值接近 0。把每个事件组的偏差取绝对值后平均就得到该模型在当前评测集上的“内部不一致分数”。至于阈值我没有一个放之四海皆准的标准。但按工程上的一般经验如果一组偏差平均值超过 0.1就要非常警惕超过 0.05 时适合用来做排序不适合用来做精确概率估计。如果是高风险场景阈值还要更严格。不要一上来就把几百条问题全部铺开。先用 20 到 30 条问题跑通流程确认 prompt、解析和指标计算都没问题再扩展到更大规模。4.3 排查链路从现象定位到具体偏差原因当你发现模型的内部一致性分数很差时不要急着下结论“模型不行”。先按下面顺序排查看现象是哪一类不一致最严重互补、边缘、条件还是表述变体不同问题指向不同原因。看 prompt问题是否真的语义等价有没有引入新的事实、语气变化、主语变化或额外限定条件看事件定义事件是否互斥且穷尽比如“下雨”和“多云”并不是互补事件。看解码参数温度、top-p、max_tokens、seed 是否固定输出是否被截断比如模型只说了“概率较高”而没有输出数字。看模型和接口同一个模型的不同版本、不同量化精度比如 FP16、BF16、FP32、不同部署框架都可能造成概率值差异。看后处理你解析数字时是否把“0.7”和“70%”都正确统一模型是否输出了“约”“可能”这类修饰词这个排查链路的价值是帮你把“模型问题”和“实验设计问题”分开。很多时候内部不一致并不全是模型的锅而是评测任务本身的事件空间定义不清晰或者 prompt 在不同问题之间引入了额外变量。5. 实际落地LLM 概率输出应该怎么用5.1 适合做的事低风险打分、筛选、候选排序、一致性自检LLM 的概率输出并非一无是处。在低风险、不需要精确比例关系的场景里它有实际价值。候选答案排序就是一个典型场景。比如给 AI 助手配置多个工具需要决定优先调用哪个模型给出“工具 A 更可能满足用户需求”的倾向性即使概率数字不完全自洽只要相对排序稳定也能用。另一个场景是低置信度筛选。当模型对某个回答给出的概率低于某个阈值时系统不直接返回给用户而是触发人工审核或二次确认。这里的概率数字不需要满足完整的贝叶斯关系只需要有初步的置信度区分能力。还有一个容易被忽视的用途用一致性测试做 prompt 调优。你可以在开发阶段对不同 prompt 模板跑同一套一致性评测选择偏差更小、概率更稳定的模板。这比只看单次任务准确率更有参考意义。5.2 不适合做的事高风险决策、推导式判断、需要严格后验的场景一旦任务进入高风险领域LLM 概率输出就必须被降级使用。医疗、法律、金融风控、工业安全这些场景里概率往往要用于计算期望损失、风险比例或决策阈值。如果你拿一个内部不一致的概率值去做推导后续所有的风险计算都会失真。更麻烦的是模型可能在单次回答里显得非常自信但换一个等价问题后那个自信就消失了。我并不主张完全禁止 LLM 输出概率。但在这些场景里必须建立额外的校验机制。比如把同一个事件拆成多个子问题检查边缘概率和条件概率是否一致或者用传统概率模型对结果做约束修正。LLM 更适合作为“概率估计的启发式信号”而不是最终后验概率的来源。5.3 一个实用建议先跑最小验证再构建后处理流程如果你决定在自己的系统里使用 LLM 概率输出我建议先不要把它直接接进主流程。先做一次最小验证确认下面几个问题都能回答模型在互补事件上偏差有多大换一种等价问法概率波动多大对同一个问题连续多次输出稳定吗解析出来的数字是否满足 [0,1] 区间基本约束如果这些答案都满足你的业务容错范围再考虑构建后处理流程。后处理层至少要包含两件事第一检测明显违背概率公理的输出比如互补事件之和不等于 1第二对多个等价问题的概率取平均或中位数降低表面措辞带来的波动。# 一个简单的后处理思路对等价问题的概率做均值聚合 probs [model_query(p) for p in equivalent_prompts] # 只保留 [0,1] 内的有效值 clean_probs [p for p in probs if 0.0 p 1.0] if not clean_probs: result None # 标记为不可信 else: result sum(clean_probs) / len(clean_probs)这段代码只是一个示例结构真正的生产实现还要考虑缓存、重试、异常处理和时间开销。但它体现了一个正确思路不要相信单次概率输出至少做一层自洽校验。6. 回到起点真正要盯住的是“可用性”而不是“很像人”6.1 把一致性当作模型的调试信息内部一致性不应该只被看作一次性的学术评测它可以成为模型迭代和 prompt 设计的“调试信号”。比如你在升级模型版本时发现新模型在某个领域任务上的准确率提高了但互补事件的一致性分数明显变差了。这说明新模型在表面能力上更强但概率信念更不稳定。如果你的应用依赖概率排序这个信号比准确率更值得关注。同样当你发现某个 prompt 模板导致模型在条件概率上严重不一致时可以尝试调整提问顺序、增加示例、或把事件结构化呈现。很多时候把事件空间写清楚比让模型“更努力思考”更有效。6.2 一个更偏工程化的结论LLM 不是贝叶斯理性体这一点在许多测试中都能得到印证。我们也没有必要强行要求它像一个完整的概率系统那样运行。工程上真正可靠的做法是接受它的局限然后用测试和后处理去管理这种局限。所以下一次再让 LLM 给出一个 0.7 的概率时你真正应该问的是如果把同一件事翻过来问它给出的数字会比 0.3 更接近 0.3 吗如果不会那这个 0.7 不是信念只是一段文字。先把不一致性量化出来再决定能不能用这才是对概率输出最基本的尊重。