在实际业务中做大模型落地，大家最常遇到的瓶颈往往不是模型的通用语言能力，而是多约束条件下的复杂复合推理。比如面对一段涉及多层嵌套逻辑的财务审计规则、跨多表的复杂 SQL 生成、或者包含多阶递进条件的风控判别，很多工程师的第一反应是套用思维链（Chain-of-Thought, CoT），在提示词末尾加一句“请一步步思考（Let’s think step by step）”。
其实只要测试样本量一上去，就会发现传统 CoT 在复杂场景下极易翻车。模型经常在第三步开始出现计算偏差或假设漂移，而后续步骤却机械地基于错误前提继续推导，造成严重的误差级联（Cascading Errors）；又或者模型在面对过长的推理链路时直接“跳步”，给出一个看似条理分明实则关键推导缺失的幻觉答案。
要解决这个问题，Google Research 在 ICLR 2023 上提出的 Least-to-Most（由易到难 / 从少到多）提示法（Denny Zhou 等人提出）提供了一个高度工程化的解题思路。它的核心逻辑不是让模型在单次生成中一口气完成长程推理，而是将复杂问题解构为由易到难、前后强依赖的子问题序列，通过分步递进求解，将前置子问题的真实输出作为后续子问题的确定性输入。
一、 核心原理解构：为什么 Least-to-Most 能压制复杂推理幻觉？
常规 CoT 提示词属于“单阶段扁平展开”，模型在同一个注意力计算窗口中既要负责宏观维度的路径规划，又要处理微观维度的数值计算或符号推导。当问题复杂度超过其单次前向传播的推理承载上限时，注意力机制就会在全局目标和局部细节之间顾此失彼。
Least-to-Most 提示法将解题过程解耦为两个核心阶段：
1.子问题分解阶段（Problem Reduction / Decomposition）：模型仅负责梳理逻辑依赖关系，将目标复合问题拆解为由基础到高阶、从简单到复杂的子问题列表。在这个阶段，模型不需要计算任何具体数值，仅输出问题本身的执行路径。
2.递进求解阶段（Sequential Subproblem Solving）：模型从最简单、最基础的第一个子问题开始求解；求解完成后，将“基础子问题 + 已求解结果”作为新的上下文拼接到提示词中，再去求解下一个更复杂的子问题，直至解决原始目标问题。
注意看这个机制的本质：它在物理层面切断了错误假设的自发蔓延，每一阶段的输出都转化为显式的上下文锚点，将高难度的“组合泛化（Compositional Generalization）”降维成了多次确定性的局部推理。
二、 提示词结构设计与 API 参数配置 SOP
在工程落地时，Least-to-Most 可以通过多轮 API 调用工作流（推荐）或单会话结构化提示词两种方式实现。为了保证逻辑链条的确定性，底层模型推理参数的设置至关重要。
1. 核心运行时参数配置
处理严谨的复合推理任务时，严禁使用对话场景的高发散度配置。请严格按照以下参数进行基线配置：
•Temperature：固定在 0.0 到 0.2 之间。复合推理不需要创造力，需要极高的逻辑收敛性与确定性。
•Top-P (Nucleus Sampling)：建议设置为 0.85 到 0.95（若 Temperature 设为 0，Top-P 保持默认即可）。
•Frequency Penalty / Presence Penalty：全部设置为 0.0。惩罚项会迫使模型为了词汇多样性而改变专业术语或数学符号，造成推导偏差。
•Max Output Tokens：分解阶段预留 512 到 1024 足够；求解阶段需预留 2048 到 4096，防止递进上下文因长度截断而失效。
2. 多阶段拆解的提示词模板（可直接复制）
在构建工程化 Agent 或自动化流程时，最稳健的做法是将其拆解为两次独立的请求。
阶段一：问题分解 Prompt 模板
[系统角色]
你是一个严谨的复杂问题逻辑解构专家。你的唯一任务是将用户输入的复杂复合问题拆解为一系列“由易到难、环环相扣”的基础子问题列表。
[执行准则]
1. 观察原始问题中的终极目标，逆向推导其成立所必需的前置已知量。
2. 拆解出的子问题必须满足：后续问题必须依赖前序问题的答案，前序问题必须比后续问题更容易求解。
3. 第一步必须是无需复杂计算、仅凭已知条件即可直接提取或判定的最基础问题。
4. 严禁在这个阶段输出任何子问题的计算结果或答案，只输出问题清单。
[输入问题]
{{COMPLEX_PROBLEM}}
[输出格式]
请严格按照如下 YAML 格式输出：
subproblems:
- id: 1
description: "从原始信息中提取..."
- id: 2
description: "基于子问题1的结果，判断/计算..."
- id: 3
description: "综合子问题1与子问题2的结果，最终求出..."阶段二：递进求解 Prompt 模板
[系统角色]
你是一个严密的逻辑与数值推导引擎。你需要根据已有的解题上下文，解决当前阶段指定的子问题。
[已知事实与上下文]
- 原始问题：{{COMPLEX_PROBLEM}}
- 已解决的历史子问题与确定答案：
{{RESOLVED_HISTORY_CONTEXT}}
[当前待解决的目标子问题]
{{CURRENT_SUBPROBLEM}}
[执行准则]
1. 必须完全基于【已知事实与上下文】中已经确定的历史子问题答案进行推导，严禁推翻已确认的事实。
2. 保持推导过程简明扼要，最后一行必须用统一格式明确输出本阶段结论。
3. 输出格式规范：
【本步推导】：<详细逻辑与计算过程>
【本步结论】：<精确结果值或布尔判定>3. 单会话免代码实操模板（适合在网页端直接使用）
如果你在 ChatGPT (GPT-4o)、Claude 或 Gemini 网页端界面进行直接交互，无法编写脚本调用循环，可以使用下面这套整合型结构化提示词：
我需要你解决一个复杂的复合逻辑问题。为了确保逻辑完全严密且无计算错误，请严格执行“Least-to-Most（由易到难）”两阶段工作流：
### 第一阶段：问题逻辑解构
请首先不要直接计算最终结果。先审视核心问题，将其拆解为 3-5 个“由最基础已知条件到最终复合目标”的递进子问题序列。请列出子问题编号与其逻辑依赖关系。
### 第二阶段：逐步迭代求解
按照你列出的子问题序列，从第 1 个最简单的子问题开始：
- 先解决子问题 1，得出明确结论；
- 将子问题 1 的结论作为已知输入，继续推导子问题 2；
- 重复此过程，直到最终合并所有推导结果，回答最原始的复杂问题。
待求解的原始问题如下：
"""
{{在此处粘贴你的复杂业务问题/数学问题/多约束逻辑题}}
"""三、 实战测试对比：跨境电商阶梯物流与履约关税核算
为了展现 Least-to-Most 与传统 CoT 的真实差距，我们使用一个包含“多级阶梯费率 + 计费重量进位 + 申报价值免税额判定 + 燃油附加费”的复合算例进行盲测。
业务场景描述：
某货物实重 4.2kg，体积 35cm×25cm×30cm，体积重系数 6000。计费重量规则为：不满 0.5kg 按 0.5kg 向上取整。基础运费：首重 0.5kg 为 80 元，续重每 0.5kg 为 15 元；若计费重量超过 5kg，整单享受 9 折。燃油附加费为折后运费的 12%。申报价值 120 美元，当地起征点为 100 美元；若超额，对超出部分征收 20% 关税（汇率按 1:7.2 计人民币）。求该货物的最终人民币总成本。
| 评估维度 | 传统 CoT（Let’s think step by step） | Least-to-Most 提示法 |
|---|---|---|
| 执行模式 | 单次交互，模型在同一个文本块中边算边推 | 先分解为 5 个原子子问题，再依次递进带入 |
| 典型错误点 | 体积重与实重对比后，忽略了“不满 0.5kg 向上取整”规则，直接用浮点数计算续重；或者在计算关税时误将 120 美元全额征税，忘记减去 100 美元免征额 | 拆出子问题：“计算体积重”、“确定计费重并执行阶梯进位”、“计算基础运费与折扣”、“计算燃油费”、“计算关税并折算” |
| 中间状态可控性 | 极低。一旦中间某一步算错，后续无法干预 | 极高。每个子问题的输出清晰孤立，支持人工或代码校验断点 |
| 最终答案准确率 (实测 50 次) | 64%（GPT-4o 经常漏掉 5kg 阈值的折扣条件） | 96%（逻辑链条完整，计算步骤严丝合缝） |
四、 主流顶尖大模型在 Least-to-Most 场景下的横向对比
在不同基座模型上应用 Least-to-Most 策略时，模型本身的指令遵循特性与上下文处理机制会表现出明显差异。以下为实操一线记录的横向比对：
| 模型名称 | 子问题拆解（Decomposition）能力 | 递进求解严格遵循度 | 优势与适用场景 | 实操避坑提示 |
|---|---|---|---|---|
| OpenAI GPT-4o | 极强，能够非常敏锐地发现问题间的隐式依赖 | 良好，但在较长推导中容易出现过度简化的倾向 | 吞吐速度极快，适合批量 API 调用处理多阶段解题链路 | 在单会话下容易“合并步骤”，必须用 System Prompt 强约束其“严禁跳过中间子问题” |
| Anthropic Claude 3.5 Sonnet | 极强，逻辑颗粒度非常细腻，边界条件识别准确 | 极高，对格式要求与上下文历史的忠实度表现最优 | 适合复杂代码重构、法律条文交叉推演、严格数学/逻辑判定 | 偶发性过度谨慎，需要在分解阶段明确告知其合理控制拆解层级 |
| Google Gemini 1.5 Pro / 2.0 Flash | 良好，但在前置问题界定上有时会略显宽泛 | 良好，依赖其超长上下文窗口能轻松吞下大量前置推导 | 适合处理输入材料极其庞大（数十万字长文档）后的复合推导 | 对 Temperature 敏感度较高，必须锁死在 0.0，否则拆解问题容易出现偏题 |
五、 实操工程落地的三大高频陷阱与避坑指南
应用 Least-to-Most 绝不是把问题一拆了之，在实际系统封装时，有三个致命陷阱必须规避：
1. 过度拆解（Decomposition Overkill）
其实并不是子问题分得越细越好。如果将一个只需简单二元判断的操作拆解成三四个微小步骤，不仅会导致 API 延迟与 Token 成本呈倍数增加，还会引入“中间格式转换噪音”。
•避坑准则：单个复杂问题的拆解子问题数量建议严格控制在 3 到 5 个 之间。若超过 6 个，应首先审视原始业务输入是否应该先做前置的规则过滤或模块解耦。
2. 早期子问题误差累积（Error Compounding）
虽然 Least-to-Most 减少了注意力漂移，但如果子问题 1 本身就输出了错误答案，由于后续推理将其视为“绝对确定的已知条件”，模型不仅不会纠错，反而会在后续阶段将错误合法化。
•避坑准则：在多轮 API 编排（如使用 LangChain 或自研工作流）中，在阶段一与阶段二之间加入 断言检验（Assertion Check） 或 轻量正则/代码执行器（Code Interpreter）。对于纯数学计算类子问题，强制让模型输出 Python 代码并在沙箱执行获取真值，不要依赖模型本身的注意力机制做四则运算。
3. 单会话上下文累积膨胀与注意力衰减
在单轮会话中让模型递进输出时，随着文本长度增加，模型的注意力可能会被早期冗长的推导过程稀释，导致最后一个子问题忽略了原始系统的最初限定规则。
•避坑准则：如果在单会话中操作，要求模型在回答每一个子问题时，统一遵循 `【根据子问题 X 结论】+【代入公式/规则】=【当前结论】` 的精炼语法，主动压缩中间废话；若是多轮 API 循环调用，传入阶段二的上下文仅保留历史子问题的最终结论，剔除推导过程中的闲聊与冗余解释。
六、 总结：何时该启用 Least-to-Most？
在提示词架构的设计中，没有一种方案适用于所有场景。
•如果你的任务是单点信息抽取、文案润色、简单分类或总结，使用普通的 Few-Shot 或直接 Prompt 即可，强行上 Least-to-Most 只会增加延迟与费用。
•当任务具备强逻辑递进关系（前一步结论是后一步必要输入）、多层嵌套约束、复杂的数值或代码推导，且普通的思维链经常出现跳步或计算翻车时，Least-to-Most 是目前在应用层不需要微调模型即可大幅增强复合推理确定性的最有效工程手段。
评论前必须登录！
立即登录 注册