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互补事件的概率相加可加性P(A∪B) P(A) P(B)A、B 互斥互斥事件的概率可加条件概率定义P(A∩B) P(AB)·P(B)贝叶斯公式P(AB) P(B全概率公式P(B) Σ P(BAᵢ)·P(Aᵢ)对每一项约束你可以定义不一致分数。最简单的是“偏差绝对值”约束左边和右边的差。比如补事件法则的不一致分数就是 |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))这个示例只测补事件规则但它足以暴露很多模型的问题。跑通之后再逐步加入条件概率、贝叶斯公式和全概率公式。关于采样参数我有一个明确建议正式测试时用 temperature0 或非常低的值同时每个问题重复多次取中位数。原因很简单高温度会产生随机波动让你分不清不一致是模型本身的问题还是采样噪声。先用低温度确定“模型本身是否一致”再研究“温度对一致性的影响”。4. 实测时最容易误判的几个干扰因素这部分是踩坑经验。我见过很多测试结论最后发现是实验设计的问题不是模型的问题。以下四个干扰因素每次测试前都要先过一遍。4.1 提示词措辞和比例尺效应同样一个事件用不同方式去问得到的概率可能差很远。比如“你估计概率是多少”和“这个概率是否大于 0.5”就是两种不同的任务。第一种要求生成一个数值第二种要求做二分类判断模型对两种任务的内部处理方式完全不同。还有比例尺效应。问“0 到 1 之间给个概率”和“0 到 100 之间给个百分比”结果看似等价但模型对小数和整数的处理方式不同。有些模型倾向于输出整数百分比在纯小数域反而表现不稳定。测试时要固定比例尺并且最好在提示词里给出明确的示例格式而不是只写一句“输出概率”。4.2 温度、随机性和多次采样温度会显著影响概率输出的稳定性。即便 temperature0很多模型的解码也不是完全确定的因为采样算法和并行实现有浮点误差。更不要提 temperature0.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 是否符合贝叶斯答案不是简单的是或否。它更像“在某些局部、某些任务上模型会表现出近似的贝叶斯行为但一旦进入更复杂的逻辑关系组合不一致就会浮现”。做一个系统化的一致性测试比争论哲学定义更有价值。你至少能知道在哪些场景下可以安心用概率在哪些场景下要加一道保险。