微调 · SFT / RLHF / DPO 与 LoRA

风格说明：本篇是 机制 + 操作混合——从 SFT 的数据工程到 RLHF/DPO 的数学推导，再到 LoRA/QLoRA 的显存账本和生产部署。覆盖"为什么要微调 → 怎么训 → 怎么对齐 → 怎么省显存 → 怎么上线"五段。Staff+ 面试必考：Fine-tune vs RAG 决策、DPO 公式推导、LoRA rank 选择。

前置阅读：01-Transformer与Attention.md（Transformer 参数结构 + Scaling Law）；../../ai-fundamentals/09-PyTorch与HF训练栈-架构师读码.md（Trainer / PEFT / 显存）；02-评估-Eval-Hallucination与质量度量.md（微调后如何评估）。
后续展开 → 03-部署-模型Serving-Caching与Cost.md（微调模型的推理部署）；03-多模态-Vision-Language与跨模态理解.md（VLM 微调）。

---

1. 微调的工程定位

1.1 一句话定义

微调（Fine-tuning）：在预训练 LLM 基础上，用 领域数据 继续训练，使模型掌握特定任务/风格/知识。本质是 把通用能力特化——从"什么都懂一点"到"某个方向懂得深"。

1.2 Fine-tune vs RAG vs Prompt Engineering 决策树

1.3 三者详细对比

维度	Prompt Engineering	RAG	Fine-tune
知识更新	手动改 prompt	实时（改文档）	重训模型（小时~天）
行为定制	有限	有限	强（风格/格式/推理模式）
成本	极低	中（向量库）	高（GPU 训练）
延迟	基线	+检索延迟	基线（可能更快：小模型替代大模型）
数据需求	0	文档库	100+ 标注样本
可解释性	中	高（引用来源）	低（黑盒）
典型场景	通用问答	企业知识库	风格定制/代码生成/垂直领域

1.4 微调的 5 大动机

动机	例子	不微调的后果
格式遵从	输出必须是 JSON Schema	Prompt 约束不稳定，5-10% 格式错误
风格统一	客服 bot 说"亲"不说"您好"	每次 prompt 塞风格指令，浪费 token
领域知识	医疗/法律/金融术语	幻觉率高，术语不准
推理增强	数学/代码/逻辑链	通用模型推理能力不足
成本优化	用 7B 微调替代 70B 通用	API 成本高 10x

1.5 微调全流程概览

---

2. SFT（Supervised Fine-Tuning）

2.1 SFT 的本质

SFT = 用 （instruction, response）对 继续训练 LLM，让模型学会"看到指令 → 生成期望的回复"。数学上就是最小化 next-token prediction loss，但 只在 response 部分计算 loss（instruction 部分 mask 掉）。

Loss = -Σ_{t ∈ response_tokens} log P(x_t | x_{<t}; θ)

2.2 数据格式

三大主流格式：

格式	模板	代表模型
Alpaca	### Instruction:\n{instruction}\n### Input:\n{input}\n### Response:\n{response}	LLaMA-1 微调
ChatML	<|im_start|>system\n{system}<|im_end|>\n<|im_start|>user\n{user}<|im_end|>\n<|im_start|>assistant\n{assistant}<|im_end|>	Qwen、GPT
Llama Chat	<s>[INST] <<SYS>>\n{system}\n<</SYS>>\n{user} [/INST] {response}</s>	Llama 2/3

关键原则：训练格式 = 推理格式。格式不一致是微调后效果差的 #1 原因。

2.3 数据质量 > 数据数量

实验	数据量	质量	效果
LIMA (2023)	1,000 条高质量	人工精标	接近 GPT-3.5
Alpaca	52,000 条	GPT-4 生成	不如 LIMA
某工业实践	100,000 条	自动爬取+过滤	不如 5,000 条人工标注

经验公式：

• 100 条：能教会格式和基础风格
• 1,000 条：覆盖主要场景
• 10,000 条：覆盖长尾 + 边缘 case
• 100,000+：持续预训练级别，需要领域语料

2.4 SFT 训练配置（实战模板）

# Axolotl / LLaMA-Factory 风格配置
model:
  base_model: meta-llama/Llama-3.1-8B-Instruct
  model_type: LlamaForCausalLM
  
dataset:
  path: ./data/sft_train.jsonl
  type: chat_template        # 使用模型原生 chat template
  field_instruction: "messages"
  
training:
  epochs: 3                   # 小数据集 3 epoch; 大数据集 1 epoch
  batch_size: 4
  gradient_accumulation: 8    # effective batch = 32
  learning_rate: 2e-5         # 全量微调 1e-5~5e-5
  lr_scheduler: cosine
  warmup_ratio: 0.03
  max_length: 4096
  bf16: true
  
  # LoRA 配置（如果用 LoRA）
  lora:
    r: 16
    alpha: 32                 # alpha = 2r 是常见选择
    dropout: 0.05
    target_modules: ["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"]

2.5 SFT 常见陷阱

陷阱	现象	修复
格式不一致	推理时输出乱码 / 不停止	确保 train = inference 模板
过拟合	训练 loss ↓ 但 eval 质量 ↓	减少 epoch / 加 LoRA dropout
灾难性遗忘	领域题好了，通用题崩了	混入 10-20% 通用数据
长度塌缩	模型只输出短回复	数据中保留长回复样本
重复退化	“是的是的是的是的”	调高 repetition_penalty / 检查数据重复

---

3. RLHF 深度解析

3.1 为什么需要对齐

