推理模型详解：当AI学会慢思考

前面讲过 CoT（思维链）——让模型在 Prompt 里一步步写出推理过程，提高复杂问题的准确率。当时提到"一些模型内置了深度思考能力"，但没展开。

2025 年下半年开始，AI 领域最大的变化之一，就是推理模型（Reasoning Models） 的崛起。OpenAI 的 o1、o3，DeepSeek 的 R1，Anthropic 的 extended thinking……这些模型和传统 LLM 有着根本性的不同。

如果传统 LLM 像"快思考"——凭直觉直接给答案，那推理模型就像"慢思考"——停下来仔细琢磨，想清楚了再说。

这篇文章咱们就来深入聊聊这个改变 AI 能力格局的新范式。

传统 LLM 的"快思考"困境

你还记得大模型是怎么工作的吗？给定上文，预测下一个 Token，一个接一个，直到完成回答。这个过程是逐 Token 自回归生成——每生成一个 Token，就根据之前的内容决定下一个。

这个机制有一个天生的弱点：它没法"回头想"。Token 一旦生成就确定了，不能回头修改。就像一个人说话，说了就收不回来。

一个真实的问题

让传统 LLM 算这道题：

小明有 15 个苹果，他给小红分了 3 个，给小李分了小红的 2 倍，又给小王分了剩下的 1/3。小明最后还剩几个？

传统模型可能会这样算：

15 - 3 = 12
小红的 2 倍 = 3 × 2 = 6
12 - 6 = 6
6 - 6/3 = 6 - 2 = 4
答案是 4 个

看起来思路清晰，但实际上你仔细验算一下：小红 3 个，小李 6 个，一共分出去 9 个，剩 6 个。小王分剩下的 1/3 = 2 个。小明最后剩 6 - 2 = 4 个。答案倒是对的。

但是如果把数字换得复杂一点，或者增加几步推理，传统模型很容易在"预测下一个 Token"的过程中跑偏——某一步生成错了，后面就一路错下去。这在数学、逻辑、代码等需要精确多步推理的领域特别致命。

"一步错，步步错"的根本原因

把问题说得更技术一点。传统 LLM 在推理时：

每个 Token 只计算一次，用固定的计算量
模型不知道自己会犯错（没有自我纠错机制）
错误会累积——第 3 步算错了，第 4 步基于错误结果继续算

这就是所谓的 System 1（快思考）——直觉式的、自动的、不怎么费脑子的思考方式。这在日常聊天、简单问答中完全够用，但在需要深度推理的场景下就显得不够可靠。

推理模型的"慢思考"革命

2024 年 9 月，OpenAI 发布了 o1（当时代号 Strawberry），标志着 AI 推理能力的质变。随后 DeepSeek 在 2025 年 1 月开源了 R1，把推理模型的竞争推向了高潮。

o1/o3 的核心创新：Test-time Compute Scaling

Test-time Compute（推理时计算），也叫 Inference-time Scaling，是推理模型最核心的理念：在推理阶段投入更多计算资源，让模型有"时间"去思考。

传统模型的推理过程是固定的——给定输入，模型以固定的计算量生成输出。每个 Token 的花费是一样的。

推理模型打破了这个限制。面对复杂问题时，它会在内部进行大量的"隐藏推理"：

用户：请证明根号2是无理数。

传统模型（快思考）：
假设根号2是有理数，则存在互质的整数p,q使(p/q)^2=2...
直接输出证明过程（可能中间有跳跃或小错误）

推理模型（慢思考）：
[内部：我需要用反证法。先假设根号2是有理数……
 等等，这里互质条件很重要，要明确说明……
 p^2=2q^2，这说明p是偶数……
 设p=2k代入……那么q也是偶数……
 矛盾！因为p和q应该互质，但都被2整除……
 没问题，逻辑通顺。可以输出了。]
假设根号2是有理数，则存在互质的整数p和q使得根号2=p/q……
（输出经过充分验证的证明过程）

方括号里的部分是"内部推理"——用户看不到，但它消耗了大量的计算资源。

Token 消耗的对比

同一个问题，不同模型的 Token 消耗：

问题	传统模型输出	o1 内部推理	o1 可见输出
解一道微积分题	~200 Token	~2000 Token	~300 Token
分析一个法律条款	~500 Token	~3500 Token	~400 Token
写一段 Python 代码	~300 Token	~800 Token	~350 Token

大部分 Token 消耗在"内部思考"上。这些思考过程对于 API 使用者来说是要付费的（虽然你看不到内容），但换来的是准确率的大幅提升。

