沙漏推理：为什么让模型“忘掉中间过程”反而更会归纳

一句话概括：这篇论文最有意思的地方，不是又提出了一个“多步骤推理流程”，而是把一个很常见、但很少被讲清楚的问题说透了：当模型在同一个上下文里同时看到原始样例、自己写过的代码、报错信息和修复指令时，它很容易学会“让这几个例子通过”的补丁，而不是恢复背后的规则。

我们平时说 LLM 会自我修正，听起来像一个自然能力：先做一版，跑一下，错了就改。可在需要少样本归纳的任务里，这个过程经常不但不变好，反而更糟。论文《Think Through a Bottleneck: Hourglass Reasoning for Rigorous Induction》给出的答案很直觉：自我修正失败，不一定是因为模型不会想，而是因为它想的时候看见了太多不该一起看的东西。

先看一个小机制：为什么“改到通过”不等于“找到规则”

想象我们给模型三组输入输出格子，让它推断第四个格子的输出。真正的目标是找到一个抽象规则，比如“把每个封闭区域里的锚点沿对角线镜像”。但模型第一次写出的程序没通过训练样例，于是我们把错误反馈丢回去：第一个样例差了两个像素，第二个样例某个颜色没动。

这时模型有两条路。

一条路是重新审视规则：是不是锚点定义错了？是不是镜像轴应该用相对位置而不是绝对坐标？这条路慢，但它会改善泛化。

另一条路是直接补代码：如果颜色是 3 就额外移动一下；如果坐标在左上角就特殊处理；如果训练样例二失败，就加一个分支。训练集立刻变好，但测试格子一换，补丁就露馅。

这就是论文说的 shortcut learning 和 patchwork logic。模型不是没有推理，而是在密集、无边界的上下文里，被错误日志和当前 artifact 拉向了最短路径。它优化的是“眼前这几个 support examples”，不是“潜在规则”。

所以关键问题不是“要不要让模型解释规则”。很多方法已经会要求模型先写规则、再写代码。问题是：当错误反馈来了以后，这个规则是否仍然是唯一的修复对象？如果模型可以绕过规则，直接编辑代码，那么“先解释规则”只是软约束。软约束在压力下很容易失效。

论文把这个失败点换成了一个结构问题：信息应该怎样流动？

沙漏的窄腰：只允许 ϕ 和 T 通过

Hourglass Reasoning 的设计很简单，名字也很贴切。上面是少量样例，下面是最终答案，中间有一个很窄的腰。模型可以在每个阶段展开大量临时分析，但跨阶段时，只能带走一个压缩后的符号状态。

这个符号状态由两部分组成。

第一部分叫 ϕ，可以理解成“怎么读输入”。在 ARC 这种格子任务里，它不是列出每个像素，而是描述哪些东西是容器、锚点、路径、对称轴，位置关系应该用相对坐标还是绝对坐标，连通性是 4-neighbor 还是 8-neighbor。它像一个解析器，把原始输入压成有角色、有结构的对象。

第二部分叫 T，可以理解成“怎么从输入变输出”。它不说“把第 5 行第 3 列涂红”，而说“对每个由 ϕ 定义的 Anchor，按输入中抽取出的 cue 做某个参数化变换”。它像一个解码器，用规则生成答案。

中间还有一个临时脚手架 z。z 可以很具体，可以列出每个 support example 里观察到的对象和线索。但它只服务于推导 T。推导完成后，z 被丢弃，不能继续传下去。

这一步很关键。论文不是说“中间思考越少越好”。恰恰相反，模型可以在某个阶段里想很多。但这些想法不能原封不动地污染下一个阶段。能穿过瓶颈的，只有被压缩成 ϕ 和 T 的规则。

