推理模型:思维链与慢思考范式

中等 🟡AI 学习
12 个标签
预计阅读时间:32 分钟
推理模型思维链Chain-of-Thoughto1DeepSeek-R1测试时计算Self-ConsistencyTree-of-ThoughtsBest-of-N强化学习模型蒸馏reasoning tokens

推理模型:思维链与慢思考范式

大语言模型早期给人的印象是"脱口而出"——问一句答一句,几乎不加思索。但面对数学证明、多步逻辑推理、复杂代码调试这类任务时,这种"张口就来"的方式经常出错。近年来,从思维链提示到 OpenAI o1、DeepSeek-R1 等专门的"推理模型",业界逐渐摸索出一套让模型"先想清楚再回答"的方法论。本文从思维链的基本原理讲起,梳理推理模型的发展脉络,介绍测试时计算这一全新的能力提升维度,并配上大量可运行的代码示例,帮助你把这些理念真正落到工程实践里。

🧩 什么是思维链

思维链(Chain-of-Thought,简称 CoT)最早是作为一种提示技巧被提出的:与其直接要求模型输出最终答案,不如引导它先写出一步步的中间推理过程,最后再给出结论。

一个直观的例子是应用题:

textCode
问题:一个书架有 3 层,每层放 12 本书,又搬走了 5 本,还剩多少本?

【普通提示】直接问:请给出答案。
模型输出:31 本

【思维链提示】请一步步思考后再给出最终答案。
模型输出:
1. 书架总共有 3 层,每层 12 本,所以总数是 3 × 12 = 36 本。
2. 搬走了 5 本,所以剩下 36 - 5 = 31 本。
最终答案:31 本

这个例子里两种方式凑巧得到了同一个答案,但在稍微复杂一些的多步计算、条件判断或逻辑推理题中,"直接给答案"的方式极易在某个环节漏算或想岔,而"一步步思考"的方式会把每一步摊开,模型和人一样,摊开步骤后出错率会显著下降。

🔬 为什么显式写出中间步骤会提升准确率

可以从几个角度理解:

1.计算量的重新分配:Transformer 在生成每一个 token 时能做的"计算"是有限的(大致对应固定的前向传播层数)。如果要求模型在一个 token 内直接吐出最终答案,相当于压缩了大量隐含推理到极短的计算路径里;而写出中间步骤,相当于把推理过程展开到了多个 token 上,每一步都能复用前面已经写下的文字作为"外部工作记忆",用输出序列的长度换取有效计算深度。
2.错误的可追溯与自我修正:中间步骤写在文本里之后,后续生成会以这些文字为条件,如果某一步出现了明显不一致,模型在后续 token 上有更大机会"发现"矛盾并调整,而不像一次性输出答案那样无法回头看。
3.任务分解降低单步难度:复杂问题被拆成若干个更简单的子问题,每个子问题对模型来说都更容易独立解决,这本质上是把"一步登天"变成"拾级而上"。

