大模型推理：Prompting、多路径搜索与迭代自改进

1 整体框架：三条“加算力”的思路

回顾 o1 / o3 / DeepSeek‑R1 等“推理型大模型”，有一个事实：性能越来越依赖 test‑time compute（推理阶段的算力），比如 o3 在 ARC‑AGI 上每道题推理成本可以超过 1000 美金。

整个内容分三块：

1. Prompting 技术：给一条问题，多花 token 让模型生成更长、更细致的一条推理路径（depth in one path）。
2. Search & Selection：对同一题生成很多条候选路径，在“宽度”上做搜索与选择（width across many paths）。
3. Iterative Self‑Improvement：让模型多轮自我反思和修改，形成“深度的迭代修正”（depth over multiple attempts）。

后面所有内容都围绕这三块展开。

---

2 Prompting：让模型在“一条路径”上想得更深

2.1 标准 Prompting vs Chain‑of‑Thought（CoT）

• 传统 few‑shot 提示只给“最终答案”的例子，模型知道输出格式，但不知道中间推理步骤的风格，在 reasoning benchmark 上表现很差。
• CoT 提示会在示例里写出完整思路，例如先算 2 罐网球总数，再相加，最后得 11；模型就会学会“先分步推，再给结论”的模式。

这带来两个关键好处：

1. 自适应计算量：题目越难，CoT 推理步数自然越长。
2. 显式策略：我们可以在 prompt 里明确要求“先分解问题，再逐步求解”，使模型采用 decomposition、planning 等策略。

2.2 Analogical Prompting：让模型自己找“类比例题”

人类解题会先想“有没有类似做过的题”。Analogical prompting 模仿这一点，让 LLM 在解新题前先自己生成相关例题和知识。

流程大致是：

1. 给一个复杂题（比如 Codeforces 编程题），在指令里要求模型：
   • 先解释核心算法概念；
   • 写一段教程；
   • 给 3 个相关例题（包含题意说明、详细解法、代码）；
   • 最后再回到原题写解法和代码。
2. 模型会自发产出：
   • 高层知识（比如“前缀积算法”是什么，时间复杂度如何）。
   • 几个结构类似的例题及其代码，这些就是自生成的 exemplars。

实验结果（GSM8K、Codeforces、BIG‑Bench temporal reasoning）显示： 自生成 exemplars + 知识的 analogical prompting > 手工 few‑shot CoT > 0‑shot CoT > 0‑shot，尤其是底层模型 text‑davinci‑003 表现最明显（61% 对比 54% 等）。

2.3 CoT 带来的“策略空间”

CoT 不只是写长过程，还支持更多 reasoning pattern：

• Least‑to‑Most Prompting：
  • Stage 1 让模型先把原题拆成若干子问题（比如先算“每次滑梯花几分钟”，再算“15 分钟能玩几次”）。
  • Stage 2 再按顺序逐个解子问题，前面的解答会连同题目一起作为后续的上下文。
  • 在 SCAN / CFQ 这类“组合泛化”任务上，Least‑to‑Most 能在只用 0.1% 训练样本的情况下，几乎完美地泛化到更长、更复杂的命令序列。
• Dynamic Least‑to‑Most：对复杂语义解析任务（CFQ），先用 LLM 自动进行句法/成分划分，再为每个子结构选择最合适的 exemplars，最后顺序生成完整 SPARQL 查询；在 MCD splits 上显著超过各种 fully supervised T5 模型。
• Self‑Discover：不再人工指定用哪种策略，而是先列出“策略库”（CoT、分解、反思等），让 LLM 自己思考“这个任务最适合什么结构”，然后组合出任务专属的推理流程，自适应调整步骤，整体在 MATH、BIG‑Bench‑Hard 等上都优于普通 CoT。

小结：Prompting 部分的主线是——用 CoT 及其变种（类比、易‑到‑难分解、自发现策略）把单条推理路径拉长并结构化，让同一模型在一条样本上多花 token 思考。

---

3 Search & Selection：多路径搜索 + 一条最优

仅靠一条 CoT 仍然容易出错，因为 LLM 第一次想错的概率不低。于是：生成多条候选，再选最好的。

3.1 Self‑Consistency：最终答案的一致性投票

Self‑Consistency 的思路：

1. 用 CoT prompting，多次采样生成不同的推理路径（高温或 nucleus sampling 确保多样性）。
2. 只看每条路径的“最后答案”，不在意中间推理是否一致。
3. 用多数表决选出出现次数最多的结果，作为最终答案。

实验表明：

• 相比“只取 log‑prob 最高的一条”（Sample‑and‑Rank），Self‑Consistency 的准确率随 sample 数增加能持续上升；
• 对 拉普拉斯的 AddSub / MultiArith、GSM8K 等数据，在多个模型上都带来 5–20+ 个百分点的提升（例如 GPT‑3 code‑davinci‑002 在 GSM8K 上从 60.1% 提升到 78.0%）。