完整流程分成四步。Induction 从 support set 里产生 ϕ 和 z。Deduction 用 ϕ 和 z 推导 T，然后丢弃 z。Implementation 把 ϕ 和 T 编译成可执行 artifact，比如 Python 程序、Verilog，或者文本推理计划。Refinement 如果发现训练样例没过，不是直接修输出，而是在新上下文里修 ϕ 和 T，再从头生成 artifact。

每一步都是独立 API 调用，没有共享聊天历史。Support set 可以稳定提供；当前 artifact 和验证反馈可以进入修复阶段；但历史草稿、旧错误、临时分析不会全部堆在一个长上下文里。这就是论文所谓 context isolation。

从信息瓶颈的角度看，Hourglass 做的事并不是数学上严格压缩互信息。作者也承认这是一个 prompt-level 的软瓶颈。但工程上，它把“哪些信息可以留下”变成了可执行的流程约束：你可以用临时细节帮助推理，但最后必须把它们蒸馏成规则。

数字最亮的地方：ARC 和芯片综合

论文在三个方向上测试了这个想法：视觉抽象、硬件逻辑综合、文本规则归纳。所有实验使用两个模型：GPT-5.5 和 Gemini 3.1 Pro。主 baseline 是 Self-Refine，最多五轮修复，和 Hourglass 对齐任务定义、反馈格式和迭代次数。

先看 ARC-AGI-2。这里每个 puzzle 都由少数输入输出格子定义一个精确变换，评分要求像素级完全匹配。论文使用公开的 120 个 evaluation puzzles，并报告 pass@1 / pass@5。

GPT-5.5 上，Self-Refine 是 51.9 / 62.8，Hourglass 变成 60.6 / 76.8，best-of-5 提升 14.0 个点。Gemini 3.1 Pro 上，Self-Refine 是 54.4 / 76.9，Hourglass 是 62.4 / 86.7，best-of-5 提升 9.8 个点。

这组数字说明的不是“写更长 prompt 有用”。因为后面的消融会显示，很多辅助提示词删掉以后，效果还在。它更像是在说：对于 ARC 这种少样本规则任务，错误反馈如果直接作用在代码上，会诱导局部补丁；如果反馈必须先改规则，再重生成代码，泛化会更稳。

ChipBench 的信号也很强。这个 benchmark 要模型从自然语言规格生成硬件逻辑，要求通过 100 个动态随机测试向量，基本没有“差不多对”的空间。论文评估两个子任务：Reference Model Generation，也就是 Python 参考模型；以及 Verilog Synthesis，也就是可综合 RTL。

在 Reference Model Generation 上，GPT-5.5 的 Hourglass 是 73.3 / 82.2，强于 Native Baseline 的 60.0 / 66.7 和 Codebook-SR 的 55.6 / 64.4。Gemini 3.1 Pro 上，Hourglass 是 75.6 / 82.2，比最强 baseline 的 pass@5 高 20.0 个点。

更醒目的是 Verilog。GPT-5.5 的 Native Baseline pass@1 是 31.1%，Codebook-SR 是 44.4%，Hourglass 到了 57.8%；pass@5 从最强 baseline 的 51.1% 到 66.7%。也就是常被概括成“31% 到 58%”的跃迁。Gemini 上提升没这么夸张，但 Hourglass 仍然从最强 baseline 的 51.1 / 57.8 到 53.3 / 62.2。

为什么芯片任务适合这个方法？因为硬件规格天然需要一致性。一个状态转移、优先级规则、位宽常量，如果在局部修补中被改歪，动态测试很快会抓出来。Hourglass 先把规格整理成符号 codebook，再用隔离流程生成和修复，相当于强迫模型始终围绕“行为表、状态转移、优先级、位宽”这些稳定对象工作。

最有教育意义的失败：语言归纳不是全面胜利

BBEH-Linguini 更复杂。它来自语言奥赛式 puzzle：给少量语言对，让模型推断隐藏的语法或词形变化规则，再应用到新句子。这里不能写代码，模型必须生成和执行文本规则。论文还做了预处理：从原始 200 个问题里去掉 48 个无法预先对齐的 unordered-pair 问题，再去掉 8 个标注方向模糊的问题，得到 144 个干净任务。

