后端工程师 LLM 微调指南：行为适配而非知识填充

核心概念解析

行为与知识

全量微调（Full fine-tuning）会更新模型的所有权重，灵活性最高，但 GPU 显存消耗最大，且存在灾难性遗忘（catastrophic forgetting）的风险。

参数高效微调（PEFT，Parameter-Efficient Fine-Tuning）只更新一个小型的适配器（LoRA、QLoRA）。目前大多数生产环境的微调都采用这种方式：在消费级或单 GPU 环境下训练适配器，在服务时合并或热切换。

指令微调（Instruction tuning）是在（指令，响应）pair 上进行微调，让模型更好地遵循命令。对齐微调（Alignment tuning，RLHF、DPO）则塑造模型的助人性和安全性偏好。

训练数据质量

微调会放大你的数据集。噪声样本会产生噪声行为。重复数据会让某些模式权重过高。错误的标签会教出错误的输出。在 GPU 之前先投入数据整理。

内部原理（高层视角）

从预训练的基座模型开始。

将监督样本（prompt、completion）准备为聊天格式。

前向传播仅在 completion token 上计算 loss（mask 掉 prompt token）。

反向传播更新权重（全量或 LoRA 适配器）。

在与训练 prompt 无关的留出集上评估。

导出合并后的权重或适配器 checkpoint。

部署到相同的推理 API 后方，并做好版本追踪。

目标：支持机器人始终以结构化格式回复，带有同理心和升级标签。

收集 2000 条真实工单记录（脱敏 PII）。

用 {summary, action, escalate: bool} 标注理想回复。

在 7B 开源模型上用 LoRA 微调。

保留 RAG 获取产品事实知识库。

推理时：检索文档、注入 prompt，微调模型负责格式化答案。

运行评估：格式有效性、升级准确率、对检索上下文的忠实度。

微调负责格式和语气。RAG 负责事实。

使用 Hugging Face PEFT 进行的说明性 LoRA 训练配置（概念性结构）。

"""
Illustrative LoRA fine-tune setup.
Requires: pip install transformers peft datasets torch
"""
from datasets import Dataset
from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer
from peft import LoraConfig, get_peft_model

BASE_MODEL = "meta-llama/Llama-3.2-1B-Instruct"

examples = [
    {
        "instruction": "Summarize the refund policy briefly.",
        "output": '{"summary": "14-day refund window for annual plans.", "escalate": false}',
    },
    {
        "instruction": "Customer threatens legal action over billing.",
        "output": '{"summary": "Acknowledge concern, escalate to legal.", "escalate": true}',
    },
]

def format_example(row: dict) -> dict:
    text = (
        f"<|user|>{row['instruction']}<|assistant|>{row['output']}"
    )
    return {"text": text}

dataset = Dataset.from_list(examples).map(format_example)

tokenizer = AutoTokenizer.from_pretrained(BASE_MODEL)
model = AutoModelForCausalLM.from_pretrained(BASE_MODEL)

lora_config = LoraConfig(
    r=8,
    lora_alpha=16,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM",
)
model = get_peft_model(model, lora_config)

def tokenize(batch):
    return tokenizer(batch["text"], truncation=True, max_length=512)

tokenized = dataset.map(tokenize, batched=True)

training_args = TrainingArguments(
    output_dir="./lora-out",
    num_train_epochs=3,
    per_device_train_batch_size=1,
    learning_rate=2e-4,
    logging_steps=1,
)

trainer = Trainer(
    model=model,
    args=training_args,
    train_dataset=tokenized,
)
# trainer.train()  # Uncomment with GPU and model access
print(f"Trainable params: {model.print_trainable_parameters()}")

在 GPU 硬件上运行，并在部署生产前做好正确的评估切分。

实际应用场景

• 一致的 schema 遵循的 JSON 提取
• 合规审查的领域特定语气（法律、医疗图表笔记）
• 可靠工具选择的功能调用微调
• 将大型教师模型蒸馏为小型学生模型用于路由分层

性能考量

训练成本：GPU 小时数随模型大小、数据集大小和 epoch 数 scaling。

服务成本：合并后的微调与基座模型的推理 profile 相同。适配器增加少量开销。

更新频率：RAG 重新索引是小时级。微调重训练是天级，且需要 MLOps 工作流。

回退风险：在提升新 checkpoint 前始终运行黄金评估集。

常见错误

• 微调用于存储频繁变化的事实。
• 合成数据训练未经人工审查。
• 没有用类生产 prompt 的留出评估集。
• 在小数据集上做全量微调。
• 部署时没有回滚到之前模型版本的机制。

FAQ

Q1: 微调改变什么？ A: 调整模型权重以适应行为、风格或格式。不是volatile事实知识的可靠存储。

Q2: 微调 vs RAG？ A: RAG 在查询时注入外部事实。微调塑造模型的响应方式。两者常结合使用。

Q3: 什么是 LoRA？ A: Low-Rank Adaptation：训练小的加性矩阵而非全部权重，降低显存和成本。

Q4: 什么是灾难性遗忘？ A: 当数据集狭窄或训练过于激进时，微调会削弱模型的通用能力。