SFT 训练的模型能"答题"，但不能保证：

• 有帮助（Helpful）：回答切题、有深度
• 无害（Harmless）：不输出暴力/偏见/违法内容
• 诚实（Honest）：不编造事实

对齐（Alignment）= 让 LLM 的输出符合人类偏好。RLHF 是第一个大规模成功的对齐方法（InstructGPT, 2022）。

3.2 RLHF 三阶段

3.3 Reward Model 训练

数据格式：给定 prompt x，两个回复 y_w（preferred）和 y_l（rejected），人类标注 y_w > y_l。

损失函数（Bradley-Terry model）：

L_RM = -E_{(x, y_w, y_l)} [log σ(r(x, y_w) - r(x, y_l))]

工程要点：

• RM 通常与 SFT 模型同架构（去掉 LM head，加 scalar head）
• 标注一致性（inter-annotator agreement）> 0.7 才有意义
• RM 大小 ≈ SFT 模型大小 才能捕捉足够的偏好信号
• 数据量：OpenAI 用 ~33k comparisons（InstructGPT），工业级需 50k+

3.4 PPO 算法细节

RLHF 的优化目标：

max_θ  E_{x~D, y~π_θ(·|x)} [r(x, y)] - β · KL(π_θ(·|x) || π_ref(·|x))

其中：

• r(x, y)：Reward Model 打分
• β：KL 惩罚系数（0.01~0.2），防止 reward hacking
• π_ref：参考策略（通常 = SFT 模型），防止模型"发疯"

PPO 更新公式：

L_PPO = -E_t [min(r_t(θ) · Â_t, clip(r_t(θ), 1-ε, 1+ε) · Â_t)]

其中:
  r_t(θ) = π_θ(a_t|s_t) / π_old(a_t|s_t)   (重要性采样比率)
  Â_t = 优势函数估计 (GAE)
  ε = clip 范围 (通常 0.2)

3.5 RLHF 的工程挑战

挑战	详情	缓解措施
训练不稳定	PPO 超参敏感，reward 抖动大	仔细 tune β, lr, clip range
Reward Hacking	模型学会"讨好 RM"而非真正有帮助	加大 β / RM ensemble / 重训 RM
4 模型同时在显存	π_θ + π_ref + RM + Critic	需 4-8 GPU 集群
标注成本	人工对比标注成本高	用 LLM-as-Judge 辅助标注，再人工校验
样本效率低	PPO on-policy，每步需 rollout	Offline RL / DPO 替代

3.6 RLHF 显存账本

RLHF 训练 Llama 3 8B (BF16) 显存估算:

π_θ (Actor):     8B × 2 bytes = 16 GB
π_ref (Frozen):  8B × 2 bytes = 16 GB
RM (Reward):     8B × 2 bytes = 16 GB
Critic:          8B × 2 bytes = 16 GB

优化器状态 (Adam, Actor + Critic):
  2 × 8B × 8 bytes = 128 GB

总计 ≈ 192 GB → 需要 4× A100 80GB (或 2× H100)

对比: SFT 同模型只需 ~50 GB → 1× A100 80GB
→ RLHF 显存成本 ≈ 4× SFT

---

4. DPO（Direct Preference Optimization）

4.1 DPO 的核心洞察

DPO 的 insight：RLHF 的 RM + PPO 两阶段可以合并成一个 闭式解——直接用偏好数据优化策略，不需要单独训练 RM。

数学推导关键步骤：

1. RLHF 的最优策略有闭式解：

π*(y|x) = (1/Z(x)) · π_ref(y|x) · exp(r(x,y)/β)

2. 反解 reward：

r(x,y) = β · log(π*(y|x) / π_ref(y|x)) + β · log Z(x)

3. 代入 Bradley-Terry loss，Z(x) 抵消：

4.2 DPO 损失函数

L_DPO = -E_{(x, y_w, y_l)} [log σ(β · (log π_θ(y_w|x)/π_ref(y_w|x) - log π_θ(y_l|x)/π_ref(y_l|x)))]

直觉：增大 preferred response 的概率，降低 rejected response 的概率，幅度相对于 reference model 来衡量。

4.3 DPO vs RLHF 对比

维度	RLHF (PPO)	DPO
训练复杂度	高（4 模型 + PPO loop）	低（1 模型 + 1 ref + 交叉熵）
显存	~4× SFT	~2× SFT
稳定性	差（PPO 超参敏感）	好（标准交叉熵 loss）
效果	强（在线采样探索）	接近 RLHF（离线数据有偏）
数据需求	在线 rollout + 标注	离线偏好对
Reward Hacking	风险高	风险低
适用	大公司有 RL infra	中小团队 / 快速迭代
代表	InstructGPT, Claude 2	Llama 3, Zephyr, Mistral

4.4 DPO 实战配置

# TRL (Transformer Reinforcement Learning) DPO 训练
from trl import DPOTrainer, DPOConfig

config = DPOConfig(
    beta=0.1,                    # KL 惩罚强度
    learning_rate=5e-7,          # 比 SFT 低一个量级
    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,
    max_length=1024,
    max_prompt_length=512,
    num_train_epochs=1,          # DPO 通常 1 epoch
    bf16=True,
    loss_type="sigmoid",         # 标准 DPO; 可选 "hinge", "ipo"
)

trainer = DPOTrainer(
    model=model,
    ref_model=ref_model,         # 冻结的 SFT 模型
    args=config,
    train_dataset=preference_data,  # {"prompt", "chosen", "rejected"}
    tokenizer=tokenizer,
)
trainer.train()

