微调 · 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 三者详细对比

1.4 微调的 5 大动机

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 数据格式

三大主流格式：

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

2.3 数据质量 > 数据数量

经验公式：

• 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 常见陷阱

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 的工程挑战

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 对比

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 的局限

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

5.1 方法演进

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

5.2 方法对比

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 选型建议

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 选择

经验法则：

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

6.4 Target Modules 选择

6.5 LoRA 架构图

7. QLoRA

7.1 QLoRA = 量化 + LoRA

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

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 全量

8. 数据工程

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

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

8.2 数据收集方法

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 评估维度

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 模型合并（无需额外训练）

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

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 训练数据合规

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 训练基础设施选择

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。

🧭 章节导航

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

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

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

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

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

C3. Constitutional AI · 原则层级

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

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

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

成本口算：

若 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）

C10. Teacher 模型选型

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

C11. RLAIF 奖励黑客案例

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 路由特征工程

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

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 题）

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