可验证的搜索不是可学习的 Chain-of-Thought

TL;DR 对于需要回溯搜索的任务（如密码算术），通过链式思维微调根本无法学会搜索本身，模型只能记忆验证模板，而非前向推理。

问题

问题背景

当前大语言模型（LLM）的推理能力提升高度依赖思维链（Chain‑of‑Thought, CoT） 与有监督微调。业界普遍假设：只要一个任务可用简短程序求解，将其逐步求解过程转化为 CoT 数据并微调，模型就能学会遵循该过程。

现有方法的局限

然而该假设在回溯搜索类任务上失效。论文在九个确定性生成器构建的推理任务上测试发现：前向可计算任务（查表、算术、8‑bit 布尔操作）的 CoT 蒸馏能够顺利迁移（准确率 ≥ 0.99 和 0.68），但密码算术（cryptarithm） 的失败极为显著——尽管其回溯搜索求解器能解决 71% 的样本，但通过 11 种 CoT 设计微调、基于可验证奖励的强化学习（RLVR） 和自训练后，蒸馏出的模型准确率始终停滞在 0.01–0.07。模型并非能力不足：它对每行算术运算的正确率达 97–100%，在 71% 的样本中将正确密码排在前八候选，却无法将搜索过程推进为从左到右的推导。微调学到的是“判决即令牌（verdict‑as‑token）”：生成形似验证步骤的序列，判决却退化为无条件模板（正确率仅 16–57%）。这表明，当过程的唯一解是在无信息结构中搜索时，就不存在忠实的前向 CoT 可供模仿。

为什么这个问题难且重要

技术挑战在于，许多现实推理任务（规划、定理证明、符号求解）天然包含搜索。Transformer 架构即便在长上下文和强化奖励信号下，似乎也倾向于记忆模式而非执行搜索。如果“模仿搜索”存在根本性天花板，单纯扩大模型或增加数据将无法突破，这对构建通用推理引擎的路线构成根本质疑。业界关注度已从静态问答转向真实过程监督与推理，此类发现直接影响合成数据生成策略和 RL 对齐路径的选择。

行业类比

如同在自动驾驶规划中，仅靠模仿人类驾驶轨迹而不学习动态搜索与路径规划，模型在未见过的复杂路口极易失效；符号推理任务中若只模仿解表面轨迹，模型无法掌握内在的组合搜索逻辑。

核心洞察

• 当任务过程需要回溯搜索（如密码算术）时，不存在忠实的、前向的链式思维（CoT）推导路径，因此监督微调无法让模型学会搜索，只能拟合出浅层的表面模式。 这一发现解释了为何许多生成式奖励（verifiable reward）看似充足的推理任务，在蒸馏搜索过程时依然失败——与传统前向计算任务（如算术、查表）可轻易蒸馏不同，搜索类任务无法被压缩为单向因果序列，模型学到的是条件判断的「空壳」，而非真正的回溯能力。
• 失败的典型信号是「verdict-as-token」现象：模型在教师强制训练后，生成的条件判断模板化且与上下文证据脱钩，正确率仅16-57%。 这揭示了暴露偏差的极端案例：模型在自回归生成中一旦无法回溯修正，便退化为无条件输出统计上常见的判断词，而非执行动态验证。该现象为诊断搜索类任务可否蒸馏提供了可操作的判据：若验证步骤的正确率远低于单步算术正确率，则表明模型未掌握搜索。
• 将搜索任务转化为「目录查找+验证」可修复不可学习性：通过预先计算搜索的组合核心并构建查找表，推理过程退化为回忆加校验，第一名的方案在测试集上达到0.92准确率。 这为工程实践提供了明确指引：面对需要搜索的推理任务，不应盲目期待模型通过链式思维串联学会搜索，而应主动将搜索结构外置，使模型仅需调用记忆和简单校验，从而绕过前向推导不存在的结构性障碍。

方法

输入与求解器构造：研究者构建了一个包含九个推理任务的确定性生成器基准，手动逆向每个生成器得到 Python 求解器，确保思维链每一步的真实性。任务分为前向可计算（查找、算术、布尔运算）和需回溯搜索的密码算术。

思维链渲染与蒸馏：求解器执行轨迹被转化为文本 CoT，用作训练数据。在 Nemotron 30B 模型（激活 3.5B）上，使用 LoRA（秩 ≤ 32）进行有监督微调。针对密码算术任务，尝试了 11 种不同的 CoT 设计，包括显式回溯记录、分支消去等。

强化学习与自训练尝试：除监督微调外，还引入可验证奖励强化学习（RLVR）：用求解器判断答案正确性作为奖励；以及自训练循环。这些均未改善密码算术任务的低准确率（0.01–0.07）。

失败诊断与控制实验：分析显示，模型能逐行完成算术（97–100% 准确），并在 71% 样本中将正确密码排在前 8，但无法连贯执行搜索。微调习得的消除步骤沦为**“判决即令牌” （verdict-as-token）**，正确率仅 16–57%。关键对照实验：若揭示密码密钥，将搜索转为正向推导，同批样本准确率从 0.03 升至 0.57，证明根本瓶颈在于缺乏可模仿的正向思维链。

差异点：不同于依赖人类或模型自举生成 CoT 的工作，本方法从程序执行的真实轨迹出发，直接检验过程的可蒸馏性，首次系统揭示了回溯搜索在 transformer 蒸馏中的根本局限。

实验

实验设计

作者构造了9 个确定性生成器产生的推理任务，分为公开/隐藏分割，共享生成器以保证分布一致。逆向工程出 Python 求解器，将其执行过程渲染为思维链（CoT），并通过 LoRA 微调（rank ≤ 32）蒸馏到 30B Nemotron 模型（激活参数 3.5B）。针对 cryptarithm 任务，测试了 11 种 CoT 设计、基于可验证奖励的 RL 和自我训练，并进行关键干预：揭示密码密钥使推导前向化。