4.5 DPO 的局限

局限	详情
分布外问题	离线数据不能覆盖 π_θ 的真实分布
偏好数据质量	垃圾标注 → 垃圾模型
无 exploration	不像 PPO 可以在线探索新策略
β 敏感	β 太小 → 过拟合偏好；β 太大 → 无变化

---

5. Post-DPO 对齐方法（2024-2026）

5.1 方法演进

GRPO / RLVR / Hardness / Test-Time Compute 机制与面试满分答 → 04-推理对齐与前沿-GRPO-RLVR-Hardness.md（DeepSeek-R1、o 系列、PRM、课程学习）。

5.2 方法对比

方法	核心改进	优势	适用
IPO	将 σ 替换为 squared loss	不依赖 Bradley-Terry 假设	偏好噪声大时
KTO	不需要 pair，只需要 👍/👎	数据收集成本最低	用户反馈场景
ORPO	将 SFT + 对齐合并为一步	省一轮训练	资源有限团队
SimPO	用序列平均 log prob 替代 ref model	不需要 ref model	显存紧张
SPPO	LLM 自我对弈生成偏好	减少人工标注	自动化对齐
GRPO	组内相对 reward，无 critic	方差低，配 可验证奖励	数学/代码推理模型

5.3 ORPO 详解（SFT + 对齐一步完成）

L_ORPO = L_SFT + λ · L_OR

L_SFT = -Σ log P(y_w_t | y_w_{<t}, x; θ)     # 标准 SFT loss

L_OR  = -log σ(log odds(y_w) - log odds(y_l))  # odds ratio preference
                                                 
odds(y) = P(y|x) / (1 - P(y|x))

优势：只需一轮训练 = SFT + 对齐同时完成。工业实践：适合"快速出 MVP"场景。

5.4 选型建议

场景	推荐方法
大公司 + 充足 RL infra	RLHF (PPO) or Online DPO
中等团队 + 有偏好 pair 数据	DPO / SimPO
只有 thumbs up/down 反馈	KTO
资源极度有限	ORPO
追求前沿 + 自动化	Self-Play PO

---

6. LoRA 原理与实战

6.1 LoRA 的核心思想

Low-Rank Adaptation：冻结 pretrained weights W，只训练低秩分解矩阵 B·A。

数学公式:
  h = W·x + ΔW·x = W·x + B·A·x

其中:
  W ∈ R^(d × k)      — 冻结的原始权重
  B ∈ R^(d × r)      — 可训练（零初始化）
  A ∈ R^(r × k)      — 可训练（随机初始化）
  r << min(d, k)     — 秩（通常 4~64）

实际更新: ΔW = B·A, rank(ΔW) ≤ r

缩放:  h = W·x + (α/r) · B·A·x
  α = scaling factor（通常 α = 2r）

6.2 LoRA 显存节省

以 Llama 3 8B 为例:

全量微调:
  模型参数: 8B × 2 bytes = 16 GB
  梯度:    8B × 2 bytes = 16 GB
  Adam 状态: 8B × 8 bytes = 64 GB
  总计 ≈ 96 GB → 需要 2× A100 80GB

LoRA (r=16, 应用到 Q/K/V/O + gate/up/down):
  可训练参数: ~20M (全参数的 0.25%)
  模型参数: 16 GB (冻结)
  LoRA 参数: 20M × 2 bytes = 40 MB
  梯度:    20M × 2 bytes = 40 MB
  Adam 状态: 20M × 8 bytes = 160 MB
  总计 ≈ 16.2 GB → 1× RTX 4090 24GB ✓

→ 显存降低 6× ！

6.3 Rank 选择

rank r	可训练参数	效果	适用
4	~5M (0.06%)	够做简单格式适配	风格微调
8	~10M (0.12%)	多数场景的起点	通用推荐
16	~20M (0.25%)	大多数任务的甜蜜点	默认选择
32	~40M (0.5%)	复杂领域 / 多语言	医疗/法律
64	~80M (1%)	接近全量微调效果	极复杂任务
128+	~160M+	收益递减	通常没必要

经验法则：

• 格式/风格 → r=8 足够
• 领域知识 → r=16~32
• 复杂推理 → r=32~64
• 如果 r=64 还不够 → 考虑全量微调

6.4 Target Modules 选择

策略	目标	参数量	适用
最小集	q_proj, v_proj	最少	快速实验
注意力全集	q/k/v/o_proj	中	多数场景
全集（推荐）	q/k/v/o + gate/up/down	最多	最佳效果
+ embed + lm_head	全部 + 词表	最大	新语言/新领域

6.5 LoRA 架构图

---

7. QLoRA

7.1 QLoRA = 量化 + LoRA

核心创新：把 base model 量化到 4-bit，在量化后的模型上做 LoRA。三大技术：

技术	作用
4-bit NormalFloat (NF4)	信息理论最优的 4-bit 量化，比 INT4 精度更高
Double Quantization	量化的缩放因子也量化（FP32 → FP8），额外节省 0.37 bit/param
Paged Optimizers	Adam 状态 offload 到 CPU，GPU OOM 时自动分页

7.2 QLoRA 显存账本

Llama 3 70B QLoRA (r=16):

模型参数 (NF4):  70B × 0.5 bytes = 35 GB
LoRA 参数 (BF16): ~160M × 2 bytes = 320 MB
Adam 状态 (LoRA only): 160M × 8 bytes = 1.28 GB
激活 (batch=1, seq=2048): ~2 GB
Paged optimizer overflow: CPU offload