核心直觉：如果多条随机路径都得出同一个结论，那这个结论更可能正确。一致性越高，模型对自己的答案越“有把握”。

3.2 用“执行结果一致性”做聚类：AlphaCode

在竞赛编程场景下，AlphaCode 的流程是：

1. 大规模采样生成成千上万份解题代码。
2. 让模型自己再生成很多新的测试输入，对所有候选代码执行这些测试。
3. 把执行结果完全相同的代码聚类，认为它们实现了同一个“语义”；
4. 从最大的若干 cluster 中各抽一份代表代码，再用真实评测系统跑，选出通过的那份。

这种“按执行一致性聚类 + 选代表”的方法，比只做简单过滤（例如只保留不超时、不过 compile error 的代码）性能明显更好，但离“oracle 总能选到真正正确程序”的上限仍有差距。

3.3 Verifier‑based Selection：ORM / PRM 作为评分器

Search & selection 里需要一个“裁判”，这就回到上一讲说的 Outcome Reward Model（ORM）和 Process Reward Model（PRM）。这一讲重点放在数学推理 verifier上。

3.3.1 “Training Verifiers to Solve Math Word Problems”（OpenAI 2021）

• 首先构建 GSM8K 数据集：约 8.5K 小学生应用题，人工编写、高质量、多步推理，并给出自然语言过程与最终答案。
• 方法一：只 fine‑tune 一个生成模型，在 GSM8K 上直接输出解答。
• 方法二：fine‑tune + verify：

1. 把 fine‑tuned 生成模型当“generator”，对每题生成大量候选解（如 100 条）。
2. 训练一个“verifier”模型，对每条解答判断对错。
3. 推理时让 verifier 在这些候选解上打分，选分最高的那条。

实验结论：

• 当训练集很小时，verifier 会过拟合，反而没有帮助；
• 数据足够大时，“fine‑tune + verification”显著优于只 fine‑tune；
• 在固定总参数预算下，“大 generator + 小 verifier”比“小 generator + 大 verifier”更划算——生成模型的能力更关键；
• 推理时生成的候选数越多，性能持续上升，最多在 400 条附近明显收益。

3.3.2 PRM800K & “Let’s Verify Step by Step”（OpenAI 2024）

这篇工作提出：过程监督（PRM）比结果监督（ORM）更强。

• 建立 PRM800K 数据集：
  • 先用 GPT‑4 生成大量数学题解的推理步骤。
  • 通过主动学习挑选那些“模型觉得很正确但答案其实错”的样本，让人一行一行标记为“正/负/中立”；
  • 相比随机挑选样本，这样的数据收集方式效率高 2.6 倍。
• 训练两个 verifier：
  • ORM：判断整条解题过程是否得出正确答案；
  • PRM：对每一步判断是否是朝向正确答案的“好步骤”。

结论：

• 在 GSM8K / MATH 上，PRM 作为 verifier 的效果普遍优于 ORM 和 Self‑Consistency，特别是在采样条数较大时差距更明显；
• PRM 对 out‑of‑distribution 数据也有更好的泛化；
• 但 PRM 需要大量人工逐步标注，成本高、难扩展。

3.3.3 Math‑Shepherd（DeepSeek 2024）：用模型自动标 step

Math‑Shepherd 的目标是：不用人手标 step‑level 标签，自动训练一个 PRM 类似的过程 verifier。

核心想法：

1. 对每个中间步骤 $s_i$，用模型继续生成 N 条完整推理（不同后续路径），看这些路径中有多大比例能得到正确答案。
2. 把这个“潜在能解题的概率”作为该步骤的标签（硬估计 HE：是否有任何正确答案；软估计 SE：正确答案频率）。
3. 用这些自动标签训练 PRM；再用它来做：
   • verification：在 256 条候选路径中打分选最好的；
   • RL：step‑by‑step PPO，把每一步 reward 奖励给生成模型。

结果（以 MetaMATH 上微调的 LLaMA2 / Mistral 为例）：

• 作为 verifier，Math‑Shepherd 在 GSM8K / MATH500 上都优于 ORM 和 Self‑Consistency；
• 作为 RL reward，step‑by‑step PPO 进一步提升了 greedy decoding 下的准确率；
• 把 RL 与 verification 结合，效果更好，例如 Mistral‑7B 在 MATH500 上可达 43.5%。

3.3.4 AutoPSV：把 ORM“一键升级”为 PRM

AutoPSV 试图在成本和效果之间折中：

