请谈谈目前有哪些主流方法可以赋予 LLM 规划能力？（例如 CoT, ToT, GoT等）
1️⃣ 考察意图
面试官想考察你对 LLM 规划能力的广度理解与对比分析能力，而非简单罗列方法名。刁钻点在于：你是否能区分 CoT、ToT、GoT 等方法的本质差异（如搜索空间 vs 推理路径），并指出各自的工程取舍（如计算成本 vs 探索深度）。答好了能展示你从提示工程到系统设计的硬实力，包括对搜索算法（BFS/DFS）、图论、以及实际落地中 token 预算控制的敏感度。
2️⃣ 标准答
主流方法可分为三类：提示工程驱动、搜索增强、微调集成。以下逐一拆解：
- Chain-of-Thought (CoT)
- 核心：通过“Let’s think step by step”引导 LLM 生成中间推理步骤，将复杂问题分解为线性链。
- 变体：Zero-shot CoT（直接加触发词）、Few-shot CoT（给示例）、Auto-CoT（自动生成示例链）。
- 工程取舍：简单高效，但线性路径无法回溯错误；对多分支问题（如逻辑谜题）容易陷入局部最优。
- 落地坑：长链推理时 token 消耗爆炸（如 10 步推理可能用 2000+ tokens），且中间步骤错误会累积。解法：用“Self-Consistency”采样多条链后投票，牺牲延迟换准确率。
- Tree-of-Thoughts (ToT)
- 核心：将推理建模为树状搜索，每个节点是“思维状态”，用 BFS/DFS 探索多条路径，并允许回溯。
- 实现：需要定义“思维生成器”（如“下一步可能的 3 种解法”）和“状态评估器”（如 LLM 打分或启发式函数）。
- 工程取舍：探索深度高，但计算成本是 CoT 的 5-10 倍（每次评估需调用 LLM）。适用场景：创意写作（如写诗选词）、24 点游戏等需要试错的开放任务。
- 落地坑：状态评估器容易受 LLM 偏见影响（如偏好长答案）。解法：用“投票机制”替代单一打分，或引入外部验证器（如代码执行结果）。
- Graph-of-Thoughts (GoT)
- 核心：将思维建模为有向图，允许节点间合并、拆分、循环（如“先并行探索 3 条子路径，再合并结论”）。
- 实现：基于“思维变换”操作（如聚合、细化、回溯），用图遍历算法（如拓扑排序）控制推理流。
- 工程取舍：灵活性最高，但图结构维护复杂（需管理节点依赖和循环检测），且 token 开销随图规模指数增长。适用场景：复杂规划（如旅行路线优化）、多步数学证明。
- 落地坑：图结构容易产生死循环（如 A→B→A）。解法：限制最大深度（如 5 层）或使用“剪枝策略”（如只保留 Top-K 节点）。
- 其他方法
- ReAct：将推理（Reasoning）与行动（Acting）交替，结合外部工具（如搜索 API）。适合需要实时信息的任务（如问答）。
- Plan-and-Solve (PS)：先写高层计划（如“步骤 1：收集数据；步骤 2：分析”），再逐行执行。适合长流程任务（如代码生成）。
- Self-Refine：迭代生成→反馈→修正，类似“写草稿→找错→重写”。适合文本润色。
- 总结对比方法搜索空间计算成本适用场景CoT线性链低数学推理、常识问答ToT树状中高创意写作、游戏GoT图状高复杂规划、证明ReAct循环中工具调用、实时问答
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，提示工程驱动的方法，如 CoT 通过线性链分解问题，简单但无法回溯；第二，搜索增强的方法，如 ToT 用树状搜索探索多条路径，GoT 用图结构支持合并和循环，但计算成本高；第三，微调集成的方法，如 ReAct 结合外部工具。总结一句：选择取决于任务复杂度——简单推理用 CoT，开放探索用 ToT，复杂规划用 GoT。”
4️⃣ 高频追问 & 应对
追问 1：ToT 和 GoT 在实际落地中，哪个更实用？
从工程角度看，ToT 更实用。因为 ToT 的树结构天然支持 BFS/DFS，实现简单（只需定义生成器和评估器），且 token 开销可控（如限制树深度为 3，分支数为 5）。GoT 虽然灵活，但图结构需要维护节点依赖和循环检测，容易引入 bug，且 token 消耗随节点数指数增长。例如在 24 点游戏中，ToT 的准确率可达 74%，而 GoT 只提升到 78%，但延迟增加了 3 倍。所以优先推荐 ToT，除非任务明确需要合并多条路径（如多源信息融合）。
追问 2：CoT 的“Self-Consistency”和 ToT 的“投票机制”有什么区别？
核心区别在采样空间。Self-Consistency 是在同一线性链上采样多条路径（如温度=0.7 生成 5 条链），然后投票选最一致答案；本质是“平行链”，无交互。ToT 的投票是在树节点上评估不同分支的优劣，然后选择最优路径继续探索；本质是“树搜索”，有回溯。例如在 GSM8K 上，Self-Consistency 将准确率从 58% 提到 72%，而 ToT 只到 68%，因为数学题更依赖线性推理。所以 Self-Consistency 适合确定性任务，ToT 适合需要探索的任务。
追问 3：如何评估这些规划方法的效率？
常用指标：准确率（如 GSM8K 上的 pass@1）、推理步数（平均 token 数）、延迟（秒/任务）。工程上更关注“成本-收益比”，例如 ToT 每提升 1% 准确率，token 消耗增加 20%，而 CoT 只增加 5%。建议用“效率曲线”对比：横轴是 token 预算，纵轴是准确率。例如在 10k token 预算下，CoT 准确率 60%，ToT 65%，GoT 62%（因图结构浪费 token 在冗余节点上）。所以实际落地时，先跑 CoT 基线，再根据预算决定是否升级到 ToT。
5️⃣ 避坑 · 常见错误答法
- ❌ 把 CoT 和 ToT 混为一谈，说“ToT 就是 CoT 加多路径” → ✅ 正确区分：CoT 是线性链，ToT 是树搜索，核心差异在“回溯”和“分支评估”，而非简单多路径。
- ❌ 只提方法名，不说适用场景和 trade-off → ✅ 必须给出具体对比（如“ToT 适合创意写作，因为需要试错；CoT 适合数学，因为步骤确定”）。
- ❌ 忽略工程实现细节，只说“用提示词实现” → ✅ 补充实现难点（如 ToT 的状态评估器如何设计，GoT 的循环检测如何做）。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“规划能力增强检索”角度切入，例如用 ToT 规划多步检索路径（先搜 A，再根据结果搜 B），对比传统 RAG 的线性检索。
- 如果你只做过传统 NLP：用“搜索算法类比”迁移，例如将 CoT 比作贪心搜索，ToT 比作 Beam Search，GoT 比作图搜索，展示你对算法本质的理解。
- 如果你是校招无项目：聚焦论文复现 demo，例如用 GPT-4 API 在 24 点游戏上实现 ToT，记录准确率和推理步数，并对比 CoT 基线，展示动手能力。
- “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models” (Wei et al., 2022)
- “Tree of Thoughts: Deliberate Problem Solving with Large Language Models” (Yao et al., 2023)
- “Graph of Thoughts: Solving Elaborate Problems with Large Language Models” (Besta et al., 2023)
- “ReAct: Synergizing Reasoning and Acting in Language Models” (Yao et al., 2022)
- “Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models” (Wang et al., 2023)