Thinking Machines Lab发表的首篇长文《克服 LLM 推理中的不确定性》讲了什么？

说实话，看完Thinking Machines Lab这篇文章，我有复杂的感觉。

这篇文章技术上确实扎实，它解决的主要是"工程层面的确定性问题"（我估计占整个问题的30%左右）。

但"为什么LLM老是给我不一样的答案"的问题，并没深入讨论。

上周我刚好在调一个用vLLM跑的推理服务，遇到的就是这种情况——temperature设成0了，结果每次返回的代码还是不太一样。

看完这篇文章，我明白了一部分原因，但还有很多困惑没解开。

第一个发现：原来"浮点误差"不是主要问题

在看这篇文章之前，我一直以为LLM的不确定性主要是因为浮点数计算精度的问题。

毕竟大家都这么说嘛，“浮点运算有误差”、“并发执行顺序不一样”…

但Thinking Machines Lab直接告诉你：不是这样的。

他们发现真正的问题在于：

大家以为的问题：非确定性 = 浮点运算误差 + 并发执行随机性 实际的根源：非确定性 = atomic操作的顺序问题 + 批处理调度 + GPU的竞争条件

最关键的一点：LLM的前向传播（forward pass）本身其实是确定性的！

没有atomic adds操作，所以理论上给定相同的输入，应该得到相同的输出。

问题出在推理系统的实现方式上，不是Transformer架构本身有问题。

这个澄清很重要。

因为它意味着，至少有一部分问题是可以通过改进工程实现来解决的，而不是说"这个架构就这样了，没办法"。

第二个亮点：给出了实际能用的方案

我最欣赏的一点是，他们不只是分析问题，还给出了具体的解决办法：

1. 避免atomic adds操作：虽然会稍微影响性能，但对大多数神经网络操作来说，“影响可以忽略不计”
2. 用semaphore保证执行顺序：确保每个并发线程块按确定的顺序累加
3. 固定批处理顺序：不让批次处理的顺序变来变去

特别有意思的是他们提到的一个细节：

 “你知道吗，广泛使用的Triton版本FlashAttention backward，算法上其实跟Tri Dao论文里写的不一样！Triton实现在反向传播时做了额外的重计算，虽然避免了atomic操作，但多用了40%的FLOPs！”

这种"内幕"一看就是真正在生产环境踩过坑的人才知道的。

不过说实话，他们的方案主要针对的是推理系统开发者。

如果你只是在用OpenAI API或者Anthropic API，这些底层优化你也管不着。

但至少你知道了，这个问题是可以解决的，只是服务商愿不愿意投入工程资源去做。

还有文章后面的有句话让我印象特别深：

 “我们拒绝这种失败主义。只要稍微努力一点，我们就能理解非确定性的根本原因，甚至解决它们！”

Thinking Machines Lab坚持要找出问题，因为：我们要搞清楚到底哪里出了问题。

这种精神值得鼓励，但是打就要企定，错就要认。

因为…

文章回避了更难的问题

为什么我在实际使用中遇到的很多"不确定性"，这篇文章好像没怎么讨论？

问题1：上下文污染的问题基本没提

上个月我在做一个多步推理的agent，发现了一个特别诡异的现象：

相同的问题，只是因为调用工具的时间不一样（一个是下午2:23，一个是2:47），最后给出的答案正确率能从100%掉到0%。

我当时就懵了——时间戳这种东西怎么会影响推理结果？

后来我查了很多资料才明白，原因是：

Softmax注意力机制的数学特性： 

这个公式意味着，任何token的注意力权重都永远大于0。神经网络没办法把某个token的logit设成负无穷，也就无法完全"忽略"它。

自回归的链式放大：时间戳在第一步造成的微小差异，经过10步推理后被放大了上万倍。

这个问题，Thinking Machines Lab的方案是解决不了的。

因为这不是工程实现的问题，而是Transformer注意力机制的架构约束。

他们文章里虽然提到了"批量归一化依赖并行请求"的例子，但没有深入分析为什么注意力机制会对无关信息这么敏感。

问题2：语义相同但措辞不同的问题

还有一个让我很困扰的问题：

我问Gemini， “What is the capital of France?” 和 “What is France’s capital?”，这两个问题意思完全一样对吧？

但实际上，返回的答案格式经常不一样：

1. 有时候只回答"Paris"
2. 有时候回答"The capital of France is Paris"
3. 有时候回答"Paris is the capital"

