LLM概率输出并非贝叶斯？量化内部一致性的方法与工程实践

LLM 输出概率看起来像“信念”，但严格说，它不一定符合贝叶斯规则。这个问题在越来越多团队里浮出水面：把大模型当“概率模型”用，拿它输出的置信度做筛选、排序、风险判断，结果经常出现矛盾。比如同一个模型对“明天下雨概率是 70%”和对“明天不下雨概率是 70%”都能给出来。如果这两句话都来自同一个模型、同一套权重，那它的概率信念在内部就是不一致的。这篇文章想把这个话题拆开：先解释什么叫做贝叶斯一致性，再讲清楚怎么量化这种一致性，最后聊一聊这类不一致性对实际开发意味着什么。

先说一个容易混淆的点：题目里的“量化”不是模型量化，不是 GGUF、INT8、FP16 那套权重压缩方案，而是“度量、测量”的意思。如果你是被“量化”这个词搜进来的，先确认自己找的是哪一类内容。平时搜技术资料，经常能看到模型量化、贝叶斯优化、量化交易这些词同时出现，它们和本文主题没有直接关系，别混在一起看。本文讨论的是概率信念的一致性，不是把模型从 FP16 压到 INT8。

1. 概率信念、贝叶斯一致性：先把概念对齐

1.1 从“模型会输出概率”到“模型拥有信念”

大语言模型在很多场景下会输出概率。最常见的是推理时每个 token 的 logprob，也就是 softmax 之后的对数概率。换一种方式，你也可以在提示词里直接问模型：“你觉得这件事发生的概率是多少？”模型会给出一个数字，比如 65%。这两种输出都表示“某种程度”，但它们能不能被称为概率信念，要看这些数字是否满足概率的基本约束。

概率不是随便一个 0 到 1 之间的数。它要满足几条基本规则：一个事件和它的补事件的概率加起来等于 1；互斥事件的概率要能相加；条件概率和联合概率要服从定义；最重要的一条是，当新证据出现时，后验概率要通过贝叶斯公式从前验和似然更新出来。如果一组概率数字连这些规则都违反，它们就更像是“看起来像概率的评分”，而不是真正的概率信念。

我一般会用一个简单问题来测试读者的直觉：你问模型“太阳明天从东边升起的概率”，它回答 99.9%。你再问“太阳明天不从东边升起的概率”，它如果回答 0.5%，那两条加起来是 100.4%，已经违反了补事件规则。实际测试里，这种偏离通常不是 0.4% 这么小，而是经常相差十几个百分点。问题一旦复杂一点，模型的概率输出就很容易失去约束。

1.2 一致性不是校准

很多人把“概率信念是否符合贝叶斯”和“模型校准度”混在一起，这是两个问题。

校准度说的是：当模型说概率是 70% 时，实际发生频率是不是接近 70%。这是频率意义上的正确性。

贝叶斯一致性说的是：模型分配给一组逻辑相关事件的概率，是否彼此兼容。它不要求概率数值绝对准确，只要求内部无矛盾。一个模型可以完全不自洽，比如 P(A)=0.7、P(¬A)=0.7，但如果你统计它说“70%”的那些事件，实际确实发生了 70%，那它校准度反而很好。反过来，一个模型可以内部高度自洽，但概率数值完全偏离真实频率。

这个问题之所以重要，是因为实际系统里经常用概率做决策。RAG 系统拿置信度决定要不要检索；Agent 拿置信度决定要不要调用工具；风险系统拿置信度决定要不要人工介入。如果概率信念内部矛盾，这些决策的上层建筑就不稳。

2. 为什么很多人默认 LLM 应该符合贝叶斯，又为什么会有矛盾

2.1 下一个 token 预测的天然吸引力

大语言模型的训练目标是预测下一个 token。给定前文，模型在词表上得到一个概率分布。这个分布看起来非常像“在已知上下文的条件下，对下一个符号的后验预测”。于是有人提出一个很自然的问题：如果模型把训练文本都看成证据，它的概率分布是不是一种隐式的贝叶斯后验？

这个想法很有吸引力。因为如果成立，你就能把模型当做一个不断根据新证据更新信念的贝叶斯智能体。许多实验也确实发现，在某些简单设定下，LLM 的概率输出会表现出部分贝叶斯更新的特征，比如在接收新证据后，答案会朝证据方向偏移。这也是题目里“并非（始终）”这层括号的含义：它不是永远不符合，而是不能默认它始终符合。