这组结果非常值得诚实看。

GPT-5.5 上，Raw Prompt 是 58.3 / 67.4。Self-Refine 不是提升，而是崩到 25.0 / 27.8。Hourglass 恢复到 46.5 / 63.1，明显比 Self-Refine 好，但 pass@1 和 pass@5 都低于 Raw Prompt。

Gemini 3.1 Pro 上，Raw Prompt 是 64.6 / 68.1，Self-Refine 同样塌到 32.6 / 33.3。Hourglass 是 63.1 / 79.9：pass@1 略低于 Raw Prompt，但 pass@5 反超 11.8 个点。

这说明两件事。

第一，显式规则化本身可能有损耗。语言 puzzle 里有很多细微知识：格、数、性、词序、音变、例外。把隐约的模式强行写成自然语言规则，可能会丢掉细节。论文称之为 lossy compression。

第二，Hourglass 不是万能药。它能缓解 Self-Refine 的上下文纠缠，让规则更稳定、更可执行；但如果任务本身依赖很多难以写全的语言知识，或者压缩成自然语言规则时已经丢信息，它也不能凭空恢复。GPT-5.5 上低于 Raw Prompt，就是一个重要边界。

这反而让论文更可信。一个方法如果在所有场景里都“全面超越”，我们要怀疑它是不是只挑了好看的指标。Hourglass 的优势很明确：当任务有精确、可验证、可重生成的规则时，它很强；当规则本身模糊、知识密集、压缩损耗大时，它只能减少一部分伤害。

真正的消融：不是格式，不是提示词，是隔离拓扑

论文最关键的证据在第 5 节消融。作者问了一个很重要的问题：Hourglass 到底赢在哪里？是因为提示词写得更细？是因为 ϕ 和 T 的模板更规整？还是因为真的需要物理隔离上下文？

他们在 ARC-AGI-2 上做了五个变体。

Weak-Init 用较弱模型做 Induction、Deduction 和 Implementation，只保留强模型做 Refiner。如果修复器本身足够强，它应该能救回来。结果 GPT-5.5 从 Full 的 60.6 / 76.8 掉到 40.1 / 61.4；Gemini 从 62.4 / 86.7 掉到 54.3 / 74.6。这说明初始压缩质量很重要。瓶颈不是随便压都行。

Plain 删掉所有辅助提示，只保留最小任务描述和输出格式。结果 GPT-5.5 是 59.9 / 79.3，Gemini 是 70.1 / 87.5，没有塌。Unstructured 去掉 ϕ 和 T 的结构化格式约束，GPT-5.5 是 58.6 / 76.4，Gemini 是 73.6 / 89.0，也没有塌。

这两组数字把“prompt engineering”解释基本排除掉了。至少在这篇论文的设置里，具体措辞和固定字段不是主要来源。

最锋利的是 Struct-SR。它让 Self-Refine 也输出同样格式的 ϕ 和 T，但所有生成、执行、反馈仍然待在一个单一上下文里。也就是说，有符号中间物，但没有物理隔离。结果 GPT-5.5 是 41.5 / 59.9，Gemini 是 31.6 / 62.8，比普通 Self-Refine 还糟。

这就是论文的核心证据：写出结构化规则不够。规则必须成为阶段之间唯一、受控的通道。否则它只是同一个混乱上下文里又多了一段文本，反而增加可纠缠的信息。

还有一个有趣细节：Code-Only 变体让 Refiner 不再接收 ϕ 和 T，只看当前失败 artifact、support set 和反馈，但仍保持角色隔离。它在 GPT-5.5 上只从 60.6 / 76.8 小幅降到 58.1 / 74.7；Gemini pass@1 甚至更高，但 pass@5 降到 79.9。作者的解释是，代码本身可能已经隐式携带了从 ϕ 和 T 编译出来的结构。换句话说，显式符号不是每一轮都必须可见；更重要的是 artifact 的生成历史受过瓶颈约束。

