ToT与ReAct:突破大模型推理能力瓶颈

大模型知识渊博,却时常"有知识,欠智慧"。传统的推理方式如同单线程的直线,限制了其解决复杂问题的潜力。

Tree of Thoughts (ToT) 与 ReAct 框架的诞生, 标志着大模型推理范式的一次根本性转向**:**

ToT 将"线性链"升级为"决策树", 赋予模型战略规划与多路径探索 的能力**;**

ReAct 则构建了"推理"与"行动"的飞轮, 让模型能在与现实世界的交互中动态思考与学习。

目录

[1. Tree of Thoughts ToT 思维树(思维链的优化)](#1. Tree of Thoughts ToT 思维树(思维链的优化))

[1.1 四大步骤](#1.1 四大步骤)

[1.2 两组实验](#1.2 两组实验)

[2. ReAct 推理 + 行动](#2. ReAct 推理 + 行动)

[2.1 简要原理](#2.1 简要原理)

[2.2 实现方法](#2.2 实现方法)

[2.3 实验](#2.3 实验)


1. Tree of Thoughts ToT 思维树(思维链的优化)

github-tree-of-thought-llm

传统 LLM 包括思维链CoT痛点:自回归文本生成机制------ 即逐一词元、从左到右地做出决策。

这意味着在需要探索、策略性前瞻,或初始决策起关键作用的任务中,语言模型可能表现不佳。

考虑多条不同的推理路径 、自我评估选择以确定下一步行动,并在必要时前瞻或回溯以做出全局决策

实验:24 点游戏、创意写作、填字游戏。

A genuine problem-solving process involves the repeated use of available information to initiate exploration , which discloses, in turn, more information until a way to attain the solution is finally discovered.------ Newell

真正的问题解决过程,涉及反复利用已有信息启动探索 ,而探索又会揭示更多信息

直至最终找到达成解决方案的路径。(探索 + 获取信息 交替)

现有语言模型通用问题解决方法的两大核心缺陷:

  1. 局部层面 :未探索思维过程中的不同延续路径 ------ 即树的分支;
  2. 全局层面 :未融入任何规划、前瞻或回溯机制来评估这些不同选项。

1.1 四大步骤

  1. 思维分解:一个 "思维" 需满足:
  • 足够 "小",使语言模型能生成有前景且多样的样本(比如一本书 就太多太难生成了)
  • 足够 "大",使语言模型能评估其对问题解决的进展(比如一个词 就太短没区分度)
  1. 思维生成

若思维空间维度大(像写作),k次独立同分布采样(调用k次) 确保候选思维的多样性。

若思维空间维度小(像24点),k个不同的方案 (调用1次)防止重复 尽量包含所有可能。

3. State Evaluator 状态评估器 V

"评估状态对最终解决问题的'前景'" ------ 即 "从当前状态出发,后续步骤能成功找到答案的概率

无需绝对准确,只需 "相对有效"(能区分优质 / 劣质状态)为搜索算法提供导航。

通过推理状态 s 生成标量值 v(如 1-10 分);

策略 (a):独立评估每个状态

快速往后模拟1-2步,验证其潜力;

利用领域知识(比如算24点 状态(1,2,3)的数字太小)

策略 (b):在状态间进行投票

当问题的"成功"标准非常抽象、难以直接量化时(例如,评估一段文本的"连贯性")

直接比较哪个更好,比给每个单独打分更容易。(可以给最佳状态打 1 分,其余都 0 分)

  1. 搜索算法(Search Algorithm)

BFS 和 DFS(也可以模块化地 使用其他搜索算法)

1.2 两组实验

24点例:

(左)思维生成 (右)状态评估

创意写作例:

  • 输入:4个随机句子

  • 输出:一个连贯的段落,包含4个段落,分别以4个输入句子结尾

  • 特点:开放性强、探索性高,需要创造性思维和高层次规划

先写若干个思路,票数最高的思路,实现成段落

双重评估体系

1. GPT-4自动评分:使用零样本提示给出1-10分的连贯性评分

每个任务输出采样5个分数取平均 分数一致性高(标准差约0.56)

2. 人工盲审对比:作者团队在100个输入上对比CoT vs ToT的输出

随机调换段落顺序以避免偏见

(ToT需要更多资源,对于LLM已经表现很好的许多现有任务,ToT可能不是必需的。)

2. ReAct 推理 + 行动

github-ReAct

  • 核心问题:当前LLMs的研究将"思考"(推理)和"动手"(行动)分开了。

  • 解决方案 :提出 ReAct 范式,让模型在解决问题时,边想边做,边做边想

  • 当模型不确定时,它可以去"查资料"(调用Wikipedia API),用事实证据来支撑推理,减少了胡说八道。

(a) 标准形 IO (b) CoT只推理 (c) 只行动 (d) ReAct 推理+行动

2.1 简要原理

智能体 - 环境交互的 "观测obs - 动作a - 上下文c"

核心问题:复杂任务中 ct→at 的映射隐式且需推理,传统策略学习失效;

原始动作空间 A:领域特定动作 ; 需要变成 ct -> 中间推理 -> at;

创新:新增语言空间 L:自然语言构成的 "推理轨迹(reasoning trace)" 或 "思考(thought)";

思考与动作的区别:无环境交互 -- 执行思考动作时,环境不会产生新的观测 obs

  • 推理功能:基于当前上下文 ct 进行推理(如分解任务、提取信息、验证事实)整合有用信息
  • 上下文传递:将思考结果 ât 加入原上下文,生成新上下文 ct+1 = (ct, ât)------ 使得后续动作(无论是思考还是领域动作)都能基于 "原始轨迹 + 中间推理" 进行决策,解决了传统方法 "跳过中间推理" 的问题。

2.2 实现方法

语言空间 L 是无限的,依赖强大的语言先验知识,必须借助大语言模型(LLM)的预训练语言能力

LLM 需同时生成两种动作:①领域特定动作 (A);②自由形式的语言思考(L)。

  1. 对于推理主导性任务(如事实核查):

强制 "思考 - 动作" 交替生成:轨迹结构为观测→思考→动作→观测→思考→动作→...

交替模式能确保每一步动作都有推理支撑,避免跳过关键逻辑。

  1. 动作密集型决策任务(如游戏):

稀疏思考生成:不强制交替,让 LLM 自主决定何时生成思考、何时生成动作;

很多动作是机械性的,无需推理。仅在关键节点 (如决策分支、信息缺失时)需要思考,稀疏模式能提高效率

2.3 实验

两个问题:

  • HotpotQA: 多跳问答。需要模型串联多个维基百科文档中的信息才能找到答案。

  • FEVER: 事实核查。需要模型根据维基百科证据判断一个陈述是"支持"、"反驳"还是"信息不足"。

设计了一个简化的维基百科API,包含三个核心操作:

  • search[entity]搜索实体,返回摘要或相似实体建议。

  • lookup[string]: 在页面内查找包含特定字符串的下一句话(模拟Ctrl+F)。

  • finish[answer]提交最终答案。

思考的范例:

  • 任务分解("我需要先搜索X,再找Y")

  • 信息提取("这段提到X成立于1844年")

  • 常识/数学推理("1844 < 1989")

  • 搜索策略调整("也许我应该换搜X试试")

  • 答案合成("所以答案是X")

ReAct:极大改善CoT的幻觉问题。得益于外部知识库的 grounding,它的推理轨迹更可信。

但由于被"思考-行动-观察"的结构所约束,推理灵活性 相比CoT下降(容易出现循环)

SC 指 self-consistency 投票自洽性;根据上者优缺点,结合CoT-SC 和 ReAct。

  • ReAct → CoT-SC : 当ReAct在限定步数内找不到答案时,回退到使用CoT-SC来依靠内部知识给出答案。

  • CoT-SC → ReAct : CoT-SC结果显示内部知识不一致、信心不足时(例如,多个推理路径得出的答案不统一),回退到ReAct去外部检索信息。

  • ReAct微调 : 让模型学习"如何获取知识"的技能 。这是一种更通用、更可迁移的能力。

  • 如果能有更多高质量的人类标注的"思-行"轨迹数据,ReAct模式的潜力将会被进一步释放。

相关推荐
奔跑中的小象3 小时前
统信UOS + 天数AI卡部署SGLang服务手册
人工智能·uos·sglang·天数智芯
DevSecOps选型指南3 小时前
中国版Mythos,为何是悬镜安全灵脉CodeAI?
人工智能·安全
Shockang3 小时前
LangGraph 状态机实战
人工智能
刹那芳华19923 小时前
循环神经网络的从零开始实现(RNN)
人工智能·rnn·深度学习
阿童木写作4 小时前
跨境图片翻译工具多合一,批量图片视频字幕翻译加智能抠图
人工智能·python·音视频·语音识别
科技之门4 小时前
AI3D从建模到贴图、绑骨和动画的完整流程怎么做?V2Fun完整工作流指南
人工智能·3d·贴图
宇宙第一小趴菜4 小时前
二、机器学习的应用领域和发展史
人工智能·机器学习
前端开发江鸟4 小时前
我写过 MCP Server,却一直以为 MCP 只有 Tool
人工智能
天国梦4 小时前
自习室智能化升级避坑指南:天学网AI智习室方案实测与选型建议
大数据·人工智能
阿里云云原生5 小时前
可用性从 99.9% 跃升至 99.995%:畅捷通如何用 AI 重塑运维底座?
运维·网络·人工智能