Skip to content
←

필사 모드: LLM 做不到的不是证明，而是立起前提

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

换了三次模型，结果却一模一样的那个项目

假设你做过一个内部工具，从日志里找出异常模式并给出原因假说。每次把模型换成最新的，句子确实更好了，但吐出来的假说清单几乎原封不动。发布时间点、流量激增、缓存未命中、依赖服务延迟。和半年前跑出来的清单一样。

在把这件事当成提示词问题、砸进去几周之前，值得先考虑另一种可能：不是模型偷懒，而是「造出清单上原本没有的新条目」这件事本身，就是当前结构里不会产出的那一类工作。

归纳、演绎，以及缺掉的那一格

Google DeepMind 的 Tom Zahavy 提交给 ICML 2026 的立场论文 Position: LLMs can not jump 把推理分成三支：从数据中提取规则的归纳，从前提推出结论的演绎，以及为解释观察而立起新假说的溯因。

论文的主张把前两者和剩下那一个明确切开。生成式 AI 已经掌握了统计模式匹配，也就是归纳，对应形式化证明的演绎也在被快速攻下。但对于造出新解释性假说的溯因，论文的立场是：这种机制根本就不存在。标题里的「跳跃」指的正是从经验跨到公理的这个动作。

这个区分之所以有用，是因为在实务里这两种失败看起来完全不同。演绎弱的模型会给出错误答案。没有溯因的模型不会错，但每次都给你同一份清单。后者在性能指标上几乎看不见。

爱因斯坦这个案例在论文里承担了什么

论文用广义相对论的建立作为案例研究。这个选择不是装饰，而是论证的核心。

当时的观测数据很稀薄。水星近日点的进动差不多就是全部了，而从那点数据里能统计地提取出来的，大概只是对牛顿力学的一个小修正。等效原理这个前提不是压缩数据压出来的，它是在数据之外被立起来，然后才用数据去检验的。

论文要指出的正是这里。那个前提一旦被给定，从它走向场方程的这段演绎，现代 LLM 是能像模像样地完成的。做不到的是立起那个前提的那一侧。

「创造力即压缩」在哪里塌掉

这个案例直接瞄准了一种被广泛接受的观点：创造力归根到底就是把数据解释得更短的能力，因此更大、压缩得更好的模型最终也会做出发现。

论文认为，这个观点在观测数据稀薄的发现上并不成立。压缩要先有可压缩的对象才运转得起来。在数据稀薄的地方立起一个新解释，是与压缩不同的运算，因此不会随着把模型做大而自动跟着来。

论文点名的瓶颈是把仿真翻译成形式公理的那一段，它给出的方向则是用物理上自洽的多模态世界模型来供给感官层面的依据。只靠文本训练出来的模型，是从「关于世界写下来的句子」里学世界怎么运转的。当它必须立起一个还没有人写过的解释时，那套训练信号无处可依 —— 这是整个论旨的核心。

这是立场论文，不是结果论文

关于读法有一点需要说清楚。ICML 的 Position 赛道不是刊登新实验结果的地方，而是刊登「这个领域该往哪个方向走」这类主张的地方。标题上的前缀就把这个事实写明了。

所以这篇论文并没有用实验去证明「LLM 做不了溯因」。它把一次历史性的发现当作计算层面的案例研究，论证的是：以当前的训练目标，没有理由认为能够到达那一段。这不是缺点，而是这种体裁的性质，相反的立场同样可以从同一个赛道里出来。它也是作者个人的立场表态，没有理由读成其所属机构的官方观点。

对实务者来说，有用的读法是这个：与其急着判定它是真是假，不如去看假定它为真时，你的设计会有哪里发生变化。

把假说空间放到模型之外去供给

第一个变化是角色的摆放。与其让 LLM「自己想出」一份假说清单，不如由系统造出一个可枚举的空间，让 LLM 去扫、去翻译、去排序。

