我去年花了三个月微调一个客服模型，踩了无数坑，最后总结出一个扎心的结论：
微调这件事，70%的功夫在数据上。
不是模型选得不对，不是参数调得不好——是数据太烂了。
后来我痛定思痛，花了大把时间重新整理数据，模型的回答质量直接从"还能用"变成了"客户分不清是AI还是真人"。今天就把我踩过的坑和总结出的经验全盘托出。
先把概念说清楚
SFT（Supervised Fine-Tuning）说白了就是：拿着高质量的人工标注数据，教模型学会特定场景下应该怎么说话。
预训练模型就像一张白纸，它懂语法、懂世界知识，但它不懂你的业务。SFT就是用它最擅长的方式（自回归生成）去适应你的任务。
但问题就在这儿——很多人以为SFT就是"拿一堆问答对扔进去跑"。把数据整理成JSONL格式、跑几个epoch就完事了。结果出来的模型要么胡说八道，要么连基本的通用能力都掉了。
我上过的当，今天就别让你再上了。
数据构建：绕不过去的大山
第一步：搞清楚你真正需要什么数据
在做SFT之前，先问自己三个问题：
1. 模型现在会什么？
说白了，基座模型本身的能力边界在哪。比如用Qwen2.5-7B，它本身就懂代码、懂问答，你要微调的只是回答问题的方式和业务知识边界，不是让它学"怎么说话"。
2. 上线后面对什么样的场景？
是单轮对话还是多轮？是有固定回答模版还是自由发挥？这个决定了数据格式。
3. 什么样的回答算"好"？
这个最重要，但很多人没想清楚。具体一点——好回答是信息全面？是语气亲切？是格式统一？你定标准，数据才能按标准生产。
我当时踩了个坑：客户说要"热情亲切"，我按自己的理解写了一大堆"亲~“开头的回答。上线后被客户疯狂吐槽太假。后来才知道他们说的"热情亲切"是"用方言+缩短回答长度”。
第二步：数据格式怎么选
目前主流的SFT数据格式有三种：
ShareGPT格式
{"conversations":[{"from":"human","value":"空调不制冷怎么办？"},{"from":"gpt","value":"请按以下步骤排查：\n1. 检查遥控器是否在制冷模式\n2. 清洗滤网...\n"}]}这个格式的好处是多轮对话天然支持，缺点是每个角色都标注from字段，数据量大时略占空间。
Alpaca格式
{"instruction":"空调不制冷怎么办？","input":"","output":"请按以下步骤排查..."}最经典的三段式，适合单轮问答。缺点是不好处理多轮。
OpenAI Messages格式
{"messages":[{"role":"user","content":"空调不制冷怎么办？"},{"role":"assistant","content":"请按以下步骤排查..."}]}跟ShareGPT很像，但API兼容性好。
我的建议：如果是多轮对话场景，直接用ShareGPT格式。如果是单轮QA库，Alpaca最轻量。别在格式转换上浪费时间，跑起来再说。
第三步：数据质量才是真正的分水岭
这才是SFT的精髓。我总结了几条硬规矩：
质量 > 数量
我一开始准备了3万条数据，跑完效果稀烂。后来砍掉80%的质量不过关的数据，用剩下的6000条重新训练，效果翻倍。
什么样的数据算"质量过关"：
- 回答准确（废话，但很多人真是拿百度百科直接扔进去）
- 格式统一（所有回答风格一致，别一个用"亲~“一个用"您好”）
- 长度适中（别一个300字一个10个字）
多样性 > 重复性
很多人做数据有一个坏习惯：同一种问题写几十个不同版本。
"空调不制冷怎么办？" "空调不制冷了怎么办？" "空调不制冷了怎么办？"这三个问题对模型来说几乎没有区别。还不如只留1个，把省下来的精力去覆盖其他case。
难例 > 简单例
模型面对"你好"、"你是谁"这种简单问题时，基本不会出问题。真正容易翻车的是：
- 边界问题（用户问的和业务擦边但不完全相关）
- 模糊问题（用户自己也说不清楚想要什么）
- 对抗问题（用户"考验"AI会不会胡说八道）
这些难例才是SFT数据的黄金。我最后6000条数据里，大概有30%是这种"难例"，训练完效果明显好了一大截。
训练技巧：别让模型的"老本"丢了
数据搞定了，训练参数也是坑。说几个最常见的坑。
Epoch别太多
一个非常普遍的错误：以为epoch越多越好。
我一开始跑了5个epoch，结果模型的通用能力全面下降——让它写个Python脚本都跑不动了。后来换成2-3个epoch，效果刚刚好。
经验值：2-3个epoch最佳，超过4个大概率过拟合。
学习率别太大
SFT的学习率应该是预训练的1/10到1/100。我一般从1e-5开始调，如果loss降得太慢就提到2e-5，太快就降到5e-6。
有个简单判断标准：如果训练1个step后loss直接跳水，说明学习率太大了。
LoRA是个好东西
说实话，除非你资源充足，否则别轻易做全量微调。LoRA+QLoRA在大部分场景下效果已经够用了。
我的常用配置：
lora_r=16lora_alpha=32lora_dropout=0.05target_modules=["q_proj","v_proj","k_proj","o_proj"]如果你用的模型比较大（32B以上），建议只微调q_proj和v_proj，省显存。
数据混入：防止灾难性遗忘
这是SFT最大的坑，没有之一。
模型在SFT后，会在你的任务上表现更好，但其他能力（代码、数学、通用问答）可能会下降。这叫"灾难性遗忘"。
我的解决办法：在训练数据里混入10-20%的通用数据。
比如你是微调法律模型，除了法律QA，再加一些：
- 通用问答（百科式的）
- 代码问题（如果模型需要写代码）
- 逻辑推理（保持模型的思维链能力）
具体的比例我试过几种：
- 纯业务数据：通用能力下降30%
- 90%业务+10%通用：通用能力下降约10%
- 80%业务+20%通用：通用能力几乎不变，但业务效果略有下降
我最后的方案是15%的通用数据混入，这个平衡点效果最好。
评估：别光盯着loss看
很多人训练完只看loss降没降。兄弟，loss降了不代表模型变好了。
我后来建立了一套评估流程：
- 自动评估：准备200条测试集，用GPT-4或人工打分，算BLEU/Rouge/LlamaIndex的评估指标
- 人工抽测：随机抽50条，找3个人盲评，“哪个回答更好”
- 线上效果：A/B测试，对比老模型和新模型的关键业务指标
最惨的教训：有一次我model loss从0.8降到了0.3，兴高采烈上线，结果线上对话满意度直接从85%掉到了62%。就是因为过拟合了训练数据，处理开放性问题的能力全面退步。
写在最后
SFT这件事，说难也难，说简单也简单。
说难——数据的质量要求高，训练参数的调优需要经验，灾难性遗忘的问题不好解决。
说简单——只要你把数据做好了，把Epoch控制在2-3个，用LoRA跑一跑，效果一般都不会太差。
最后送大家一句话：别迷信参数，别忽视数据。
我见过太多人花大把时间研究learning rate和weight decay，结果拿出去的数据质量一塌糊涂。先把数据抄一遍，再回来调参。这是我用三个月踩坑换来的经验。
有问题评论区聊，别客气。