内部推理的内容特征

虽然 OpenAI 没有公开 o1 的完整内部推理过程（原因是安全和竞争），但 DeepSeek-R1 开源了它的完整思考链。看一个真实例子：

用户：一个 10L 的容器装满了水，还有一个 7L 和一个 3L 的空容器。
     如何得到 5L 水？

R1 思考过程：
<think>
好的，这是一个经典的倒水问题。让我一步步分析。

初始状态：10L满(10)，7L空(0)，3L空(0)
目标：得到 5L

我需要考虑倒水的各种可能性。从大容器往小容器倒是最自然的。

方案1：从10L倒到7L...
10L倒满7L → (3,7,0)
7L倒满3L → (3,4,3)
3L倒回10L → (6,4,0)
7L倒满3L → (6,1,3)
3L倒回10L → (9,1,0)
7L倒入3L → (9,0,1)
10L倒满7L → (2,7,1)
7L倒满3L → (2,5,3) ← 7L容器中正好是5L！

验证：2+5+3=10✓ 目标达成。

这个路径是正确的。让我想想还有没有更短的路径...
</think>

可以通过以下步骤得到5L水：
1. 将10L容器的水倒入7L容器 → (3,7,0)
2. 将7L容器的水倒入3L容器 → (3,4,3)
...

你能看到 R1 在思考过程中做了这些事：

拆解任务：识别出这是"倒水问题"
穷举探索：尝试不同的倒水路径
自我验证：每一步都验证状态是否正确
寻找最优解：思考完一个路径后，还问"有没有更短的"
错误修正：如果某条路走不通，它会注意到并切换

这种"自言自语"式的内部推理，是人类解决复杂问题时的自然方式。现在 AI 也能这样做了。

R1 的"啊哈时刻"

DeepSeek-R1 训练过程中有一个著名的"啊哈时刻"（Aha Moment）。研究人员发现，R1 在强化学习训练中自然而然地学会了：

自我质疑："等等，上一步可能有问题……"
回溯修正："让我重新检查一下第三步的计算……"
策略切换："这种方法行不通，换个思路试试……"

这些行为没有被人为编程进去——它们是模型在训练中自然涌现的。这让研究人员自己都感到震惊。

GRPO：让 R1 学会思考的训练方法

R1 能涌现推理能力，很大程度上归功于它的训练算法——GRPO（Group Relative Policy Optimization，群体相对策略优化）。

传统 RLHF 的局限

之前的大模型训练主要用 RLHF（基于人类反馈的强化学习）。流程是：

训练一个奖励模型（Reward Model）来模拟人类偏好
用这个奖励模型来强化学习微调 LLM

问题在于：奖励模型也是训出来的，有偏差，且训练成本高。

GRPO 的思路

GRPO 是 DeepSeek 团队提出的新方法。它的核心思想很简洁：

不训练单独的奖励模型，而是让模型自己生成多个答案，通过组内比较来评估每个答案的好坏。

具体做法：

对同一道题：
  模型生成 4 个不同的答案 → [答案A, 答案B, 答案C, 答案D]

对每个答案：
  - 用规则评分器打分（数学题看最终答案对不对）
  - 计算组内平均分
  - 高于平均分的答案 → 强化这种行为
  - 低于平均分的答案 → 抑制这种行为

这种方式有几个精妙之处：

1. 不需要奖励模型。用规则（数学题对错）直接打分，避免了奖励模型的偏差。

2. 组内相对比较。不是跟某个绝对标准比，而是跟同一批答案的平均水平比。这天然处理了难度差异——难题大家都分低，简单题大家都分高，相对排名才是关键。

3. 推动了"思考习惯"的形成。那些得分高的答案往往是经过了更仔细推理的。模型在训练中逐渐学到：多想想、多检查，更可能得到高分。

GRPO 和 PPO 的区别

维度	PPO（传统 RLHF）	GRPO
奖励来源	训练单独的奖励模型	规则打分 + 组内比较
参考基线	需要 Value 网络评估优势	组内平均分作为基线
计算开销	高（需训练和运行多个模型）	低（只需 LLM 本身）
奖励偏差	受奖励模型质量影响	受规则设计影响
涌现能力	有限	自我质疑、回溯等行为自然涌现

主流推理模型对比

截至 2026 年 5 月，主流的推理模型包括：