但这里有一个关键区别：模型的目标函数是预测下一个符号，而不是维护一个自洽的世界模型。它的训练数据是互联网文本，其中包含大量互相矛盾的说法、不同立场的表述、各种语境下的概率用法。模型学到的是“在类似语境下通常输出什么数字”，而不是“为所有事件维护一套无矛盾的概率指派”。因此，LLM 完全可能在局部表现得像贝叶斯，在全局上却不一致。

2.2 训练目标和贝叶斯信念之间有几道坎

具体来说，有几道坎决定了 LLM 不必然符合贝叶斯。

第一，条件概率的积化和问题。一个符合贝叶斯规则的模型，对 P(A,B) 的边缘化计算应该得到一致结果。但 LLM 是通过自回归逐 token 生成的，每个 token 的分布受前面生成内容影响。如果你换一种方式问同一个问题，前面的 token 不同，后面的条件分布就会不同，最终得到的“概率”可能完全不同。

第二，表面形式影响。LLM 对数字、百分比、文字描述的反应很敏感。同一种不确定性，用“0.7”和“70%”和“七成”来表达，模型给出的对应概率不一定一致。这在非贝叶斯模型里很正常，但它意味着模型不是在做稳定的概率演算，而是在匹配训练数据里的表达习惯。

第三，先验主导。LLM 在训练时见过太多常用表述，它对某些事件有很强的先验。当你在问题里给出证据时，它可能没有真正做似然更新，而是回到先验分布。这样的行为会让条件概率测试出现系统性偏差，看起来像“不会做贝叶斯更新”，实际更像“先验压过了证据”。

2.3 矛盾表现：几个常见例子

我在实际测试中比较常看到这几类矛盾：

• 补事件不一致：P(A) 和 P(¬A) 之和明显偏离 1。
• 条件方向不一致：P(A|B) 高，但 P(B|A) 也高，二者与联合概率对不上。
• 语境漂移：同一个概率问题，换主语、换时间、换表述，数值变化远超合理范围。
• 边缘化不一致：P(B) 通过全概率公式算出来是一个值，直接问模型又是另一个值。

这些现象不是某一个模型独有。不同系列、不同规模的模型表现不同，但都很难完全避免。测试得越多，你会越清楚地看到：LLM 的概率信念更像一块“局部平整、整体起伏”的地形，而不是一块处处符合几何规则的平面。

3. 设计一个内部一致性测试：怎么量化才算数

如果你要判断“这个 LLM 是否以及何时符合贝叶斯”，不能靠几个零散问题和现场感觉。你需要一个可复现的测试框架。下面是我的建议思路，可以直接照搬到自己的实验里。

3.1 选事件集：逻辑关系要能对照

测试的第一步是构造事件集合。事件之间必须有明确的逻辑关系，这样你才知道“一致”应该是什么样子。

我建议从最简单的双事件开始，再逐步扩展：

• 单事件：A。
• 补事件：¬A。
• 条件事件：A|B、B|A。
• 联合事件：A∩B。
• 互斥拆分：B = B₁ ∪ B₂，B₁、B₂ 互斥。

常见的题目类型包括天气、体育比赛、医学检查、产品评价、历史事件等。尽量选择模型知识覆盖比较好的领域，同时也要包含一些模型可能没有稳定先验的冷门事件。只测常识题会有偏差，因为模型对常识题往往有强先验，可能掩盖一致性表现。冷门题反而更容易暴露出模型“编概率”的痕迹。

3.2 获取概率的两个途径：logprobs 和自然语言估计

第二步是决定怎么获取模型的“概率”。

第一个途径是读 token logprob。你可以给模型一个固定前缀，比如“判断以下断言成立的概率，请只输出一个 0 到 1 之间的数字：”，然后让模型生成答案，取答案部分 token 的概率。也可以用更精细的方式：把“是”和“否”作为候选，分别计算两个 token 的概率并做归一化。

第二个途径是让模型直接输出自然语言概率估计。你问它“这个断言成立的概率是多少？”它可能回答“70%”或者“0.7”。这种叫言语化概率。

两条途径得到的结果经常不一致。logprob 反映的是模型生成过程中对每个 token 的概率分配，而言语化概率反映的是模型对自己答案的自我报告。它们哪个更接近“真实信念”，本身就是研究问题。我建议在测试中把两条途径分开记录，不要混在一起算一致性分数，否则结论会失真。

3.3 需要检查的约束条件与不一致度量

第三步是选定要检查的约束。以下这些是最基本的：

