05：预训练、微调与对齐：大模型如何从续写机器变成助手

前几篇文章里，我们一直从一个底层机制出发：

给定上下文，预测下一个 token。

这个机制足够简单，也足够强大。

它解释了模型如何读入 token，如何用 embedding 表示语言，如何通过 Transformer 建立上下文关系，也解释了为什么预测语言会让模型压缩世界结构。

但到这里会出现一个新的问题：

如果模型只是学会续写文本，
它为什么不会漫无目的地，围绕着启始文本，像编小说或水帖子那样持续不断地写下去？
它为什么会停下来回答「我」的问题？

比如你输入：

帮我解释一下什么是梯度下降。

一个只会续写的模型，理论上可以接着生成很多不同东西：

帮我解释一下什么是梯度下降。这是很多初学者都会问的问题……
帮我解释一下什么是梯度下降。本文将从数学定义开始……
帮我解释一下什么是梯度下降。网友 A：我也想知道……
帮我解释一下什么是梯度下降。抱歉，我不太清楚……

这些都像是某种文本续写。

但我们真正期待的是：

梯度下降是一种让模型参数逐步变好的优化方法……

也就是说，现代助手不只是会预测下一个 token。它还学会了一个更具体的行为模式：

当上下文表现为用户指令时，应该生成一个有帮助、可理解、符合边界的回应。

这个行为不是凭空出现的。

它来自三个层次：

预训练：学会语言、知识和世界结构
监督微调：学会把「用户指令」接成「理想回答」
偏好对齐：学会哪种回答更有帮助、更诚实、更安全

理解这三个层次，就能理解为什么大模型不是一开始就是 ChatGPT 这样的助手。

一、预训练：先让模型成为一台强大的续写机器

预训练是大模型能力的底座。

它做的事情看起来很朴素：

拿海量文本；
把文本切成 token；
让模型在每个位置只能看到前文；
用当前位置的输出预测下一个 token；
把预测分布和真实下一个 token 对比；
预测错了就调整参数；
重复很多很多次。

这些文本可能来自网页、书籍、代码、论文、问答、教程、新闻、论坛、对话、说明文档和各种结构化内容。

模型在这个阶段并不知道自己未来要当「助手」。它只是在学习：

什么样的文本会出现在什么样的上下文之后？
哪些词和哪些词有关？
哪些事实、格式、推理步骤、代码结构经常共同出现？
人类通常如何描述问题、解释概念、写程序、争论观点？

这就是为什么预训练模型会有很强的基础能力。

它见过大量数学推导，所以能压缩数学结构；见过大量代码，所以能压缩程序模式；见过大量问答，所以知道很多问题和回答的关联；见过大量文章，所以能模仿各种文体。

但要注意：预训练只告诉模型「什么文本在统计上可能接下来出现」，并没有明确告诉它：

用户问问题时，你应该认真回答；
不知道时不要编；
危险请求应该拒绝；
回答要结构清晰；
不要突然切换成论坛评论区；
不要把用户问题当成文章标题继续写。

所以，预训练模型更像一个通用语言引擎，而不是一个可靠助手。

它拥有很多潜在能力，但这些能力还没有被整理成稳定的产品行为。

可以把它想象成一个读过很多书、代码和聊天记录的人，但还没有接受过「如何做助理」的训练。

他可能懂很多东西，却不一定知道什么时候该简洁回答、什么时候该追问、什么时候该拒绝、什么时候该给步骤。

二、监督微调：把「续写文本」改造成「回应指令」

接下来进入监督微调，通常也叫 SFT，Supervised Fine-Tuning。

它的核心很直接：

给模型看很多「用户指令 -> 理想回答」的样本。

比如：

用户：请用三句话解释什么是 embedding。
助手：embedding 是把离散符号转换成向量的方法……

用户：把下面这段话改得更简洁。
助手：……

用户：请帮我写一个 Python 函数，判断字符串是否为回文。
助手：……

这些样本不是普通网页续写，而是专门构造成对话式任务。

它们告诉模型：

当你看到一个请求时，要把它当成任务；
当用户要求格式时，要尽量遵守格式；
当问题很宽泛时，可以先组织结构；
当信息不足时，可以说明假设或追问；
当用户要代码时，可以给代码和解释；
当请求不合适时，可以拒绝或转向安全替代方案。

从第一性原理看，SFT 并没有改变「预测下一个 token」这个训练目标。

它改变的是训练数据分布。

预训练时，模型看到的是整个互联网式的混合文本分布；SFT 时，模型看到的是高质量的指令-回答分布。

于是模型学到一个新的条件模式：

如果上下文像一条用户指令，
那么后面更应该接一个助手式回答。

这一步非常关键。