模型	发布方	参数量	开源	特点
o3	OpenAI	未公开	否	最强推理能力，支持 low/medium/high 三档推理量
o4-mini	OpenAI	未公开	否	高性价比，推理能力接近 o3
DeepSeek-R1	DeepSeek	671B (MoE)	是	开源标杆，完整思考过程可见，API 价格低
DeepSeek-R1-Distill	DeepSeek	1.5B-70B	是	R1 蒸馏到小模型，本地可部署
Claude 4.5 extended thinking	Anthropic	未公开	否	Claude 的扩展思考模式，可按需开启
Gemini 3.1 Deep Think	Google	未公开	否	支持更多推理步骤的增强模式
Qwen3	阿里	0.6B-235B	是	双模式：思考模式和非思考模式可切换

DeepSeek-R1 的两种用法

R1 有个特别方便的设计：它支持思考模式和非思考模式切换：

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://api.deepseek.com"
)

# 方式1：直接使用 R1（内置思考，会自动进行内部推理）
response = client.chat.completions.create(
    model="deepseek-reasoner",  # 即 R1
    messages=[{
        "role": "user",
        "content": "证明：在任意6个人中，必存在3个人两两认识或两两不认识。"
    }]
)

# 方式2：V3 + "深度思考"模式（控制是否思考）
response = client.chat.completions.create(
    model="deepseek-chat",  # V3
    messages=[{
        "role": "system",
        "content": "遇到需要推理的问题时，请先仔细思考再回答。"
    }, {
        "role": "user",
        "content": "证明：在任意6个人中，必存在3个人两两认识或两两不认识。"
    }]
)

# 两种方式的结果区别：
# R1：输出中有 <think>...</think> 包含完整思考过程
# V3+提示：思考过程更简略，可能在复杂推理上不如 R1 稳定

Spring AI 中使用推理模型

@RestController
public class ReasoningController {

    private final ChatClient reasonClient;

    public ReasoningController(ChatClient.Builder builder) {
        // 配置推理模型（以 DeepSeek-R1 为例）
        this.reasonClient = builder
            .defaultSystem("你是一个擅长数学和逻辑推理的助手。")
            .defaultOptions(OpenAiChatOptions.builder()
                .model("deepseek-reasoner")
                .temperature(0.6)  // 推理模型建议用稍低的温度
                .maxTokens(8000)   // 给内部推理留足空间！
                .build())
            .build();
    }

    @PostMapping("/solve")
    public ResponseEntity<String> solve(@RequestBody String problem) {
        // 注意：如果 API 返回了思考过程，R1 的 <think> 标签会包含在内
        String response = reasonClient.prompt()
            .user(problem)
            .call()
            .content();

        return ResponseEntity.ok(response);
    }

    // 流式输出：可以看到模型的"思考过程"逐步流出
    @PostMapping(value = "/solve-stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<String> solveStream(@RequestBody String problem) {
        return reasonClient.prompt()
            .user(problem)
            .stream()
            .content();
    }
}

什么时候用推理模型

推理模型不是万能的。它的"慢思考"有代价：

代价

更贵：o1 内部的隐藏 Token 也要付费，一个复杂问题可能消耗 10 倍于普通模型的 Token
更慢：生成思考过程需要额外时间，一个数学证明可能需要 30 秒甚至更久
输出不可控：你不能精确控制思考过程的长度和方向（虽然 o3 提供了 low/medium/high 三档）
对简单问题过度思考：问它"1+1 等于几"，它也可能"深思熟虑"一番

场景选择指南

场景	推荐模型类型	原因
数学证明、复杂计算	推理模型	需要多步严格推导
逻辑推理（逻辑谜题、智力题）	推理模型	需要系统化穷举和验证
竞赛编程（ACM/LeetCode Hard）	推理模型	需要算法设计和正确性验证
法律条款分析	推理模型	需要精确的逻辑推导和条件判断
日常对话、闲聊	传统模型	不需要深度推理，推理模型浪费
事实问答、知识查询	传统模型 + RAG	答案在文档中，不需要深度推理
创意写作、头脑风暴	传统模型	推理可能限制创意
翻译	传统模型	翻译不需要复杂推理
企业客服、常规查询	传统模型	任务模式固定，不需要深度推理
代码补全、简单代码生成	传统模型	速度快更重要
复杂系统架构设计	推理模型	需要权衡多种方案，多步推理

实用策略：先用传统模型，失败了再升级。

大多数场景下，传统模型就够了。遇到它反复搞不定的复杂问题时，再切换到推理模型。这样既省成本又省时间。

推理模型和 RAG 的关系

一个常见的问题是：RAG 和推理模型怎么配合？