对每一项约束，你可以定义不一致分数。最简单的是“偏差绝对值”：约束左边和右边的差。比如补事件法则的不一致分数就是 |P(A) + P(¬A) − 1|。把所有题目的分数取平均，就得到这一类约束的平均不一致程度。

更严格一点的做法是把多个约束组合起来算一个全局分数，比如把所有约束残差的平方和加总。但我不建议一开始就上复杂指标，先看每个约束各自的偏差分布，更容易定位问题。先记住一个原则：一致性测试的目标是找“哪里坏了”，不是只给一个总分。

3.4 一个最小实验设计示例

下面给一个通用伪代码示例，帮助你理解流程。这只是一个框架，具体提示词和模型接口要根据你的环境调整：

# 伪代码示例：验证补事件不一致 events = [ ("明天下雨", "明天不下雨"), ("掷硬币正面朝上", "掷硬币正面不朝上"), # ... 可以扩展到几十对事件 ] def ask_prob(model, statement): prompt = f"判断以下断言成立的概率，只输出 0 到 1 之间的数字：{statement}" # 调用模型，取答案中的数字，这里省略接口细节 return model.generate(prompt) inconsistency_scores = [] for a, not_a in events: p_a = ask_prob(model, a) p_not_a = ask_prob(model, not_a) score = abs(p_a + p_not_a - 1) inconsistency_scores.append(score) print("平均补事件不一致分数:", sum(inconsistency_scores) / len(inconsistency_scores))

这个示例只测补事件规则，但它足以暴露很多模型的问题。跑通之后再逐步加入条件概率、贝叶斯公式和全概率公式。

关于采样参数，我有一个明确建议：正式测试时用 temperature=0 或非常低的值，同时每个问题重复多次取中位数。原因很简单，高温度会产生随机波动，让你分不清不一致是模型本身的问题还是采样噪声。先用低温度确定“模型本身是否一致”，再研究“温度对一致性的影响”。

4. 实测时最容易误判的几个干扰因素

这部分是踩坑经验。我见过很多测试结论，最后发现是实验设计的问题，不是模型的问题。以下四个干扰因素，每次测试前都要先过一遍。

4.1 提示词措辞和比例尺效应

同样一个事件，用不同方式去问，得到的概率可能差很远。比如“你估计概率是多少”和“这个概率是否大于 0.5？”就是两种不同的任务。第一种要求生成一个数值，第二种要求做二分类判断，模型对两种任务的内部处理方式完全不同。

还有比例尺效应。问“0 到 1 之间给个概率”和“0 到 100 之间给个百分比”，结果看似等价，但模型对小数和整数的处理方式不同。有些模型倾向于输出整数百分比，在纯小数域反而表现不稳定。测试时要固定比例尺，并且最好在提示词里给出明确的示例格式，而不是只写一句“输出概率”。

4.2 温度、随机性和多次采样

温度会显著影响概率输出的稳定性。即便 temperature=0，很多模型的解码也不是完全确定的，因为采样算法和并行实现有浮点误差。更不要提 temperature=0.7 时，同一个问题跑五次能出五个不同的概率值。

我在测试时会做这样的处理：每个问题重复 10 到 20 次，记录中位数和四分位距。如果四分位距很大，说明这个模型在这个问题上的概率输出很不稳定。这种不稳定性本身就是一种“不可靠”信号，但它和“贝叶斯不一致”是两回事，要分开报告。不要因为某一次跑出来很一致就下结论。

4.3 logprobs 与口头概率是两种东西

前面提过 logprobs 和言语化概率要分开。这里再强调一次：它们经常给出相反结论。

例如，模型在生成“明天会下雨”这句话时，每个 token 的 logprob 都不算低；但当你就同一个事件问它“给出一个概率数值”时，它可能回答 40%。这两个数字并不矛盾，因为它们来自不同的生成路径和不同的推理过程。但如果你的目标是评估模型概率信念的一致性，就必须在同一个路径内部比较，不能在 logprob 和言语化概率之间交叉比较。

4.4 先验过强导致的“证据不足”假象

很多条件概率测试会失败，不是因为模型不会做贝叶斯更新，而是因为它被先验主导。举一个常见场景：你告诉模型“某种疾病的检测结果呈阳性”，然后问“这个人得病的概率”。模型的答案可能更多受“这种疾病常见程度”的先验影响，而不是受“检测灵敏度”的影响。

这不算模型“作弊”，但它说明模型的推理路径不是贝叶斯式的。如果你要研究这个问题，最好把先验信息写清楚，并且用多个不同的先验设置做对照，才能看出模型到底是在做更新，还是在回退到默认判断。只测一个先验设定，很难分清“不一致”和“先验不同”的区别。