没有 SFT，模型可能知道很多知识，却不知道应该以「助手」的身份把知识组织给你。

有了 SFT，模型才开始从「什么都能续写」转向「优先按用户请求完成任务」。

但 SFT 也有边界。

因为很多问题并不只有一个标准答案。

比如用户问：

帮我改一下这段产品文案。

可能有很多种回答：

更简洁的版本；
更有销售感的版本；
更克制专业的版本；
先指出问题再给改写；
直接给 3 个备选方案；
先追问目标用户和投放场景。

这些回答都可能是对的，但好坏不一样。

SFT 可以告诉模型「像这样回答」，却很难细致地告诉模型「这些可行回答里，哪个更好」。

所以，还需要下一层：偏好对齐。

三、偏好对齐：让模型知道什么回答更值得被选择

偏好对齐要解决的问题，不是「能不能回答」，而是「应该倾向于哪种回答」。

同一个问题，模型可以生成很多候选答案：

一个很长但啰嗦的答案；
一个很短但遗漏关键条件的答案；
一个语气很好但事实不准的答案；
一个结构清楚、承认不确定性、能解决问题的答案；
一个看似热情但越界的答案。

人类用户往往并不是只要「有答案」，而是希望答案：

有帮助；
诚实；
不乱编；
符合上下文；
尊重约束；
必要时提醒风险；
在不确定时说清楚不确定。

这就是对齐要做的事。

常见做法包括 RLHF、RLAIF、DPO 等。它们具体算法不同，但第一性原理相似：

让模型生成多个候选回答；
让人类、AI 评审器或偏好数据判断哪个更好；
把这种偏好信号转化成训练信号；
让模型以后更倾向于生成被偏好的回答。

你可以把它理解成：模型本来已经会很多种说法，对齐过程不是从零教它语言，而是在调整输出分布。

提高：有帮助、清晰、可靠、符合边界的回答概率
降低：胡编、迎合、危险、啰嗦、跑题的回答概率

这和人类学习有点像。

一个人会说话，不代表他会做客服、老师、医生助理或产品顾问。不同角色需要知道哪些说法更合适，哪些说法虽然能说但不该说。

偏好对齐就是在训练这种「应该怎么回答」的倾向。

当然，对齐不是魔法。

它可能带来新的问题：

过度拒绝：本来可以回答的问题也拒绝；
过度迎合：用户说什么都顺着说；
风格变平：回答安全但缺少锋芒；
奖励投机：模型学会看起来符合偏好，但实质没做好；
能力折损：某些微妙能力在对齐后变弱。

所以，对齐不是简单地「越多越好」，而是一个持续权衡。

好的对齐应该让模型更可靠，而不是只让它更客气。

四、助手不是一种知识，而是一种行为分布

理解了预训练、SFT 和对齐后，我们就能更准确地定义「助手」。

助手不是模型脑子里多了一个叫「助手人格」的小模块。

它更像是一种被训练和系统约束塑造出来的行为分布：

看到问题，更倾向于回答；
看到任务，更倾向于拆解；
看到缺失信息，更倾向于说明假设或追问；
看到危险请求，更倾向于拒绝并给安全替代方案；
看到格式要求，更倾向于遵守；
看到工具结果，更倾向于把结果整合成可读答案。

同样是 next-token prediction，为什么结果会不同？

因为上下文、训练数据和偏好信号改变了「下一个 token 应该长什么样」。

这也是为什么同一个底座模型，经过不同的后训练后，会变成不同风格的产品：

有的更像搜索助手；
有的更像代码搭档；
有的更像写作编辑；
有的更像客服机器人；
有的更像推理型研究助理。

底层机制仍然是预测 token，但预测分布被塑造成了不同的任务行为。

所以，我们不要把「助手感」误解成神秘能力。

它来自一连串很具体的工程选择：

训练什么语料；
保留什么能力；
写什么指令样本；
偏好什么回答；
拒绝什么请求；
系统提示词怎么写；
工具结果如何回填上下文；
产品界面如何引导用户表达任务。

这些都会改变模型在真实使用中的行为。

五、现代 AI 助手不是裸模型，而是一个系统

很多人在讨论大模型时，会把所有能力都归因于「模型本身」。

但实际产品里的 AI 助手，通常不是一个裸模型。

它是一个系统：

底座模型
+ 系统提示词
+ 开发者指令
+ 用户上下文
+ 检索结果
+ 工具调用
+ 安全策略
+ 记忆或偏好
+ 评估与反馈
= 产品里的助手行为

预训练、微调和对齐主要塑造模型本身；系统层则决定模型在每一次请求里拿到什么信息、遵守什么边界、能调用什么工具、如何把结果返回给用户。