虽然事实都对，但这种不一致性在某些场景下（比如我在做结构化输出提取）就很麻烦。

更极端的例子是翻译。

我看过一个案例，用LLM翻译一本科幻小说，里面有个虚构的城市叫"Silver Valley"。

结果整本书里，这个地名被翻译成了12种不同的版本：

1. 意译的：银谷、银色山谷、银谷城
2. 音译的：西尔弗谷、斯尔佛山谷、希尔福谷
3. 还有一些错译：白银峡谷、银矿谷…

传统的机器翻译（那种基于规则或短语表的）反而能保持100%一致。

这说明什么？

增加"智能"和"上下文感知"，反而降低了一致性。

这种问题，Thinking Machines Lab的文章里基本没有讨论。

因为这不是浮点误差的问题，而是统计预测模型的本质特性。

问题3：架构层面的根本局限

我其实对LLM幻觉都研究了很久，其实LLM的非确定性问题分两个层次：

那70%的问题，才是我在实际使用中最头疼的。

比如说，Yann LeCun（卷积神经网络的发明者之一）就批评过，自回归解码可能存在"根本局限"：

1. 只能顺序生成，不能并行
2. 每一步都依赖前一步，错误会累积
3. 无法做全局优化，只能贪婪选择

这些问题，不是优化工程就能解决的，可能需要全新的架构范式。

但Thinking Machines Lab的文章里，对这些更深层的问题几乎没有讨论。

可以换个思路

也许我们不应该试图"消除"LLM的不确定性，而应该学会"管理"它。

为什么这么说？

因为LLM本质上是个统计预测器，不确定性是它的本质特征，不是bug。

类比一下：

1. 逻辑系统：如果A且B，那么一定C（100%确定）
2. 统计系统：如果A且B，那么C的概率是95%（概率性）

人类的认知其实也有很多统计成分。

比如你看到一只黑羊，你会想"这只羊应该全身都是黑的"，而不会谨慎地说"至少我看到的这一面是黑的"。

这就是统计预测。

更好的策略可能是：

策略1：重新定义"成功"的标准

不要去追求"完全确定性"，而是追求：

1. 语义鲁棒性：语义相同的输入，应该给出语义相同的输出（不必逐字相同）
2. 工程可靠性：追求"99.9%可靠"而不是"100%确定"

就像其他工程系统一样：

1. 航空系统：99.999%可靠（5个9）
2. 金融系统：99.99%可靠（4个9）
3. LLM系统：也许99.9%可靠（3个9）就够了

策略2：三层防御体系

既然完全消除不可能，那就建立多层防护：

第一层：源头控制

1. 清洗工具输出，去掉时间戳、ID这些无关信息
2. 标准化用户输入，让语义相同的问法变成统一格式

第二层：检索增强（RAG）

1. 对于事实性问题，用外部知识库保证一致性
2. 比如"法国首都是什么"，直接查知识库返回"Paris"，而不是让LLM"想"

其实这就是GPT5目前的方案。

第三层：验证修正

1. 多次运行取最常见的答案（投票机制）
2. 自动检测答案质量，不合格就重新生成

这些方法虽然不能完全解决问题，但能把不确定性降到可接受的范围。

最后我给这篇文章打分的话…

7-8分吧。

这是一篇优秀的工程文章，但不是"完整解决方案"，缺乏实战~

适合开发vLLM、SGLang这类推理系统的娃，还有需要在生产环境保证可复现性，也挺OK的。

反正你偏向理论，尤其是对底层实现细节方面，也可以喵喵。

但是产品经理、应用开发者、搞研究，这些都是需要完整方案以及要结合其他架构层的方法，那这文就没有这些了……

Thinking Machines Lab这篇文章，让我想起了"工程乐观主义"这个词。

他们相信：只要理解根本原因，我们就能解决问题。

在工程层面，这种精神完全正确，也值得学习。

但面对更深层的架构和本质问题时，也许我们需要的不只是"优化"，还有认知转变：

 不是所有问题都有技术解决方案。有些"问题"其实是新系统的本质特征，我们需要重新定义什么叫"成功"。

就像量子力学的不确定性，不是测量精度的问题，而是物理世界的本质。

LLM的统计不确定性，也是如此。

所以我的建议是：

1. 短期：可以用他们的方案解决工程层问题（那30%）
2. 中期：部署RAG和多路径验证（缓解架构层问题）
3. 长期：接受不可避免的部分，建立新的评估标准

这才是完整的"克服不确定性"之道。