• 先训练一个 outcome‑supervised verifier（OSV，相当于 ORM），只看最终答案对不对。
• 再用 OSV 去评估每一步推理的“正确概率”，计算前后步骤置信度的变化：
  • 如果置信度明显上升，说明这步是好 step；
  • 如果置信度骤降，说明是坏 step。
• 以此为自动标签训练一个 process‑supervised verifier（PSV）。

在 GSM8K / MATH（数学）与 HellaSwag / Winogrande / ANLI（常识推理）上，OSV+PSV 几乎总是优于单纯 OSV 或 Self‑Consistency，说明这种“用自己置信度变化标注 step”的方法兼顾了 PRM 的细粒度和 ORM 的低成本。

3.4 Tree‑of‑Thoughts（ToT）：用树搜索充分利用步级评分

前面的 selection 多在“整条解答生成完之后”再评分。ToT 则进一步：在生成过程中就进行分支探索和剪枝。

以 24 点游戏为例：

1. 在每个中间状态，让 LLM 生成若干下一步“思路”（thought generation）；
2. 用另一条 prompt 让 LLM 给每个状态估一个评分（thought evaluation）；
3. 用 BFS 或更高级的 MCTS 在这棵“思维树”上按分数扩展 top‑b 节点，剪掉低分分支；
4. 最终在搜索树中找到达到 24 的一条路径。

实验表明：在相同 token 预算下，ToT(b=5) 在 24 点游戏上的成功率可达 74%，远高于 IO prompt / CoT / CoT‑Self‑Consistency 的个位数到 10% 左右表现。

小结：Search & selection 这一块的主线是——多条路径 + 更好的裁判（Self‑Consistency / ORM / PRM / AutoPSV） + 树搜索，在“宽度”和“局部深度”上进一步挖掘 base 模型的潜力。

---

4 Iterative Self‑Improvement：多轮自我修正

即便有搜索和 verifier，LLM 仍会犯错。第三部分讨论：如何让模型在推理时自己不断“反思+重写”。

4.1 Reflexion / Self‑Refine：显式“自评 + 修改”

基本模式：

1. 模型先输出一个答案（带或不带 CoT）。
2. 再让模型根据某种反馈生成一段“反思”（reflection），指出哪里可能错了、如何改进。
3. 把原答案 + 反思一起作为上下文，再生成新的版本，如此迭代多轮。

• 如果有外部评价（例如 HotPotQA 的有无答对标记、ALFWorld 环境的 reward），Reflexion 能在决策、推理、编程任务上稳步提高成功率。

4.2 代码自调试（Self‑Debugging + Effi‑Learner）

代码场景特别适合自我改进，因为：

• 可以通过执行单元测试获得非常清晰的错误信息；
• 还能获取性能指标（时间 / 内存 profile）来做效率优化。

自调试的多种反馈形式包括：

• 简单：“你的代码没通过测试，请修复”；
• 附带单测输出（哪一组输入失败）；
• 行级解释；
• 执行 trace（每行运行的中间状态）。

在 Spider / TransCoder / MBPP 等多数据集上的实验结果显示：反馈越丰富，修复后代码的正确率越高；不同 LLM（Codex、GPT‑3.5/4、StarCoder）都受益。

Effi‑Learner 进一步利用性能 profile（时间、内存热点）驱动多轮优化，使模型能自动“写得又对又快”。

4.3 自纠错的失败与改进

• “LLMs Cannot Self‑Correct Reasoning Yet”指出：没有 oracle feedback 时，纯靠模型自己判断对错往往越改越糟，因为它会错误地否定正确答案或接受错误答案；类似地，多代理辩论在没有强 evaluator 时，也不一定优于 Self‑Consistency。
• LeCo（Learning from Correctness）尝试让模型自己给每一步推理打置信度，识别低置信度的错误 step，再把“之前置信度高的步骤”作为事实前提重新生成后半部分，从而逐步逼近正确答案，减少对人工提示和外部工具的依赖。

4.4 如何分配 token 预算？

结合 test‑time scaling，这里给出的经验是：

• 在给定 FLOPs 预算下，小模型可以用更多样本 / 更多修正，大模型则每条样本花更多推理步。
• “最佳策略”高度依赖于具体模型和任务：有些模型自反思能力强，适合多轮 sequential revision；有些模型更适合平行采样 + verifier 选择。

---

5 大原则：Bitter Lesson 与推理技术设计

最后用 Sutton 的 Bitter Lesson 收尾：

• 应优先设计可随算力扩展的通用方法，而不是在人为规则、手工 prompt 里硬编码太多“我们的发现”；
• 像 CoT、Self‑Consistency、Verifier、Tree‑of‑Thoughts、Test‑Time Scaling 等方法，都符合“算力越多、表现越强”的思路，是目前推理型 LLM 研究的重要方向。

---