思维链最初只是一种提示词技巧(在提示里加一句"请一步步思考",英文常见的说法是 Let's think step by step),后来的研究发现,只要模型规模足够大,这种简单的提示改动就能在数学、常识推理等基准测试上带来大幅提升,几乎是"零成本"的能力释放。这也是它被称为"涌现能力"的原因之一——在小模型上效果不明显,但在足够大的模型上会突然变得显著。

🐢 快思考与慢思考:系统 1 与系统 2

心理学家丹尼尔·卡尼曼在《思考,快与慢》中提出,人类大脑存在两套思维系统:

系统 1(快思考):直觉式、自动化、几乎不耗费精力,比如看到"2+2="脱口而出"4"。
系统 2(慢思考):需要主动投入注意力,进行有意识的分析、推演和校验,比如心算"37 × 24"或者证明一道几何题。

这个类比很适合用来理解普通对话模型和推理模型的差别:

普通对话模型更接近系统 1。它们经过预训练和指令微调后,倾向于用一次前向传播直接生成看起来"通顺、自信"的答案,回复速度快、成本低,适合闲聊、简单问答、文本改写等大多数日常场景。但一旦遇到需要多步演绎的难题,"脱口而出"就容易出现似是而非的错误——答案读起来很有道理,实际上逻辑链条是断的。
推理模型则更接近系统 2。它们在给出最终回复之前,会先生成一段(有时相当长的)内部推理文本,反复审视问题的条件、尝试不同解法、检查中间结果是否自洽,出现矛盾时会主动回退重新推导,最后才"收敛"到一个答案。这个过程更像人在草稿纸上演算,而不是张口就来。

需要说明的是,"慢"不只是一个比喻——推理模型确实会消耗更多的响应时间和计算资源来生成这些中间推理内容,某些较难的问题甚至可能思考几十秒到几分钟。这是一种主动的取舍:用响应延迟和算力成本,换取答案正确率和任务完成质量的提升。对时间不敏感、正确性要求高的场景(数学竞赛题、复杂代码重构、多步骤规划)非常划算;而对需要即时反馈的场景(客服聊天、简单查询)则未必是最优选择,这也是为什么现在很多产品会让用户在"快速模式"和"深度思考模式"之间自行切换。

下面这张表把两种模式的关键差异并排放在一起(数字为示意值,用于建立直觉,非精确基准):

| 维度 | 快思考(普通模型) | 慢思考(推理模型) |

| --- | --- | --- |

| 响应延迟 | 0.5 到 2 秒 | 5 秒到数分钟 |

| 输出 token 结构 | 直接给答案 | 先生成推理 token 再给答案 |

| 单次调用成本 | 低 | 高(推理 token 也计费) |

| 简单问答准确率 | 高,且更划算 | 高,但性价比低 |

| 多步难题准确率 | 一般,易断链 | 明显更高 |

| 适用场景 | 闲聊、改写、检索问答 | 数学、代码、规划、证明 |

✍️ 提示工程实战:CoT 家族

在没有专门推理模型可用、或希望在普通模型上榨出更强推理能力时,思维链提示仍然是最便宜的工具。下面给出两种最常用的写法。

Zero-shot CoT:不提供示范,只加一句触发语。

pythonCode
from openai import OpenAI

client = OpenAI()

question = "一个班有 30 名学生,男生比女生多 6 人,男生有多少人?"

# 关键在于结尾的触发句,把模型从"直接作答"推向"逐步推理"
prompt = f"{question}\n请一步步思考,最后用『答案:』开头给出结论。"

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}],
    temperature=0,
)
print(resp.choices[0].message.content)

Few-shot CoT:给出几个"问题 + 完整推理 + 答案"的范例,让模型模仿这种推理格式。范例质量比数量更重要,通常 2 到 4 个即可。

pythonCode
few_shot = """问题:停车场有 15 辆车,开走了 6 辆又来了 4 辆,现在有几辆?
推理:先算开走后剩下 15 - 6 = 9 辆,再加上新来的 4 辆,得到 9 + 4 = 13 辆。
答案:13

问题:一盒鸡蛋有 12 个,打碎了 3 个,又买了 2 盒,一共有几个完好的鸡蛋?
推理:原来完好 12 - 3 = 9 个,买 2 盒即 2 × 12 = 24 个,合计 9 + 24 = 33 个。
答案:33
"""

new_question = "问题:图书馆有 200 本书,借出 45 本,归还 12 本,现在有几本?"

prompt = few_shot + new_question + "\n推理:"

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}],
    temperature=0,
)
print(resp.choices[0].message.content)

经验上,Zero-shot CoT 部署最省事,Few-shot CoT 在格式敏感或专业领域(如特定单位换算、行业规则)上更稳定,但会占用更多输入 token。

🗳️ Self-Consistency:多次采样再投票

单条思维链有随机性,一次想岔就一路错到底。Self-Consistency 的思路很简单:对同一问题用较高温度采样多条独立的推理路径,抽取每条路径的最终答案,再做多数投票。它假设"正确答案往往被多条不同推理路径共同指向,而错误答案则五花八门"。

pythonCode
from collections import Counter
import re

def extract_answer(text: str) -> str:
    # 约定模型用「答案:xxx」收尾,这里抓取最后一个答案标记
    matches = re.findall(r"答案[::]\s*(.+)", text)
    return matches[-1].strip() if matches else text.strip().splitlines()[-1]

