让模型一步步思考

问模型一道多步算术题，只许给答案。它经常答错。问同一个问题，让它把步骤一步步写出来，它经常答对。

这看起来像把戏。不是。这是生成方式的直接结果。

机制

每个 token 在网络里恰好走一次前向传播。一次前向传播的计算量是固定的——相当可观，但对每个 token 来说有限且恒定。

所以一道需要五步推理的题，如果一个 token 就答完，五步只拿到一次前向传播的计算量。中间过程没有任何地方可以存放。

现在让模型把步骤写出来。每一步都是 token。每个 token 都有自己的前向传播。关键在于，每一步都会成为后续步骤的输入——生成的文本变成了工作记忆。

**思维链（chain-of-thought）把一个单次前向传播的问题，变成需要多次前向传播的问题。**推理不是表演；token 本身就是计算。

什么会触发它

明确指令。「回答之前，一步步推导。」简单有效。

**结构化 prompt。**要求一种具体的拆解方式：先找出已知条件，再说明要求什么，然后求解。

示范。少样本示例里带上推导过程，而不只是答案。这是最可控的一种，因为你能指定想要的推理形状。

**推理模型。**较新的模型训练成在回答之前先生成长篇推理，不需要你要求。机制是一样的——更多 token、更多次前向传播——只是从 prompt 挪到了训练里。

哪里有用

真正有先后依赖的任务：

• 算术和单位换算——每一步运算都要有地方写下来
• 多约束问题——排期、逻辑谜题，任何约束之间会互相影响的事
• 调试——先追踪执行过程，再定位问题
• 对比分析——先逐个评判选项，再排序
• 长因果链——一步步走，比一步跳过去可靠得多

哪里没用

简单查找。「法国的首都是哪里？」想半天没有任何收益，还要多花 token。

**纯粹的格式转换。**重新排版没有什么推理可以拆解。

**缺失的知识。**推理找不回模型本来就没有的信息。它会产出一份详尽、结构漂亮的错误答案——可以说比一句简短的错答案更糟，因为那个结构很有说服力。

**超出能力的真难题。**步骤再多也造不出模型没有的能力。

一个不太舒服的提醒

写出来的推理不一定反映真正决定了答案的东西。

研究展示过这样的例子：模型先得出结论，再生成一套为它辩护的推理；也有例子里，改一个线索会改变答案，而它写出来的推理完全没提到这个线索。看得见的这条链，可能是一段看似合理的叙述，而不是忠实的过程记录。

两件事同时成立：多出来的 token 确实提升了准确率，而它写出的推理并不是可靠的审计记录。把它当作有用的草稿纸，而不是可以信任的解释。

这在实操上很要紧。如果你要核实一个答案为什么是这么得出的，检查它写出的推理，作为证据比看上去要弱。

实操要点

**推理必须写在答案之前，永远如此。**答案之后生成的 token 影响不了答案——答案已经定下来了。事后追加的解释，从机制上说就是合理化。

**要求最终答案有清晰的边界。**否则用程序抽取会很脆弱。「以 ANSWER: <value> 结尾」就够了。

它花的是输出 token，而输出 token 是贵的那种。推理让输出长度翻三倍，账单里这一块也就翻三倍。准确率要紧时值得，简单任务上就是浪费。

**准确率优先时，用自洽性。**在非零 temperature 下生成若干条独立的推理路径，取多数答案。能稳定提升准确率，代价是好几倍的花费。

要点回顾

• 每个 token 只走一次前向传播，所以写出来的步骤是真的多做了计算，不是表演。
• 由指令、结构、带推导过程的示例或训练触发。
• 对顺序推理有用；对查找、格式转换和缺失的知识没用。
• 写出来的推理不一定忠实反映是什么推动了答案——它提升准确率，但不是审计记录。
• 推理必须在答案之前；写在之后影响不了任何东西。

下一篇： 从 LLM 里取出 JSON