总计 GPU ≈ 39 GB → 单卡 A100 80GB ✓

对比:
  全量微调 70B: ~640 GB → 需要 16× A100
  LoRA (BF16) 70B: ~150 GB → 需要 2× A100
  QLoRA 70B: ~39 GB → 单卡 A100 ✓

→ QLoRA 让消费级 GPU 微调 70B 成为可能

7.3 QLoRA 实战

from transformers import AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig, get_peft_model

# 4-bit 量化配置
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",          # NormalFloat4
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,     # Double Quantization
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.1-70B-Instruct",
    quantization_config=bnb_config,
    device_map="auto",
)

# LoRA 配置
lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                    "gate_proj", "up_proj", "down_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM",
)

model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# trainable params: 159,907,840 || all params: 70,553,706,496 || trainable%: 0.2267

7.4 QLoRA vs LoRA vs 全量

维度	全量微调	LoRA (BF16)	QLoRA (NF4)
显存 (8B)	96 GB	16 GB	6 GB
显存 (70B)	640 GB	150 GB	39 GB
训练速度	基线	1.1x	0.7x（解量化开销）
效果	最好	接近全量	轻微降低 (~1-2%)
硬件	多卡 A100/H100	1-2 卡 A100	单卡 A100 / 2× 4090

---

8. 数据工程

8.1 数据是微调的"第一要素"

“The model is only as good as your data.”

维度	不好的数据	好的数据
指令多样性	100 个相似指令	100 个覆盖不同场景
回复质量	GPT-3.5 自动生成	人工 + GPT-4 + 人工校验
长度分布	全是短回复	短/中/长均匀分布
格式一致	混搭模板	统一 ChatML
无害性	包含有害内容	严格过滤

8.2 数据收集方法

方法	成本	质量	规模
人工编写	极高	最好	小（100-1k）
人工标注 + 模板	高	好	中（1k-10k）
LLM 生成 + 人工校验	中	好	大（10k-100k）
Self-Instruct	低	中	极大（100k+）
从日志挖掘	低	中	大
开源数据集	免费	参差不齐	极大

8.3 数据配比（混合训练）

推荐的数据混合比例:

领域任务数据:     50-60%    — 核心微调目标
通用对话数据:     15-20%    — 防止灾难性遗忘
代码数据:         10-15%    — 维持推理能力
长文本数据:       5-10%     — 维持长上下文能力
安全/拒绝数据:    5%        — 保持对齐

总计: 100%

8.4 灾难性遗忘防范

8.5 合成数据生成

# 用 GPT-4 生成训练数据的实用模板
GENERATION_PROMPT = """你是一个{domain}领域的专家。请根据以下要求生成一条高质量的训练样本：

要求：
1. 指令应该自然、多样，覆盖{domain}的真实场景
2. 回复应该专业、准确、格式规范
3. 回复长度: {length}（短=50字 / 中=200字 / 长=500字以上）
4. 难度: {difficulty}（初级/中级/高级）

请输出 JSON:
{{"instruction": "...", "response": "..."}}"""

# 质量过滤 pipeline
def quality_filter(sample):
    checks = [
        len(sample["response"]) > 50,           # 最短长度
        not has_repetition(sample["response"]),   # 无重复
        not has_hallucination(sample),            # 事实检查
        format_valid(sample),                     # 格式正确
        safety_check(sample),                     # 安全检查
    ]
    return all(checks)

---

9. 评估微调效果

9.1 评估维度

维度	离线指标	在线指标
任务质量	MT-Bench, AlpacaEval, Arena Elo	用户满意度, CSAT
忠实性	Hallucination rate, FactScore	人工抽检错误率
安全性	Red-team pass rate	违规内容投诉
效率	Tokens/s, TTFT	P95 延迟
通用能力	MMLU, HumanEval, GSM8K	跨场景泛化

9.2 过拟合检测

关键信号:
1. Train loss ↓ 但 eval loss ↑         → 经典过拟合
2. 训练集上 100% 准确但开放题质量差    → 记忆化
3. 输出多样性下降（distinct-n ↓）       → 模式塌缩
4. 通用基准 (MMLU) 大幅退步            → 灾难性遗忘
5. 长度分布与训练集完全一致             → 长度记忆化

应对:
- Early stopping（eval loss 最低点）
- LoRA dropout 0.05-0.1
- 数据增强（改写/翻转/扰动）
- 减少 epoch

9.3 Benchmark 污染

问题：如果训练数据包含基准测试的题目，分数虚高。

检测方法：

• N-gram overlap 检测
• Canary string 插入
• Holdout benchmark（不公开的测试集）
• 最可靠：用 MT-Bench / Arena 这类开放式评估

---

10. 生产部署微调模型

10.1 LoRA 合并

# 合并 LoRA 到 base model
from peft import PeftModel

base_model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.1-8B")
peft_model = PeftModel.from_pretrained(base_model, "path/to/lora_adapter")
merged_model = peft_model.merge_and_unload()
merged_model.save_pretrained("merged_model/")

# 合并后推理速度 = base model（无额外开销）

10.2 多 LoRA Serving（S-LoRA）

场景: 100 个租户各有自己的 LoRA adapter

传统方案: 部署 100 个模型 → 成本 100×
S-LoRA: 1 个 base model + 100 个 LoRA adapter 动态加载

