★ FEATURED ARTICLE 最近有位开发者朋友问我为什么同一个大模型别人调用起来效果明显更好自己调用却总感觉“笨笨的”我和他一起排查了一下午最终发现问题的根源不是模型选错了也不是Prompt写得不好而是几乎完全没利用“推理时计算”这个杠杆。模型权重是固定的但模型在生成答案时“想多久、想几条路、怎么回头修正”这些全是主动权在我们手里的。把这一层玩明白效果提升往往立竿见影。这篇文章想做的事情很直接把从思维链CoT到思维树Tree-of-ThoughtsToT这条技术路线完整拆开讲清楚每一种推理时计算手段的原理、适用场景、实操参数和成本边界。不是为了堆术语而是给出一套能直接拿去用的决策思路。适合正在调大模型应用、被推理准确率困扰的开发者和算法工程师也适合想系统了解“如何让大模型更聪明”的进阶学习者。1. 推理时计算到底是什么先搞清这笔算力花在哪1.1 训练时与推理时两种花钱买能力的方式大模型的能力来源从来不只是训练阶段。传统印象里模型要变强就得调参、加数据、加大训练算力把知识“固化”进权重里。但训练完之后权重就冻结了。在服务阶段模型每生成一个token都会消耗计算资源这是另一笔能被我们主动控制的算力支出也就是“推理时计算”。打个比方训练时计算像一个学生平时上课刷题把知识内化成解题直觉推理时计算则像考试时多打几遍草稿、用不同方法交叉验证检查答案。平时不努力的考生考试时认真检查也可能及格反之哪怕是个学霸草草看一眼就交卷也容易犯低级错误。模型同样如此——在不同任务上多花推理算力带来的收益差异非常大。我在实际项目中见过很多案例同一个开源模型直接生成答案的正确率只有40%左右但套上一层思维链后提升到70%再加上多次采样投票能逼近85%。这不代表模型变强了而是推理策略变了。理解这个底层逻辑是后续所有技巧的地基。1.2 为什么这两年大家都在谈推理时计算过去一年里推理时计算从一个学术名词变成了工程热点。“推理时扩展”这个概念之所以爆发背后有三层现实原因。第一大量生产环境的模型是通过API或开源权重使用的训练环节根本动不了。我们唯一能调节的就是prompt、采样参数、生成长度、调用次数这些推理阶段变量。第二研究表明在不少复杂推理任务上“小模型大规模推理时计算”可以追平甚至超越“大模型普通推理”的效果。这不是说训练不重要而是说推理阶段的投入被严重低估了。第三推理阶段的计算量是高度可选的。想要更多思考就多生成一些中间token想要多条候选路径就多采样几次想搜索得更深就多扩展几个节点。这种“按需付费”的特性让推理时计算成为性价比极高的优化手段。但这个杠杆不是无脑加的。它带来的直接代价是延迟变高、token账单变长、体验变卡。怎么平衡后面的实操章节会给出具体策略。1.3 推理时计算的技术版图为了不迷失在细节里先给一张全局图景。目前业界常用的推理时计算手段可以分成几大类思维链CoT让模型把推理步骤显式写出来相当于要求模型打草稿。自洽性采样CoT-SC同一个问题多次生成完整的CoT再对最终答案投票相当于让多个“草稿版本”互相印证。思维树ToT把推理过程拆成多个决策步骤每个步骤探索多个候选分支再通过评估和回溯找到最优路径相当于把草稿纸变成了一棵有取舍的搜索树。验证器与搜索增强训练一个过程奖励模型或结果奖励模型给每一步或每个候选打分再用搜索算法比如蒙特卡洛树搜索在推理空间里找高置信路径。这些方法并不是互相替代的关系而是递进关系从最便宜的“让模型多写点字”到最昂贵的“让模型在大量候选路径里做结构化搜索”。选择哪一层取决于任务的复杂度和你对正确率的容忍度。2. 思维链CoT最便宜的推理时计算入口2.1 CoT为什么有效把“猜答案”变成“算答案”在CoT出现之前大模型面对复杂推理问题时经常被要求直接从问题跳到答案。这对模型来说非常反直觉相当于让人做一道复杂的数学题但不许打草稿只能在脑子里一顿猛算然后直接写出最终结论。模型每一步都在做概率预测跳的步子越大、中间环节越多误差累积就越严重。CoT的核心机制是让模型把中间步骤显式地吐出来。每一步只生成一个相对小的推理片段模型在小步长上的预测准确率远高于大跨度跳跃。更重要的是这些中间步骤本身会参与后续token的生成相当于给后续推理提供了“脚手架”。模型不再是凭空猜测答案而是在自己上一句的基础上继续推算这和人类解题时的思维过程非常接近。我最早在数学应用题上调CoT时感受特别明显。直接让模型答题它经常靠“题感”猜一个数字然后照着这个数字编一个解题过程结果对不上。一旦加了“请逐步推理”模型开始老老实实地设未知数、列方程、计算求解整个过程的可控性一下子就上来了。2.2 触发CoT的三种实用姿势不是所有模型都会自动展开思维链需要用指定的方法触发。根据我的经验有三种方式最常用也最稳定。第一种是少样本示例法。在系统提示里给出两到三个完整的“问题-推理-答案”示例让模型模仿结构。示例最好和当前任务在风格上接近不需要完全同领域但推理类型要相似。比如你要做逻辑推理示例就配逻辑题而不是配代码生成题。第二种是指令触发法。直接告诉模型“请一步步思考并在给出最终答案前进行推导”。这种方式最轻量但对模型本身的基础能力有一定要求。太小的模型即使接到指令产出的推理过程也往往是事后编的而不是真正参与决策。第三种是零样本CoT的变体也就是经典的“Lets think step by step”这类通用触发短语。实际使用时不建议每次都写英文原句用中文效果也不差比如“请一步步地分析和推理”。有些API服务还会在模型侧内建这部分逻辑表现为“深度思考”之类的选项本质上是一样的。我自己在项目里通常采用“指令触发一个结构化示例”的组合这样既不会让token消耗失控又能让模型稳定进入推理模式。2.3 让CoT稳定发挥的细节参数CoT看起来简单但细节不到位的时候效果差别很大。最常被忽略的是生成长度上限。很多接口默认的max_tokens只有几百模型推理到一半被截断了最后只输出一个不完整的推理过程没有结论或者被迫在一个句子中间戛然而止。给复杂任务设置足够长的输出上限非常关键。温度参数也有讲究。CoT阶段建议温度保持在比常规生成略低的水平比如0.4~0.7之间。温度太低会让推理路径过于保守模型可能只肯走最常用的思路不敢尝试新的计算方式温度太高又容易“胡言乱语”中间推理步骤出现幻觉。需要一个折中。还有一个小技巧是给推理过程和最终答案做结构隔离。比如在提示词里要求模型先输出“推理”和“/推理”标签包裹的步骤再输出“答案”标签包裹的结论。这样后续程序可以方便地剥离推理过程只取最终答案。我在多个项目里都用这种标签法解析起来非常干净也避免了把推理内容当成最终结果展示给用户导致体验臃肿。3. 自洽性CoT-SC用“多次思考”换“一次对的答案”3.1 为什么单个CoT不够稳就算加了CoT模型依然可能犯错。原因很简单大模型的生成带有随机性即使温度不高每次采样也可能走出不同的推理路径而单条路径一旦在某个中间步骤出现偏差后面很可能一路错到底。我举一个实际例子。让模型推理一道包含多个条件的分段计费问题第一次采样它思路正确但计算失误第二次采样它正确理解了题目但忘了某个条件第三次才完整答对。单次采样的正确率可能就是60%到70%你永远不知道这次是不是那个“对”的采样。这种不确定性在普通问答任务里还能忍但在金融、医疗、代码审查这类场景里是完全不能接受的。自洽性的思路非常朴素既然单次采样不靠谱那就多采样几次让答案们“开会投票”。如果大多数推理路径都指向同一个最终结论这个结论的正确概率就会显著提升。它不依赖单个路径的完美而是依赖“多个独立思路相互印证”的统计效应。3.2 自洽性的实现过程与投票策略CoT-SC的实操流程不复杂一共三步。第一步对同一个问题生成N次独立的CoT推理结果每次采样时温度和prompt可以保持一致但采样随机性会带来不同的探索方向。N一般取5到8太少没有统计意义太多边际收益递减。第二步从每个完整回答里抽取最终答案部分把推理过程剥离掉。这一步建议在提示词层面就约定好答案格式比如统一规定“最终答案是xxx”否则解析时很痛苦。第三步对所有答案做聚类和投票。答案字符串一致的归为同一组取出现次数最多的答案作为最终输出。对一些答案表述不一致但语义一致的情况需要提前定义归一化规则比如数字要转成统一格式或者对选择题只保留选项编号。这套流程我在代码里通常用一个简单的字典计数就实现了核心逻辑不超过20行。但请注意投票只对“有唯一正确答案”的任务有效。如果任务是写一篇文案、一个故事自洽性就不适用因为压根没有“标准答案”可以投票。3.3 几个容易被忽略的坑CoT-SC最大的坑是温度配错。很多人以为要投票就得把温度调得很高来增加多样性结果采样结果千奇百怪正确路径反而被淹没也有人跑到另一个极端温度压到接近0结果每次采样几乎一样投票变成了形式主义。我的实测经验是温度可以比单次CoT略高一点比如0.5到0.8既保留路径多样性又不至于完全失控。第二个坑是成本和延迟被忽略。采样N次意味着token开销直接变大。很多API是按token计费的N8时一次请求的费用相当于8次普通请求。好在多数服务支持并行发起采样所以墙钟时间不一定线性上涨但账单一定是线性的。需要先算清楚项目预算再定N值。第三个坑是投票结果的一致性判断。模型在表达同一答案时可能使用完全不同的句式比如“答案是42”和“结果等于42”如果不做归一化就会变成两个阵营导致票数被稀释。建议在提示词里强制统一输出格式必要时在后处理里写正则表达式把答案提取出来再比较。4. Tree-of-ThoughtsToT把思考变成可搜索的树4.1 链的局限一错到底CoT把思考展开了但仍然是一条单行道。模型的推理过程是线性生成的每一个token都依赖前面所有内容。如果中间任何一步的判断是错的后面的推理无论多努力都只是在错误的假设上继续堆砌。更麻烦的是模型通常不会主动发现并修正自己的中间错误只会一条路走到黑。我在实际项目里见过一个很搞笑的例子让模型算三个人年龄的倍数关系它先从“设甲的年龄为x”开始然后写到一个等式时算错了后面所有步骤都对着这个错误结果展开最后信心满满地给出了一个明显荒谬的负数年龄。这就是链式推理的天然缺陷没有回溯机制。人类解复杂问题时如果思路不通会果断放弃这条路径回到分岔口尝试另一条路。ToT做的事情就是把这种“分岔-尝试-回溯”的搜索过程搬到模型推理里。它的核心洞察是把推理过程拆成多个步骤每个步骤生成多个候选而不是只生成一个最可能的后续。每一个候选都像一个树的分支先对分支做初步评估把有希望的分支保留下来继续扩展把没希望的分支剪掉最终在树的末端找到一条通向正确答案的路径。4.2 ToT的四件套分解、生成、评估、搜索ToT实现起来需要四个组件每个都有很多实现细节。第一个是问题分解器。它决定怎么把大问题拆成小步骤。比如一个算术应用题的“步骤”可以是“提取条件”“建立方程”“计算变量”“验证答案”四个阶段一个谜题可以按谜面信息处理顺序来拆。分解得好不好直接决定了搜索空间的大小。第二个是候选生成器。在每个步骤上用CoT等方式让模型生成多个候选动作。可以用同一个prompt多次采样来获得不同候选也可以设计多个不同视角的prompt来引导不同方向。我通常让两个提示词模板并行生成再用采样去重候选质量会比单模板高很多。第三个是评估器。最粗暴的方案是让大模型自己给候选打分比如“从正确性角度给下面这个中间步骤评分0到10分”。更可靠的方案是训练一个过程奖励验证模型专门评估“这一步做得对不对”但工程成本高。还有一个轻量方案是写一些启发式规则比如数学题里检查“变量是否都有定义”“等式两边是否量纲一致”。第四个是搜索算法。广度优先适合候选路径不太深、每层候选不太多的问题深度优先更省token配合回溯可以深入探索单条路径。最简单的是beam search每层保留Top-B个候选分支继续扩展复杂一点的是蒙特卡洛树搜索用探索和利用的平衡来动态分配搜索资源。这里给一个ToT核心流程的骨架代码伪代码级别的方便理解实际项目里可以根据任务改造成异步或批处理。def solve_with_tot(question, decomposer, generator, evaluator, beam_width3, max_steps5): # 初始化根节点推理起始状态 states [{question: question, steps: [], score: 1.0}] for step in range(max_steps): candidates [] for state in states: # 第1步把当前状态推进到下一步生成多个候选动作 actions generator.generate_actions(state) for action in actions: new_state apply_action(state, action) candidates.append(new_state) # 第2步评估所有候选过滤掉低分状态 scored [(eval(evaluator.score(c), c)) for c in candidates] # 第3步按beam_width剪枝只保留最有可能的几个路径 scored.sort(keylambda x: x[0], reverseTrue) states [item[1] for item in scored[:beam_width]] # 第4步从剩余的完整路径里取最终答案 return extract_best_answer(states, evaluator)这段代码里每一步都要调用多次模型token消耗和耗时都很高。所以ToT不是默认选项而是“普通方法压不住”时才上的重型武器。4.3 搜索策略与算力取舍在ToT里真正决定效果上限的是搜索策略。我建议从最简单的beam search开始而不是一上来就上蒙特卡洛树搜索。beam search只需要调一个参数每层保留几个分支。分支数设为1时ToT退化成普通的CoT设为3到5时能明显提升成功率再往上收益曲线会变得非常平缓。如果问题中间步骤的“成败判断”非常清晰比如代码运行后的报错信息、数学格式校验可以用深度优先加回溯。这个方法的钱花得更值得因为它不会在明显错误的路上继续花钱。蒙特卡洛树搜索则更适合那些评估信号弱、搜索空间巨大的问题。它通过多次模拟来估计每个分支的期望成功率动态分配算力。但它的调度逻辑复杂维护成本高建议在验证过beam search无法满足需求之后再考虑。一个重要的性价比原则ToT不要对整棵树每个节点都用最高质量的评估器。可以把算力集中在“关键决策点”普通步骤用标准CoT带过在分岔点才展开全面搜索。我在实际项目中用这种“稀疏ToT”的方式把复杂任务的推理成功率从62%拉到了81%token消耗只增加了2.1倍。5. 更广的推理时计算视野验证器、计算边界与性价比5.1 让模型自己打分可靠吗启发式、LLM打分与验证器用大模型给推理步骤打分这件事本身就存在不确定性。我测试过让同一个模型评估另一个模型生成的中间步骤发现它经常被长得很唬人但逻辑错误的推导误导换成让它给自己的思路打分偏差更大。所以在ToT的评估环节不能把命运完全交给“模型自觉”。在工程上评估器可以分三层部署。第一层是规则启发式成本几乎为零比如检查数学题的变量是否都有定义、生成的代码是否能通过语法检查、路径规划的目标点是否在合法范围内。能写规则的地方优先写规则。第二层是轻量级的大模型打分把候选步骤和问题的关键约束一起发给模型让模型给出结构化的评分和理由。这一层适合规则覆盖不了的语义判断。第三层是专门训练的过程奖励模型或结果奖励模型质量最高但成本也最高。只有当任务非常固定、调用量足够大时才值得去训练一个专属验证器。我的建议是能用规则用规则能用单一模型打分就别训练新模型。大多数项目做到前两层就足够了。5.2 推理时计算的成本方程推理时计算本质上是用钱买准确率。了解成本方程才能冷静判断“加一次采样到底值不值”。一次推理的完整token消耗等于输入token数加上所有输出token数。在CoT-SC场景下总成本约等于采样次数乘以单次完整对话的token数再加上聚合和解析的开销。如果采样次数是8每次输出的推理过程是800个token那么一次问题解答就要消耗大约6400个输出token。在ToT场景下成本就更夸张了每个节点的生成和评估都会召唤一次模型调用。假设每层5个候选一共4层每个候选生成带评估消耗500个token总共就是10000个token。我通常这样计算性价比先用量化方式来对比任务在不同推理策略下的正确率再算单位成本下的正确率提升幅度。如果从CoT切到CoT-SC正确率提升了15个百分点成本上升8倍但整体项目毛利能承受那这就是一笔好买卖。反过来如果提升只有3个百分点那这笔钱就不值得花。这里有个容易被忽略的细节不是所有API服务都能并行处理多次采样。有些服务支持在同一请求里生成多个候选有些则必须串行调用。串行时延迟会线性拉长如果你的场景对首Token延迟有强要求CoT-SC的“实时体验伤害”可能比成本更致命。5.3 什么时候升级模型什么时候多花推理算力很多人的第一反应是“效果不好就换个更大的模型”这在很多场景下反而是最贵的方案。一个更大规模的模型不仅API单价更高整体延迟也更高而且可能带来完全不可控的行为变化。相比之下在现有模型上加推理时计算改动范围可控失败了随时可以回滚。我的判断标准很简单先用便宜的推理时计算手段把当前模型的推理潜力榨干再去考虑换模型。如果CoT-SC已经把准确率推到平台期比如连续增加采样次数都不再上涨那说明模型的“单步推理能力”已经到顶了此时换一个基础能力更强的模型才有效果。如果CoT-SC还没试或者采样次数加到20次准确率还在缓慢上升那就说明模型还有余力换模型是浪费钱。用模型能力强弱来分流还有个好处小模型加充足推理时计算在很多场景下会比大模型加粗糙推理更可靠。因为小模型的采样成本低试错空间大大模型虽然单次准确率高但一次错误带来的损失也更大。这是一个反直觉但实测经常成立的结论。6. 实操落地从API到代码的推理时计算配置模板6.1 一个开箱即用的提示词模板下面这个模板是我在多个数学推理和逻辑推理场景里反复用过的兼容中文任务也容易改造成其他语言。它把CoT和结构化输出一起解决了。你是一个严谨的推理引擎。请按以下流程回答问题 1. 先用推理标签列出你的完整推导过程每一步都要基于前一步的结果。 2. 再用答案标签给出最终答案答案必须是一个独立的字符串不要包含任何解释。 3. 如果你发现自己某一步推导有误请在后续步骤中进行修正无需重头再来。 问题{question}这个模板的关键在于定义了推理和答案的边界。解析时只需要提取答案标签里的内容推理过程可以完整丢弃不会污染下游逻辑。配合CoT-SC使用时每个采样都会生成相同格式的输出投票聚合时几乎不需要额外的清洗工作。如果要做ToT这个模板可以作为“候选生成器”的基底在某个子状态上把问题替换成当前子问题让模型生成下一步的候选动作再叠加一个候选格式要求比如“输出三个候选方案用编号区分”。6.2 分场景参数推荐表不同任务适合的推理策略和参数组合差别很大。以下是我实践下来的推荐配置可以直接抄作业。任务类型推荐策略采样次数温度最大输出token备注简单事实问答直接生成10.2200不需要推理时计算多步数学应用CoT10.42000防止截断关键逻辑判断CoT-SC5~80.72000答案格式强制统一代码Debug定位CoT-SC4~60.63000要求输出代码块复杂规划/谜题ToT(beam3)每节点2~30.7节点内500评估器用规则打分高价值金融计算CoT-SC后验校验8~100.52500追加规则校验模块这里的温度和采样次数是我反复调整后比较稳的组合。温度太低时多次采样结果高度雷同CoT-SC几乎退化成单次CoT温度太高时错误答案也多样化投票结果容易被随机性主导。0.5到0.7是一个比较安全的区间具体可以按任务微调。6.3 成本核算方法动手之前先花五分钟估算一下推理策略的账单。基本公式是总token消耗 输入token × 调用次数 所有输出的token之和一个常见的误区是只算模型生成部分的token。在实际对话式API调用中历史消息和系统提示每轮都会作为输入重新发送调用次数越多输入部分的累加越是不可忽视。尤其在做ToT时每扩展一个节点都要携带完整的上下文状态输入token可能比输出token多出好几倍。建议在接入推理时计算策略前先在日志里记录每次调用的token拆分跑上一周后再决定是否要调整策略。很多团队上线推理优化后准确率没问题月底一看账单傻眼就是因为没有估算这部分叠加成本。推理时计算是杠杆但用杠杆前得先确认自己能扛住可能被放大的成本。7. 常见问题与排查技巧实录7.1 问题与排查速查表这几个问题是我在推理时计算落地过程中踩过的、也帮别人排查过的典型坑。整理成表方便查。异常现象常见原因排查方向解决方案加了CoT后答案变差任务本身不需要多步推理检查任务复杂度简单任务直接生成即可模型输出推理到一半被截断max_tokens设太小检查返回截断标识把max_tokens上调到估算值的1.5倍CoT-SC投票结果分裂答案格式不统一检查原始输出格式强制结构化标签、归一化后投票采样次数增加但准确率不再涨模型单步能力到顶测试不同能力模型换更强模型或调整问题分解ToT搜索时token爆炸每层候选宽度过大看评估器打分分布调小beam_width、增加剪枝模型步骤自评分数都很高评估器语义区分度低抽查评估器输出加规则校验或换更强评分模型7.2 我踩过的坑与独家建议第一个建议是别把推理时计算当作万能药。有相当一部分任务比如常识问答、简单信息抽取、文案润色本身没有复杂的推理链条硬套CoT和ToT只会增加延迟和费用效果甚至可能变差。我在项目早期曾经为了“统一提升效果”给所有接口都加了CoT结果原本低延迟的轻量场景被无谓拖慢用户体感明显变差。后来按任务复杂度分级才解决了问题。第二个建议是精力优先放在“答案解析层”。推理时计算生成的中间内容经常带着各种前缀、感叹词和无关议论。如果解析层不够健壮后面所有投票、搜索逻辑都会被垃圾输入干扰。我在做CoT-SC时会先用正则把答案标签里的内容抠出来再对字符串做归一化比如去掉空格、统一全半角、把中文数字转阿拉伯数字然后才放入计数器。这些脏活累活看起来不酷但往往比调模型参数更能稳定提升最终效果。第三个建议是在小规模样本上先验证再全量上线。推理策略切换属于高影响变更直接全量上线风险很大。先把新策略应用到一批有标注的测试集上对比准确率和成本设置一个回归门槛比如准确率不低于旧策略两个百分点再逐步放量。这样即使策略有问题影响范围也可控。最后再分享一点我的个人体会在大模型应用落地这一年多里我最大的感受是很多人过度关注“选哪个模型”却低估了“怎么使用模型的推理能力”。同样的模型在懂得用CoT、CoT-SC、ToT这些手段的人手里和不懂的人手里表现完全是两个档次。而且推理时计算是少数几个“只要调参就能立刻见效”的优化方向试错成本低、反馈速度快非常适合作为日常效果优化的首选手段。如果你时间有限我的建议是先只学会一个技巧在关键任务上给模型加CoT并对结果格式做严格约束。这一条就能帮你超过大多数“直接提问”的调用方式。等真正遇到CoT解决不了的复杂推理问题时再逐步升级到CoT-SC和ToT。把这套阶梯用熟你的大模型应用效果会上一个明显的台阶。
阅读完成 · 觉得有帮助？
