一个不算少见的情形：团队整理了几百条对话，跑完一轮模型微调，演示当天效果不错；上线一周，同样的问题换个说法又冒了出来。
接下来的动作往往是继续补数据——再加一千条。但在补之前，有个问题值得先回答：模型是真的不会，还是没被要求清楚？这两件事对应的处理方式完全不同。
先把诉求拆开
多数人说要“微调”，实际想解决的需求大致落在三类里。
- 输出形状：字段、顺序、语气、拒答方式要稳定。
- 语言习惯：让回答贴近某个行业的表达，而不是通用书面语。
- 任务收窄：把一个宽泛的通用模型，固定到具体流程的某一步。
这三类都能通过模型微调来做，但代价不同。格式类的需求通常一轮训练就能看出变化，语言习惯需要更干净的样本，任务收窄则要先把边界写清楚——边界不清，样本就会自相矛盾，训练只是在放大这种矛盾。
提示词能稳住的，先别训
如果几十行提示词加几个示例就能稳定输出，微调的收益要打问号。它不仅是一次训练，还带上了长期维护：基础模型换代、上下文长度变化、业务口径调整，每一件都意味着重新准备数据、重新验证。省下来的调用成本，未必抵得上这部分人力。
数据的价值在于“错得有代表性”
把一批正确但平庸的回答喂进去，模型学到的是安全的中庸。真正能拉开差距的，是模型当前失败的案例：它在哪里误解了指令，在哪里把两个相近的概念混为一谈，在哪里答得过于笼统。这类样本不好收集，需要人工逐条看，但它们决定微调最终的形态。数量上的堆叠，很少能替代这一步。
会变的事实，别往权重里塞
产品名、政策口径、库存状态这类高频变动的信息，更适合放在检索或外部数据里。模型微调擅长的是稳定的行为模式——怎么说、按什么顺序说、什么时候不该说。把两者混在一份训练集里，常见的结果是模型答得流畅，内容却停在训练那天。这类问题排查起来很费劲，因为语气上看不出破绽。
先有评测集，再谈训练
没有一组固定的、人工判过的评测样本，你很难判断这次训练到底做了什么。损失曲线下降，可能只是模型学会了格式，也可能顺带丢掉了原本擅长的能力——灾难性遗忘通常发生在你没盯着的地方。评测集不需要大，但要覆盖真实场景里那些容易被绕过的提问。
所以，判断要不要做模型微调，我倾向于把它当成一个排除法的结果：提示词试过、检索补过、评测集建好，仍然存在稳定的行为偏差，再动权重。走偏的项目，多数不是栽在训练阶段，而是栽在决定要不要训练的那一刻。