关键发现

前向可计算任务（查表/算术、8 位布尔运算）的蒸馏准确率分别达 ≥0.99 和 0.68，模型成功习得程序。但 cryptarithm 的蒸馏准确率始终在 0.01–0.07，而搜索求解器可解 71% 实例。模型并非能力不足——每行算术准确率 97–100%，71% 情况下正确密码排在前 8——而是无法将搜索作为从左到右的推导执行。微调仅学到验证步骤的“形状”，判断沦为无条件模板，正确率仅 16–57%（“判决即令牌”）。揭示密钥后，相同实例准确率从 0.03 跃升至 0.57，证实瓶颈在于缺乏忠实的前向 CoT。第一名方案将搜索预计算为目录，将轨迹简化为回忆+验证，private LB 达 0.92。

深度解读

该工作严格证明：当程序唯一解是信息自由结构上的回溯搜索时，不存在可模仿的前向推导，微调只能捕获验证模板，而非搜索能力。这推翻“任何短程序均可蒸馏”的假设，并划定了 CoT 学习的边界。与关注架构容量的研究不同，实验通过任务结构隔离确认失败源于程序属性，而非模型规模或微调方法。对工程实践而言，这意味着搜索密集型任务无法单纯用 CoT 微调解决，必须将搜索部分外包给符号求解器或预计算为查表，模型仅负责验证与记忆，才可能突破天花板。

行业影响

落地场景

当前大量 AI 产品试图通过链式思维(CoT)蒸馏让大模型学会复杂推理，例如数学解题助手、代码生成工具、逻辑谜题求解器。这篇论文指出，对于需要回溯搜索的任务（如字母算术 Cryptarithm），模型无法通过模仿前向推导学会真正搜索，只能记忆模板并通过验证输出答案。因此，在以下场景中必须避免强行蒸馏：

• 自动化推理系统：需要搜索的规划、调度、约束满足问题，直接微调模型效果极差。
• 可解释 AI 生成：若要求模型输出完整推理步骤以增加可信度，对搜索类任务反而会产出表面上连贯但逻辑错误的幻觉式推导。

商业价值

• 降低训练成本：识别“不可学习”的程序类别，避免在无意义的 CoT 数据生成和微调实验上浪费计算资源。
• 提升产品可靠性：通过区分前向可计算任务与搜索依赖任务，将后者交给符号求解器或预计算目录，可大幅减少错误率。案例中，将搜索问题转化为记忆+验证后，准确率从 0.03 跃升至 0.92，直接提升用户体验。
• 增强模型可信度：避免模型产生“因果链断裂”的推理，减少在高风险领域（如金融分析、医疗诊断推理）的决策失误。

与现有产品/工作流的接口

论文的方法可直接集成到现有的LLM 工作流中：

1. 任务分类器前置：在调用微调模型前，快速判断任务是否包含信息无结构的搜索（如存在大量回溯）。若为搜索类，则路由到外部符号求解器（如 Python 执行器）或**检索增强生成(RAG)**中的预计算目录。
2. 混合系统架构：对于 CoT 蒸馏可行的部分（如算术、查表），继续使用LoRA 微调的轻量模型；对不可行部分，保持经典算法求解，并通过验证器（如奖励模型）集成结果。
3. 训练数据质量门禁：根据论文提出的前向可推导性测试，过滤不适合 CoT 蒸馏的数据，仅保留可忠实推导的轨迹，提升合成数据的有效性。

具体落地 Use Case

• 教育科技 — 自动解题与辅导：平台提供字母算术谜题，若让 LLM 直接生成解题步骤，成功率仅 0.01-0.07。改用目录化预计算：提前算出所有可能映射，生成“调取记忆+验证”的 CoT，准确率飙升至 0.92。系统可在后端无缝切换策略，为学生提供即时、准确、可解释的解答。
• 电商搜索与推荐 — 复杂规则调试：供应链优化中的排程问题往往涉及回溯搜索。直接微调 LLM 做排程推理将不可靠，而采用LLM 作为交互界面，将自然语言需求翻译为约束，再调用 MILP 求解器，最后用 LLM 解释结果，兼顾灵活性与确定性。

局限

• **结论适用范围限定于“无信息结构的搜索”任务。** 论文明确指出，只有当问题的唯一求解路径是在无信息结构上执行回溯搜索时，忠实的前向 CoT 才不存在，学习才会失败。对于具备可利用结构或预计算空间可解耦的任务，结论不一定成立。这一前提缩小了结论的普遍性，也暗示了绕行方案（如将搜索核心预计算为目录，将推导转化为**召回+验证**），但该方案已偏离“学习搜索过程”的原始目标，更多是在工程上规避核心难题。
• **实验设置中的微调方法较为单一。** 蒸馏仅采用 rank≤32 的 LoRA，未探索全参数微调或更高秩适配器，尽管作者通过 3B 到 671B 不同骨干模型和 RLVR 验证了天花板效应，但无法完全排除适配容量不足的可能性。此外，任务均由确定性生成器构造，分布简单且无噪声，与现实推理任务存在差距，结论向更复杂、开放域推理场景的迁移性有待进一步检验。
• **与同领域工作相比，缺少缓解策略与正面建模。** 已有工作（如 Dziri 等）指出 Transformer 在多步组合推理中的脆弱性，本文精确刻画了“verdict-as-token”这一失败签名，但并未提出有效的训练策略来恢复搜索能力。未探讨与检索增强生成、工具调用或规划模块的协同可能，而这些方案在实际工程中常被用于弥补 LLM 的搜索短板。作为诊断性研究，其价值在于划定边界，而非提供直接改进路径。