一个常见的场景是：产品的回答「不太像我们公司说话」，于是有人提议收集一批对话做模型微调。几周后模型确实换了腔调，却在原本答得不错的问题上开始出错，团队只好把提示词改回去。
这不是微调本身的问题，而是它被当成了默认选项。动手之前有个更值得先回答的问题：你要改的，是模型说话的方式，还是它知道的东西。
先分清「怎么说」和「知道什么」
模型微调用梯度去调整参数，它擅长的是让输出分布向一批样本靠拢——语气、结构、字段顺序、判断的粒度。这类东西很难用提示词描述清楚，尤其当格式约束叠了好几层时，写提示词会变成一场不断打补丁的拉锯。
但它不擅长往模型里塞进会变的事实。价格、库存、政策条款，今天写进训练样本，明天就可能过期，而模型不会告诉你它记的是旧版本。这类需求更接近检索：资料放在外部，让模型回答时去查。区别在于，检索错了可以换文档，微调错了只能重训。
数据的一致性比数量更要紧
很多人把微调当成数据工程，先想着凑够多少条。实际更影响结果的是标注之间是否互相矛盾：同一个问题，两个人给出风格不同的答案，模型学到的就是模糊的平均值。与其把样本从一千条堆到一万条，不如先把几百条里的分歧挑出来，定一份写法规范。
另一个常被忽略的点是负样本。只告诉模型「应该怎么答」，它学不到「什么情况下不该答」。涉及边界的问题，比如超出范围时如何拒答、信息不足时如何追问，最好在数据里显式出现。
没有评估集，等于没有做
微调最容易失控的地方，是它「看起来变好了」。模型会更自信、更流畅，也更难被你发现问题。所以在训练之前，先留一批不参与训练的样本，覆盖正常问题、边界问题和以前踩过的坑，每次迭代都跑一遍。这不复杂，但不少项目省掉了它，最后只能靠人工抽查。
还要留意灾难性遗忘：模型在新数据上收敛的同时，通用能力可能悄悄退化。一个实用的做法是把少量通用样本混进训练集，或者在评估里保留一组与业务无关的题目。
哪些情况值得动手
- 输出格式高度固定，字段多、约束多，提示词已经难以维持稳定；
- 需要用更小的模型承接高频请求，用微调换延迟和成本；
- 行业内的表达习惯相对稳定，且有足够一致的样本可以复用；
- 任务边界清晰，答案的对错能被写成规则。
反过来，如果真实需求是「答得更准、更新更快」，那大概率不是模型微调该解决的问题。
上线只是开始
微调过的模型是一项需要维护的资产。数据换一版，行为就可能漂移；基座模型升级，之前的适配工作要重做；线上冒出的新问题，要回流成新样本。把这些流程想清楚，比纠结用哪个训练框架有用得多。
我的判断是：模型微调适合那些已经想明白「要改什么」的团队，而不是用来探索需求的工具。如果一个需求用提示词和检索都还说不清楚，微调只会把这种模糊固化进参数里。