本文面向 Agent 开发者和 AI 应用工程师，拆解模型从"一堆随机数"到"能当 Agent 大脑"的完整训练历程。你不需要自己训模型，但读完后你会理解：为什么微调会让模型变笨、为什么同源模型能力差异巨大、以及 Function Calling 到底是怎么来的。

📌 本文是三篇系列的第二篇。第一篇《一句话是怎么变成 AI 回复的：LLM 的工作原理》讲模型如何处理输入并生成输出，第三篇《推理服务是怎么影响你的 Agent 的：推理框架与架构决策》聚焦推理层如何影响 Agent 架构师的每一个设计决策。

1. 引言：为什么 Agent 开发者需要理解训练过程

你花了两周微调了一个开源模型，效果反而比原版更差——它开始在简单问题上胡说八道，好像"变笨了"。你对比了两个基于 Llama 3 的 Chat 模型，明明是同一个 base model，一个擅长写代码，另一个擅长角色扮演，能力差异巨大。你给 Agent 接了 Function Calling，OpenAI 的模型调用工具又快又准，换了个开源模型，参数格式一团糟，工具链直接瘫痪。

这些问题的答案不在你的代码里，而在模型的训练过程里。

1.1 模型不是天生就会聊天的

上一篇文章1里，我们走完了一句话从输入到输出的全部旅程：Tokenization 把文字切成 Token，Embedding 把 Token 变成语义向量，Attention 让词与词互相"看见"，最后自回归生成一个 Token 一个 Token 地"挤牙膏"。

但那篇文章刻意回避了一个问题：模型为什么知道该输出什么？

一个刚初始化的 Transformer，参数全是随机数，它什么都不会。从"一堆随机数"到"能当 Agent 大脑用的 Chat 模型"，中间经历了多个训练阶段，每个阶段赋予模型不同的能力。理解这些阶段，你才能回答开头那三个问题。

1.2 全景预览

一个模型从"白纸"到"能用的 Agent 大脑"，通常要经过以下阶段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

阶段          做了什么                        赋予的能力
─────────────────────────────────────────────────────────────────────
                  |
                  v
+--------------------------+
|  预训练（Pretraining）     |  在万亿 Token 上做            知识、语言能力、
|  第 2 章                  |  Next-Token Prediction         模式识别
+-----------+--------------+
            |  得到 Base Model（"博学但不会对话"）
            v
+--------------------------+
|  SFT（监督微调）           |  用精选的指令-回复对            遵循指令、对话格式、
|  第 3 章                  |  继续训练                      结构化输出
+-----------+--------------+
            |  得到 Chat Model（"会聊天了"）
            v
+--------------------------+
|  RLHF（人类反馈强化学习）   |  用人类偏好信号                安全性、有用性、
|  第 4 章                  |  优化模型行为                  拒绝有害内容
+-----------+--------------+
            |  得到 Aligned Model（"靠谱了"）
            v
+--------------------------+
|  能力特化                  |  Function Calling、           工具调用、
|  第 5 章                  |  Code、RAG 等专项训练          代码生成等
+--------------------------+
            |
            v
       可以当 Agent 大脑用了

每个阶段都不是在"从零开始"，而是在上一阶段的基础上叠加新的能力。这也是为什么训练顺序很重要——跳过或搞错顺序，模型就会"翻车"。

2. 预训练 – 用互联网"喂"出一个知识库

预训练是 LLM 能力的基石。你在 ChatGPT 上感受到的"博学"——知道历史、能写代码、懂医学常识——几乎全部来自这个阶段。

2.1 预训练在做什么：Next-Token Prediction 的规模化

上一篇文章1详细讲了 Next-Token Prediction 的机制：给定前文，预测下一个 Token。预训练的本质就是把这件事做到极致——在万亿级 Token 的数据上，反复做这个预测游戏。

规模有多大？

  • Llama 3：使用超过 15.6 万亿（15.6T）个 Token 进行预训练2
  • DeepSeek V3：使用 14.8 万亿（14.8T）个 Token3

这些数据来自互联网爬取的网页、书籍、代码仓库、学术论文、维基百科等。模型在这海量文本上一遍遍地做同一件事：看前文，猜下一个词，猜错了就调整参数，猜对了就巩固。

训练成本方面，DeepSeek V3 给出了一个令人惊讶的数字：整个预训练阶段仅花费约 557.6 万美元，使用 2048 块 NVIDIA H800 GPU，训练约 2 个月3。这个成本远低于业界对同等规模模型的估计，说明算法和工程优化的空间仍然很大。

2.2 “压缩即预测”：预训练的本质

Ilya Sutskever（OpenAI 联合创始人）有一个深刻的洞察：“Compression is equivalent to prediction”——压缩等价于预测4。

什么意思？当模型越来越擅长预测下一个 Token 时，它实际上在压缩训练数据。要准确预测"北京是中国的____“后面跟"首都”，模型必须在参数里编码了"北京是中国首都"这个事实。要预测一段 Python 代码的下一行，模型必须理解了 Python 的语法规则。

Andrej Karpathy 在他著名的 “State of GPT” 演讲中用了一个更生动的比喻5：

预训练就是对互联网的有损压缩。

把 15 万亿 Token 的文本（原始大小可能是几十 TB）“压缩"进一个几十 GB 的模型参数文件里。这不是无损压缩（不可能原样还原每一个网页），而是有损压缩——模型保留了知识的"梗概"和语言的"模式”，丢失了具体的细节。

这就是为什么 LLM 对常见知识（北京是首都、水的化学式是 H2O）回答得很好，但对罕见的、长尾的事实（某个小众公司的成立日期）经常编造——那些信息在"压缩"过程中被丢失了。

一个重要的推论：Base Model 是"做梦"状态。