架构:
  Base Model (70B): 常驻 GPU
  LoRA Adapters: 存在 Host Memory / SSD
  请求路由: 按 tenant_id 选择 adapter
  热加载:  LRU 缓存 top-K adapters in GPU

vLLM 支持:
  --enable-lora
  --max-loras 16         # GPU 同时缓存的 adapter 数
  --max-lora-rank 64

10.3 模型合并（无需额外训练）

方法	原理	适用
Linear Merge	W = α·W_1 + (1-α)·W_2	两个微调模型合并
TIES	剔除微小变化 + 解决符号冲突	多模型合并
DARE	随机丢弃 90% delta + rescale	减少干扰
SLERP	球面线性插值	两模型风格融合

工业用途：合并"领域模型"和"通用模型"，得到"领域强 + 通用不退"的模型。

10.4 A/B 测试微调模型

A/B 测试设计:
  Control: Base model (通用)
  Treatment: Fine-tuned model (领域)
  
  分流: 10% → Treatment（初期保守）
  
  监控指标:
    - Primary: 任务成功率 / 用户满意度
    - Secondary: 延迟 / Token 消耗 / 安全事件数
    - Guardrail: 严重错误率 < 0.1%
  
  统计显著性: p < 0.05, 8000+ samples
  
  扩量路径: 10% → 30% → 50% → 100%

---

11. 合规与安全

11.1 训练数据合规

风险	详情	缓解
版权	训练数据含受版权保护内容	数据来源审计 + 授权
PII 泄露	训练数据含个人信息	PII 检测 + 脱敏
偏见	训练数据有人群偏见	公平性审计 + debiasing
有害内容	模型学会有害行为	安全过滤 + Red-teaming

11.2 中国法规要点

• 《生成式人工智能服务管理暂行办法》（2023.8 生效）：提供者需做训练数据合规审查、内容过滤、算法备案
• 数据出境：模型训练数据涉及个人信息出境需安全评估
• 标签义务：AI 生成内容需标注为 AI 生成

11.3 Red-teaming

Red-team 微调模型的 checklist:
□ 尝试 prompt injection 绕过安全限制
□ 测试生成个人信息 / 敏感内容
□ 测试领域幻觉（编造不存在的法规 / 产品）
□ 测试对抗性输入（特殊字符 / 长输入 / 多语言）
□ 测试退化 case（微调前能做、微调后不能做的事）
□ 针对电商: 测试错误定价 / 虚假优惠 / 竞品推荐

---

12. 进阶主题

12.1 持续预训练（Continued Pre-training, CPT）

与 SFT 不同，CPT 用 无标注领域语料 做 next-token prediction，让模型先"读懂"领域知识，再做 SFT。

典型 pipeline:
  Base Model → CPT (领域语料 10B+ tokens) → SFT (标注数据) → DPO (偏好数据) → Deploy
  
  适用: 医疗/法律/金融等专业性极强的领域
  数据: 论文 / 教材 / 法规 / 行业报告
  配置: 学习率 2e-5, 长训练 (2-5 epoch on corpus)

12.2 Mixture of Experts 微调

MoE 模型微调的特殊考虑:
- Expert 选择不均: 某些 expert 被过度训练 → 加 load balancing loss
- 显存: 虽然推理只激活部分 expert, 训练时所有 expert 都在显存
- LoRA on MoE: 只在 shared 层 + 活跃 expert 上加 LoRA
- DeepSeek V3 (671B / 37B active):
  LoRA 目标: shared attention + top-2 expert 的 gate/up/down

12.3 训练基础设施选择

场景	推荐	成本/月
个人实验 (7B)	RunPod 1× A100	~$500
团队 (7-13B)	2-4× A100 (自建/云)	$2k-5k
中等 (70B QLoRA)	1× A100 80GB	$1k
生产 (70B 全量)	8× H100	$30k+
大规模 (400B+)	256+ GPU 集群	$500k+

---

13. 五道大厂面试题

13.1 🟦 字节：Fine-tune vs RAG 决策

题目：“你怎么决定一个任务该 fine-tune 还是 RAG？说一个你做错选择的经历。”

参考答案：

决策框架看 3 个维度：知识时效性、行为定制度、数据规模。

知识时效性高（如商品库、政策文档每天变）→ RAG 优先，因为 fine-tune 模型无法实时更新知识。行为定制度高（如客服需要特定话术、输出必须严格 JSON Schema）→ fine-tune 优先，prompt 约束不够稳定。数据规模是 gate——不到 100 条标注数据就别想 fine-tune。

我做错的一次：为支付客服 bot 选了 RAG，知识库包含 3000 篇 FAQ。RAG 的召回率做到 90%，但用户满意度只有 65%——问题出在回复风格。RAG 从文档里检索来干巴巴的"操作步骤"，但用户要的是"有温度的客服"。后来切成 RAG + LoRA：RAG 提供事实，LoRA 微调回复风格（用 2000 条真人客服对话），满意度提升到 82%。

教训：RAG 解决"知道什么"，fine-tune 解决"怎么说"，很多场景需要组合使用。

13.2 🟧 阿里：LoRA rank 选择

题目：“LoRA rank 怎么选？r=4 和 r=64 的 trade-off 是什么？”

参考答案：

rank r 决定了 adaptation 矩阵的表达能力。r=4 意味着 ΔW 的秩最多 4——只能编码 4 维方向的变化，适合风格微调（“说话客气点”）。r=64 能编码 64 维变化，足以做复杂领域适配（“学会医学诊断推理”）。

