AI-NEWS

Appearance

预训练 · SFT · RLHF ​

🎯 学习目标

  • 区分预训练、SFT（Supervised Fine-Tuning）与 RLHF 的目标与数据形态
  • 了解奖励模型、PPO、DPO 在通俗层面的作用
  • 知道应用工程师何时只需 API、何时考虑微调或 LoRA
  • 理解量化、KV Cache 等推理优化名词对延迟与成本的意义

引言 ​

你使用的 ChatGPT、DeepSeek、通义千问，并不是直接把互联网文本「灌进一个搜索框」。它们经历多阶段训练：先在无标注文本上学会语言规律（预训练），再用人工示范教它听指令（SFT），最后用人类偏好对齐「更有用、更安全」的行为（RLHF 或同类方法）。这就是为什么模型会拒答违法请求、会按 Markdown 格式回答、也会在不确定时显得「Politely vague」——这些都是训练与对齐的结果，不是 Prompt 魔法。

作为应用开发者，99% 的场景不需要自己训练基座模型，但你需要读懂产品文档里的 Instruct、Chat、Reasoning 版本差异，理解「为什么同一 family 有不同 checkpoint」，以及在什么情况下才值得做 SFT / LoRA 而不是加 RAG。本节用工程视角概览训练管线，并介绍 GPU、分布式训练、推理优化 在部署侧的含意。

章节正文 ​

第 1 步：预训练：基座模型如何「学会语言」 ​

预训练（Pre-training） 在大规模 无标注 文本（网页、书籍、代码等）上进行，目标通常是 next-token prediction：随机截取片段，让模型预测下一个 Token。损失函数是交叉熵——预测错则惩罚。算力消耗占整个训练过程的绝大部分，产出 Base Model（基座模型）。

Base 模型会续写，但不一定「听指令」。你问「写一首关于春天的诗」，它可能续写成「……的要求如下：」而不是直接写诗——因为它学的是「互联网上接下来会出现什么字」，不是「助手该如何回答用户」。

数据规模与算力：千亿参数模型需要数千 GPU·月级别的训练。一般企业购买 API 或开源权重即可，勿重复造轮子除非有战略级需求与预算。

开源代表：Llama、Qwen、DeepSeek-V3 Base；商用：各厂商未完全公开细节的 Base，再发布 Chat/Instruct 版本。

第 2 步：SFT：从「续写互联网」到「当助手」 ​

SFT（Supervised Fine-Tuning，监督微调） 使用人工标注的 （指令，理想回答） 对，教模型对话格式、任务遵循、基本安全边界。数据质量远比数量关键——几千条精心标注往往比百万条噪声更有效。

SFT 后的模型会：

  • 理解 System / User / Assistant 角色结构
  • 更倾向直接回答问题，而非无限制续写
  • 学会拒绝部分有害请求（仍不完美，需后续对齐与护栏）

与 Prompt 的关系：SFT 把「通用能力」烙进权重；Prompt 在推理时做 情境特化（「你是法务助手，只引用提供的条款」）。多数产品需求用 强 Instruct 模型 + 好 Prompt + RAG 即可，不必 SFT。

何时考虑 SFT / LoRA（Low-Rank Adaptation，低秩适配）：

  • 固定格式极严格且 Prompt 反复失败（如特定 JSON 方言、内部代码风格）
  • 领域术语密集且公开模型 consistently 误解
  • 有上千条高质量标注且愿意维护训练 pipeline

LoRA 只更新少量适配参数，比全量微调便宜，常于单卡或多卡即可完成 7B–70B 量级适配。

第 3 步：RLHF 与 DPO：对齐「人类偏好」 ​

RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习） 典型三步：

  1. 用 SFT 模型生成多个回答，人工排序（哪个更好）
  2. 训练 Reward Model（奖励模型） 预测人类偏好分数
  3. 用 PPO（Proximal Policy Optimization） 等强化学习算法调整 LLM，使高奖励回答更可能出现