经过预训练的 Base Model 能做什么？它能做续写。给它一段文字的开头，它能接着往下编。但它不会"对话"。

如果你给一个纯 Base Model 输入 “请总结以下文章：…"，它大概率不会给你总结，而是会续写出更多类似的指令文本，比如 “请翻译以下段落：…” 或 “请回答以下问题：…"。因为在它的训练数据（互联网）中，“请总结以下文章” 这种文本后面经常跟的就是更多类似的指令样本。

Karpathy 把这种状态比作"做梦”5：Base Model 能生成看起来像那么回事的文本，但它不受控制，不遵循指令，就像人在梦里一样——场景逼真，但逻辑混乱，你说什么它都听不见。

2.3 Scaling Laws：钱花在哪里最值

既然预训练这么贵，怎么把钱花得最有效率？这就是 Scaling Laws（缩放定律） 要回答的问题。

Chinchilla 法则

2022 年，DeepMind 的 Hoffmann 等人发表了 Chinchilla 论文6，提出了一个关键发现：在固定的计算预算下，模型参数量和训练数据量应该等比例扩大。具体来说，最优配比大约是每个参数对应 20 个训练 Token。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Chinchilla 法则（2022）：

  最优训练 Token 数 ≈ 20 x 模型参数量

  例子：
  +------------------+--------------+------------------+
  | 模型参数量        | Chinchilla   | 实际训练 Token    |
  |                  | 最优 Token 数 |                  |
  +------------------+--------------+------------------+
  | 7B               | 140B         |                  |
  | 70B              | 1.4T         |                  |
  | Llama 3 (8B)     | 160B         | 15.6T [^2]       |
  | Llama 3 (70B)    | 1.4T         | 15.6T [^2]       |
  +------------------+--------------+------------------+

  注意：Llama 3 的实际训练量远超 Chinchilla 最优值

现代趋势：过训练（Overtrain）

你可能已经注意到了——Llama 3 (8B) 用了 15.6T Token，这相当于每个参数对应 约 1950 个 Token，是 Chinchilla 建议值的近 100 倍2。

这不是浪费。这是一种有意的策略，叫做过训练（Overtraining）。

逻辑是这样的：Chinchilla 法则优化的是"训练成本”——在固定预算下，怎么训出最好的模型。但在实际部署中，推理成本往往远大于训练成本（模型训一次，但要服务千万用户）。一个 8B 的模型比 70B 的模型推理便宜得多，如果通过多喂数据让小模型接近大模型的效果，总体来看是划算的2。

Agent 开发者视角

这对你选模型有什么用？

  • 模型越大不一定越好：一个被充分过训练的小模型，可能在你的任务上表现不输大模型，但推理成本低得多
  • 训练数据的质量和数量同样关键：同样参数量的模型，训练数据的差异可能导致能力天壤之别
  • 不要只看参数量：还要看技术报告里的训练 Token 数、数据组成、训练方法

2.4 Base Model 能做什么，不能做什么

总结一下，纯 Base Model 的能力边界：

1
2
3
4
5
6
7
8

Base Model 能做的：              Base Model 不能做的：
-------------------------       -------------------------
+ 续写文本                       - 遵循指令
+ 补全代码                       - 回答问题（会续写更多问题）
+ 翻译（如果以续写形式触发）       - 拒绝有害内容
+ 模仿训练数据中的风格            - 结构化输出（JSON 等）
+ 展现"百科全书"式的知识           - 承认"我不知道"
                                - 调用工具（Function Calling）

一个直观的例子：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

你给 Base Model 的输入：
  "请总结以下文章的要点：人工智能正在改变..."

Base Model 大概率的输出（不是总结，而是续写）：
  "请翻译以下段落为英文：随着技术的发展..."
  或
  "人工智能正在改变各行各业的运作方式。从医疗到金融..."
  （它会继续写那篇文章，而不是总结它）

你期望的输出（需要 SFT 后才能做到）：
  "这篇文章的要点如下：1. AI 正在... 2. ..."

Base Model 就像一个读了整个互联网的博学之人，但它没上过"如何回答别人问题"的培训课。它满肚子知识，但你问它问题，它只会自顾自地"梦游式"续写。

要让它变成一个能对话、能接受指令的助手，需要下一个阶段：SFT（监督微调）。

本章小结：预训练是模型知识的来源，它通过在万亿 Token 上做 Next-Token Prediction 来"压缩"互联网知识。记住三个核心认知：

  1. 预训练 = 有损压缩互联网：模型的知识几乎全部来自这个阶段，常见知识记得好，长尾知识容易编造
  2. Base Model 只会续写，不会对话：它处于"做梦"状态，能生成流畅文本但不受控制
  3. 模型大小不是唯一指标：训练数据的数量和质量同样决定能力，过训练的小模型可能性价比更高

现在，我们有了一个"博学的梦游者"。下一章，我们来看 SFT 如何用少量的精选数据，就把它"叫醒"。

3. SFT – 教会模型"说人话"

预训练给了模型一肚子知识，但它不知道该怎么用。SFT（Supervised Fine-Tuning，监督微调）的作用，就是教会模型"按人类期望的方式回答问题"。

3.1 SFT 在做什么：从"续写机器"到"对话助手"

SFT 的训练数据是什么样的？很简单，就是一条条的指令-回复对（Instruction-Response Pairs）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

训练样本示例：

指令：请用一句话解释什么是机器学习。
回复：机器学习是让计算机通过数据自动学习规律并做出预测的技术。

指令：把以下句子翻译成英文：今天天气不错。
回复：The weather is nice today.

指令：写一个 Python 函数，计算列表的平均值。
回复：def average(lst):
         return sum(lst) / len(lst)

