SFT 与 LoRA：数据、训练与验证最小闭环

上一篇把“该不该微调”讲清楚了，这一篇开始回答“真要调，怎么落地”。
目标不是把所有训练技巧讲完，而是先搭一套够用骨架：SFT 和 LoRA 分别在解决什么、数据集到底怎么组织、训练后如何判断是不是有效提升。

先看方法分工：SFT 与 LoRA 是什么关系？

可以把它们看成同一条链路上的两个层次：

SFT（监督微调）：训练目标与任务定义；
LoRA（低秩适配）：参数更新方式与资源成本优化。

也就是说：

你做的是 SFT 任务；
可以选择用 LoRA 来实现这个 SFT，降低显存和训练成本。

为什么 LoRA 在工程里这么常见？

因为它在“效果可接受”和“资源可承受”之间给了一个好平衡：

只训练少量增量参数，显存压力小；
训练速度更快，迭代频率更高；
基座模型保持不变，便于做多任务适配和版本管理。

它的边界也要清楚：

对一些高难度能力迁移，LoRA 不一定等价于全参数微调；
数据质量差时，LoRA 也救不了任务效果。

数据集怎么做才“像工程资产”？

很多微调失败不是训练器问题，而是数据问题。
一个够用的数据设计可以包含三层：

样本结构层：instruction + input + output（或等价 schema）；
覆盖层：主路径样本 + 边界样本 + 拒答样本；
质量层：去重、去冲突、去低信息样本。

你至少要确保：

标注口径一致；
输出格式稳定；
关键场景有足够覆盖，而不是只堆“看起来像”的例子。

训练前先定义“要赢在哪里”

不要训练完才想评估。先写清楚目标：

是提升结构化输出正确率？
还是提升领域术语一致性？
或者降低幻觉、提高拒答质量？

不同目标，对应不同验证集设计。
这一步没做，后面很容易出现“loss 降了，但业务没变好”。

一个最小可用训练闭环

可以用这条流程起步：

准备训练集、验证集、回归题集（固定不动）；
跑一版基线（不微调）拿到指标；
跑 LoRA-SFT 训练；
在同一套验证/回归题上对比；
只在显著提升场景进入灰度。

这套闭环的价值是：

你能判断“有没有提升”；
你能解释“提升发生在哪”；
你能发现“副作用在哪”。

常见坑：只看训练损失，不看任务指标

训练过程里最容易出现三种错觉：

loss 很好看，但线上结构化字段仍然错；
某些主路径变好，但边界场景退化；
术语一致性提升了，拒答策略却变弱了。

所以评估至少要拆成：

任务正确率；
格式合规率；
安全与拒答表现。

小结：微调不是“跑个脚本”，而是一个可验证过程

SFT 定义任务目标，LoRA优化训练成本；
数据质量和覆盖面决定上限；
训练闭环必须绑定业务指标，而不是只盯 loss。

把这套最小闭环跑通后，再去谈更大规模数据、更复杂训练技巧，收益会明显更稳定。