def self_consistency(question: str, n: int = 5, temperature: float = 0.8) -> str:
    prompt = f"{question}\n请一步步思考,最后用『答案:』开头给出结论。"
    answers = []
    for _ in range(n):
        resp = client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{"role": "user", "content": prompt}],
            temperature=temperature,  # 必须 > 0 才能采样出不同路径
        )
        answers.append(extract_answer(resp.choices[0].message.content))
    # 多数投票,返回出现次数最多的答案
    winner, count = Counter(answers).most_common(1)[0]
    print(f"各路径答案分布:{Counter(answers)},投票胜出:{winner}({count}/{n})")
    return winner

print(self_consistency("37 × 24 等于多少?", n=5))

Self-Consistency 几乎不需要额外训练,只靠多花几倍推理成本就能明显拉高准确率,是最容易落地的测试时计算手段之一。代价是:n 越大成本线性上升,且对开放式生成(如写作)不适用——它只对"有唯一可判定答案"的任务有效。

🏆 Best-of-N:采样加打分

Best-of-N 与 Self-Consistency 类似都要采样多条,但不是投票,而是用一个"打分器"给每条候选评分,选最高分那条。打分器可以是规则校验器(比如跑单元测试、验算等式),也可以是专门的奖励模型。

这里引出两个重要概念:

结果奖励模型(ORM,Outcome Reward Model):只看最终答案对不对给一个整体分数。
过程奖励模型(PRM,Process Reward Model):给推理过程的每一步都打分,能定位"从哪一步开始走错",信号更细,训练更贵。

下面用一个可运行的规则打分器演示 Best-of-N 挑选 Python 代码题的最优解:

pythonCode
import subprocess, tempfile, os

def score_code(code: str, test_snippet: str) -> int:
    # 打分器:把候选代码和测试拼起来跑,通过得 1 分,否则 0 分(充当 ORM)
    with tempfile.NamedTemporaryFile("w", suffix=".py", delete=False) as f:
        f.write(code + "\n" + test_snippet)
        path = f.name
    try:
        r = subprocess.run(["python", path], capture_output=True, timeout=10)
        return 1 if r.returncode == 0 else 0
    finally:
        os.remove(path)

def best_of_n(task: str, test_snippet: str, n: int = 8) -> str:
    candidates = []
    for _ in range(n):
        resp = client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{"role": "user", "content": task}],
            temperature=0.9,
        )
        code = resp.choices[0].message.content
        candidates.append((score_code(code, test_snippet), code))
    # 按分数降序,取最优候选
    candidates.sort(key=lambda x: x[0], reverse=True)
    best_score, best_code = candidates[0]
    print(f"最佳候选得分:{best_score}/1")
    return best_code

task = "写一个 Python 函数 is_prime(n) 判断素数,只返回函数定义。"
test = "assert is_prime(7) and not is_prime(8) and not is_prime(1)"
print(best_of_n(task, test, n=8))

当有可靠的自动校验器(编译器、测试套件、数学验算器)时,Best-of-N 往往比 Self-Consistency 更强,因为它用的是"真信号"而非"多数假设"。

🌳 Tree-of-Thoughts:把推理变成可搜索的树

思维链是一条直线,Tree-of-Thoughts(ToT)则把推理建模成一棵树:每一步生成多个候选"想法",对它们打分,保留最有希望的若干条继续展开(类似 beam search),走不通就回退。它适合需要探索、试错、规划的问题(如 24 点、逻辑谜题、多步规划)。

下面是一个高度简化的 ToT 骨架,用于说明结构:

pythonCode
def propose_steps(state: str, k: int = 3) -> list[str]:
    # 让模型基于当前推理状态,提出 k 个可能的下一步
    prompt = f"当前推理进展:\n{state}\n请提出 {k} 个不同的下一步思路,每行一个。"
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.7,
    )
    return [s for s in resp.choices[0].message.content.splitlines() if s.strip()][:k]

def evaluate(state: str) -> float:
    # 让模型给当前路径打一个 0 到 1 的"有希望程度"分(充当启发式评估器)
    prompt = f"评估这条推理路径有多可能导向正确答案,只输出 0 到 1 的小数:\n{state}"
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0,
    )
    try:
        return float(resp.choices[0].message.content.strip().split()[0])
    except ValueError:
        return 0.0