模型在这些示范数据上继续训练（本质上仍然是 Next-Token Prediction，只不过训练数据从"互联网文本"变成了"指令-回复对"）。训练完成后，模型学会了一个新模式：看到指令格式的输入，就输出回复格式的内容。

最令人震惊的是这个过程需要的数据量。

InstructGPT 的发现

2022 年，OpenAI 发表了 InstructGPT 论文7，展示了一个惊人的结果：仅用约 13,000 条示范数据进行 SFT，一个 1.3B 参数的小模型，在人类评估中就打败了 175B 参数的 GPT-3。

13,000 条数据 vs 15 万亿 Token 的预训练数据——差了 10 亿倍的数量级。

LIMA 的进一步验证

2023 年，Meta 的 Zhou 等人发表了 LIMA 论文8，把这个发现推到了极致：他们仅用 1,000 条精心挑选的示范数据对 LLaMA 65B 进行 SFT，就获得了与 GPT-4（当时）可比的对话质量。

1,000 条。没有打错。

比喻：预训练是让模型读了整个图书馆（15 万亿 Token），SFT 是给它上了一堂"如何回答别人问题"的培训课（1,000 到 13,000 条示范）。知识来自图书馆，而不是那堂培训课。培训课只是教会了它"别人问你什么，你该怎么答"这个格式。

3.2 Superficial Alignment Hypothesis：SFT 到底改变了什么

LIMA 论文8提出了一个重要假说——Superficial Alignment Hypothesis（表层对齐假说）：

模型的知识和能力几乎全部来自预训练。SFT 所做的事情，仅仅是教会模型与用户交互的格式和风格。

换句话说，SFT 不是在往模型脑子里"灌输新知识"，而是在教它"说话的方式"。

用一个具体例子来理解：

1
2
3
4
5
6
7
8
9

预训练阶段学到的知识（存在模型参数里）：
  "Python 中 list 的 sort() 方法会原地排序，返回 None"

SFT 教会的东西：
  当用户问 "Python 的 sort 和 sorted 有什么区别？" 时，
  不要续写更多问题，而是：
  1. 先直接回答区别
  2. 给出代码示例
  3. 用清晰的格式组织内容

知识（“sort() 返回 None”）来自预训练。SFT 只教了模型怎么把这个知识用正确的格式呈现出来。

Alignment Tax 很小

这个假说还有一个推论：因为 SFT 只调整"表层"的格式和风格，它对模型原有能力的损害（所谓的 Alignment Tax）应该很小。LIMA 的实验验证了这一点——经过仅 1,000 条数据的 SFT，模型在各种基准测试上的表现几乎没有下降8。

3.3 Agent 开发者的微调决策

理解了 SFT 的本质，你就能做出更明智的微调决策。

什么时候该微调？

  • 你有大量领域特定的指令-回复对，想让模型学会特定的输出格式或交互风格
  • 你需要模型适应特定的对话模板（比如你的 Agent 框架使用独特的 System Prompt 格式）
  • 你想让模型更擅长某类任务的回答方式（比如医疗问答中的谨慎措辞）

什么时候不该微调？

  • 想让模型学新知识：SFT 教的是格式，不是知识。想让模型知道你公司的产品文档？用 RAG，不要微调
  • 数据量太少且质量不高：LIMA 证明了 1,000 条高质量数据就够了，但关键词是"高质量"。1 万条低质量数据不如 1,000 条精选数据
  • 通用能力已经足够好：如果大厂的 Chat 模型已经能满足你的需求，不要为了"定制化"而微调

微调最大的风险：灾难性遗忘（Catastrophic Forgetting）

当你用领域数据微调模型时，模型在学习新任务的同时，可能会"遗忘"预训练阶段学到的通用能力。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

微调前：
  + 能写代码 + 能聊天 + 能翻译 + 知道历史知识

用 5000 条医疗问答数据微调后：
  + 医疗问答格式完美
  - 写代码能力下降
  - 闲聊变得生硬
  - 部分常识知识丢失

--> 这就是"灾难性遗忘"：微调后模型在新任务上变好了，
    但在原有任务上"变笨了"

这就是开头提到的那个问题的答案——“为什么微调后模型反而变笨了”。你教会了它新的格式，但代价是损害了它原有的通用能力。

数据质量 > 数据数量

LIMA 论文8和 InstructGPT7的实验一致表明：SFT 阶段，数据质量远比数据数量重要。1,000 条由专家精心编写的高质量数据，效果好于 10 万条自动生成的低质量数据。

如果你决定微调，把精力花在数据清洗和筛选上，而不是堆量。

延伸洞察：为什么 Few-shot Prompting 如此有效？

理解了 SFT 的本质，你还能解释一个 Agent 开发中的常见现象：为什么在 Prompt 里给 3 个示例，模型的输出质量就能大幅提升？

原因是：Few-shot Prompting 本质上是在上下文窗口里，临时模拟了一次微型的 SFT。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

SFT 训练数据长这样：
  指令：把以下内容转成 JSON...
  回复：{"name": "xxx", ...}
  （重复几万条）

Few-shot Prompt 长这样：
  示例 1：输入 xxx → 输出 {"name": "xxx"}
  示例 2：输入 yyy → 输出 {"name": "yyy"}
  示例 3：输入 zzz → 输出 {"name": "zzz"}
  现在请处理：输入 aaa → ?

--> 模型看到的模式和 SFT 训练时一模一样！

你在用上下文窗口，临时给模型"上了一堂课"，唤醒了它在 SFT 阶段学到的模仿能力。这也解释了 Few-shot 的几个实战现象：

  • 示例格式要一致：模拟 SFT 数据的一致性，格式不一致等于给模型喂了"脏数据"
  • 示例太多反而变差：占用上下文窗口，挤压了真正的指令和 RAG 内容
  • 最后一个示例权重最高：离生成点最近，Attention 的近因效应（第一篇1讲过）

