# 让模型先思考再作答 关于 reasoning model 和 test-time compute 的速成课。20 个概念——single-pass answer、chain-of-thought、reasoning model、test-time compute、effort dial、overthinking、reasoning tokens、thinking tax、unfaithful reasoning、routing 等——每个都有英文名称、一幅图、一个例子和一张卡片。核心一句话：想得更久，会让模型更擅长难题，却在简单题上白费力气。结尾附所有概念的速查表。 - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~30 分钟阅读 - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/zh/learn/reasoning-models-express --- ## 1. 作答前先思考 整个想法源自一个简单的观察：一步步推演问题的模型，比直接跳到答案的模型做得更好——就像人一样。 ### 地图：七组共 20 个概念 > 一张地铁图：先看整条线路，再一站一站地乘过去。 先是三个**基础**：模型默认怎么作答、chain-of-thought 是什么、为什么那些步骤有帮助。然后是六组，每章一组：**reasoning model**、**test-time compute**、推理**何时**有用、思考的**代价**、为什么推理**不等于真相**，以及如何**用得好**。 后面的每个概念都是同一个形状：它的**英文名称**（记住它——那就是术语）、一幅生活中的画面、一幅**图**，以及一张**卡片**，上面有*是什么*、_思路_、_例子_、*陷阱*和*关联*等字段。 _Diagram: 基础在上，下面是六组——第 2–7 章依次讲它们。_ ### Single-pass Answer — 一口气脱口而出 > 一个学生喊出脑子里冒出的第一个数字，另一个学生先在草稿纸上把题算出来——后者对的概率高得多。 默认情况下，模型**一遍**就生成答案：直接给出回答——说白了就是脱口而出。对简单的问题，这没问题。但凡是需要好几步逻辑的问题，直接跳到答案就是它容易出错的地方，就像一个人匆匆忙忙做难题会犯粗心的错。解决办法就是老师们要求的那条：别只给答案，要**把步骤走一遍**。 _Diagram: 简单的问题，一遍就能落在正确答案上；难的问题，则一下子跳过了它。_ #### Single-pass Answer (直接作答、脱口而出) - **是什么:** 模型立刻生成答案，中间没有任何步骤。 - **适合:** 简单的、一步就能答的问题。 - **陷阱:** 遇到多步问题就会出错，就像一个人匆匆忙忙答难题。 - **关联:** 解决办法是 **chain-of-thought**：先写步骤，再给答案。 ### Chain-of-Thought (CoT) — 出声推理，一步一步来 > 在数学题里把解题过程写出来——按顺序写下每一步——这样推理一目了然，中间的失误会被发现，而不是被埋没。 **Chain-of-thought**（CoT）是这样一种技巧：让模型在给出最终答案*之前*，先一步步生成它的推理，而不是只给出答案。当被要求“好好想一想”时，模型会写出中间步骤——顺着这些步骤推下去，得出正确结论的概率，远高于一步跳到结论。这些步骤不只是摆样子：生成它们，正是让模型能够*一步步搭出*正确答案，而不是靠猜。把思考写在纸面上，思考就变得更好。 _Diagram: 问题 → 步骤 → 步骤 → 步骤 → 答案。链条是可见的，所以中间的失误能被发现。_ #### Chain-of-Thought (CoT、逐步推理) - **思路:** 先写出推理步骤，再给出最终答案。 - **例子:** 在提示里加上“一步一步想清楚”——模型就会展示它的中间步骤。 - **为什么有效:** 模型是一步步搭出答案，而不是猜答案。 - **关联:** 通过 **working memory** 起作用；在 **reasoning model** 里默认内置。 ### Working Memory — 工作就发生在这些步骤里 > 脑子里算一长串计算容易出错；同样的计算写在纸上，一行一行来，就可靠了——纸替你装着脑子会漏掉的东西。 为什么写出步骤会有帮助？每生成一步，就成为模型接下来一步可以依托的**上下文**。它实际上是把自己的输出当作 **working memory**，把一次艰难的跳跃拆成一串小而好办的动作。一个一跳解决不了的大问题，变成一个序列就能解决了。这就是整门课背后的核心洞见：给模型留出推理的空间，而不是要求它立刻给出答案，才能解开难题。 _Diagram: 每一个新步骤都会读到问题和之前的所有步骤——模型的输出变成了它的草稿纸。_ #### Working Memory (把输出当草稿纸) - **是什么:** 已经写下的步骤，是下一步的上下文。 - **思路:** 一次大跳跃 → 一串小动作。 - **例子:** 一长串计算一行一行地做，而不是全都装在“脑子里”。 - **关联:** 解释了 **chain-of-thought** 为什么有效，以及 **test-time compute** 为什么能买到质量。 > **框定问题:** "这是一个模型应该一步步推演的问题——还是一个简单到直接跳到答案也没问题的问题？" > 把步骤走一遍的模型，胜过脱口而出答案的模型。Chain-of-thought——出声推理，一步一步来——把一次艰难的跳跃变成一串好办的动作，准确度也随之而来。 ## 2. Reasoning model 一个起初只是提示技巧的东西，变成了一类模型。Reasoning model 经过训练，会在作答前先思考——逐步推演的过程默认内置。 ### Reasoning Model — 受过训练、作答前先思考的模型 > 反射式作答的人，和受过训练、会先停下来推理的人之间的差别——思考的习惯已经长进了他们的工作方式里，而不是需要你去要求的东西。 **Reasoning model** 是专门训练过的模型：在最终答案之前先生成一段内部的思维链——*默认*就先“思考”，而不是只有被提示时才这样做。标准模型是脱口而出；chain-of-thought 提示是哄它去推理；而 reasoning model 把这个过程内置了。它先产生一段内部推理，再给出答案，在真正需要推演的问题上明显更强。 _Diagram: 标准模型脱口而出，CoT 提示要求写步骤，reasoning model 自己思考，每一次都是。_ #### Reasoning Model (会思考的模型) - **是什么:** 经过训练、作答前默认先一步步思考的模型。 - **区别:** CoT 要在提示里去要求；这里思考是内置的。 - **强项:** 在真正需要推演的问题上明显更强。 - **关联:** 内置的 **chain-of-thought**；是 **test-time compute** 的一种形式。 ### Speed–Depth Trade-off — 用速度换深度 > 一位谨慎的专家花一分钟想一想再回答，给出的答案比立刻回答的快手更好——但你得等。 Reasoning model 每个答案要花更多力气和时间，因为在回答之前要生成所有那些内部步骤。这让它比标准模型**更慢也更贵**，换来的是在难题上更强。这是一个真正的**取舍**，不是白送的升级：你要为思考的深度付出代价——延迟和 token。所以 reasoning model 并不是简单的“更好”，它是另一种工具。 _Diagram: 难题上的准确度上升了——每个答案的延迟和 token 也一起上升。_ #### Speed–Depth Trade-off (用速度换深度) - **你得到:** 难题上更好的答案。 - **你付出:** 每个答案的延迟和 token。 - **陷阱:** 把 reasoning model 当成“就是更好”——它是一笔交换，不是升级。 - **关联:** 两种价格的详情——第 5 章的 **reasoning tokens** 和 **latency**。 ### Tool, not Default — 难题的工具，而不是默认选项 > 你请深度思考的专家来处理真正棘手的案子，而不是去回答前台的日常问题——用错了地方，就浪费了他们的才能。 当任务真正需要谨慎的多步思考时，reasoning model 是合适的工具；对简单快速的活儿则是错的，它的反复斟酌纯属浪费。用它来给一条消息分类或重新排版，就像**雇一位哲学家来接电话**：更慢更贵，却没有任何好处，因为这个任务从来不需要思考。它是处理工作中那一块难题的有力工具，而不是在其他一切事情上取代快速模型。 _Diagram: 难的活儿交给 reasoning model，日常的交给快速模型。日常的活儿放到 reasoning model 上是大材小用。_ #### Tool, not Default (专家，而非默认) - **思路:** Reasoning model 用于难的那一块，不是用于所有事情。 - **例子:** 多步规划——要用；给消息分类或重新排版——不用。 - **陷阱:** “哲学家接电话”：更慢更贵，却没有任何好处。 - **关联:** 在实践中这就是 **difficulty matching** 和 **routing**。 > **模型问题:** "这个任务真的需要一个先思考的模型吗——还是我在为一个快速的标准模型本可以瞬间搞定的活儿，付 reasoning model 的时间和成本？" > Reasoning model 经过训练，作答前先一步步思考——在难题上更强，作为交换更慢更贵。它是处理难题的工具，而不是一切的默认选项。 ## 3. Test-time compute 在 reasoning model 之下，是一个更深的想法，正在改变 AI 进步的方式：让模型变好，不只靠多训练，还可以让它在作答的那一刻更卖力地工作。 ### Test-time Compute — 在作答时多花力气 > 考试时间更多，你会检查答案、换个思路再试、抓出错误——同一个人，仅仅因为被允许多花些时间，就考得更高。 **Test-time compute** 指的是在作答的那一刻——也就是模型运行的**推理**阶段——多花一些计算，以换取更好的结果。模型不再是快速的一遍，而是想得更久，生成更多推理，也许尝试几种思路再挑出最好的。reasoning model 背后那个惊人的发现是：让模型在*作答时*多做点工作，质量就会提升，就像在难题上多给一个人一些时间。你可以靠更多的思考买到更好的答案，而不仅仅是更多的训练。 _Diagram: 一遍、想得更久，或者试几次再挑最好的——这些全都是 test-time compute。_ #### Test-time Compute (inference-time compute、推理时计算) - **是什么:** 模型作答那一刻更多的计算。 - **怎么做:** 想得更久，生成更多推理，尝试几种思路并保留最好的。 - **例子:** 同一个人考试时多给一小时——他会检查并抓出错误。 - **关联:** 由 **effort dial** 控制；是与 **train-time compute** 并列的第二条轴。 ### Effort Dial — 决定想多用力的旋钮 > 一个调节努力程度的恒温器：难题调高，简单题调低，思考的量正好配得上任务的价值。 Test-time compute 是一个**旋钮**，不是开关：你可以只花一点思考，也可以花很多，一般来说越多，难题上的结果越好——直到**收益递减**的那个点。在 API 里，这个旋钮通常叫 **reasoning effort** 或 **thinking budget**。它的威力在于，你可以按每个请求的难度来调节力度：真正的难题调高，日常的保持低位。 _Diagram: 在难任务上，准确度随思考预算上升，然后趋于平缓；在简单任务上，它根本不上升。_ #### Effort Dial (reasoning effort、thinking budget) - **是什么:** 一个设置，决定模型在这个请求上思考多少——少一点或多一点。 - **怎么运作:** 思考越多 → 难题上越好，但收益递减。 - **例子:** 日常的活儿用低力度，真正的难题用高力度。 - **关联:** **difficulty matching** 的杠杆；每拧一格都要花 **reasoning tokens**。 ### Train-time vs Test-time Compute — 提升的两条轴 > 一个学生在考前更用功地学习，同一个学生在考试中被多给了时间——这是取得更好结果的两种不同方式。 从历史上看，模型的进步主要靠**训练**——更多的数据、更大的模型，一次性在前期完成。Test-time compute 是**另一条轴**：在**推理时**更卖力地工作来改进答案，模型每次运行都是如此。这是获得更多能力的第二种方式——不只是更聪明的模型，而是同一个模型想得更久。了解这两条轴，有助于你弄清楚模型的质量——以及它的**成本**——到底来自哪里。 _Diagram: 训练是一次性、前期付费；作答时的思考，每个请求都要付费。_ #### Train-time vs Test-time Compute (两条轴) - **Train-time:** 更多数据、更大的模型——一次性，在前期。 - **Test-time:** 想得更久——模型每次作答都要付。 - **为什么重要:** 显示质量从哪里来——以及你是付一次，还是每个请求都付。 - **关联:** test-time 这条轴的价格是 **reasoning tokens** 和 **latency**。 > **算力问题:** "这个难任务，会不会因为让模型在作答时想得更久而受益——考虑到成本，到底值得想多少？" > Test-time compute 指的是在模型作答时多花力气，而不只是在训练时——更多的思考，在难题上得到更好的答案。它是一个旋钮：难的时候拧大，日常的时候拧小。 ## 4. 推理在何时有用 推理恰恰在问题难的地方威力巨大，在问题简单的地方毫无意义。分清哪个是哪个，就是用好它的大半。 ### Multi-step Problems — 思考在哪里能回本 > 一条转弯很多的复杂路线值得仔细规划；通往隔壁房子的直路则不用——路越难走，思考越值。 推理在**多步问题**上帮助最大，这类问题真正需要好几步逻辑：数学和计算、多步规划、复杂代码、逻辑谜题，以及错一步就毁掉答案的细致分析。这些恰恰是脱口而出会失败、而逐步推演会成功的任务。问题越难、步骤越多，额外的思考对结果的改善就越大——这就是为什么 reasoning model 在满是真正难题的基准测试上表现出色。 _Diagram: 数学、规划、复杂代码、谜题、分析——步骤之间相互依赖的任务。_ #### Multi-step Problems (困难的多步任务) - **是什么:** 答案由好几个相互依赖的逻辑步骤搭建出来的任务。 - **例子:** 数学、规划、复杂代码、谜题、分析。 - **为什么:** 错一步就毁掉答案——逐步推演能抓住它。 - **关联:** **reasoning model** 和高 **effort dial** 的主要目标。 ### Overthinking — 简单任务一无所获 > 午饭吃什么，两个选项你都满意，却斟酌良久——所有这番思考得出的是同一个答案，只是更慢。 对于简单直接的任务——给这个分类，提取那个，重新排版这段文字，回答一个基本的事实问题——推理除了延迟和成本，什么也没增加。这里没有多步逻辑可以推演，所以思考是白费力气；一遍就能看出答案。更糟的是，让模型对一个琐碎任务“思考”，偶尔反而会让它*更差*——它**想多了**，把本来不需要斟酌的事情搞复杂了。 _Diagram: 一个简单任务：快速模型立刻又便宜地回答；reasoning model 给出同样的答案，却更慢更贵。_ #### Overthinking (不必要的斟酌) - **是什么:** 在一个没有什么可推理的任务上推理。 - **例子:** 分类、提取、重新排版、一个简单的事实。 - **代价:** 白白付出延迟和金钱；有时答案甚至更差。 - **关联:** 在整个请求流上重复，就成了 **thinking tax**。 ### Difficulty Matching — 让思考的深度匹配难度 > 好员工在难的决定上花很长时间，简单的立刻回答——按每件事真正的需要来校准力度。 起支配作用的原则是 **difficulty matching**：让模型思考的力度与问题的难度相称。真正困难、高风险、多步骤的工作，配得上 reasoning model 或更多的 test-time compute；简单、日常、范围明确的工作，交给快速的标准模型。这呼应了模型经济学里的 routing 思想：大多数请求很简单，要的是速度；少数很难，要的是思考。把一切都送给 reasoning model，和把一切都送给前沿模型一样浪费——要校准，别默认。 _Diagram: 从易到难的一把标尺：快速模型、一点思考、reasoning model。_ #### Difficulty Matching (校准，别默认) - **思路:** 任务越难，思考越多；简单的任务一点也不需要。 - **例子:** 大多数请求交给快速模型；难的那一块交给 reasoning model 或高力度。 - **陷阱:** 所有事情都用同一档思考——要么慢，要么不准。 - **关联:** 杠杆是 **effort dial**；放在系统里就是 **routing**；与模型经济学是同一个思想。 > **匹配问题:** "这个问题真的有困难的多步逻辑，需要思考来理清吗——还是简单到推理只会增加延迟和成本？" > 推理在困难的多步问题上帮助最大，在简单问题上毫无帮助。让思考的深度与难度相称——难的那一块用 reasoning model，简单的大多数用快速模型。 ## 5. 思考的代价 思考不是免费的。更多的推理意味着更多的时间和更多的 token，而无视这笔成本，正是团队最后花一大笔钱、慢吞吞地回答简单问题的原因。 ### Reasoning Tokens — 思考越多，token 和钱越多 > 一个在有人斟酌的整个过程中一直跑着的计价表——想得越久，账单越大，不管多出来的那些思考有没有必要。 所有那些推理步骤都是生成出来的 token——**reasoning tokens**——你要为它们付费。Reasoning model，或者高档的 test-time compute 设置，会在答案之前产生大量内部思考，其中每个 token 都要花钱。所以推理的每个答案，比一次直接作答明显贵得多。让它在难题上更强的深度，恰恰也是让它更贵的原因。这就是为什么“所有事都用 reasoning model”会毁掉 AI 预算。 _Diagram: 直接作答：输入和答案。有了推理，两者之间夹着一长段思考——全都算在账单上。_ #### Reasoning Tokens (thinking tokens、思考 token) - **是什么:** 模型在作答前生成的内部推理 token。 - **代价:** 和任何输出一样计费——而且数量可能比答案多得多。 - **例子:** 直接作答是一张小账单；同一个答案经过长时间思考，就是一张大账单。 - **关联:** 随 **effort dial** 增长；在整个请求流上累积成 **thinking tax**。 ### Latency — 它更慢，用户能感觉到 > 那位花一分钟才回答的谨慎专家，在难题上值得等，但如果你只是问现在几点，就让人抓狂。 生成所有那些步骤需要时间，所以 reasoning model 和重度的 test-time compute 给出答案**更慢**——有时慢得多。这就是 **latency**。对后台任务没关系；对盯着屏幕等待的用户，长时间的延迟是对体验的真实代价。对于用户预期要花点时间的难题，多出来的几秒是值得的，而对于本该感觉瞬间完成的交互，就不合适了。速度是你拧大思考时所花掉的东西。 _Diagram: 有了推理，答案来得晚得多：在后台没问题，对在线用户则很难受。_ #### Latency (响应时间) - **是什么:** 模型在作答前花在思考上的时间。 - **适合:** 后台任务；预期会有停顿的难题。 - **伤害:** 本该感觉瞬间完成的界面。 - **关联:** **speed–depth trade-off** 的第二种价格，与 **reasoning tokens** 并列。 ### Thinking Tax — 别为任务不需要的思考买单 > 雇一位又慢又贵的深度思考者整天回答简单问题——你付着高价，还要等得更久，而这些答案一个手脚麻利的职员瞬间就能给出。 要避免的浪费，是把推理的成本和延迟花在得不到好处的任务上。把每个请求——简单的和困难的一视同仁——都送进 reasoning model，意味着在整个请求流上缴 **thinking tax**，而实际上只有一小块需要它。模型经济学里的同一条纪律在这里适用：默认走更便宜、更快、不带推理的路径，只有真正困难、对得起它成本的情况，才升级到推理。在思考能回报你的地方付钱，多一个 token 都不付。 _Diagram: 整个请求流都走 reasoning model，尽管只有寥寥几个难请求需要思考。_ #### Thinking Tax (处处推理) - **是什么:** 整个请求流都用 reasoning model，而不只是难的那一块。 - **代价:** 每个简单请求你都要付 token 和延迟。 - **解法:** 默认走快速路径，需要时才升级到推理。 - **关联:** **overthinking** 在整个请求流上的总和；用 **routing** 来治。 > **成本问题:** "在这里，推理带来的额外准确度值得它的成本和延迟吗——还是我在为那些直接回答同样好、还便宜得多的任务缴 thinking tax？" > 思考要花 token 和时间——推理每个答案更贵更慢。只在难题对得起它的地方付这笔钱；把一切都送进 reasoning model，等于对整个请求流征税，而好处只有一小块需要。 ## 6. 推理不等于真相 人很容易相信一条又长又看似严谨的推理链。但步骤多并不保证答案对——reasoning model 也可能信心十足、洋洋洒洒地出错。 ### Confidently Wrong — 再长的链条也可能得出错误的答案 > 一个建立在有缺陷前提上的详尽而自信的论证——每一步都衔接得整整齐齐，结论依然是错的。光鲜不是证明。 推理提高的是难题上答对的*概率*；它不保证答对。模型可以产生一条冗长、流畅、看起来合理的思维链，却导向错误的结论——**链条早期的一个错误**被自信地带到了最后，或者推理听起来严谨，其实并不严谨。看得见的步骤让答案*感觉*更可信，而这恰恰是陷阱：推理越多，看起来越权威，却不一定越正确。 _Diagram: 早期的一个失误——之后的每一步都整整齐齐地把错误带到一个自信的错误答案。_ #### Confidently Wrong (光鲜却错误) - **是什么:** 一条流畅的长推理链，结论却是错的。 - **怎么发生:** 早期的错误被带到最后；推理只是听起来严谨。 - **陷阱:** 看得见的步骤制造出一种可信的感觉。 - **关联:** 靠 **verify the answer** 来治，而不是靠读那条链。 ### Unfaithful Reasoning — 展示出来的推理，可能并不是真正的原因 > 有人凭直觉做了决定，事后再编一套听起来合乎逻辑的理由——解释听上去很真，却不是他们真正得出结论的方式。 还有一个更微妙的陷阱：模型展示出来的思维链，并不保证就是真正产生它答案的过程。它可以生成*看起来*像通向结论之路的推理，而真正的依据其实是别的东西——一种**听起来合理的事后编造**，而不是忠实的叙述。这叫做 **unfaithful reasoning**，而一条诚实的链所具备的性质叫做 **faithfulness**。所以你不能完全相信展示出来的推理，把它当作答案*为什么*是这样的解释。它是有用的信号，也有助于提高准确度，但并不是一扇能保证看到模型真实逻辑的窗口。 _Diagram: 上面是模型展示的内容；下面是真正驱动答案的东西。两者之间可能有差距。_ #### Unfaithful Reasoning (CoT faithfulness、事后合理化) - **是什么:** 展示出来的步骤，并不是真正产生答案的过程。 - **例子:** “凭直觉”做的决定，加上事后编的逻辑解释。 - **陷阱:** 把这条链当作答案_为什么_是这样的精确解释来读。 - **关联:** 又一个理由去 **verify the answer**，而不是信任思考本身。 ### Verify the Answer — 检查结果，别欣赏思考 > 你检查一个复杂的计算，是独立地确认结果，而不是欣赏演算过程有多整齐——重要的是答案是否正确。 实际的结论是：评判 reasoning model 的输出，看**答案**是否正确、是否经过现实的核验，而不是看推理看起来多么令人印象深刻。别处讲过的所有纪律依然适用——让它**扎根**于真实事实，对照来源检查，跑 **evals**，在高风险的决定上留一个**人**。推理让难题的答案更有可能是对的；但并不意味着不经核验就可以放心相信。一条自信的思维链，在你检查它落在哪儿之前，依然只是一个自信的猜测。 _Diagram: 给答案打分，而不是给推理链的光鲜程度打分——靠 grounding、来源、evals 和一个人。_ #### Verify the Answer (检查结论，而非推理链) - **思路:** 拿答案去对照现实来评判，而不是看推理的光鲜程度。 - **怎么做:** 扎根于事实、核对来源、evals、重要的事情有人把关。 - **例子:** 独立确认计算的结果，而不是重读那段整齐的演算。 - **关联:** 防范 **confidently wrong** 和 **unfaithful reasoning**。 > **信任问题:** "我信任这个答案，是因为推理看起来很周全——还是我真的核验了结论，并且知道一条长链依然可能信心十足地出错？" > 更多的推理提高的是概率，而不是保证——一条长链可能得出错误的答案，展示出来的步骤也可能不是真正的原因。要核验答案；别信任思考本身。 ## 7. 用得恰到好处 推理是一种强大的能力，价格也很明确，所以用好它就是那套如今已经熟悉的纪律：把思考花在能回报的地方，并核验它的产出。 ### Routing & Escalation — 只在难的那一部分把思考拧大 > 你对那一个棘手的步骤全神贯注，其余的一带而过——把力气集中在难点真正所在之处，而不是平均摊开。 统一的做法，是在整个系统里让思考与难度相称。这就是 **routing**：在真正困难、多步骤、高风险的任务上用 reasoning model 或更多 test-time compute，对简单的大多数用快速的标准模型。你甚至可以混用——快速模型处理日常路径，并把困难的子问题**升级**给 reasoning model。把斟酌花在问题难的地方，也只花在那里，你就能获得准确度的提升，而不必在所有事情上缴 thinking tax。 _Diagram: 快速模型自己回答简单的部分，把难的部分交给 reasoning model。_ #### Routing & Escalation (model routing、移交) - **问题:** 所有事都用一个模型——要么又贵又慢，要么不准。 - **思路:** 默认用快速模型；困难的子问题交给 reasoning model。 - **例子:** 快速模型负责对话，把一个棘手的多步计算移交给 reasoning model。 - **关联:** **difficulty matching** 在系统层面的形式；**thinking tax** 的解药。 ### Ingredient, not Finished Dish — 推理不能取代核验 > 一位谨慎的专家更可能是对的，但高风险的决定你仍然要确认——他们的谨慎提高了概率，却不能免去检查的必要。 最后一条纪律把这门课和其余的内容连了起来：推理能提升难题上的质量，但它依然是一个会出错的模型，可能信心十足地出错，所以其他一切依然重要。让它扎根于事实，核验答案，跑 evals，在有后果的决定上留人。推理是获得更好输出的又一种方式——与好的**上下文**、**检索**和合适的模型并列——而不是一个神奇的升级，能让你免于围绕它去搭建可靠性。更好的思考是一种更强的**食材**，而不是一道做好的菜。 _Diagram: 推理是一份好输出的一种食材；围绕它的可靠性工程依然是必需的。_ #### Ingredient, not Finished Dish (推理 ≠ 可靠性) - **思路:** 推理能改善输出，但本身不能让它可靠。 - **并列:** 好的上下文、检索、合适的模型。 - **仍然需要:** 扎根于事实、核验、evals、重要决定有人把关。 - **关联:** 把 **verify the answer** 与其余所有工程联系在一起。 ### 一切如何连在一起 > 一根杠杆，三个后果：它带来收益，它花钱，它还带着风险——用它时，三样都要放在心里。 **Chain-of-thought** 内置于 **reasoning model**，而 reasoning model 是 **test-time compute** 的一种形式。这根杠杆有三个后果：多步问题上的**收益**，token 和延迟上的**代价**，以及信心十足地出错或不忠实的推理这一**风险**。用好它，意味着瞄准收益（**difficulty matching**、**routing**），守住预算（没有 **thinking tax**），并检查结果（**verify the answer**）。 _Diagram: CoT → reasoning model → test-time compute；收益、代价和风险都汇聚在“用得恰到好处”。_ #### 在你伸手去用推理之前 - **问题是否真的困难**——多步逻辑、数学、规划——需要思考来理清？ - **还是它很简单**——推理只会白白增加延迟和成本？ - **成本和延迟在这里值得吗**，还是你在用思考给简单任务征税？ - **你在做 routing 吗**——难的那一块用推理，简单的大多数用快速模型？ - **你在核验答案吗**，而不是相信一条看起来周全的思维链？ - **惯常的那些纪律还适用吗**——grounding、evals、高风险决定有人把关？ #### 你用好了推理的迹象 - 你**只在真正困难的问题上把思考拧大**，而不是默认如此。 - 你**简单的大多数用快速模型**，把推理留给难的那一块。 - 你把推理的**成本和延迟**算进去，而不是给每个请求征税。 - 你**核验答案**，而不是相信推理看起来有多周全。 - 你依然使用 **grounding、evals 和人工监督**——推理让它们更锋利，而不是取代它们。 ## 速查表：整门课的所有概念 ### 先思考 - **Single-pass Answer** (直接作答): 模型一遍就脱口而出答案——简单的行，难的不行。 - **Chain-of-Thought** (CoT): 先写推理步骤，再给答案。 - **Working Memory** (把输出当草稿纸): 每一步都成为下一步的上下文。 ### Reasoning model - **Reasoning Model** (会思考的模型): 经过训练，作答前默认先一步步思考。 - **Speed–Depth Trade-off** (用速度换深度): 难题上更好，但更慢更贵。 - **Tool, not Default** (专家，而非默认): 用于难的那一块，不是用于所有事情。 ### Test-time compute - **Test-time Compute** (inference-time compute): 作答时多做功——得到更好的答案。 - **Effort Dial** (reasoning effort、thinking budget): “想多少”的旋钮——收益递减。 - **Train-time vs Test-time** (两条轴): 训练付一次，思考每个请求都要付。 ### 何时有用 - **Multi-step Problems** (困难任务): 数学、规划、代码、逻辑——思考回本的地方。 - **Overthinking** (不必要的斟酌): 在简单任务上——同样的答案，更慢更贵，有时还更差。 - **Difficulty Matching** (校准，别默认): 让思考的深度匹配任务的难度。 ### 思考的代价 - **Reasoning Tokens** (thinking tokens): 所有的思考都是生成出来的——也是计费的——token。 - **Latency** (响应时间): 想得更久，就答得更晚；对在线用户很难受。 - **Thinking Tax** (处处推理): 整个请求流都推理，而只有一小块需要。 ### 推理不等于真相 - **Confidently Wrong** (光鲜却错误): 一条流畅的长链，依然可能得出错误的答案。 - **Unfaithful Reasoning** (CoT faithfulness): 展示出来的步骤，可能不是答案的真正原因。 - **Verify the Answer** (检查结论): 拿答案去对照现实来评判，而不是看推理链的光鲜程度。 ### 用得恰到好处 - **Routing & Escalation** (model routing): 默认用快速模型，难的部分交给 reasoning model。 - **Ingredient, not Finished Dish** (推理 ≠ 可靠性): 推理是一种食材；核验和 evals 依然需要。 > 推理让模型在作答前先思考，以时间和 token 为代价，提高难题上的准确度。只在难度对得起它的地方把思考拧大，并核验答案——再好的思考，在核验之前，依然是一个会出错的猜测。 速成课结束 · 7 章 · 20 个概念 接下来是练习：拿一个你的模型一遍就答错的真正难题，让它去推理——提示它一步步思考，或用一个 reasoning model——看着准确度提升。然后在一个简单任务上试同样的做法，留意那番思考除了拖延一无所买。最后，找一个推理看起来滴水不漏、答案却是错的例子，去体会为什么你核验的是结论，而不是推理链。当你让思考的深度配上问题的难度时，这套纪律就豁然贯通了。但有一个想法要置于其余之上：让模型在作答前先思考，会让它更擅长难题，却在简单题上白费力气——所以在它能回报的地方把思考拧大，在它不能回报的地方拧小，并且永远去核对它落到了哪儿。