def tree_of_thoughts(question: str, depth: int = 3, beam: int = 2) -> str:
    frontier = [question]  # 当前保留的推理路径集合
    for _ in range(depth):
        candidates = []
        for state in frontier:
            for step in propose_steps(state):
                new_state = state + "\n-> " + step
                candidates.append((evaluate(new_state), new_state))
        # 按评估分排序,只保留 beam 条最有希望的路径继续展开
        candidates.sort(key=lambda x: x[0], reverse=True)
        frontier = [s for _, s in candidates[:beam]]
    return frontier[0]

print(tree_of_thoughts("用 4, 6, 8, 3 通过加减乘除凑出 24。"))

ToT 表达力最强,但实现复杂、调用次数多、成本最高。工程上除非任务确实需要显式搜索,否则通常优先尝试更便宜的 CoT 和 Self-Consistency。

🚀 从 o1 到 DeepSeek-R1:推理能力如何被训练出来

思维链提示虽然有效,但它依赖用户在提示词里"手动引导",模型本身并没有被专门训练成一个擅长长链条推理的系统,推理质量也参差不齐——有时想岔了就一路错到底,不会自我纠正。真正的转折点是 OpenAI 在 o1 系列模型上展示的路径:把"会不会做长链条推理"从提示词技巧变成模型自身通过训练获得的能力。

其核心思路可以概括为:

1.强化学习驱动,而非单纯监督微调:传统的指令微调是让模型模仿人类写好的标准答案,但人类很少会把自己所有的试错、回头检查的过程都写下来当作训练样本。o1 类模型采用强化学习的思路,对模型自己生成的推理过程按最终答案是否正确(或按过程是否合理)给予奖励信号,让模型在大量尝试中逐渐学会"什么样的思考方式更容易导向正确答案",包括何时该多验证一步、何时该换一种解法重试。
2.推理链是模型的原生行为,而不是提示词套出来的:经过这种训练后,模型不需要用户在提示里写"请一步步思考",也会默认先在内部生成一段较长的思考过程,再输出面向用户的最终回答。思考过程本身的长度和复杂度是模型根据问题难度自适应决定的——简单问题几乎不多想,难题则会展开成很长的推演。
3.DeepSeek-R1 的开源验证与技术路线公开:2025 年初,DeepSeek-R1 的发布把这条路径的关键细节以论文和开源权重的形式公开出来,其中一个引人关注的做法是:先用纯强化学习(不依赖大量人工标注的思维链数据)在基础模型上直接训练出具备推理能力的雏形模型,观察到模型会自发学会拉长推理过程、进行自我检查甚至"顿悟"式的纠错行为;随后再结合少量高质量的冷启动数据和多阶段训练进一步稳定和优化输出的可读性与语言一致性。这一路线证明了推理能力可以在相对可控的成本下、通过强化学习被系统性地"训练"出来,而不再是只有少数闭源大厂才能复现的黑箱能力,也带动了后续一大批开源推理模型的跟进。

这里补充几个训练侧的关键术语,帮助理解这套流程:

| 术语 | 含义 | 在推理模型里的角色 |

| --- | --- | --- |

| RLHF | 基于人类反馈的强化学习 | 早期对齐主力,奖励来自人类偏好 |

| GRPO | 组相对策略优化 | R1 采用的高效 RL 算法,省去价值网络,用一组采样的相对得分做基线 |

| ORM | 结果奖励模型 | 只看最终答案对错给奖励 |

| PRM | 过程奖励模型 | 给每一步推理打分,信号更细但更贵 |

| 冷启动数据 | 少量高质量推理样本 | RL 前先做 SFT,稳定语言风格与可读性 |

| 蒸馏 | 用大模型输出训练小模型 | 把 R1 的推理能力迁移到小尺寸模型 |

从 o1 到 DeepSeek-R1,一个共同的技术共识逐渐清晰:长而有效的思维链不是提示词工程的产物,而是可以通过强化学习作为模型的内在能力训练出来的,模型学会的不只是"多写字",而是"在多写的过程中真正做对更多验证、回退和修正"。