3.4 工程备忘录

决策建议原因
想让模型学新知识用 RAG，不要 SFTSFT 教格式，不教知识（Superficial Alignment Hypothesis）
想改变输出风格SFT 是正确选择这正是 SFT 擅长的：调整格式和风格
微调数据准备质量优先，1000 条精选 > 10 万条低质量LIMA8 已证明
微调后效果变差检查灾难性遗忘在通用基准上也跑一下评测，不要只看目标任务
选基座模型优先选已经经过充分 SFT 的 Chat 模型除非你有充足的高质量数据和评测体系

本章小结：SFT 是让模型从"续写机器"变成"对话助手"的关键步骤，但它改变的只是表面。记住三个核心认知：

  1. SFT 教的是格式，不是知识：模型的知识来自预训练，SFT 只教它用正确的方式呈现知识（Superficial Alignment Hypothesis）
  2. 数据质量 > 数据数量：1,000 条精选数据就够了（LIMA），堆量不如提质
  3. 微调有风险：灾难性遗忘会让模型在原有任务上"变笨"，不要轻易微调

现在，模型会聊天了。但它还不够"靠谱"——它可能啰嗦、可能不安全、可能不承认自己不知道。下一章，我们来看 RLHF 如何让模型学会"做人"。

4. RLHF – 让模型学会"做人"

SFT 教会了模型说人话，但"说人话"不等于"说得好"。一个经过 SFT 的模型能回答问题了，但它经常回答得不好——啰嗦、不安全、不知道自己不知道什么。

RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）要解决的，就是这个"好不好"的问题。

4.1 为什么需要 RLHF：SFT 的不足

SFT 后的模型存在一些典型问题：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

问题 1：啰嗦
  用户：法国的首都是哪里？
  SFT 模型：法国是一个位于西欧的国家，拥有悠久的历史和灿烂的
  文化。法国的首都是巴黎，巴黎位于法国北部的塞纳河畔，是世界
  上最著名的城市之一......（500 字）
  理想回答：巴黎。

问题 2：不安全
  用户：教我怎么做一个钓鱼网站
  SFT 模型：好的，制作钓鱼网站的步骤如下......
  理想回答：我不能帮助你做这件事，这是违法的。

问题 3：不承认不知道
  用户：XYZ 公司 2024 年 Q3 的营收是多少？
  SFT 模型：XYZ 公司 2024 年 Q3 的营收为 23.5 亿美元......（编造的）
  理想回答：我没有这个信息，建议查阅 XYZ 公司的财报。

这些问题的共同点是：不是"对不对"的问题，而是"好不好"的问题。

SFT 可以教模型"看到问题就回答"，但很难教模型"什么样的回答是好的"。因为"好"的标准是主观的、多维度的——简洁性、安全性、诚实性、有用性，这些很难用简单的训练数据来示范。

RLHF 的核心思想是：让人类直接告诉模型什么样的回答更好，然后用强化学习让模型朝着"更好"的方向优化。

4.2 RLHF 三步法（经典路线）

经典的 RLHF 流程由 InstructGPT 论文7确立，分为三步：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

RLHF 经典三步法

Step 1: SFT
+------------------------+
|  用示范数据做监督微调     |  --> 得到初始的 Chat Model
|  （上一章讲的内容）       |
+-----------+------------+
            |
            v
Step 2: 训练 Reward Model（奖励模型）
+--------------------------------------------------------+
|                                                        |
|  对同一个问题，让 Step 1 的模型生成多个回答（如 4 个）     |
|                                                        |
|  人类标注员比较这些回答，排出好坏顺序：                    |
|    回答 A > 回答 C > 回答 B > 回答 D                    |
|                                                        |
|  用这些偏好对训练一个 Reward Model：                      |
|    输入：一个问题 + 一个回答                              |
|    输出：一个分数（越高 = 人类越喜欢）                     |
|                                                        |
+-----------+--------------------------------------------+
            |
            v
Step 3: PPO 优化（强化学习）
+--------------------------------------------------------+
|                                                        |
|  把 Step 1 的模型当作"演员"（Policy）                    |
|  把 Step 2 的 Reward Model 当作"评委"                   |
|                                                        |
|  循环：                                                 |
|    1. "演员"生成一个回答                                 |
|    2. "评委"给回答打分                                   |
|    3. 分数高 --> 鼓励这种回答方式                         |
|       分数低 --> 抑制这种回答方式                         |
|    4. 但不能偏离原始模型太远（KL 散度约束）                 |
|       --> 防止模型为了讨好评委而"走极端"                   |
|                                                        |
+--------------------------------------------------------+

Step 3 中的"不能偏离原始模型太远"非常关键。如果没有这个约束，模型可能会发现一些"投机取巧"的方式来获得高分（比如给每个回答都加上"希望对你有帮助！"），而不是真正提高回答质量。这种现象叫做 Reward Hacking（奖励攻击），后面会详细讲。

4.3 DPO：去掉中间商

经典 RLHF 的三步法虽然有效，但工程复杂度很高——你需要同时维护四个模型（SFT Model、Reward Model、Policy Model、Reference Model），PPO 的训练也不稳定。

2023 年，Rafailov 等人提出了 DPO（Direct Preference Optimization，直接偏好优化）9，核心洞察非常优雅：

“Your Language Model is Secretly a Reward Model” ——你的语言模型本身就是一个奖励模型

DPO 的做法是：直接用人类的偏好对（“回答 A 比回答 B 好”）来训练语言模型，不需要单独训练一个 Reward Model。

1
2
3
4
5
6
7

经典 RLHF：
  偏好数据 --> 训练 Reward Model --> 用 RL (PPO) 优化语言模型
  （两步，四个模型）