5. 不一致性说明什么：结果解读和观察框架

测试做完之后，你会得到一堆不一致分数。怎么解读这些分数，比跑测试本身更重要。

5.1 不一致不是随机噪声，而是有结构的

大多数模型的概率不一致不会均匀分布。它们往往在某些类型的事件上更明显，比如：

• 事件表述很长、带多个从句时；
• 涉及否定、双重否定时；
• 涉及罕见事件或模型没有稳定知识的事件时；
• 数字比例尺超出常见范围时。

如果你发现不一致主要集中在这些类别，说明模型的问题不只是“不会概率演算”，而是“语言理解层面的偏差传导到了概率输出”。这对改进方案有指导意义：可以尝试在提示词里简化表述、避免否定结构，而不是去改模型的推理能力。

5.2 概率极端区域更不可靠

我观察到一个比较普遍的规律：模型在给出 90% 以上或 10% 以下概率时，偏差往往更大。可能是因为训练数据里高置信度断言很多，也可能是因为模型倾向于输出“听起来有力”的数字。

所以当你拿 LLM 概率做筛选时，不要把 95% 和 99% 当作差别很大的两个档位。更稳妥的做法是把概率值先映射到几个粗粒度区间，比如“低 / 中 / 高”，再用于决策。这样既保留了概率的部分信息，又不会被极端区域的不可靠性带偏。

5.3 一致性可以当“预警指标”

虽然 LLM 概率不完美，但可以用一致性测试做预警。在你部署一个新任务前，先跑一组和任务逻辑结构相近的概率测试。如果发现某个类型的事件一致性特别差，你就能提前知道这个任务上不能依赖概率输出做精细决策。

这个思路不要求模型做到百分百贝叶斯一致。你只需要一个门槛：任务允许的误差范围是多少，模型的不一致分数是否在这个范围以内。把门槛写进测试脚本，每次模型升级后跑一遍回归，这比人工抽查可靠得多。模型版本一换，概率行为可能变，但一致性测试的结果能很快告诉你“能不能沿用旧阈值”。

6. 对开发和研究人员来说，这几点可以落地

最后说几个可以直接用到实际项目里的建议。

6.1 别把绝对概率当事实，用相对排序更稳

在很多任务里，你需要的不是准确概率，而是排序。比如 RAG 检索结果重排、候选答案选择、异常检测打分，这类场景只要模型的相对顺序大体正确，绝对数值偏差一点影响不大。用相对排序会大幅降低概率不一致带来的风险。

我在做检索过滤时，通常会把 LLM 输出概率转成排名，再做阈值截断。这样即使模型的 P(A) 和 P(¬A) 相加不是 1，只要它能把“更像正确答案”的排在前面，任务仍然能跑。先保证排序稳定，再考虑绝对档位。

6.2 任务内先做一致性检查，再决定是否采信

如果非要用绝对概率，比如“概率超过 80% 才自动执行”，那就必须先在目标任务的数据上做一致性检查。检查很简单：找一批和任务结构相同的样例，针对同一逻辑事件问多个等价版本，看概率是否稳定。

• 同一断言，换措辞；
• 补事件；
• 条件方向互换；
• 用百分比和小数两种方式问。

如果这些测试的一致分数在可接受范围内，再考虑用绝对阈值。否则建议降级为排序 + 人工兜底。不要因为模型在演示样例上表现好，就直接上生产环境。

6.3 几个值得关注的方向

这个方向的研究还有很多没做完。比较值得关注的有几个：

• 一致性约束解码：在生成概率时强制满足补事件或可加性约束；
• 一致性感知提示：让模型先检查自己前后回答是否矛盾；
• 分层概率校准：对不同的逻辑结构分别校准；
• 把一致性测试做成标准化基准，方便不同模型之间横向对比。

这些都是开放问题，目前没有谁能说已经解决了。对普通开发者来说，最重要的是先建立“概率不等于事实”的认知，再通过测试知道自己的模型在什么时候可以信任。

回到最初的问题：LLM 是否符合贝叶斯？答案不是简单的是或否。它更像“在某些局部、某些任务上，模型会表现出近似的贝叶斯行为；但一旦进入更复杂的逻辑关系组合，不一致就会浮现”。做一个系统化的一致性测试，比争论哲学定义更有价值。你至少能知道，在哪些场景下可以安心用概率，在哪些场景下要加一道保险。