比如，一个客服助手要可靠，不能只靠模型「记住」客服规则。

更合理的结构是：

模型理解用户问题；
RAG 找到最新政策和订单信息；
工具查询物流或退款状态；
安全策略约束隐私和权限；
模型把这些结果组织成自然语言；
用户反馈继续进入评估闭环。

这才是现代助手的真实形态。

模型是核心，但不是全部。

从这个角度看，很多产品问题就会变得更清楚。

如果模型答错事实，不一定应该微调，可能需要检索或工具。

如果模型格式不稳定，不一定需要换模型，可能需要更清晰的指令样本或输出约束。

如果模型不懂公司内部流程，可能不是模型太笨，而是上下文没有给到正确文档。

如果模型总是过度拒绝，问题可能出在安全策略、偏好数据或系统提示词。

六、常见误解

误解一：微调就是让模型变聪明。

不完全是。大多数时候，微调是在改变模型的行为分布，让它更适合某类任务或某种输出格式。它可以提升特定任务表现，但很难凭空创造预训练中完全没有的基础能力。

误解二：预训练模型已经什么都会，对齐只是给它加限制。

不对。对齐不只是限制，也是在把能力组织成可用行为。没有对齐，模型可能会更随意、更不稳定、更容易迎合错误前提。

误解三：prompt 足够好，就不需要微调。

prompt 是运行时的临时引导，微调是训练后的长期分布改变。少量、变化快、个性化的任务适合 prompt；高频、稳定、格式要求强的任务，可能更适合用微调或工作流固化。

误解四：助手的回答完全代表模型真实「想法」。

不对。回答是模型在当前上下文、系统指令、对齐策略和采样设置共同作用下生成的 token 序列。它更像系统行为，不是一个独立主体的内心独白。

误解五：对齐一定会让模型变弱。

也不一定。粗糙对齐可能带来能力折损，但好的对齐能让模型更可靠、更可控、更适合真实产品环境。关键在于偏好数据、评估体系和训练方法是否足够好。

七、这对产品和工程意味着什么

如果把大模型看成一个从预训练到对齐逐层塑造的系统，工程判断会更清楚。

1. 先判断问题发生在哪一层

不同问题，对应不同解法：

缺少通用能力：可能要换更强底座模型；
缺少领域知识：优先考虑 RAG、工具或领域数据；
不听格式：优化指令、示例、输出约束或 SFT；
风格不稳定：用偏好数据和评估集约束；
事实不可靠：接入检索、数据库或验证器；
任务链太长：引入工作流、工具调用或 Agent 框架。

不要把所有问题都用「换模型」解决，也不要把所有问题都用「写更长 prompt」解决。

2. 数据质量比数据数量更接近瓶颈

预训练阶段确实需要规模，但后训练阶段更看重质量。

一千条高质量、边界清楚、覆盖真实任务的指令样本，可能比十万条噪声样本更有价值。

偏好数据也是一样。

如果评审标准混乱，模型就会学到混乱偏好；如果评审只奖励表面礼貌，模型就可能变得圆滑但没用。

3. 评估要比较候选答案，而不是只看单次输出

对齐本质上是偏好选择，所以评估也应该多看比较。

两个答案哪个更有帮助？
哪个更少幻觉？
哪个更遵守用户约束？
哪个在边界场景下更稳？
哪个更知道什么时候该调用工具？

这比只看一次回答「像不像对」更接近真实产品质量。

4. 产品体验来自整条链路，不只来自模型参数

用户感受到的是最终助手，而不是某个训练阶段。

一个好用的 AI 产品，往往同时依赖：

强底座模型；
高质量后训练；
清晰系统提示词；
可靠知识接入；
可验证工具；
合理交互设计；
持续评估闭环。

这也是为什么同一个模型，放进不同产品里，体验可能差别很大。

八、总结：从续写机器到助手

现在我们可以用简单几句话总结本文：

预训练让模型学会语言和世界的结构；
监督微调让模型学会按用户请求来做不同回应；
偏好对齐让模型更倾向于有帮助、诚实、安全的回答；
系统层把模型接到上下文、工具、策略和反馈；
于是，一个续写系统被塑造成了助手。

如果再压缩成一句话：

预训练赋予模型能力，微调教模型接住用户请求，对齐让模型知道什么该说、什么不该说，系统工程把这些能力变成用户可用的助手体验。

这也解释了一个很重要的事实：

大模型产品的能力，不只来自「模型有多大」，还来自它如何被训练、如何被对齐、如何被放进系统里。

下一篇，我们会继续往下看：为什么当模型、数据和计算规模继续扩大时，能力边界会突然变化？这就是 Scaling Law 与涌现要讨论的问题。