Q5: 如何评估微调后的模型？ A: 留出任务指标、格式合规性、安全检查，以及与基座模型加 prompt 基线的对比。

Q6: 什么时候微调不值得？ A: 当 prompt 工程加 RAG 能达到质量标准时，或当缺乏精心的训练数据和评估基础设施时。

微调数据流水线

生产微调需要 MLOps 规范：

Source：生产日志（脱敏）、人工编辑的理想响应、合成数据（经审查）。

Format：与推理匹配的聊天模板（system、user、assistant 角色）。

Split：训练/验证/测试，且 RAG 耦合评估中无文档重叠。

Train：带验证集 early stopping 的 LoRA。

Eval：自动化加安全和格式的人工审查。

Register：模型卡，包含数据集 hash、基座模型版本、指标。

Deploy：金丝雀部署，带基座加适配器关闭的回滚。

LLM 生成的训练数据可以教会模型自身的失败模式。如果是合成数据，使用更强的教师模型、人工抽检和多样性过滤器。

何时优先选择 Prompt 而非微调

• 高质量样本少于 500 条
• 行为每周都在变化
• 需要 prompt 中指令的可解释性
• 每个租户切换多种行为（prompt 标志优于 N 个适配器）

当需要一致的格式、减少 prompt 长度或在规模上实现领域语气时，微调胜出。

LoRA 超参数（起始参考）

始终在不同于训练改写的任务上评估，以检测记忆化。

全量微调 vs LoRA 决策

对于大多数产品团队，LoRA 加开源基座模型可以覆盖格式和语气需求。

推理时与 RAG 结合

system: policies + citation rules
user: question
retrieved: top chunks
model: fine-tuned for JSON + support tone

微调教会如何格式化答案。RAG 提供答案应该引用什么。

数据集规模指南（经验法则）

质量优于数量。500 条专家标注样本胜过 10,000 条噪声合成样本。

合规考量

在客户数据上微调可能涉及：

• 训练使用的同意书
• 数据保留策略
• 删除权（能 unlearn 吗？）

记录哪些数据进入了每次训练运行。适配器是更小的产物，但仍然编码了训练数据信号。

部署策略

保持 N-1 适配器 checkpoint 热可切换。特性开关将流量百分比路由到新适配器。如果格式错误率飙升则自动回滚。

ML 与平台团队交接清单

• 适配器 checkpoint 加评估报告
• 训练数据清单 hash
• 推理集成
• 生产监控

没有交接清单，微调会发布而没有回滚路径。

将以下内容纳入微调 ROI：

• 每次重训练前的工程师审查
• 如果总和超过 12 个月的 prompt+RAG 迭代成本，延迟微调

存储与产物管理

在对象存储中存储适配器，并附带元数据：基座模型 hash、训练 commit、数据集版本、评估分数、训练超参数。推理服务器在部署时按版本 tag 加载适配器。绝不覆盖 adapter blob原地；不可变产物支持回滚。

对于受监管行业，维护训练数据血缘以供审计：哪些客户数据进入了哪次运行，包含保留到期时间。

参考附录：生产 FAQ

如何知道在生产中是否有效？

在更改模型或 prompt 之前，对这一层做埋点。对比周环比的 p50 和 p95 延迟、错误率以及任务特定质量分数。AI 回归很微妙：平稳的 aggregate uptime 可能掩盖了错误答案。

第一个值得尝试的配置变更是什么？

在增加能力之前先降低变异性。降低事实路径的温度、缩小 retrieval top-K、收紧 context budgets、添加输出验证。复杂度不是测量的替代品。

什么应该放在 on-call runbook 中？

症状、仪表盘链接、回滚杠杆（模型版本、特性开关、索引快照）、负责团队和客户通信模板。LLM 事故需要内容回滚，而不仅仅是服务重启。

如何向产品经理解释权衡？

使用美元和秒：每次成功任务的成本、首个 token 的 p95 时间、黄金集上的准确率。不要争论模型智能；争论可衡量的用户结果和失败容忍度。

何时应该重训练、重新索引或重写 prompt？

文档变化时重新索引。行为规范变化时重写 prompt。当 prompt 加 RAG 经过评估迭代无法满足格式或语气要求时重训练或微调。默认顺序：prompt、RAG、微调。

常见的回滚路径是什么？

保持之前的模型版本、之前的索引快照和之前的 prompt 模板可通过版本 ID 寻址，至少七天。回滚应该是一个特性开关或部署 revert，而不是消防演习。

这与手册的其他部分如何交互？

这个主题是堆栈中的一层。阅读前言中列出的先决条件。在调试端到端故障时，在得出模型错误的结论之前，沿着请求路径从 ingress 经过 retrieval、推理和输出验证走一遍。

用微调改变行为。用检索改变事实。把微调当作一个具有版本控制、评估门禁和明确所有权的部署产物，而不是一次性的数据上传。

参考文献

Hu et al.: LoRA: Low-Rank Adaptation of Large Language Models

Hugging Face PEFT documentation

Blog 002 for RAG as the knowledge layer

Blog 006: LLM Quantization: Precision, Memory, and Production Tradeoffs