定量来看，Llama 3 8B 全量 Q/K/V/O 矩阵有 ~67M 参数：r=4 可训练 1.3M (0.016%)，r=64 可训练 21M (0.26%)。显存差异：r=4 的 Adam 状态约 10MB，r=64 约 168MB——差别不大（相比 base model 16GB 是噪声）。所以 rank 选择的主要 trade-off 不在显存，而在过拟合风险。

经验法则：数据 < 1k 条用 r=8-16 防过拟合；数据 1k-10k 用 r=16-32；数据 > 10k 用 r=32-64。还有一个 trick：先用 r=64 训练，然后做 SVD 分析实际有效秩——通常发现有效秩 < 16，说明可以用更小的 r。

我在实际项目中的做法：r=16 起步（甜蜜点），在 validation set 上 grid search {8, 16, 32}，选 validation loss 最低的。alpha 通常设 2r。

13.3 🟪 蚂蚁：DPO vs RLHF

题目：“DPO 比 RLHF 好在哪？什么场景 DPO 不够用？”

参考答案：

DPO 三大优势：（1）不需要单独训练 Reward Model，显存从 4 模型降到 2 模型（~2× SFT vs ~4× SFT）。（2）用标准交叉熵 loss 替代 PPO，训练稳定性大幅提升——不再需要 clip、GAE、KL 退火等 RL 技巧。（3）代码实现简单——TRL 几行就能跑。

DPO 不够用的三个场景：

一是 分布偏移严重。DPO 是 offline 方法——用固定的偏好 pair (y_w, y_l) 训练，但这些 pair 是 SFT 模型生成的，训练后 π_θ 的分布已变。如果偏好数据的 y_l 和 π_θ 的真实差回复差距很大，DPO 的梯度信号变弱。解决方案：Iterative DPO / Online DPO（边训边采样新 pair）。

二是 需要精细 reward 信号。DPO 只有 pair-wise “谁好谁差”，但某些场景需要"好在哪、差在哪"的 pointwise/token-level 反馈。比如代码生成的 “第 5 行有 bug” 这类信号，DPO 用不了，需要 Process Reward Model (PRM)。

三是 复杂对齐约束。如果同时要 helpful + harmless + honest + 合规 + 领域准确，单一 DPO loss 很难平衡多个目标。RLHF 可以组合多个 RM 做加权。

13.4 🔵 Google：Low-resource Language Fine-tuning

Question: “How would you fine-tune a model for a new language with limited data?”

Answer:

Three-stage approach for low-resource language adaptation:

Stage 1: Continued pre-training (CPT) with monolingual corpus. Even 1-2B tokens makes a difference. Key: use the existing tokenizer if it covers the script; otherwise extend the vocabulary (+5k-10k tokens) and initialize new embeddings by averaging semantically related existing tokens. Learning rate: 1/10 of original pre-training (2e-5 for 8B model).

Stage 2: Cross-lingual transfer via translation pairs. Fine-tune on parallel data (English-target) to teach the model “same meaning, different language.” This leverages the model’s existing English capability. Data-efficient alternative: use mT5 or NLLB to generate pseudo-parallel data.

Stage 3: Task-specific SFT in target language. With only 500-2000 labeled samples, LoRA r=32 on all linear layers with alpha=64. Critical: include 30% English data in the mix to prevent catastrophic forgetting of the English “reasoning backbone.”

One practical trick: “translate-then-finetune.” Use GPT-4 to translate high-quality English SFT datasets (like OpenHermes) to target language, then fine-tune on translated data. This scales to 50k+ samples at low cost.

Evaluation pitfall: standard benchmarks (MMLU etc.) are English-only, so you need target-language evaluation—either translate a benchmark or build custom evaluation sets.

13.5 🟢 AWS：Multi-tenant Fine-tuning Platform

Question: “Design a multi-tenant fine-tuning platform serving 100+ customers.”

Answer:

Architecture with 4 layers:

Data Layer: Each tenant’s data isolated in tenant-specific S3 prefixes with IAM policies. Data validation pipeline checks format, PII (auto-redact), toxicity, and size limits. Schema enforcement: all data must be JSONL with {“messages”: […]} format.

Training Layer: Kubernetes-based job orchestration (Kubeflow Pipelines or SageMaker Training). Jobs are LoRA-only (not full fine-tune) to keep GPU cost per tenant manageable (~$50-200 per training run on 8B model). Resource quotas per tenant tier. GPU pool: spot instances for non-urgent jobs (60% cost savings), on-demand for SLA-bound jobs.

Model Registry: MLflow-based with tenant isolation. Each adapter stored as ~40MB artifact (vs 16GB for full model). Lineage tracking: which base model + which data version + which hyperparams. Auto-versioning with canary promotion.

Serving Layer: S-LoRA architecture—single base model cluster (vLLM) serves all tenants. Request routing by tenant_id → load corresponding LoRA adapter. LRU cache for top-K active adapters in GPU memory. Cold start for inactive adapters: ~200ms to load from host memory.

Key metrics: Training SLA < 2 hours for 10k samples on 8B model. Serving overhead per adapter switch: < 5ms (hot cache) / < 200ms (cold). Cost per tenant per month: ~$100-500 depending on training frequency and serving volume.

---

14. STAR-M-P 真实事故

14.1 事故概述

“LoRA 微调后客服 bot 在退款场景回复错误金额”

14.2 STAR-M-P 复盘

Situation（情境）：
电商平台客服 bot，用 Llama 3 8B + LoRA (r=16) 微调，训练数据 5000 条客服对话。上线后处理退款咨询场景。

