论文:Atom of Thoughts for Markov LLM Test-Time Scaling
代码:https://github.com/qixucen/atom
论文大纲
├── 1 研究背景【提出大规模语言模型推理的需求】
│ ├── 训练规模与推理规模【因果关系】
│ │ └── 大型LLM的性能随着模型参数与数据规模增长而提升,但高质量数据不足【背景介绍】
│ ├── 测试时推理扩展(Test-Time Scaling)【核心需求】
│ │ └── 通过强制模型在推理阶段进行更深入的逻辑推理来弥补数据瓶颈【动机】
│ └── 现有方法的不足【问题描述】
│ ├── 历史信息累积【干扰与浪费】
│ │ └── Chain-based/Tree-based/Graph-based方法常需保留大量中间推理,造成高计算成本【具体挑战】
│ └── 推理有效性下降【副作用】
│ └── 多余的历史依赖可能干扰模型对当前问题的专注度【现象】
├── 2 核心思想:Atom of Thoughts (AOT)【提出Markov式思路】
│ ├── 灵感来源【继承与创新】
│ │ └── 人类分解式解决问题往往可视为“记忆无关”的马尔可夫过程【原理借鉴】
│ ├── 关键特征【理论基础】
│ │ ├── Markov性质【仅依赖当前状态】
│ │ │ └── 每一步的子问题求解不需保留完整历史,直接简化为下一步独立状态【优势】
│ │ └── Atomic Question State【自包含性】
│ │ └── 将复杂问题不断划分成可单独验证的小子问题,有效避免错误累积【好处】
│ └── 整体框架【系统概览】
│ └── 通过“分解 (Decomposition) + 收缩 (Contraction)”的循环,持续简化问题【高层思路】
├── 3 方法与技术细节【两阶段状态转移机制】
│ ├── 分解 (Decomposition)【过程描述】
│ │ ├── DAG结构临时搭建【信息抽取】
│ │ │ └── 利用依赖关系,将当前问题拆成多个子问题,并识别独立/依赖子问题【结构化】
│ │ └── 依赖标注【核心实现】
│ │ └── 以JSON等格式标记子问题间的依赖边,保证DAG有向无环【技术手段】
│ ├── 收缩 (Contraction)【目的:保持Markov状态】
│ │ ├── 子问题合并【去冗余】
│ │ │ └── 将已解的独立子问题作为已知条件并剔除历史过程,仅保留必要信息【简化】
│ │ └── 生成新原子状态【改写问题】
│ │ └── 把尚未解决的依赖子问题收敛成一个新的独立问题,供下一步迭代【过渡】
│ └── 与现有框架集成【兼容性】
│ ├── 与CoT或ToT等方法结合【可插拔增强】
│ │ └── 先用AOT进行“原子化”预处理,再交给这些推理链/树/图算法,减少历史噪声【操作流程】
│ └── 可设置统一终止条件或在任意中间状态切入其他方法【灵活度】
├── 4 实验与结果【实证研究与评估】
│ ├── 多任务评测【数据支持】
│ │ ├── 数学推理(MATH、GSM8K)【准确性】
│ │ │ └── AOT在复杂计算题上取得较高精度,与深度方法相比有明显提升【表现】
│ │ ├── 知识问答(MMLU-CF)与逻辑推理(BBH)【适用性】
│ │ │ └── 同样在多项选择/判断推理方面超过其他基线【结果】
│ │ └── 多跳推理(HotpotQA、LongBench)【优势最大化】
│ │ └── 在需要跨文段和多重条件连接的问题中,AOT相较传统方案显著领先【效果】
│ ├── 计算效率【资源投入对比】
│ │ └── 无需维护所有历史步骤,推理开销更低【收益】
│ └── 消融实验【必要性证明】
│ ├── 去除DAG或分解模块后,性能明显下降【对比】
│ └── 证明了两阶段设计是提升效果的核心【结论】
└── 5 局限与未来展望【总结与改进方向】
├── 局限性【问题保留】
│ ├── 依赖错误时的风险【初始分解】
│ │ └── 若DAG分解不合理,后续收缩会积累偏差,需更精细的质量监控【缺陷】
│ └── 缺少反思机制【无法回溯】
│ └── 当前仅基于Markov过程,无法自主修正早期错误【挑战】
└── 未来工作【展望】
├── 引入自我反省或回退策略【可能方案】
│ └── 结合RL或多次验证,动态检修子问题依赖关系【可行路线】
└── 推广到更多场景【潜力】
└── 为LLM提供更灵活、高效的推理扩展模式【价值】
核心方法:
├── 1 整体流程【从输入到输出的关键路径】
│ ├── 输入:原始问题 (Q₀)【信息来源】
│ │ └── 将待解答的复杂问题(如多跳推理题目、数学题等)以纯文本形式输入【数据形式】
│ ├── 处理:两阶段状态转移机制【核心框架】
│ │ ├── (1) 分解 (Decomposition)【第一阶段】
│ │ │ ├── 调用LLM识别子问题【技术:零样本/少样本提示】
│ │ │ │ └── 依赖自然语言理解能力,将原始问题拆分成若干子问题【语义分割】
│ │ │ ├── 临时构建有向无环图 (DAG)【结构表示】
│ │ │ │ ├── 顶点:子问题 (Qᵢ)【节点映射】
│ │ │ │ └── 边:子问题之间的依赖关系【依赖标注】
│ │ │ └── 目标:识别出“独立子问题”和“依赖子问题”【划分标准】
│ │ ├── (2) 收缩 (Contraction)【第二阶段】
│ │ │ ├── 将已解决的独立子问题转换为已知条件【融合信息】
│ │ │ │ └── 把答案嵌入到新的问题描述中,去除冗余历史推理【精简】
│ │ │ ├── 合并依赖子问题到一个新的自包含问题【生成Markov状态】
│ │ │ │ └── 形成下一个迭代输入,使其仍能独立求解且保持原问题等价【问题重写】
│ │ │ └── 对外输出:新的原子化问题 (Q₁, Q₂, …)【阶段性产物】
│ │ └── (循环) 重复分解与收缩,直到满足终止条件【迭代】
│ │ └── 若最终问题可直接求解,则可调用LLM生成答案【收敛到解】
│ ├── 可选插入:与现有推理方法结合【灵活衔接】
│ │ ├── Chain-of-Thought / Tree-of-Thought / Forest-of-Thought【兼容接口】
│ │ │ └── AOT可先行简化问题,再将新问题交给上述框架继续深度推理【预处理增强】
│ │ └── Self-Consistency / RL推理等高级模块【可插拔扩展】
│ │ └── 在AOT简化后的问题上执行多样化推理策略【进一步提升】
│ └── 输出:最终答案 (A)【结果】
│ └── AOT将收缩阶段累积的已知条件统一纳入,生成原问题的完整解答【完备性】
└── 2 关键技术与衔接方式【各环节如何工作并相互配合】
├── 依赖标注与DAG构建【文本解析】
│ └── 通过LLM识别子问题依赖关系并产出JSON等结构化标记,实现可控的图构建【自动化+可解释】
├── Markov性质保持【状态独立】
│ └── 收缩时只保留当前问题必要信息,摒弃历史干扰,确保下一轮推理只依赖新问题本身【防止冗余累积】
├── 收敛性与终止判断【控制机制】
│ └── 可设定最大深度/自动判别答案一致性来停止迭代,避免无休止拆分【效率保障】
└── 与其他推理策略交互【分工与协同】
├── 提前停止:只进行一次分解-收缩后就可切换至CoT/ToT【浅度整合】
└── 全程协作:在每轮新问题上应用多路径搜索或一致性投票【深度整合】
(1)类别层面的问题:
在推理阶段强行扩展运算量(Test-Time Scaling)时,往往会出现过度保留并处理大量历史推理信息的问题。
传统的链式推理、树式搜索等方法,要么在中间步骤累积越来越多的上下文和推理路径,要么需要反复回溯历史过程。
这样不仅导致计算开销增大,也因噪声或错误信息的累积而使推理质量下降。
AOT 的核心观点是:将复杂问题迭代地拆解成若干子问题,再把已解决的子问题变为已知条件或剔除冗余信息,形成一个新的“原子化”问题,使当前推理只依赖当下状态而无需携带全部历史推理。
(2)具体问题:
现有的推理框架(如链式推理Chain-of-Thought、树式推理Tree-of-Thought等)往往要“记住”所有历史中间推理信息(例如先前所有中间结论),导致:
- 推理成本过高:维持并处理大量历史信息,计算开销大。
- 历史干扰:累积的冗余或错误信息会干扰模型对当前子问题的专注度。
AOT 的出现正是为了解决“如何在推理过程中避免无用的历史信息累积、同时保持推理有效性”这个具体痛点问题。
AOT 的核心性质是“马尔可夫性质(Markov Property)”,即每一步的状态只依赖“当前问题”本身,而不需要完整的过去历史。
- 现在只和过去有关,和过去的过去无关
导致这一性质的原因:
AOT 在解题时会不断进行“分解(Decomposition)+ 收缩(Contraction)”,将已经解决的子问题视为已知条件或丢弃无关历史,只向后传递最必要的信息。
- 由于“收缩”会生成一个新的、能够独立求解的“原子化问题”,这一问题不再显式依赖完整历史,从而在推理链上呈现“只依赖当前状态”的马尔可夫性质。
Atom of Thoughts(AOT)是一种让大模型在推理阶段采用“马尔可夫式”思路的框架:先将复杂问题拆解为多个子问题,并识别其依赖关系,然后把已解决的子问题当作已知条件,最终收缩成一个新的、独立可解的子问题,不携带过多历史信息。
AOT 强调“分而治之 + 已解融入”的循环流程,通过每一步对问题的“收缩”来保持状态的“原子化”,杜绝多余的历史推理对后续的干扰,从而在推理成本与推理效果之间取得更好的平衡。
数据分析
数据来源:
- 多类型数据集选择:
- 数学推理:MATH、GSM8K
- 知识推理:MMLU-CF
- 多步/多跳推理:HotpotQA、LongBench
- 逻辑推理:BBH(其中包含多种小型子测试)
- 数据规模(论文示例):
- GSM8K 共有 1,319 道题目;作者在实验中使用了其全部测试集。
- 其余数据集(MATH、MMLU-CF、HotpotQA、LongBench、BBH 等),作者一般各取 1,000 条左右(或全部测试集)进行评测。
- 数据准确性与覆盖面:
- 覆盖数学、常识、逻辑与多跳推理等不同领域,确保能全面评估 AOT 的通用性和稳定性。
- 作者同时参考了各数据集原始标注的正确答案,保证后续评估的可靠性。
-
数学推理(MATH、GSM8K)
- 观察数据:AOT 相比传统方法在正确率上有增益,如在 MATH 上获得更高分数,在 GSM8K 达到更高的精确度。
- 得出的结论:逐步分解、逐步收缩,让模型在每次只应对“精简后”的子问题,就减少了对冗余历史的依赖,计算过程更轻、更快。
-
多跳问答(HotpotQA、LongBench)
- 观察数据:F1 值或 Hit Rate 相较传统模型显著提升(如 HotpotQA F1 有 3~10% 左右提升)。
- 作者的解释:多跳问题往往需要跨段落、跨知识点的连接,传统方法需反复检索大量上下文;AOT 分解后,每一步只关心下一跳的核心信息,显然更容易达成高效且准确的推理。
-
知识和逻辑测试(MMLU-CF、BBH 等)
- 作者对比:传统的链式/树式方法在内容广泛、上下文复杂的推理上也容易出现历史噪声导致偏差;AOT 则通过 Markov 流式问题接续,避免堆积错误。
- 结论:AOT 在多种题型上都有改善,说明上述假设的普适性。
1. 按照逻辑关系拆解解法
AOT 解法的整体公式化描述
从论文来看,AOT 的核心思想可以用一个“分解—收缩”的两阶段循环来表示,其满足马尔可夫性质。形式化地讲,我们把原始问题记为 (Q_0),子解法的迭代过程用下列步骤描述:
- 分解 (Decomposition):在状态 (Q_i) 时,利用 LLM 将问题拆解为若干子问题,并标注它们的依赖关系,临时形成一个有向无环图 (G_i)。
- 收缩 (Contraction):将已解决或可直接回答的子问题收敛为已知条件,合并或去除冗余中间推理,生成新的独立问题 (Q_{i+1}),使之符合马尔可夫性质(只依赖当前状态,而非完整历史)。
最后在若干次迭代后得到可直接求解的原子问题 (Q_D),并输出答案 (A)。
整体解法与同类算法相比的主要区别
-
传统 Chain-of-Thought (CoT):
- 保留从第 1 步到第 n 步的全部中间推理,链条越长,历史越多。
- 不具备自动剪裁冗余信息的机制。
-
Tree-of-Thought (ToT) / Forest-of-Thought (FoT):
- 会在不同节点/分支进行多路径搜索,但依然需要维持或回溯较多历史分支信息。
- 仍存在冗余推理路径在后续可能干扰决策的问题。
-
AOT:
- 强调“马尔可夫式”——当前问题只依赖直接上一步,不用完整历史。
- 通过“分解 + 收缩”及时扔掉已解决子问题的详细推理过程。
- 更注重减少冗余、缩短推理链,具有更高的运算效率和对错误的屏蔽能力。
将 AOT 细化为若干子解法
下面把 AOT 拆解为 3 个主要子解法(如果再深入,也可以继续拆解其中的子过程)。每个子解法都对应了 AOT 的一个关键特征或需求。
-
子解法1:DAG 依赖标注
- 之所以用 DAG 标注子问题,是因为我们需要区分独立子问题和依赖子问题;而且分解后的子问题之间往往是一种无环关系(先后顺序固定,不能无限循环依赖)。
- 具体做法:
- 在当前问题 (Q_i) 中,通过 LLM(或其他规则)将其拆解成子问题集合 ({q_1, q_2, \dots, q_k})。
- 识别哪一些子问题是“独立”(不依赖别的结论),哪一些子问题要用其它子问题的答案。
- 形成有向无环图 (G_i),其节点是子问题,边表示依赖关系。
-
子解法2:独立子问题转化为已知条件
- 之所以要将独立子问题转化为已知条件,是因为这样可以迅速排除不必要的历史推理,让后续问题更精简。
- 具体做法:
- 对于 DAG 中无入边的子问题(即独立子问题),可以直接求解;其解答会被当作“新条件”写入下一步问题描述中;
- 将这些独立子问题连带的原推理过程从历史中剥离,不再保留其所有步骤。仅保留它们的解。
-
子解法3:依赖子问题收缩为新原子问题
- 之所以把依赖子问题收缩,是因为需要将与当前问题紧密关联但尚未解决的部分归并成一个新的可独立解决的问题,使得后续不必再回顾庞大的推理历史。
- 具体做法:
- 将 DAG 中有依赖的子问题合并为一个“主问题”。它会被改写(把已经确定的条件写入其中),以形成 (Q_{i+1})。
- 去掉上一步中解决的独立子问题及所有依赖边,让 (Q_{i+1}) 不再冗余继承过去的推理文本。
- 重复该过程,直到所有子问题可一并求解或问题变得足够简单,可直接解出答案。
举例:数学题中使用子解法的场景
- 子解法1 (DAG 标注):
假设某道几何题需要先算角度,再算边长,再算体积。AOT 会在当前问题中识别出这些子问题(角度、边长、体积)各自依赖哪些已知量或者彼此的结果。 - 子解法2 (独立转化为已知条件):
如果角度计算无需别的子问题支持,就先算出角度并把答案“θ = 30°”直接写入新的问题描述;不保留过程细节。 - 子解法3 (依赖收缩):
剩余要用 θ 这一步计算结果的边长、体积问题,合并成一个新的问题“已知θ=30°,求边长以及体积”。后面再重复分解或直接算出答案。
2. 子解法之间的逻辑链条或网络(决策树表示)
为便于理解,这里以决策树形式简单展示 AOT 的子解法逻辑:
AOT(Atom of Thoughts)
├── 子解法1: DAG依赖标注
│ ├── 根据当前问题Q_i分解出子问题q_1, q_2, ...
│ └── 标注q_1 -> q_2之间的依赖关系, 形成G_i
├── 子解法2: 独立子问题转化为已知条件
│ ├── 识别DAG中无入边子问题q_j
│ └── 将其答案直接写入下一步问题描述中, 并删除冗余过程
└── 子解法3: 依赖子问题收缩为新原子问题
├── 把有依赖关系的子问题合并成新问题Q_{i+1}
└── 继续后续的分解—收缩循环, 直至可直接解出
- 该结构更像一个流程链条,但当我们在某次迭代内,DAG 中子问题可以并行或相互依赖,也可视为网络式分解。AOT 的本质是不断重复这三个子解法过程,直到问题被完全解决。
3. 是否存在隐性方法
逐行对比,挖掘潜在关键步骤
- 显性方法:上文列出的 3 个子解法(DAG标注 / 独立子问题转化 / 依赖收缩)是论文中明确提出的。
- 可能的隐性方法:
- 子问题评估/反思机制
- 在论文描述中,若分解出的子问题不正确(比如依赖关系标注错了),就会导致后续不准确。
- AOT 虽然没大篇幅描述“怎么自动修正错误分解”,但从一些实验和终止条件来看,作者暗示了要么通过 LLM 自洽验证,要么在收缩后做结果比对——这是一个隐含的“质量控制”关键步骤。
- 可定义为“子解法4: 子问题一致性检查”:
- 之所以需要它,是因为如果子问题本身错误,后续一切都无意义;
- 它如何实现:在分解完后,先让 LLM 检查各子问题描述是否互相矛盾或重复,然后再做收缩。
- 动态终止判定
- 作者在文中提到可以根据问题“是否已足够简化”或“是否到达最大深度”来终止迭代。
- 这往往是多个指标(问题长度、子问题数量、答案一致性)一起决定的,并没单独列为算法步骤,但它实际在每一轮 iteration 结束时都要做判断。
- 可定义为“子解法5: 动态终止判定”:
- 之所以需要它,是因为无限迭代会造成不必要的成本,且并不一定带来更好的结果。
- 它如何实现:给定一个深度上限或让 LLM 对比收缩前后的问题,如果答案一致,则停止。
- 子问题评估/反思机制
隐性特征
- 在收缩过程中,除了显式提到的“把独立子问题当作条件”,可能还有其他特征:比如对不正确的子问题答案进行排除或修订。但论文没有大篇幅展开。
- 这些特征并不直接在“分解+收缩”两词中呈现,却对 AOT 的效果起了补充作用。
4. 方法可能存在的潜在局限性
-
对分解质量过于依赖
- 如果 DAG 依赖标注阶段出现严重错误,后续就会“垃圾进,垃圾出”。
- 需要更多机制确保分解正确性。
-
缺乏强力的反思或回溯
- Markov 性质的好处是“不带历史”,坏处是一旦错误进入当前状态,后面不容易纠正(没有系统回溯)。
- 只能在有限的子问题检查或终止判定里做微弱的修改。
-
循环次数与成本的平衡
- 虽然减少历史信息带来单次推理成本降低,但如果过度拆分导致 iteration 次数激增,也可能让总体开销上升。
- 需要合理设计何时拆分、何时直接解题。
-
对隐性方法(质量控制、终止策略)的依赖
- 论文虽然提出一些思路,但尚未系统化阐述如何实现最优检查与终止。
- 在实际应用中可能需要更多工程或策略调优。
全流程
-
原始问题 (Q_0):
“某位 45 岁男性患者,自述咳嗽、发烧 3 天,胸片显示肺部阴影,血象有白细胞增高,还可能存在其他基础病。请判断最可能的诊断,并给出治疗建议。” -
AOT 子解法循环:
- 分解 (DAG 分解):
- 子问题1:咳嗽、发烧等症状是否符合细菌感染?
- 子问题2:肺部阴影是普通肺炎还是其他类型病灶?
- 子问题3:基础病(如糖尿病、高血压)是否会加重病情?
- 标注依赖关系:子问题3 的解答需要先确诊子问题1,等等……
- 独立子问题转化:
- 若血象增高可直接判断存在炎症,子问题1 可较快得出“存在细菌感染”结论。
- 将此结论写入新问题描述中(比如“已确认为细菌感染,是否可排除病毒病因?”)。
- 依赖子问题收缩:
- 把剩下的“肺部影像特征”与“基础病”合并成新问题 (\widetilde{Q}_1):
“已知病人有细菌感染迹象,肺部阴影疑似细菌性肺炎,基础病要监测什么指标?” - 此时无需再保留关于血象分析的详细过程。
- 把剩下的“肺部影像特征”与“基础病”合并成新问题 (\widetilde{Q}_1):
- 重复上述步骤,直到可直接给出主诊断和治疗方案。
- 分解 (DAG 分解):
-
输出:
最终答案:“患者最可能是社区获得性细菌肺炎,建议针对性抗菌药物及控制血糖、血压等。”
提问
1. 问:AOT 虽然号称“马尔可夫式”推理过程,能不能举一个数学推理场景,让我看到到底是怎么避免“链式信息累积”的?
答:
在数学推理中,AOT 会先将复杂题目拆解成若干子问题,并识别这些子问题之间的依赖。
如果一个子问题的结果对下一步推理是必要的,则将该结果标记成“已知条件”,而不再保留所有中间推理步骤。
这样在下一个迭代时,模型只面向“当前问题 + 前一步结论”,并不带着完整的历史推理链。
比如,若一道几何题包含“求三角形某边再算圆半径”,只需保留最后的“边长数值”给下一步算圆半径,省去三角形求边的推理历史。
2. 问:论文中对 DAG 的构建方式着墨很多,如果子问题互相循环依赖,AOT 会怎么处理?
答:
AOT 在“分解”阶段会将子问题组织成“有向无环图(DAG)”,关键点就在于排除循环依赖。
如果模型检测到循环(例如 A 依赖 B,B 又依赖 A),会重新检查分解方案,要么合并子问题成一个更大子问题,要么让 LLM 做出冲突裁剪。
论文中强调 DAG 的无环性是保障“收缩”能进行下去的前提,一旦出现环,就无法保证马尔可夫性质。
3. 问:AOT 只保留当前状态却不追溯历史,一旦前面推理出了错误结果,后续是否就永远无法纠正?
答:
这是马尔可夫式设计的潜在缺陷。论文中给出的弥补方案包括:
- 在每次收缩完后,对子问题答案进行自洽验证,若冲突则回退。
- 与自一致性(Self-Consistency)或投票机制相结合,让不同的推理路径对比,若多数路径发现前面解错,则触发“修正”或重新分解。
因此并非完全没有纠错能力,但其纠错需要额外的“反思”机制来检测不一致。
4. 问:在多跳问答(如 HotpotQA)里,AOT 的关键效率提升点到底在哪?为什么传统 Chain-of-Thought 不行?
答:
多跳问答通常需要跨多段文本寻找信息。
传统 Chain-of-Thought 会保留全部上下文与中间推理记录,每一跳都要读取、处理过去所有信息。
AOT 则将已经确认的“证据”扼要地融入下一问题描述里,不再带着完整中间推理过程。
这样能够让后续模型的输入长度更短,干扰更少,从而提高推理速度和准确率。
5. 问:论文中声称“任何原始问题都能被转换成原子化的下一状态”,要是原问题已经很简单,还要用分解吗?
答:
如果原问题够简单,可以直接跳过分解环节,AOT 也没有强制分解。作者在实验中表明,对于简单问题,AOT 只做一次(d=1)的分解就行,或者根本不拆分,直接让 LLM 解答。AOT 的益处主要在于复杂问题层面,如果问题本身结构简单、推理链短,那就没有必要分解成原子状态。
6. 问:AOT 强调的“独立子问题”识别是怎么做的?如果 LLM 判断失误把依赖子问题当成独立子问题,岂不是信息丢失?
答:
确实可能出现错误识别。作者在论文中给出的具体方法是利用 LLM 生成子问题时,会顺带标注“该子问题需要哪些已知结论”,并在 JSON 格式中明确指明依赖。
若某子问题在依赖列表是空,则判定其独立。
错误识别的案例,需要借助子问题答案在后续整合时做自洽检查,若发现矛盾,会提示模型重新划分依赖关系。
7. 问:相比 Tree-of-Thought,AOT 在分支搜索方面有没有性能劣势?看起来它没有在并行路径上花功夫。
答:
是的,AOT 没有像 ToT 那样在并行分支(不同思路)上做大量搜索,它专注于“化简历史依赖”。
作者在论文中提到,也可先用 AOT 把问题简化,再在简化后的问题上用 ToT 进行并行搜索,这算是一种混合策略。
AOT 的主要价值在于减轻冗余而非探索多解。
8. 问:论文说可以对依赖图里的子问题做并行求解,但具体实现步骤藏在哪?
答:
作者提到的“并行”更多是一种可能性:DAG 中若若干子问题彼此互不依赖,就可以同时求解。
具体实现则取决于模型接口能否多线程调用或管线化。
论文本身没有给出大段伪代码,而是概念性地提出,可将无入边子问题打包给模型并行处理。
9. 问:把复杂问题拆成很多子问题,会不会导致提示 Token 数量反而增多,从而抵消减少历史带来的收益?
答:
这正是 AOT 在论文中讨论的“计算成本平衡点”。
当问题需要大规模分解(如 5~6 层迭代)时,的确会有额外的提示成本。
但作者实验数据显示,随着问题复杂度上升,AOT 削减的“无关历史”远大于分解本身的提示开销,所以总体是更划算的。
然而对于不太复杂的问题,收益就没那么明显。
10. 问:AOT 把子问题答案当条件塞进下一问题描述,会不会使提示过度简化,导致模型失去上下文理解?
答:
作者对这个担忧的回答是:AOT 并非删除所有上下文,只是移除无用或与当前子问题无关的部分,保留那些必需信息(如关键结论、限定条件)。
若题目真正需要长期保持某些上下文信息,就不会贸然丢弃;因此不会破坏语义理解的完整性。
11. 问:AOT 设计依赖对 LLM 的高质量能力,比如准确分解和依赖标注。在规模较小或质量一般的模型上是否依然适用?
答:
论文的实验大多基于较强模型(如 GPT 系列)做提示。
对于规模小、理解力弱的模型,AOT 的效果可能大打折扣,特别是分解环节更易出错。
作者认为,AOT 适用于“具备可观理解/推理能力”的 LLM,这是它的应用前提之一。
12. 问:AOT 在定量指标(如 F1、EM)上表现不错,为什么还要反复强调“Markov Property”?
答:
“Markov Property”是作者在理论层面总结出的特征,用来解释为什么 AOT 不需要保留过多历史信息:后续状态只依赖当前时刻,而不依赖更早的完整序列。
F1、EM 等指标只是效果体现,这个性质则为算法提供了思想基础,可让后续研究者更好地理解或扩展这种思路。
13. 问:如果遇到“并行依赖”的问题,比如子问题 A、B 都需要子问题 C 的答案,AOT 是否会重复执行 C?
答:
论文中提到一旦子问题 C 求解完成,可将 C 的答案作为新条件写回问题描述中,再让 A、B 去引用,无须重复算 C。
但这一过程要在 DAG 构建时就识别出“C 是多个子问题的先决条件”,并把它作为一个独立节点优先解决。
14. 问:文本中多次提到可与其他方法(如 CoT-SC、ReAct 等)“无缝对接”。请问 AOT 是如何无缝插入的?
答:
简单来说,AOT 可以先做一轮(或数轮)分解和收缩,把问题简化成一个更短、更独立的“新问题”。
然后把这个“新问题”输入到 CoT-SC 或 ReAct 等方法里做更深层次的解答。
因此,“无缝对接”指的是在解题入口处用 AOT 做预处理,并不与后续方法发生冲突。
15. 问:作者在实验中选择了哪些基线方法进行对比?为什么没有选择一些新的 RL-based 推理增强?
答:
论文里最常对比的是 Chain-of-Thought、Tree-of-Thought、Self-Consistency、Forest-of-Thought 以及一些微调模型(DeepSeek 等)。
作者倾向选择这些“推理扩展”经典或主流基线来突出 AOT 在历史信息处理上的改进。
至于 RL-based 方案也可能带来收益,但它本身解决的是“策略搜索”,与减少冗余历史的目的略有差异,所以未被列入主要对照组。
16. 问:若问题在任何阶段都能被解出,但 AOT 还会继续分解吗?如何防止过度迭代?
答:
在论文设定中,一旦某次收缩后能直接解出问题,AOT 就会停止迭代,不再继续拆分。
作者还建议可设置迭代深度上限(比如 d=5)或让 LLM 自行判断“题目已可解答”,以杜绝无休止的拆分。
17. 问:DAG 构建需要用户自定义标签还是全自动?文中所示 JSON 结构是手动写还是让模型自动输出?
答:
作者倾向于自动输出。
他们的实验流程中,通过对 LLM 的提示编写,让模型按 JSON 格式返回子问题描述及其依赖节点 ID。
这一步并非完全人工干预。论文附录也给了具体提示模版示例,说明如何要求模型产出 JSON 依赖标注。
18. 问:AOT 能对非文本数据(如图像、传感器数据)做分解吗?论文可没说怎么处理多模态?
答:
论文主要针对文本推理场景。
对多模态数据要先把图像或其他信息转成可解释的描述,才能让 LLM 做文字式子问题拆分。
作者并未在文中详述多模态方案,只说 AOT 原理可推广,但尚需额外的多模态编码或对齐技术。
19. 问:AOT 听起来把问题重写了好几次,这会不会影响对答案的可解释性?最后的解答还能还原完整过程吗?
答:
作者承认这是一种取舍:AOT 在压缩历史的同时,牺牲了部分可追溯性。
论文中提到,可以保留简短的“变更记录”以便事后审查,但默认情况下并不要求输出所有中间推理。
对于需要“全量可追溯”的场景,AOT 也可切换到存储关键节点信息的模式,只是会增加计算量。
20. 问:作者给的多项实验都显示 AOT 准确率提升较大,但能否举一个失败案例,让人看看 AOT 的极端局限性?
答:
作者在附录里提到一个极端案例:某道数学题同时涉及长链逻辑和非常细微的上下文依赖,如果分解不当就会把两条关键依赖线拆开,导致最终收缩后上下文缺失。
结果 AOT 得到的答案与正确解差异很大。换言之,AOT 在“需要同时维持多个相互关联、但又不能轻易分割的链式推理”上,易出现分解不完整的情况。
如果 DAG 构建失败或误拆,后面的收缩阶段就无从补救,这就是它的极端局限场景。
代码
示例问题
假设我们有这样一个几何问题:
对于一个常数 b > 10,存在两个可能的三角形 ABC,满足 AB = 10,AC = b,且 sin B = 3/5。求这两个三角形中边 BC 长度的正差值。
Atom of Thoughts 解决过程
1. 初始状态 Q₀
系统首先接收到原始问题,这是初始状态 Q₀。
2. 分解阶段
系统使用 LLM 将问题分解为多个子问题,并标注它们之间的依赖关系:
子问题1: 在三角形 ABC 中,已知 sin B = 3/5,求 cos B 的值。
- 回答: cos B = ±4/5
- 依赖: [](没有依赖其他子问题)
子问题2: 对于 cos B = 4/5 的情况,设 BC = a₁,利用余弦定理建立 b 和 a₁ 的关系。
- 回答: b² = a₁² - 16a₁ + 100
- 依赖: [0](依赖子问题1的结果)
子问题3: 对于 cos B = -4/5 的情况,设 BC = a₂,利用余弦定理建立 b 和 a₂ 的关系。
- 回答: b² = a₂² + 16a₂ + 100
- 依赖: [0](依赖子问题1的结果)
这些子问题和它们的依赖关系形成了一个 DAG(有向无环图)。
3. 收缩阶段
系统识别出子问题1是独立的(没有依赖),而子问题2和3依赖于子问题1。
收缩过程将子问题1的结果作为已知条件,并将子问题2和3收缩成一个新的原子化问题:
已知三角形 ABC,满足 AB = 10,AC = b > 10,sin B = 3/5,cos B = ±4/5。对于 cos B = 4/5 时,BC = a₁,满足 b² = a₁² - 16a₁ + 100;对于 cos B = -4/5 时,BC = a₂,满足 b² = a₂² + 16a₂ + 100。求 |a₁ - a₂| 的值。
这就是收缩后的新状态 Q₁。
4. 解答阶段
系统直接解答收缩后的问题:
从 b² = a₁² - 16a₁ + 100 和 b² = a₂² + 16a₂ + 100,我们有:
a₁² - 16a₁ = a₂² + 16a₂
整理得:a₁² - a₂² - 16a₁ - 16a₂ = 0
因式分解:(a₁ - a₂)(a₁ + a₂) - 16(a₁ + a₂) = 0
提取公因式:(a₁ + a₂)(a₁ - a₂ - 16) = 0
由于 a₁ + a₂ > 0(三角形边长为正),所以 a₁ - a₂ - 16 = 0,即 a₁ - a₂ = 16
因此,两个三角形中边 BC 长度的正差值为 16。
5. 对比传统方法
传统 Chain-of-Thought 方法:
- 需要从头到尾维护完整的推理链
- 每一步都依赖于所有前序步骤
- 随着推理深度增加,计算资源消耗迅速增长
使用 Atom of Thoughts:
- 将原问题转化为更简单、自包含的问题
- 每一步只依赖于当前状态,不需要回顾完整历史
- 大幅减少了计算资源的浪费
实际代码运行过程
当用户运行 python main.py --dataset math --start 0 --end 1 --model gpt-4o-mini
处理这个问题时:
- 系统首先使用
direct
函数尝试直接解答 - 然后使用
decompose
函数将问题分解为子问题并建立 DAG - 通过
merging
函数实现收缩,生成新的原子化问题 - 解决收缩后的问题并返回最终答案
整个过程中,系统会尝试多种解法(直接解答、分解解答、收缩解答),并选择最佳结果作为最终答案。
这个例子展示了 Atom of Thoughts 如何通过原子化状态转换,实现更高效的推理过程,特别是在处理需要多步推理的复杂问题时,显著提高了推理效率和准确性。