ReaComp：把 LLM 的推理编译成符号求解器

论文：ReaComp: Compiling LLM Reasoning into Symbolic Solvers for Efficient Program Synthesis 作者：Atharva Naik, Yash Mathur, Prakam, Carolyn Rose, David Mortensen 链接：https://arxiv.org/abs/2605.05485

一、从一个痛点说起

你可能已经体验过 o1、DeepSeek-R1 这类”思维链”模型的能力——它们在推理时生成大量的中间步骤，一步步把问题想清楚。这叫做 test-time scaling：在推理阶段投入更多计算（更多 token），换取更好的答案。

这个思路很有效，但有一个无法回避的问题：贵。

想象一下：每次解一个编程题，模型都要输出几千甚至上万 token 的思考过程。如果你要解 1000 个同类问题，这个思考过程其实大同小异——但模型还是得每次重新想一遍，每次都烧一遍 token。

这就好比一个数学家，每次做同一类型的方程题都要从头推导公式，而不是把公式记下来反复使用。

ReaComp 的核心问题是：能不能把 LLM 的推理过程”固化”下来，变成一个不需要 LLM 就能运行的求解器？

答案是：能。

二、核心类比——LLM 是编译器，不是运行时

这是理解 ReaComp 最重要的一个类比。

我们熟悉的编译器（比如 GCC、LLVM）做的事情是：读取高级代码，翻译成高效的机器码。编译过程本身很慢，但编译出来的程序运行飞快，而且可以反复使用。

ReaComp 把 LLM 放在了编译器的位置：

传统编译	ReaComp
高级语言代码	LLM 的推理轨迹（自然语言）
编译器（GCC）	Coding Agent + LLM
机器码	符号求解器（可执行程序）
编译一次，运行无数次	提炼一次，求解无数次

关键转变：LLM 从”每次推理都要用”变成了”只在提炼模式时用一次”。

测试时，你运行的是编译出来的符号求解器——一个普通的程序，不需要 GPU，不需要 token，零 LLM 开销。

三、方法拆解：从推理轨迹到符号求解器

第一步：收集推理轨迹

给 LLM 几个同类问题的样例，让它用自然语言一步步推理出答案。这些推理轨迹就是”原材料”。

比如，对于程序合成任务，LLM 可能会这样推理：

“先看看输入和输出的关系……输入是 [1,2,3]，输出是 [3,4,5]，差值是 2……再看第二个样例，输入 [0,0]，输出 [2,2]，差值还是 2……所以规律是给每个元素加 2。“

第二步：Coding Agent 读取轨迹，提取模式

接下来，一个 Coding Agent（本质上是另一个被引导去写代码的 LLM）阅读这些推理轨迹，试图从中提取出可复用的解题策略。

它要回答的问题是：“这些推理背后，有没有一个通用的算法模式？”

回到上面的例子，Coding Agent 会识别出：“这是一个映射操作——对列表的每个元素应用同一个变换。“然后它会尝试用代码来表达这个模式。

第三步：构建受限 DSL 和搜索求解器

这是最精巧的部分。Coding Agent 不是直接写一个硬编码的求解程序，而是：

定义一个受限的领域特定语言（DSL）——一组精心选择的操作原语
构建一个搜索求解器——在这个 DSL 的空间里搜索，组合原语来解决问题

为什么要这样做，而不是直接让 LLM 写答案？

因为符号求解器是可验证的。它搜索出的每一个解都可以被执行、测试、确认正确性。而 LLM 直接生成的代码，你永远不知道它是不是碰巧对了。

第四步：测试时零 LLM 调用

编译完成后，你得到的是一个独立的符号求解器。面对新问题时：

求解器在 DSL 空间中搜索组合
找到候选解后验证
全程不需要 LLM

零 token 消耗。

四、直觉理解：为什么这能工作？

推理的本质是模式识别

LLM 在推理时做的事情，很多情况下是在识别和套用模式。比如解数学题时的”这个结构看起来可以用归纳法”，或者编程时的”这是个经典的动态规划问题”。

这些模式一旦被识别出来，就可以用精确的符号规则来表达，而不需要自然语言的模糊描述。

知识蒸馏，但目标是符号程序

你可以把 ReaComp 看作一种特殊的知识蒸馏。传统的知识蒸馏是把大模型的知识转移到小模型（神经网络 → 神经网络）。ReaComp 是把 LLM 的推理知识转移到符号程序（神经网络 → 代码）。

符号程序的优势：