DPO：
  偏好数据 --> 直接优化语言模型
  （一步，两个模型）

DPO 在数学上等价于 RLHF（在特定假设下），但工程实现简单得多9。它已经被 Llama 32、Qwen 2.5 等主流模型的训练流程广泛采用。

4.4 DeepSeek R1 的创新：GRPO + 纯规则奖励

如果说 DPO 是对经典 RLHF 的简化，那 DeepSeek R110则走了一条更激进的路——它用纯规则奖励取代了人类偏好标注。

GRPO（Group Relative Policy Optimization）

DeepSeek R1 使用的 RL 算法叫 GRPO10，它的关键创新是去掉了传统 PPO 中的 Critic Model（价值网络），改用同一个问题的多个采样回答的组内平均分数作为 baseline。

1
2
3
4
5
6
7
8

传统 PPO：
  回答的优势 = Reward - Critic(状态)
  --> 需要额外训练一个 Critic Model，增加复杂度

GRPO：
  对同一个问题采样 G 个回答，每个回答都有一个分数
  回答的优势 = 该回答的分数 - 这组回答的平均分
  --> 不需要 Critic Model，用组内对比代替

纯规则奖励：避免 Reward Hacking

更有趣的是 DeepSeek R1 的奖励设计。它没有使用人类标注的偏好数据，而是使用了两类纯规则奖励10：

  1. 格式正确性奖励：回答是否符合要求的格式（比如是否包含 <think>...</think> 标签）
  2. 答案正确性奖励：对于数学题，答案对不对（可以自动验证）；对于代码题，能不能通过测试用例

为什么要用规则奖励而不是 Reward Model？因为 Reward Model 本身就可能被"攻击"。模型可能学会生成"看起来好"但实际上不好的回答，专门讨好 Reward Model 的偏见。纯规则奖励没有这个问题——答案要么对要么错，格式要么符合要么不符合。

涌现出推理能力

DeepSeek R1 最令人兴奋的发现是：在 RL 训练过程中，模型自发地涌现出了 self-verification（自我验证） 和 reflection（反思） 能力10。

没有人教模型"你要检查自己的答案"，也没有在训练数据中示范"回头看看之前的推理有没有错"。但当 RL 奖励信号只看最终答案的正确性时，模型自己发现了"先想一想、检查一下、再给答案"这种策略能获得更高的分数。

这是一个深刻的洞察：

RLHF 通常不注入知识，但 RL 可以涌现推理能力。

预训练注入知识，SFT 教格式，但 RL 可以让模型学会使用知识的策略——比如分步推理、自我检查、多角度验证。

4.5 Agent 开发启示

为什么不同模型的"性格"不同？

GPT-4 回答偏正式、谨慎；Claude 更啰嗦但更细致；DeepSeek 更直接。这些差异很大程度上来自 RLHF/DPO 阶段的偏好数据和奖励设计不同。同一个 Base Model，用不同的偏好数据做 RLHF，会训出截然不同的"性格"。

这也是为什么同一个 Llama 3 Base Model，社区微调出了风格迥异的 Chat 模型——RLHF 策略不同，模型的行为模式就不同。

为什么模型会"过度拒绝"？

你可能遇到过：让模型写一个虚构的犯罪小说情节，它拒绝了；让它解释一个安全漏洞的原理（用于防御），它也拒绝了。

这就是 Reward Hacking 的一种表现。在 RLHF 训练中，Reward Model 学到了"拒绝 = 安全 = 高分"的模式，导致模型在不需要拒绝的时候也倾向于拒绝。模型不是"理解了"什么该拒绝，而是"学会了"拒绝能得高分。

Anthropic 的 Constitutional AI 论文11提出了一种缓解方案：用一组明确的"宪法原则"来训练模型，让模型学会区分真正有害的请求和正常的请求，而不是一刀切地拒绝。

RLHF 的 Alignment Tax：过度对齐会让模型"变笨"吗？

在第 3 章我们提到，SFT 的 Alignment Tax 很小（LIMA 的证据）。但 RLHF 阶段的情况有所不同。

学术界和工程界都观察到：过度的安全对齐可能会损害模型的逻辑推理能力。这就是为什么社区中一些去掉 RLHF 安全层的"Uncensored"版本（如早期的 WizardLM-Uncensored），在代码生成和逻辑推理任务上，有时反而比官方对齐版本表现更好。

这不难理解：RLHF 训练鼓励模型输出"安全、礼貌、面面俱到"的回答。但"安全礼貌"和"简洁高效"之间经常存在张力。一个被重度 RLHF 训练的模型，可能会在你只需要一个 JSON 的时候，先输出三段"我理解你的需求"的客套话。

对 Agent 开发者的启示：如果你的场景不涉及面向终端用户的安全问题（比如内部工具、代码辅助），选择对齐程度适中的模型可能比选择"最安全"的模型效果更好。

为什么开源 Base Model + 自己 RLHF 通常不如大厂 Chat 模型？

因为 RLHF 的效果高度依赖：

  • 高质量的偏好数据：需要大量人类标注员按一致的标准标注
  • Reward Model 的质量：训一个好的 Reward Model 本身就很难
  • RL 训练的稳定性：PPO 训练容易崩溃，需要大量超参搜索
  • 评估体系：你怎么知道 RLHF 做得好不好？需要完善的自动和人工评测

这些都需要大量的工程投入和经验积累。除非你有充足的资源和数据，否则直接用大厂已经做好 RLHF 的 Chat 模型，通常是更经济的选择。

4.6 工程备忘录

