如何做大模型微调？
面试速答（30 秒版 TL;DR）
- 大模型微调的本质，是用任务数据继续训练模型，让模型在某类任务上的输出分布更稳定，而不是“把知识塞进去”。
- 正确顺序通常不是“先微调”，而是先做基线评估，再判断问题到底属于 Prompt、RAG、工具链，还是模型行为本身。
- 真正适合微调的场景，通常是：任务长期稳定、输入输出模式固定、对格式一致性或领域风格有持续要求。
- 一条靠谱流程一般包括：定义目标与指标、准备评测集、构建训练集、选择方案、训练、离线评估、灰度上线、持续回流数据。
- 工程上最常见的落地路线不是全量训练，而是
SFT + LoRA/QLoRA + 严格评估。
先把一个误区打掉：微调不是“喂资料”
很多人说“我把公司文档给模型学一下，就是微调”。这句话在大多数工程场景里是错的。
更准确的区分是：
- RAG 解决的是“回答时看什么资料”
- 微调 解决的是“模型以什么方式回答”
所以如果你的核心问题是：
- 知识经常变化
- 回答必须引用最新制度或数据库
- 需要按租户、按权限查实时信息
优先方向通常不是微调，而是检索、工具调用、知识库治理。
反过来，如果你的核心问题是：
- 输出格式总不稳
- 特定领域术语老是跑偏
- 某类分类/抽取任务波动很大
- 你想让小模型承接固定任务
那微调才真正进入候选名单。
一句最适合面试的总结：
- 微调改的是模型参数里的行为偏好，RAG 改的是推理时可用的上下文。
什么情况下值得做微调
1. 任务边界稳定，且会长期重复
例如：
- 客服工单分类
- 合同字段抽取
- 医疗问诊摘要结构化
- 电商商品属性补全
- 固定模板报告生成
这类任务有一个共同点：输入形态相对稳定，目标输出也比较明确。只要样本质量足够，微调通常能把“偶尔答对”拉成“整体更稳”。
2. 你要的是“稳定性”，不是“新知识”
微调特别适合改善这些问题：
- JSON 总是少字段
- 标签分类边界不一致
- 术语、语气、格式不统一
- 多轮指令里经常漏约束
这些都更像“行为习惯问题”，而不是“知识缺失问题”。
3. 你希望把任务下沉给更小模型
这是很多团队真正做微调的原因。
不是因为基础大模型不够强，而是因为：
- 大模型太贵
- 延迟太高
- 并发成本太重
- 某个任务其实不需要通用智能
这时常见思路是：
- 用强模型先产出高质量样本和评测标准
- 再用这些数据去微调较小模型
- 用更低成本承接高频固定任务
什么情况下不要急着做微调
1. 连基线都没跑清楚
如果你还不知道：
- 当前 Prompt 的最好成绩是多少
- 加 few-shot 后能提升多少
- 接 RAG 后是否已经足够
- 失败样本主要集中在哪些类型
那直接上微调，基本等于盲试。
2. 问题本质上是数据链路问题
例如：
- 检索召回错了
- 文档切块不合理
- 工具返回结构不稳定
- 上下文塞得太长导致关键信息被淹没
这类问题即使微调，也只是把系统缺陷往模型里硬压，成本高、收益还不稳定。
3. 样本太少，且质量不可控
微调不是魔法。样本如果：
- 标注口径不一致
- 输出风格互相冲突
- 充满脏数据和重复样本
- 覆盖不到边界场景
那训练出来的模型通常只会更稳定地犯错。
大模型微调的标准流程怎么讲
上面这条链路里，最容易被忽略但最关键的步骤有两个：
- 先做评测集
- 先分类型看失败样本
因为训练从来不是第一步，评估才是第一步。
每一步到底在做什么
1. 定义目标，不要把“效果更好”当目标
目标必须可操作。常见写法应该像这样：
- 分类准确率从
82%提升到90% - JSON 合法率从
88%提升到98% - 医学摘要关键字段召回率提升
10% - 平均 token 成本下降
40%
面试里可以直接说：
- 微调目标要同时包含效果指标和成本指标，否则无法判断上线价值。
2. 先做评测集，再收训练集
评测集和训练集不能混在一起。
评测集的作用是：
- 作为基线比较标准
- 判断新模型是否真的提升
- 避免“训练集背熟了，看起来像提升”
一个合格评测集至少应覆盖：
- 常规样本
- 难样本
- 低频边界样本
- 易混淆类别
- 线上真实失败样本
3. 构建训练集，核心是口径统一
训练数据常见来源包括：
- 人工标注数据
- 业务历史优质样本
- 专家修订后的答案
- 强模型蒸馏出的高质量结果
但来源不是关键，关键是：
- 标签定义清晰
- 输出模板统一
- 错误样本被纠偏
- 数据去重做过
- 分布接近真实线上场景
一个很典型的坑是：
- 训练集 70% 都是简单样本，导致模型在离线平均分不错，但上线一碰到复杂样本就掉得很厉害。
4. 选技术路线，先选简单有效的
工程里最常见的是以下几类：
| 路线 | 适用场景 | 面试口径 |
|---|---|---|
SFT | 分类、抽取、固定风格生成 | 最基础、最常用的监督微调 |
LoRA / QLoRA | 开源模型低成本训练 | 参数高效，显存和成本更友好 |
| 偏好优化 | “没有唯一正确答案，但可比较优劣”的任务 | 更适合质量偏好对齐，不适合一上来就做 |
大部分面试场景下，一个很稳的回答是：
- 第一阶段通常先做 SFT；如果是开源模型落地，常配合 LoRA/QLoRA 控制训练成本。
5. 训练时别只盯 loss
训练 loss 下降，不等于业务效果真的变好。
工程上更应该同步观察：
- 评测集准确率
- 结构化输出合法率
- 关键字段召回率
- 幻觉率/越权率
- 推理时延与 token 成本
因为你最终上线的是“系统效果”，不是一条训练曲线。
6. 上线要灰度，不要全量替换
离线评估通过，只代表“值得继续试”，不代表“可以全量上”。
更稳的流程通常是：
- 小流量灰度
- 与旧版本或基线方案 A/B 对比
- 重点观察真实失败样本
- 确认没有明显回归后再放量
微调的数据怎么准备，才算工程上靠谱
1. 数据量不是第一位，样本质量才是
很多任务不是“越多越好”，而是“先把坏样本拿掉”。
优先检查这些问题：
- 同一输入对应多个冲突答案
- 标注人之间标准不一致
- 模型生成样本没经过人工筛查
- 大量重复样本拉高了表面指标
2. 样本分布要像真实线上请求
如果线上请求是：
- 80% 常规单轮任务
- 15% 缺字段脏输入
- 5% 极端复杂样本
那训练和评测至少要能映射这种结构。否则训练出来的模型，只会在“实验室世界”里表现很好。
3. 边界样本要刻意补
真正决定系统下限的，经常不是普通样本，而是这些：
- 多意图输入
- 模糊表达
- 专业缩写
- 长上下文噪声
- 冲突信息
- 不完整输入
面试时这句话很好用：
- 普通样本决定平均分，边界样本决定你上线后会不会翻车。
微调和 Prompt、RAG、工作流的关系怎么答
这是高频追问。
一个成熟回答不是四选一，而是分层处理：
| 问题类型 | 优先方案 |
|---|---|
| 知识不新、不全、不可追溯 | RAG / 工具调用 |
| 输出格式不稳、风格不一致 | Prompt + SFT |
| 复杂任务要拆步骤、加检查、调工具 | Workflow / Agent |
| 想让更小模型更稳地承接固定任务 | 微调 |
更工程化的说法是：
- Prompt 决定短期指令约束
- RAG 决定回答时能看到什么证据
- 工作流决定系统如何执行
- 微调决定模型长期行为偏好
所以微调很少单独存在，它往往是整个系统优化链条里的其中一环。
面试里的标准答法
问：如何做大模型微调？
可以这样答：
- 先判断问题是不是适合微调，区分它到底是知识问题、流程问题，还是模型行为稳定性问题。
- 给任务建立基线和评测集，明确指标，例如准确率、格式合法率、召回率和成本。
- 收集并清洗高质量训练数据，保证标签和输出口径统一，同时覆盖边界样本。
- 先用监督微调做第一轮验证；如果是开源模型落地，常用 LoRA 或 QLoRA 控制训练成本。
- 训练后做离线评估，再灰度上线观察真实收益，最后把线上失败样本持续回流，形成闭环。
如果要再压缩成一句话：
- 做大模型微调，重点不是“怎么训”，而是“先证明这事值得训，再用高质量数据把模型训对”。
问：微调最大的难点是什么？
标准答法：
- 最大难点通常不是训练命令，而是数据集口径、评测标准和线上闭环。没有这三样，微调很容易做成不可复现的玄学优化。
问：为什么很多微调项目效果不稳定？
标准答法：
- 常见原因包括：任务不适合微调、训练数据质量差、评测集不独立、边界样本覆盖不够，以及只看训练指标不看线上业务指标。
常见误区
- 误区一：把微调当成“补知识库”。
- 误区二：Prompt 都没打磨好，就直接开始训练。
- 误区三：没有独立评测集，只看训练 loss。
- 误区四：上线直接全量替换，不做灰度验证。
- 误区五：只看平均准确率，不看边界样本和真实业务成本。
易错点 / 坑
- 数据清洗不彻底，导致模型学到互相冲突的口径。
- 训练集和评测集重叠，离线结果虚高。
- 只优化效果，不看推理成本，最后商业上不成立。
- 把所有失败问题都归因给模型，忽略检索、工具和工作流缺陷。
- 没有做失败样本回流，导致模型版本迭代越来越盲。
速记要点
- 微调优先解决的是 行为稳定性问题，不是 实时知识问题。
- 顺序要对：先评估，再训练；先分问题，再选方案。
- 工程常用路线：SFT + LoRA/QLoRA + 独立评测集 + 灰度上线。
- 数据质量、边界覆盖、线上闭环，通常比训练技巧更重要。
- 真正成熟的微调项目，目标一定同时包含 效果、成本、稳定性。