回到前面的日志分析例子：不要用自由文本接收原因假说，而是把服务依赖图、最近的发布列表、配置变更历史、基础设施事件展开成笛卡儿积来生成候选。候选数量会到几百个，人是看不完的。这时 LLM 的角色不是提出者，而是过滤器兼翻译器。这不是把模型往低了用，而是把它放到它擅长的那一段上。

"""假说来自一个可枚举的空间，模型负责扫过并排序。"""
from dataclasses import dataclass
from itertools import product


@dataclass(frozen=True)
class Hypothesis:
    subject: str      # 什么东西
    change: str       # 发生了怎样的变化
    mechanism: str    # 通过哪条路径造成症状

    def as_claim(self) -> str:
        return f"{self.subject}的{self.change}通过{self.mechanism}造成了症状"


def enumerate_space(services, changes, mechanisms):
    """假说空间的大小与边界由代码持有。"""
    return [Hypothesis(*t) for t in product(services, changes, mechanisms)]


def refutable(h: Hypothesis, evidence: dict) -> bool:
    """可反驳性检查：用来确认它的观测是否真的存在。"""
    return h.subject in evidence and h.mechanism in evidence[h.subject]


space = enumerate_space(
    services=["payment-api", "session-cache", "search-index"],
    changes=["发布", "配置变更", "容量缩减"],
    mechanisms=["连接池耗尽", "缓存未命中激增", "超时传播"],
)
evidence = {"payment-api": {"连接池耗尽", "超时传播"}}

testable = [h for h in space if refutable(h, evidence)]
print(len(space), "个候选中，能用观测验证的有", len(testable), "个")
for h in testable[:3]:
    print("-", h.as_claim())

这里要紧的是 enumerate_space 是代码这个事实。系统能发现什么的上限，写在这个函数里而不是写在提示词里，于是它可以被评审，也可以被扩大。

不要把提出和反驳交给同一个模型

第二个变化是角色的分离。把出假说的一方和砸假说的一方放进同一次调用，结果很容易倒向那些「自己能通过」的假说。这不是模型不老实，而是目标函数的问题。一次性要求一个好答案时，可反驳性低的答案看起来反而更像好答案。

于是把流水线这样切开。提出阶段把候选铺开，不打分。反驳阶段针对每个候选，分别写出「如果它为真就必然能看到的观测」和「如果它为真就绝不能看到的观测」，再拿这些观测去真实数据里查。人只看最后活下来的那几个。

把反驳阶段拆成单独一次调用，还会带来一个副产品：写不出「为真就绝不能看到的观测」的假说会被自动筛掉。这类假说通常是不可反驳的表述，也就是不管观测到什么都能活下来的句子。这些句子读起来像模像样、却不含任何信息，在实务中最消耗时间。

这种摆法的好处是，即使论文的主张是错的，你也不亏。如果下一代模型真的做起了溯因，那提出阶段的候选质量就直接变好了。结构原样不动。

哪些是我们的问题，从哪里开始是论文的问题

最后要把范围划清楚。论文谈的是科学发明，也就是立起新公理这个量级的跳跃。我们每天做的系统，绝大多数并不要求那个层级的跳跃。

所以把这篇论文概括成「LLM 没有创造力」，是概括过头了。更准确的概括是这一句：在已知假说空间内搜索，与把这个空间本身撑大，是两种不同的工作，而当下的工具在前者上强得多。 因此我们该先问自家系统是否需要后者；如果需要，就必须在设计里写明那一部分由人或仿真器来承担。

回到开头那个日志工具：半年都吐出同一份清单，原因很可能不在模型，而在于根本没有任何地方定义过那份清单。

参考资料

현재 단락 (1/54)

假设你做过一个内部工具，从日志里找出异常模式并给出原因假说。每次把模型换成最新的，句子确实更好了，但吐出来的假说清单几乎原封不动。发布时间点、流量激增、缓存未命中、依赖服务延迟。和半年前跑出来的清单一...

작성 글자: 0자원문 글자: 3,574자작성 단락: 0/54