答案是：它们解决的是不同层面的问题，可以叠加使用。

用户问题
    ↓
RAG 检索相关文档 ──→ 获得上下文知识
    ↓
推理模型拿到"知识 + 问题"
    ↓
内部深度推理（基于提供的知识进行逻辑推演）
    ↓
输出经过验证的答案

RAG 解决了"知识从哪里来"的问题（补充了训练数据中没有的最新知识和私有数据），推理模型解决了"知识怎么用"的问题（需要逻辑推导才能得出答案的场景）。

比如问："基于公司去年的财报数据，预测今年 Q3 的营收趋势，并说明预测依据。"

RAG 负责：检索去年的财报数据，提供给模型
推理模型负责：分析数据规律、考虑季节性因素、给出有逻辑链条的预测

Java 实现示例

@Service
public class RAGReasoningService {

    private final VectorStore vectorStore;
    private final ChatClient reasonClient;

    public RAGReasoningService(VectorStore vectorStore, ChatClient.Builder builder) {
        this.vectorStore = vectorStore;
        this.reasonClient = builder
            .defaultOptions(OpenAiChatOptions.builder()
                .model("deepseek-reasoner")  // 推理模型
                .build())
            .build();
    }

    public String analyzeWithReasoning(String question) {
        // Step 1: RAG 检索相关文档
        List<Document> docs = vectorStore.similaritySearch(
            SearchRequest.query(question).withTopK(5)
        );

        String context = docs.stream()
            .map(Document::getContent)
            .collect(Collectors.joining("\n\n"));

        // Step 2: 推理模型基于上下文进行深度分析
        return reasonClient.prompt()
            .user("""
                请基于以下参考材料，回答用户的问题。
                在进行推理时，请：
                1. 先列出问题中涉及的关键数据
                2. 逐步推导你的分析过程
                3. 每一步都要基于材料中的具体数据
                4. 如果材料信息不足，明确指出

                ===参考材料===
                %s
                ===用户问题===
                %s
                """.formatted(context, question))
            .call()
            .content();
    }
}

推理模型的未来趋势

推理模型的发展远未停止。几个值得关注的方向：

1. 推理量可控（如 o3 的 low/medium/high）

用户可以根据任务复杂度选择推理深度。简单问题用 low（快且便宜），复杂问题用 high（慢但精确）。这解决了"简单问题也过度思考"的问题。

2. 推理 + 工具调用

让推理模型在思考过程中自己决定调用什么工具。比如做数据分析时，它推理到"需要先计算标准差"，就自己调用 Python 执行器算出来，然后基于结果继续推理。

# 推理模型 + 工具调用的典型模式
# 思考过程：
# <think>
# 我需要先得到数据集的描述性统计...
# → 调用 calculate_stats(data)
# 结果：均值=45.2, 中位数=43.7, 标准差=12.8
# 标准差较大说明数据离散度高。接下来我需要做一个假设检验...
# → 调用 t_test(data, mu=40)
# 结果：p-value=0.032
# p<0.05，拒绝原假设。结论是显著偏离40。
# </think>

3. 推理蒸馏

把大推理模型（如 R1 671B）的推理能力蒸馏到小模型中（如 R1-Distill-Qwen-7B）。这让消费级设备也能跑推理模型。

4. 推理可视化

让用户看到模型的思考过程不只是为了"炫技"，而是为了建立信任。你能看到它是怎么得出答案的，就知道该不该信。

小结

这篇文章咱们搞清楚了推理模型的几个核心问题：

传统 LLM 的局限：逐 Token 生成，没有"回头想"的机制，容易在复杂推理中"一步错步步错"

推理模型的创新：Test-time Compute Scaling——在推理阶段投入更多计算，进行内部深度推理

DeepSeek-R1 和 GRPO：

R1 是开源推理模型的标杆，完整展示思考过程
GRPO 用组内相对比较代替奖励模型，让思考行为自然涌现
"啊哈时刻"——自我质疑、回溯修正是模型自己学会的

使用策略：不是所有场景都需要推理模型。日常任务用传统模型（快、便宜），复杂推理用推理模型（慢、精确、贵）。先默认用传统模型，搞不定再升级。

与 RAG 配合：RAG 提供知识，推理模型负责逻辑推演，两者可叠加使用。

下一篇文章咱们来聊 A2A（Agent-to-Agent）协议——当多个 AI 智能体需要互相通信和协作时，它们之间怎么"对话"。

03-推理模型详解：当AI学会慢思考