🔌 调用推理模型 API 与预算控制

使用推理模型时,接口层面和普通模型有两点不同:一是会额外产生一批"推理 token"(reasoning tokens),它们通常不返回给你看,但要计费;二是很多接口提供了"推理力度"(reasoning effort)旋钮,用来控制模型愿意花多少测试时计算。

下面演示如何调用并读取 reasoning token 用量(伪 SDK 写法,字段名以各家实际文档为准):

pythonCode
resp = client.chat.completions.create(
    model="o3-mini",
    messages=[{"role": "user", "content": "证明:任意三个连续整数之积能被 6 整除。"}],
    reasoning_effort="high",   # low / medium / high,控制思考深度
)

msg = resp.choices[0].message
usage = resp.usage
print("最终回答:", msg.content)
# 推理 token 单独统计,属于输出计费的一部分
print("推理 token:", usage.completion_tokens_details.reasoning_tokens)
print("可见输出 token:", usage.completion_tokens)

在生产环境里,reasoning effort 应该按任务难度动态调节,避免对简单问题浪费算力。下面是一个简单的预算路由器:

pythonCode
def route_effort(question: str) -> str:
    # 用轻量启发式(长度、关键词)决定给多少思考预算
    hard_signals = ["证明", "为什么", "推导", "规划", "优化", "复杂度", "调试"]
    if any(k in question for k in hard_signals) or len(question) > 120:
        return "high"
    if len(question) > 40:
        return "medium"
    return "low"

def ask(question: str) -> str:
    effort = route_effort(question)
    resp = client.chat.completions.create(
        model="o3-mini",
        messages=[{"role": "user", "content": question}],
        reasoning_effort=effort,
    )
    print(f"[effort={effort}]")
    return resp.choices[0].message.content

print(ask("今天星期几用一句话回答"))         # 走 low
print(ask("请推导快速排序的平均时间复杂度"))   # 走 high

在 shell 里直接用 curl 调用时,注意把 API key 从环境变量取出,写成 ${OPENAI_API_KEY} 这样的形式:

textCode
curl https://api.openai.com/v1/chat/completions -H "Authorization: Bearer ${OPENAI_API_KEY}" -H "Content-Type: application/json" -d '{"model":"o3-mini","reasoning_effort":"medium","messages":[{"role":"user","content":"9.11 和 9.9 哪个大?"}]}'

🧪 从推理模型蒸馏到小模型

推理模型强但贵。一个常见的工程做法是"蒸馏":让强推理模型(教师,如 R1)在大量问题上生成带完整思维链的高质量解答,再用这些数据去微调(SFT)一个小模型(学生),让小模型以极低的推理成本获得接近的推理能力。DeepSeek 就用这种方式蒸馏出了多个小尺寸的 R1-Distill 模型。

数据构造的核心流程如下:

pythonCode
import json

def build_distill_dataset(questions: list[str], out_path: str):
    records = []
    for q in questions:
        resp = client.chat.completions.create(
            model="deepseek-reasoner",   # 教师模型
            messages=[{"role": "user", "content": q}],
        )
        msg = resp.choices[0].message
        reasoning = getattr(msg, "reasoning_content", "")  # 教师的思维链
        answer = msg.content

        # 只保留答对的样本(拒绝采样):这里用一个占位校验函数
        if not verify(q, answer):
            continue

        # 学生模型的训练样本:把思维链包进 <think> 标签,教它模仿"先想再答"
        target = f"<think>\n{reasoning}\n</think>\n\n{answer}"
        records.append({"prompt": q, "completion": target})

    with open(out_path, "w", encoding="utf-8") as f:
        for r in records:
            f.write(json.dumps(r, ensure_ascii=False) + "\n")
    print(f"共产出 {len(records)} 条蒸馏样本 -> {out_path}")

def verify(question: str, answer: str) -> bool:
    # 实战中替换成真校验:数学题验算、代码题跑测试、或用另一模型判分
    return "答案" in answer

# build_distill_dataset(["计算 128 的所有正因子之和", "..."], "distill.jsonl")