Task（任务）：
用户问"我买了 399 的鞋子想退款，能退多少？“，bot 应该回复"根据退货政策，可全额退款 399 元”。

Action（行动）：
上线第 3 天，监控发现 bot 在 8 个退款 case 中回复了错误金额——“可退款 299 元”、"退款 199 元"等。经排查发现：

1. 训练数据问题：5000 条对话中有 200+ 条是模拟数据（GPT-4 生成），金额是随机生成的，与实际订单不关联
2. 模型记忆化：LoRA 微调 3 个 epoch 后，模型"记住"了训练集里高频出现的金额模式
3. 缺少 grounding：bot 没有查询订单系统获取真实金额，纯靠 LLM 生成

Result（结果）：

• 8 个用户收到错误退款金额承诺
• 2 个用户按错误金额提交退款被驳回，投诉到客服主管
• 紧急回滚到 prompt-only 版本

Metrics（量化）：

• 错误率：8/400 退款咨询 = 2% 金额错误
• 影响用户：8 人
• 回滚时间：发现到回滚 4 小时
• 修复时间：3 天（重构数据 + 加 grounding）

Prevention（预防措施）：

1. 数据清洗：移除所有包含具体金额的合成数据，金额必须从系统 API 获取
2. Grounding 强制：退款/价格等数值类场景，强制 Tool Use 查订单系统，LLM 只负责话术
3. 数值回归测试：上线前跑 100 条包含具体金额的 case，验证金额是否与订单系统一致
4. 灰度策略：新模型 5% 流量灰度 3 天，人工抽检 50 条后再扩量

---

15. 一句话速记

微调 = SFT（学格式）+ 对齐（RLHF/DPO，学偏好）+ LoRA（省显存）。SFT 数据质量 > 数量（LIMA: 1000 条 ≈ GPT-3.5）。DPO 把 RLHF 的 4 模型简化为 2 模型 + 交叉熵 loss。LoRA r=16 是甜蜜点，QLoRA 让单卡 A100 微调 70B 成为可能。最大风险 = 灾难性遗忘 + 数据质量差 + 缺少 grounding。

---

🧭 章节导航

#	文件	风格
00	00-README.md	索引
01	01-Transformer与Attention.md	机制
02	01-Prompt工程-Few-Shot-CoT与Tool-Use.md	操作
03	02-RAG检索增强-向量库与Chunking.md	设计
04	01-Agent框架-LangChain-LangGraph与AutoGen.md	设计
05	01-AI辅助开发-Cursor-Copilot与Claude-Code.md	操作
06	02-评估-Eval-Hallucination与质量度量.md	机制
07	03-部署-模型Serving-Caching与Cost.md	操作
08	01-电商AI辅助交易场景.md	设计
09	本篇 · 微调-SFT / RLHF / DPO / LoRA	机制+操作
10	03-多模态-Vision-Language与跨模态理解.md	设计

v2.4 增补 · 合成数据飞轮、RLAIF 与 SLM 路由

C1. 合成数据飞轮（Synthetic Data Flywheel）

阶段	风险	控制
Teacher	幻觉进训练集	拒答采样、事实校验 Tool
规模	垃圾重复	去重 embedding、多样性采样
领域	金额/库存错误	禁止合成具体金额；Tool grounding

LIMA 原则：飞轮 质>量；每轮 Δeval 必须为正才扩量。

C2. RLAIF · AI 反馈替代人类偏好

对比	RLHF	RLAIF
反馈源	人类标注	Constitution / AI judge
成本	高	低
风险	对齐人类价值	奖励黑客、自我强化偏见

流程：SFT → AI 评 preference pair → DPO/RLAIF loss → 人类抽检 5%。

C3. Constitutional AI · 原则层级

原则栈（示例）:
  L0: 法律/公司红线（不协助欺诈）
  L1: 无害（不仇恨、不危险指导）
  L2: 有帮助（解决用户任务）
  L3: 风格（简洁、品牌语气）

面试答：Constitution 是 可版本化的 policy.yaml；变更走 eval 回归 与 17 治理。

C4. 蒸馏与 SLM 路由（Distillation + Routing）

策略	说明
Response distillation	Teacher 输出作 SFT 标签
Speculative decoding	小模型草稿+大模型验证
Cascade	先小后大，按置信度升级
路由特征	意图、token 长度、风险 tier

成本口算：

若 70% 流量 SLM@$0.2/1M, 30% LLM@$3/1M
混合 $/1M ≈ 0.7*0.2 + 0.3*3 = 1.04 （vs 纯 LLM 3）

C5. 与 LoRA/QLoRA 的关系

• 飞轮数据 增量 LoRA 适配域；基座冻结 防灾难性遗忘
• Router 可用 小分类器（BERT/小 LLM）单独训练，不与生成 LoRA 混用

C6. STAR-M-P · 合成数据导致金额错误（与 §14 呼应）

Prevention v2.4：合成 pipeline 剥离数值实体；数值 仅 Tool；飞轮 eval 数值子集 硬 Gate。

C7. 口播题（6 题）

C-Q1 · 合成数据能否替代真实日志？

不能全替代；长尾与新规 靠真实；合成补 格式与覆盖。

C-Q2 · RLAIF 最大风险？

Judge 漂移与奖励黑客 → 人类审计+Constitution 版本 pin。

C-Q3 · Constitutional 与 System Prompt 区别？

Constitution 进 训练/对齐；System Prompt 进 推理——两层都要 eval。