这篇论文证明了什么，又没有证明什么

我们可以把边界说清楚。

论文证明得比较强的是：在它测试的三个 benchmark 上，把归纳、推导、实现、修复拆成隔离阶段，并只让压缩符号状态跨阶段流动，能显著改善少样本归纳任务里的自我修正。ARC-AGI-2 的 +14 best-of-5、ChipBench Verilog 的 31.1% 到 57.8%、以及 BBEH 上 Self-Refine 崩溃而 Hourglass 部分恢复，都是很具体的证据。

论文也通过消融说明：收益主要不是来自漂亮模板或额外提示词。Plain 和 Unstructured 仍然接近或超过 Full；Struct-SR 说明“同样写 ϕ 和 T，但不隔离上下文”不够。这个证据链很干净。

但论文没有证明几个更大的命题。

第一，它没有证明 LLM 获得了人类式抽象能力。Hourglass 是一个测试时工作流，不更新模型权重，也不把跨任务策略长期保留下来。每个任务解决后，ϕ 和 T 就被丢掉，下个任务重新归纳。

第二，它没有给瓶颈提供形式化保证。ϕ 和 T 是自然语言，隔离靠 prompt 和 API 调用实现，不是模型架构里的硬约束。模型仍然可能在 ϕ 或 T 里偷带无关细节，只是流程降低了这种泄漏的机会。

第三，它不是 compute-matched 的胜利。论文明确写到，角色隔离会增加 API 调用、token 和延迟。GPT-5.5 单次运行平均 61,911 tokens / 3.7 calls，Self-Refine 是 19,594 tokens / 1.4 calls，约 3 倍 token；Gemini 是 122,007 tokens / 4.4 calls 对 61,426 tokens / 1.7 calls，约 2 倍 token。作者没有做预算匹配实验。

第四，ARC-AGI-2 使用公开 evaluation set，潜在预训练暴露是所有相关方法共享的限制。附录里的 competition mode 很亮眼——比如 N=2 时 pass@2 87.8%、平均约 $3.98/task，oracle ceiling 91.4%；N=4 oracle 到 95.4%、约 $11.30/task——但作者也强调这是探索性次要结果，不是主贡献。

为什么这件事值得记住

这篇论文最值得带走的，不是某个具体 prompt 模板，而是一种关于推理系统的设计直觉：有时候，让模型看见更少东西，反而是在让它更好地思考。

今天很多 agent 系统的默认方向是把上下文做大，把历史都塞进去，把工具调用和错误日志都保留。这样做在开放式任务里很方便，但在精确归纳任务里，历史不是纯资产。历史里有错误、有偶然成功、有局部补丁、有已经被推翻的假设。把这些东西持续暴露给模型，会让下一轮推理被污染。

Hourglass 的反直觉之处在于，它不是增加一个更聪明的 judge，也不是让模型反思更久，而是重新规定信息的边界：临时推理可以存在，但必须过期；错误反馈可以使用，但必须通过规则修复；artifact 可以重生成，但不能把旧补丁当作长期记忆。

这也解释了为什么“自我修正失败”不是一个单纯的模型能力问题。它是模型能力和系统拓扑共同产生的结果。同一个模型，在一个单体上下文里会修出补丁；在一个沙漏式流程里，可能会更稳定地回到规则。

如果未来有 Meta-Hourglass，像作者在讨论里设想的那样，把每个任务内诱导出的策略长期积累成跨任务 meta-strategy，那会是更大的故事。但就这篇论文本身而言，结论已经足够清楚：在少样本、精确、可验证的归纳任务上，真正重要的不是让模型“多想几步”，而是让每一步之间只传递该传递的东西。

有时候，推理能力不是从更大的上下文里长出来的，而是从一个更窄的瓶颈里被迫成形的。