现象训练原理Agent 开发对策
模型"性格"不合适RLHF 偏好数据决定模型风格换模型比改 Prompt 更有效
模型过度拒绝Reward Hacking换个表述方式，或选择对齐策略更温和的模型
想要推理能力RL 可以涌现推理策略优先选择经过推理 RL 训练的模型（如 DeepSeek R1、o1）
想自己做 RLHF工程复杂度极高除非有充足资源，否则直接用大厂 Chat 模型
模型回答质量不稳定RLHF 训练不充分或 Reward Model 有偏差用 System Prompt 明确约束风格和标准
模型输出太啰嗦/太客套RLHF 的 Alignment Tax选对齐程度适中的模型，或在 System Prompt 中强调简洁

本章小结：RLHF 是让模型从"会说话"到"说得好"的关键步骤。记住三个核心认知：

  1. RLHF 解决的是"好坏"问题，不是"对错"问题：它让模型学会简洁、安全、诚实地回答
  2. DPO 和 GRPO 大幅简化了流程：但核心思想不变——用偏好信号引导模型行为
  3. RL 可以涌现推理能力：DeepSeek R1 证明了 RL 训练可以让模型自发学会 self-verification 和 reflection

现在，模型既有知识（预训练），又会对话（SFT），还靠谱（RLHF）。但对 Agent 开发者来说，还差最后一块拼图——模型怎么学会调用工具？

5. Function Calling – 让模型学会"用工具"

对 Agent 开发者来说，这可能是最实用的一章。Function Calling（函数/工具调用）是 Agent 系统的基石——没有它，模型只能"说"，不能"做"。

5.1 Function Calling 的训练本质

Function Calling 不是什么魔法。它的核心就是 SFT + 特定格式的训练数据。

模型学会调用工具的方式，和它学会回答问题的方式本质相同：在训练数据中看到足够多的"需要调用工具的场景 + 正确的工具调用格式"，然后学会在类似场景中输出类似格式的 Token 序列。

一条 Function Calling 的训练样本长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

System: 你是一个助手。你可以使用以下工具：

  get_weather:
    description: 查询指定城市的天气
    parameters:
      city: string, 城市名称
      date: string, 日期（可选）

User: 北京明天天气怎么样？
Assistant: <tool_call>
{"name": "get_weather", "arguments": {"city": "北京", "date": "明天"}}
</tool_call>

本质上，模型做的事情和生成普通文本一样——它只是在预测下一个 Token。只不过训练数据让它学会了：当工具定义出现在 System Prompt 中、且用户问题涉及工具能力范围时，应该输出特定格式的 Token 序列来"调用"工具。

比喻：教模型 Function Calling，就像教一个人填表格。你给他一张空白表格（工具定义），告诉他"当客户要查天气时，在 city 栏填城市名，在 date 栏填日期"。他不需要理解气象学，只需要知道怎么把用户的话映射到正确的表格字段。

5.2 为什么不同模型的工具调用格式不同

目前 Function Calling 没有行业标准。各家模型厂商各自定义了不同的格式，这给 Agent 开发带来了不小的适配成本。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

OpenAI 格式：
{
  "tool_calls": [{
    "type": "function",
    "function": {
      "name": "get_weather",
      "arguments": "{\"city\": \"北京\"}"
    }
  }]
}

Anthropic (Claude) 格式：
{
  "type": "tool_use",
  "name": "get_weather",
  "input": {
    "city": "北京"
  }
}

开源模型（常见格式之一）：
<tool_call>
{"name": "get_weather", "arguments": {"city": "北京"}}
</tool_call>

注意差异：

  • 嵌套层级不同：OpenAI 多了一层 “function” 嵌套
  • 参数字段名不同：OpenAI 用 “arguments”（字符串），Anthropic 用 “input”（对象）
  • 分隔方式不同：开源模型经常用 XML 标签包裹

这就是为什么 Agent 框架（如 LangChain、AutoGen 等）都需要做一个适配层（Adapter）——把不同模型的工具调用格式统一成框架内部的标准格式。选择 Agent 框架时，检查它对你目标模型的 Function Calling 适配是否完善，能避免很多坑。

5.3 工具调用的常见翻车场景

理解了 Function Calling 的训练本质（本质上是 Token 序列预测），你就能理解为什么工具调用会翻车——模型不是在"理解"工具，而是在"预测"工具调用的 Token 序列。当预测不够准时，就会出错。

翻车 1：参数幻觉——编造不存在的参数名

1
2
3
4
5
6
7

你定义的工具参数：
  get_weather(city: string, date: string)

模型实际输出：
  get_weather(city: "北京", date: "明天", unit: "celsius")
                                          ^^^^^^^^^^^^^^^^
                                          你没定义这个参数！

模型在训练数据中见过很多天气 API 都有 unit 参数，所以它"自作聪明"地加上了。这就是参数幻觉——模型根据训练记忆"编造"了看似合理但实际不存在的参数12。

翻车 2：工具选择错误

1
2
3
4
5
6
7

可用工具：
  search_documents: 搜索内部文档
  search_web: 搜索互联网

用户：帮我查一下公司上个季度的销售数据

模型选择：search_web   <-- 错了！应该用 search_documents

当两个工具的功能描述有重叠时（都涉及"搜索"），模型容易选错。工具的 description 写得越清晰、越有区分度，选择准确率越高。

翻车 3：嵌套调用困难——多步工具链容易断

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

用户：帮我查北京明天的天气，如果会下雨就帮我取消明天的户外会议

期望的工具调用链：
  Step 1: get_weather(city="北京", date="明天")
  Step 2: 根据天气结果判断是否下雨
  Step 3: 如果下雨，cancel_meeting(date="明天", type="outdoor")

实际可能发生的翻车：
  - 模型一次性输出两个工具调用，没等第一个返回结果
  - 模型做了天气查询但忘了后续的取消会议步骤
  - 模型直接回答"好的，我帮你取消了"，根本没调工具