效果：回答更 helpful、更 harmless、风格更一致；副作用：可能 over-refusal（过度拒答）、verbosity bias（话变多）、推理模型上的 「think longer」 行为。

DPO（Direct Preference Optimization） 等方法跳过显式 Reward Model，直接用偏好对优化策略，训练更稳定，被许多新模型采用。你无需实现 PPO，但应理解：「模型性格」来自对齐阶段，Eval 时要测拒答率与过度保守。

Reasoning Model（推理模型） 如 OpenAI o 系列、DeepSeek-R1，往往在对齐之外还有 长链推理 专项训练，适合数学、代码 debug，但 更慢、更贵——见 1.5 选型。

第 4 步：基础设施：训练与推理各需要什么 ​

训练侧

  • GPU + CUDA（或 ROCm 等）：矩阵运算加速
  • 分布式训练：数据并行（多卡同模型不同 batch）、模型并行（层切分到多卡）、流水线并行，支撑超大模型
  • 框架：PyTorch、JAX；大模型训练常用 DeepSpeed、FSDP 等

推理侧（与你更相关）

  • 量化（Quantization）：FP16/BF16 → INT8/INT4，减显存、提吞吐，略损精度
  • KV Cache：自回归生成时缓存已算过的 Key/Value，避免重复 prefill
  • Continuous Batching：动态组 batch，提高 GPU 利用率（vLLM 等）
  • 投机解码（Speculative Decoding）：小模型草稿 + 大模型验证，降延迟

本地 Ollama 开箱即用常已含量化权重；生产 vLLM / TGI 则暴露吞吐与并发指标。选 API 时这些优化由云厂商承担，你主要看 latency SLA 与单价。

第 5 步：应用工程师决策树：我是否需要训练？ ​

按顺序尝试，越靠前越优先：

  1. 换 Instruct 模型 / 调参数（temperature、JSON mode）
  2. Prompt 工程 + 少样本示例
  3. RAG 注入知识与引用
  4. 工具调用 把计算与查询外包给确定性系统
  5. Eval 驱动 的 Prompt 迭代与路由（小模型处理简单意图）
  6. LoRA / SFT（有数据、有评估、有维护能力）
  7. 自训基座（极少数团队）

维护成本：微调模型需 数据版本、Eval 回归、模型 registry、与基座升级同步。若业务规则频繁变，RAG 往往比反复微调更敏捷。

合规：训练数据版权、用户数据是否可用于微调，需法务评审；调用 API 时注意 数据留存策略（opt-out 训练、企业 VPC）。

动手练习 ​

  1. 解释给产品经理：为什么「同一个 DeepSeek，有 V3 也有 R1」——各适合什么任务？
  2. 列出你业务中三条「也许该 LoRA」与三条「绝对该 RAG 而非微调」的场景，并说明理由。
  3. 搜索一家模型厂商文档中的「数据用于训练」默认策略，写三条企业使用建议。
  4. 画训练阶段流程图：Pretrain → SFT → RLHF/DPO → 部署，每步标注输入数据类型与产出物名称。

常见问题 ​

Q：RLHF 和「安全过滤器」是一回事吗？

不完全是。RLHF 在权重里塑造整体偏好；上线还可叠加 Moderation API、关键词护栏、输出审计等工程层。多层组合才是企业常态。

Q：开源权重等于能商用吗？

取决于 License（Llama、Qwen、DeepSeek 等条款不同）。部署前读 License，并区分「研究用」与「商用」限制。

Q：量化后的本地模型值得上生产吗？

视任务而定。简单问答、草稿生成常可；高精度抽取、复杂推理需对比 Eval。同时评估运维、监控、扩容成本是否低于 API。

本节小结 ​

LLM 产品化路径是预训练获得语言能力，SFT 学会指令跟随，RLHF/DPO 对齐人类偏好。应用开发默认调用 Instruct 模型并用 RAG/Prompt 定制；微调是后手而非首选。推理侧的量化与 KV Cache 影响本地部署成本，云 API 则把优化封装在单价里。理解训练阶段，有助于解释模型拒答、风格与版本差异。