C-Q4 · 何时上 SLM 路由？

QPS 高、任务可分类、错误可 Verifier 兜底；支付 L3 禁止纯 SLM 终审。

C-Q5 · 蒸馏后模型变笨？

检查 分布偏移；保留 Teacher 处理尾部；加 拒绝回答 样本。

C-Q6 · DPO 与 RLAIF 能一起吗？

能；偏好对来自 AI judge 即 RLAIF-DPO。

C9. 合成数据质量维度（Rubrics）

维度	检查	工具/方法
事实性	可核对字段	Tool verify
多样性	embedding 距离	去重阈值
毒性	有害内容	Llama Guard
格式	JSON/schema	校验器
领域	术语覆盖	词表命中率
拒绝	应拒答样本比例	10–20%

C10. Teacher 模型选型

Teacher	适用	风险
GPT-4 class	复杂推理、格式	成本、泄露
开源 70B	批量合成	需自托管 GPU
领域微调模型	垂直话术	偏见继承

规则：Teacher 输出 不得 直接进入 prod；必须经 Student eval Gate。

C11. RLAIF 奖励黑客案例

现象	原因	修复
回复变长讨好 judge	length bias	长度惩罚项
过度道歉	安全偏好过强	重构 constitution
工具调用减少	judge 不喜工具痕迹	分场景 judge

C12. Constitutional AI 版本化

constitution_version: "2026-05-01"
principles:
  - id: L0-legal
    text: "不得协助欺诈、洗钱、逃税"
  - id: L1-harmless
    text: "不得生成仇恨、暴力具体指导"
  - id: L2-helpful
    text: "在合规前提下完成用户任务"
change_control:
  requires: [eval_regression_pass, legal_signoff]

C13. SLM 路由特征工程

特征	类型	说明
intent_id	分类	来自小 classifier
token_len	数值	超长升 LLM
risk_tier	枚举	L3 禁止 SLM 终审
confidence	概率	低于阈值升级
lang	类别	小语种升 LLM

C14. 蒸馏数据配方（比例建议）

来源	占比	说明
真实生产（脱敏）	40–60%	锚定分布
Teacher 合成	20–40%	补长尾
拒绝/边界	10–20%	对齐安全
多轮对话	10%	格式多样性

C15. DPO × RLAIF 联合训练注意点

• preference 对 同一 prompt 的 A/B 需 可比（温度固定）
• β 过大 → 模式崩塌；过小 → 对齐无效
• 与 LoRA rank 联动：RLAIF 常 r=8~16 即可

C16. STAR-M-P · RLAIF judge 漂移致礼貌过头

Situation：客服 bot 对齐后 解决率下降（用户要操作步骤却收到道歉）。

Action：抽检 judge 偏好；引入 task success 辅助奖励；human 重标 500 对。

Metrics：解决率 +12%；平均轮次 -0.4。

C17. 口播题扩展（8 题）

C-Q7 · 合成数据版权？

Teacher 条款 + 合成物权属——法务条款；禁喂竞品机密。

C-Q8 · 飞轮何时停？

连续两轮 eval 主指标下降 即停，回滚数据版本。

C-Q9 · Router 训练数据？

生产日志 人工标注路由标签 或 bandit 探索。

C-Q10 · Speculative decoding 与蒸馏？

推理加速技术，不替代 SFT 蒸馏——可叠加。

C-Q11 · 多 LoRA 适配器切换？

Serving 支持 adapter name；注意 KV cache 隔离。

C-Q12 · QLoRA 与合成数据量？

数据量大时 易过拟合合成模式——提高真实占比。

C-Q13 · Constitutional 与 RLHF 顺序？

先 Constitution 约束 SFT，再 RLAIF/DPO 细调偏好。

C-Q14 · SLM 路由如何 eval？

分路由决策 准确率 + 端到端 $/successful task。

C18. 大厂题（微调向 8 题）

ID	题	要点
T11	设计合成数据平台	过滤→gen→curate→version
T12	RLAIF 替代 50 人标注？	可以但需 5% 人审
T13	领域 LoRA 与基座升级	回归 eval + 重新 merge
T14	多任务路由 Serving	单网关多 adapter
T15	灾难性遗忘	混合通用数据 10–30%
T16	数值 grounding	Tool-only 数字
T17	偏好数据不平衡	重采样 + DPO weighting
T18	开源 vs 闭源 Teacher	成本/质量/合规三角

C19. v2.4 Checklist 扩展

• 合成 rubrics 六维
• Teacher 选型表
• 奖励黑客三例
• constitution YAML 版本控制
• 路由特征五类
• 蒸馏配方比例
• §C16 STAR
• §C17 八题任选 3

C8. v2.4 Checklist

• 飞轮六阶段与风险控制
• RLAIF vs RLHF 表
• Constitution 四层
• SLM 路由三种策略
• 混合成本口算
• 数值合成红线

官方文档与源码（一级依据）

AI Engineering · 正文机制应来自下方 官方文档（L1） 与 官方源码仓库（L2）；
禁止用教程站/博客充当机制依据。本章 QPS/延迟/STAR 为面试示意。
写作规范：docs/official-sources-registry.md §0

L1 · 官方文档

• Spring AI Reference
• LangGraph Interrupts
• LangChain4j Docs

L2 · 官方源码

• spring-projects/spring-ai
• langchain-ai/langgraph
• langchain4j/langchain4j

L3 · 论文 / 开放规范

• L3 MCP Specification