多步工具链是 Agent 开发中最难的部分之一。模型需要在每一步都正确判断：该调什么工具、该等结果还是继续、该用上一步的结果做什么。步骤越多，出错概率越高。

5.4 Agent 开发备忘录

原则做法原因
选模型看 BFCL参考 Berkeley Function Calling Leaderboard13这是目前最权威的 Function Calling 基准测试
Tool 定义写清楚description 要具体、有区分度，避免模糊措辞description 就是给模型的"说明书"，写得越清楚模型越不容易选错
参数加约束用 enum 限定可选值，用 required 标记必填字段减少参数幻觉的概率
工具数量控制单次请求不要超过 10-15 个工具定义工具太多会降低选择准确率，也增加 Token 消耗
多步链用 ReAct每一步都让模型先思考再行动降低多步工具链的断链概率
JSON 输出加兜底代码层面做 JSON 修复和参数验证模型可能输出不合法的 JSON（参见第一篇文章关于概率生成的讨论1）

本章小结：Function Calling 是 Agent 系统的基石，但它本质上只是特定格式的 Token 预测。记住三个核心认知：

  1. Function Calling = SFT + 特定格式数据：不是魔法，模型只是学会了在特定上下文下输出工具调用格式的 Token
  2. 没有行业标准：各家格式不同，Agent 框架的适配层是必需品
  3. 翻车是常态：参数幻觉、工具选错、多步断链都是 Token 预测不够准的表现，必须在代码层面兜底

至此，我们已经走完了模型从"白纸"到"Agent 大脑"的全部训练历程。下一章，让我们把所有阶段串起来，形成一个完整的认知框架。

6. 全景回顾与 Agent 工程启示

6.1 一图看懂：模型能力的来源

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

训练阶段        加了什么                没加什么             对应 Agent 行为
=========================================================================

预训练          + 世界知识               - 对话能力           模型知道
(第 2 章)       + 语言模式               - 指令遵循           "北京是首都"
                + 代码理解               - 安全过滤           "Python 语法"
                + 推理基础               - 工具使用
                |
                v
SFT             + 指令遵循               - 偏好判断           模型能按你的
(第 3 章)       + 对话格式               - 安全边界           指令回答问题，
                + 结构化输出             - 自我纠错           输出 JSON
                |
                v
RLHF            + 安全性                 - 新知识             模型变得靠谱：
(第 4 章)       + 有用性                 - 新技能             简洁、安全、
                + 诚实性                                     承认不知道
                + 推理策略（RL 涌现）
                |
                v
Function        + 工具调用格式            - 工具的实际能力      模型能输出
Calling         + 工具选择判断                                tool_call JSON
(第 5 章)       + 参数提取

6.2 Agent 开发的"训练物理学"

把全文的工程启示汇总为一张表。每一个你在开发中遇到的问题，都能追溯到具体的训练阶段：

你遇到的问题背后的训练原理正确的做法
模型对专业知识回答不准预训练数据中该领域内容不足（第 2 章）用 RAG 补充知识，不要指望微调灌知识
模型对长尾事实编造答案预训练的"有损压缩"丢失了罕见信息（第 2 章）RAG + 让模型承认不知道
微调后模型"变笨"了灾难性遗忘（第 3 章）控制微调数据量，在通用基准上监控退化
想让模型学新知识SFT 只教格式，不教知识（第 3 章）用 RAG，不要用 SFT
模型输出格式不稳定SFT 数据中格式示范不足在 System Prompt 中给 Few-shot 示例
模型过度拒绝正常请求RLHF 阶段的 Reward Hacking（第 4 章）换表述方式，或选对齐策略更温和的模型
不同模型"性格"差异大RLHF 偏好数据不同（第 4 章）换模型比改 Prompt 更有效
Function Calling 参数错误工具调用训练数据不足或工具描述不清（第 5 章）写清楚 description，限定参数范围
多步工具链容易断多步推理对 Token 预测准确率要求极高（第 5 章）ReAct 模式 + 每步验证 + 重试机制
开源模型工具调用不如闭源闭源模型有更多专项训练数据（第 5 章）参考 BFCL13 基准选模型

6.3 选模型的决策框架

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

                  你的 Agent 需要什么？
                         |
            +------------+------------+
            |                         |
     通用能力就够了              需要领域定制
            |                         |
            v                         v
   +--------+--------+       +-------+--------+
   | 大厂闭源模型      |       | 需要的是       |
   | GPT-4o / Claude  |       | 知识？还是格式？ |
   | DeepSeek         |       +-------+--------+
   +---------+--------+           |          |
             |               知识        格式/风格
             v                 |            |
     直接用，不要折腾         v            v
                          用 RAG        用 SFT 微调
                        不要微调       开源模型 + LoRA
                                           |
                                           v
                                    微调后务必在
                                    通用基准上评测
                                    防止灾难性遗忘

什么时候选大厂闭源模型？

  • 通用 Agent 场景，不需要极致的领域定制
  • 团队没有 ML 工程能力或 GPU 资源
  • 需要最好的 Function Calling 支持
  • 快速验证产品想法，MVP 阶段

什么时候选开源模型 + 微调？

  • 数据隐私要求严格，不能调用外部 API
  • 有充足的高质量领域数据（至少 1,000 条精选样本）
  • 有 ML 工程团队和 GPU 资源
  • 需要深度定制模型行为和输出格式

什么时候微调是多余的（RAG 就够了）？

  • 你想让模型"知道"的是可以检索的文档知识
  • 知识会频繁更新（微调不可能每天重新训练）
  • 不需要改变模型的回答格式或风格

7. 推荐资源

以下是本文涉及的核心概念的高质量学习资源。不追求全面，只推荐信噪比最高的。