蒸馏的要点有三条:一是拒绝采样,只保留教师答对的样本,避免把错误推理也学进去;二是保留完整推理轨迹而非只留最终答案,学生要学的是"怎么想";三是格式统一(如用 标签分隔思考与回答),方便训练和后续解析。实践表明,一个几 B 参数的小模型经过高质量蒸馏,在特定数学/代码基准上可以逼近甚至超过参数大十倍的普通模型。

📈 测试时计算:新的 Scaling 维度

在推理模型出现之前,提升大模型智力水平的主要手段是"训练时 Scaling":加大模型参数量、加大预训练数据量、加大训练算力投入,这条路径在过去几年支撑了模型能力的持续跃升,但边际成本越来越高,单纯堆参数带来的收益也在放缓。

推理模型的兴起揭示了另一条此前被低估的路径——测试时计算(test-time compute):在模型训练完成、参数固定之后,通过在推理(也就是回答问题)阶段投入更多计算量,同样可以换来更好的输出质量。常见的具体做法包括:

生成更长的思维链:允许模型在给出最终答案前展开更充分的中间推理,思考步骤越完整,越不容易漏掉关键条件或计算错误。
多次采样再投票(Self-Consistency / Best-of-N):对同一个问题让模型独立生成多条不同的推理路径和答案,再通过多数投票或额外的打分模型挑出最可靠的一个,用"多算几遍取共识"来抵消单次采样的随机性和偶然错误。
搜索与回溯:把推理过程建模成一棵可以分叉、评估、剪枝的搜索树,在多个候选思路之间比较优劣,或者在发现某条路径走不通时主动回退,尝试另一种解法。

一个反复被观察到的经验规律是:在一定范围内,思考的 token 越多,困难任务的准确率越高,但收益递减。下面这张示意表(数字为演示性质,非精确基准)展示了这种关系:

| 平均思考 token 数 | AIME 类难题准确率(示意) | 单题相对成本(示意) |

| --- | --- | --- |

| 0(直接作答) | 20% | 1x |

| 约 1000 | 45% | 3x |

| 约 4000 | 68% | 9x |

| 约 12000 | 79% | 24x |

| 约 30000 | 83% | 55x |

可以看到,从"不思考"到"适度思考"提升巨大,但从"很多思考"到"极多思考"提升趋缓而成本陡增——这正是 reasoning effort 旋钮需要按任务调节的原因。

这条路径带来的启示是:模型的"实际智力表现"并不完全由训练阶段固化的参数量决定,还取决于推理阶段愿意花多少计算去"想"。同样一个模型,只允许它快速给出一次性答案,和允许它反复推演、多路径验证后再作答,二者在困难任务上的正确率可能有天壤之别。这也解释了为什么现在很多产品会提供"慢思考"或"深度推理"开关——本质上是把测试时计算量作为一个可以按需调节的旋钮,让用户在响应速度和答案质量之间自行取舍。

对使用者而言,理解测试时计算的意义在于:面对确实需要严谨推理的任务(复杂数学、多步骤代码逻辑、需要权衡多个约束条件的规划问题),主动选择支持深度推理的模型或模式,并给予足够的等待时间,往往比在普通快思考模型上反复用提示词技巧"哄"出更好答案更有效;而对于简单直接的任务,继续使用响应更快的常规模型则是更合理的成本选择。

🎯 真实案例

推理模型的价值在这些场景里体现得最明显:

数学竞赛(AIME、GPQA):AIME 是美国高中数学邀请赛,题目需要多步严密推导。普通模型往往在中间某步算错就满盘皆输,而推理模型能一步步验算、发现矛盾后回退,正确率大幅领先。GPQA 是研究生级别的物理/化学/生物问答,同样高度依赖多步推理。
代码调试:给一段有隐蔽 bug 的代码,推理模型会"在脑子里跑一遍"——推演变量在每一步的取值,定位到究竟哪一行的边界条件出错,而不是凭直觉猜一个改动。
多约束规划:比如"给 5 个人排班,满足若干互斥和偏好约束",这类问题需要同时兼顾多个条件,快思考模型很容易顾此失彼,而推理模型会系统性地逐条检查约束是否都满足。
模型落地:o1/o3 展示了闭源推理模型在竞赛数学和编程上的飞跃;DeepSeek-R1 以开源形式复现并公开了训练路线;Qwen 等团队也推出了带推理能力的开源模型和蒸馏版本,让中小团队能以较低成本用上"慢思考"。