可解释：你能看懂每一步在做什么
可验证：可以形式化地证明正确性
可复用：编译一次，无限使用
零成本：不需要 GPU

类比：教科书 vs 老师

LLM 就像一个家教老师，每次你提问他都要重新讲解一遍。ReaComp 做的事情是：请老师把他会的东西写成教科书——之后你只需要看书，不需要再请老师。

教科书（符号求解器）虽然不如老师（LLM）灵活，但对于它覆盖的知识范围，它更精确、更快速、更便宜。

五、实验结果：真的有用

程序合成任务（PBEBench-Hard）

这是 ReaComp 的主战场。PBEBench-Hard 是一组有难度的程序合成基准测试：

方法	准确率
LLM + test-time scaling	68.4%
ReaComp（纯符号求解器）	84.7%
ReaComp + LLM（混合模式）	85.8%

注意这个结果：

纯符号求解器（不需要 LLM）已经比带 test-time scaling 的 LLM 高出 16.3 个百分点
混合模式进一步提升，但主要收益来自符号求解器

同时 token 使用量减少了 78%。

跨领域迁移：历史语言学

更令人惊喜的是，ReaComp 提炼出的求解器能 zero-shot 迁移到一个完全不同的任务——预测语音变化（历史语言学的经典问题），达到 80.1% 准确率。

这说明 ReaComp 提取出的不是表面模式，而是真正的问题解决策略——这些策略具有跨领域的抽象性和泛化能力。

六、这为什么重要？——三个层面的启示

1. 推理效率：从”用多少算多少”到”一次提炼永久使用”

当前的 test-time scaling 范式本质上是线性的：解 100 个问题 = 100 倍的 token 成本。ReaComp 提出了一种”摊销”的方式：花一次成本提炼出求解器，之后边际成本为零。

对于生产环境中需要反复求解同类问题的场景（代码生成、数据分析、自动化测试），这种范式的成本优势是压倒性的。

2. Agent 编程的新范式：LLM 是架构师，不是工人

当前的 AI Agent 模式是：LLM 每次都在”动手干活”。ReaComp 提出了一种不同的分工：

LLM 作为架构师：理解问题，设计解决方案的结构
符号程序作为执行者：按照架构师的蓝图高效执行

这更像现实中的软件开发流程——高级工程师设计架构，编写自动化工具；工具被反复执行，不需要高级工程师每次都参与。

3. 神经-符号混合系统的前景

ReaComp 的结果指向一个更远的愿景：

LLM（神经）擅长：理解模糊输入、识别模式、创造性思考
符号系统擅长：精确执行、可验证推理、高效复用

把两者结合——用 LLM 来构建符号工具，用符号工具来执行精确任务——可能是 AI 系统走向更高效、更可靠的关键路径。

这不是要取代 LLM，而是让 LLM 做它最擅长的事，然后把重复性工作交给更适合的工具。

七、局限性与思考

任何好工作都有边界，ReaComp 也不例外：

依赖 Coding Agent 的能力：如果 LLM 无法从推理轨迹中提取正确的模式，整个流水线就断了。对于高度复杂或高度创造性的推理，这一步可能是瓶颈。
DSL 设计的权衡：DSL 太简单，表达能力不足；太复杂，搜索空间爆炸。如何自动设计合适的 DSL 是一个开放问题。
适用范围：当前验证主要在程序合成和语言学任务上。对于开放性推理（比如写作、策略规划），符号化是否可行还不清楚。
冷启动成本：虽然摊销后很高效，但”编译”过程本身需要 LLM 参与。对于只需要解一两个问题的场景，直接用 LLM 反而更简单。

八、总结

ReaComp 的核心洞察可以用一句话概括：

不要让 LLM 每次都重新推理，而是让它把自己的推理编译成可复用的符号求解器。

这个思路简洁但深刻。它不是否定 test-time scaling 的价值，而是提出了一种更高效的使用方式——把”运行时推理”转化为”编译时提炼”。

对于 AI 从业者来说，这是一个值得认真思考的方向：在我们的系统中，LLM 是应该一直待在运行时，还是可以退到幕后，成为工具的构建者？

答案可能取决于具体场景。但 ReaComp 至少证明了：在很多重要场景中，让 LLM 退到幕后，效果反而更好。

📝 本笔记基于 arXiv:2605.05485 论文撰写，面向有 LLM 和编程基础的开发者。目标是帮助理解核心思想，而非复现实验细节。如需深入，请阅读原论文。