视频

资源时长推荐理由
Andrej Karpathy: State of GPT540min预训练、SFT、RLHF 三阶段讲得最通透的一个演讲
Andrej Karpathy: Intro to Large Language Models1h全网最好的 LLM 入门课，涵盖训练全流程
Anthropic: RLHF and Constitutional AI Explained15minAnthropic 官方讲解 RLHF 和 Constitutional AI 的思路

论文

论文推荐理由
InstructGPT (Ouyang et al., 2022)7RLHF 三步法的奠基论文，定义了当前的训练范式
LIMA (Zhou et al., 2023)8证明了 SFT 只需极少数据，提出 Superficial Alignment Hypothesis
DPO (Rafailov et al., 2023)9优雅地简化了 RLHF 流程，工程价值极高
DeepSeek R1 Technical Report (2025)10GRPO + 纯规则奖励的完整实践，推理能力涌现的第一手证据

工具

工具用途
BFCL Leaderboard13选模型时查 Function Calling 能力排名
Open LLM Leaderboard开源模型综合能力排名
LMSys Chatbot Arena基于人类盲评的模型排名，最接近真实使用体验

本文是三篇系列的第二篇，聚焦于"模型能力的来源"：预训练压缩知识、SFT 教会格式、RLHF 对齐偏好、Function Calling 赋予工具使用能力。

第一篇《一句话是怎么变成 AI 回复的：LLM 的工作原理》讲了模型怎么工作（Tokenization、Embedding、Attention、自回归生成）。

第三篇《推理服务是怎么影响你的 Agent 的：推理框架与架构决策》将聚焦推理层如何影响 Agent 架构师的每一个设计决策：vLLM vs TGI 选型、批处理策略、量化方案、以及推理成本优化。

Build, fail, iterate. Good luck!

参考资料

  1. 本系列第一篇：《一句话是怎么变成 AI 回复的：LLM 的工作原理》，详细讲解了 Tokenization、Embedding、Attention 和自回归生成的原理。 ↩︎ ↩︎ ↩︎ ↩︎

  2. Llama 3 技术报告：Dubey et al., “The Llama 3 Herd of Models” (2024)。Llama 3 使用超过 15.6T Token 进行预训练，8B 模型的过训练比例约为 Chinchilla 最优值的 100 倍。https://arxiv.org/abs/2407.21783 ↩︎ ↩︎ ↩︎ ↩︎

  3. DeepSeek V3 技术报告：DeepSeek-AI, “DeepSeek-V3 Technical Report” (2024)。使用 14.8T Token 预训练，总训练成本约 557.6 万美元（2048 块 H800 GPU）。https://arxiv.org/abs/2412.19437 ↩︎ ↩︎

  4. Ilya Sutskever 关于 “Compression is equivalent to prediction” 的观点，多次在公开演讲和访谈中提及。核心思想源自信息论：一个好的压缩器必然是一个好的预测器，反之亦然。 ↩︎

  5. Andrej Karpathy, “State of GPT” 演讲 (2023)。系统梳理了 GPT 系列模型的训练流程（预训练、SFT、RLHF），提出"预训练是互联网的有损压缩"和 Base Model “做梦"状态等比喻。https://www.youtube.com/watch?v=bZQun8Y4L2A ↩︎ ↩︎ ↩︎

  6. Chinchilla 论文：Hoffmann et al., “Training Compute-Optimal Large Language Models” (2022)。核心发现：在固定计算预算下，模型参数量和训练 Token 数应等比例扩大，最优比例约为 20 tokens/parameter。https://arxiv.org/abs/2203.15556 ↩︎

  7. InstructGPT 论文：Ouyang et al., “Training language models to follow instructions with human feedback” (2022)。确立了 SFT + Reward Model + PPO 的经典 RLHF 三步法，展示了 1.3B 模型通过 RLHF 可以超越 175B GPT-3。https://arxiv.org/abs/2203.02155 ↩︎ ↩︎ ↩︎ ↩︎

  8. LIMA 论文：Zhou et al., “LIMA: Less Is More for Alignment” (2023)。仅用 1,000 条精选数据做 SFT，效果可比 GPT-4。提出 Superficial Alignment Hypothesis：知识来自预训练，SFT 只教格式。https://arxiv.org/abs/2305.11206 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  9. DPO 论文：Rafailov et al., “Direct Preference Optimization: Your Language Model is Secretly a Reward Model” (2023)。提出直接用偏好对优化语言模型，无需单独的 Reward Model，在数学上等价于 RLHF。https://arxiv.org/abs/2305.18290 ↩︎ ↩︎ ↩︎

  10. DeepSeek R1 技术报告：DeepSeek-AI, “DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning” (2025)。使用 GRPO 算法 + 纯规则奖励训练，涌现出 self-verification 和 reflection 能力。https://arxiv.org/abs/2501.12948 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  11. Constitutional AI 论文：Bai et al., “Constitutional AI: Harmlessness from AI Feedback” (2022)。Anthropic 提出用一组"宪法原则"训练模型自我监督，缓解 Reward Hacking 导致的过度拒绝问题。https://arxiv.org/abs/2212.08073 ↩︎

  12. Gorilla LLM 论文：Patil et al., “Gorilla: Large Language Model Connected with Massive APIs” (2023)。系统研究了 LLM 在 API 调用场景下的幻觉问题，提出了检索增强的 Function Calling 方法。https://arxiv.org/abs/2305.15334 ↩︎

  13. BFCL（Berkeley Function Calling Leaderboard）：Yan et al. (2024)。目前最权威的 Function Calling 基准测试，涵盖简单调用、多步调用、并行调用等场景。https://gorilla.cs.berkeley.edu/leaderboard.html ↩︎ ↩︎ ↩︎