下面是推理模型 vs 普通模型在几类基准上的示意对比(数字为演示性质,用于体现量级差异,非精确官方数据):

| 基准 | 普通模型(示意) | 推理模型(示意) |

| --- | --- | --- |

| AIME 数学竞赛 | 约 15% | 约 80% |

| GPQA 研究生问答 | 约 40% | 约 75% |

| 竞赛编程(Codeforces 分位) | 约 50 百分位 | 约 90 百分位 |

| 简单常识问答 | 约 92% | 约 93% |

注意最后一行:在简单任务上,推理模型的优势几乎消失,但成本和延迟却高得多——这再次印证了"按需选择模式"的重要性。

⚠️ 常见坑

对简单任务滥用推理模型:既慢又贵,收益却几乎为零。简单问答用快思考模型即可。
误把思维链当最终答案:推理模型的思考内容可能冗长且含自我怀疑、试错,不要直接展示给终端用户,要解析出最终结论。有些接口甚至不返回原始思维链。
忘记推理 token 计费:推理 token 通常按输出价计费且量可能很大,不监控用量容易账单爆炸。
Self-Consistency 用在开放式任务上:投票只对"有唯一可判定答案"的题有效,对写作、翻译这类无标准答案的任务无意义。
temperature 设成 0 还想采样多样路径:Self-Consistency / Best-of-N 必须用较高温度,否则每次采样几乎一样,投票失去意义。
蒸馏时不做拒绝采样:把教师答错的推理也学进去,学生会继承错误模式。
对推理模型强行叠加"请一步步思考":原生推理模型已自带思考,额外的 CoT 提示有时反而扰乱其内部格式,通常直接给任务即可。

✅ 最佳实践

分层路由:先用轻量分类判断任务难度,简单走快模型、难题走推理模型或高 effort,兼顾质量与成本。
给足思考预算再谈质量:确认是难题就调高 reasoning effort 或允许更长输出,不要一边限制 token 一边抱怨答得不好。
配可靠校验器就用 Best-of-N:代码有测试、数学能验算时,用真信号打分比多数投票更准。
监控 reasoning token:把推理 token 用量纳入可观测指标,设预算告警。
面向用户只展示结论:把思维链留在后台用于调试与审计,前台呈现干净的最终答案。
难任务用推理模型、量产任务用蒸馏小模型:先用强模型跑出高质量数据,再蒸馏出便宜的专用小模型规模化部署。

✍️ 小结

思维链把"直接给答案"变成"先展开推理再给答案",本质上是让模型的计算过程从一个 token 的瞬间判断,延展成一段可追溯、可自我检查的推理轨迹;快思考与慢思考的类比说明了普通对话模型与推理模型在设计目标上的根本差异;从 o1 到 DeepSeek-R1 的技术演进证明了这种"慢思考"能力可以通过强化学习被系统性地训练进模型本身,而不再依赖提示词的临时引导;测试时计算则揭示了一条与"堆参数"并行的新扩展路径——用推理阶段的算力投入换取更高的智力表现。这三者共同构成了当前推理模型技术栈的核心图景,也是理解为何近两年模型在复杂推理任务上突飞猛进的关键线索。

最后用一张表把全文的关键技术点收束起来:

| 技术 | 一句话定义 | 适用场景 | 成本量级 |

| --- | --- | --- | --- |

| Zero-shot CoT | 加一句"请一步步思考" | 通用推理,快速起步 | 低 |

| Few-shot CoT | 给几个带推理的范例 | 格式敏感、专业领域 | 低到中 |

| Self-Consistency | 多次采样后多数投票 | 有唯一答案的题 | 中 |

| Best-of-N | 多次采样后打分选优 | 有可靠校验器的题 | 中到高 |

| Tree-of-Thoughts | 把推理变成可搜索的树 | 需要探索回溯的规划题 | 高 |

| 原生推理模型 | RL 训出的内在慢思考 | 数学、代码、复杂推理 | 高 |

| 蒸馏小模型 | 学教师的推理轨迹 | 规模化、低成本部署 | 一次性训练成本 |