---
title: "03-推理模型详解：当AI学会慢思考"
created: 2026-05-15
tags:
  - 博客

---
# 推理模型详解：当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 在推理时：

1. 每个 Token 只计算一次，用固定的计算量
2. 模型不知道自己会犯错（没有自我纠错机制）
3. 错误会累积——第 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（基于人类反馈的强化学习）。流程是：

1. 训练一个奖励模型（Reward Model）来模拟人类偏好
2. 用这个奖励模型来强化学习微调 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 中使用推理模型

```java
@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();
    }
}
```

## 什么时候用推理模型

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

### 代价

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

### 场景选择指南

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

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

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

## 推理模型和 RAG 的关系

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

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

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

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

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

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

### Java 实现示例

```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 智能体需要互相通信和协作时，它们之间怎么"对话"。