一个做售后工单系统的团队曾问过我：手头只有八百多条历史记录，能不能靠模型微调做一个自动分类器。这个问题本身不新鲜，值得说的是他们接下来的补充——「效果不好就再多标一点」。这种把微调当成通用解法的直觉，在不少项目里都能见到。它往往不是技术判断，而是对不确定性的回避。
先弄清微调在改什么
预训练模型在海量文本上学到的是通用语言规律，但它并不知道某家公司把「退换货」叫「返修回流」，也不知道工单里的「已催」在业务上意味着什么。模型微调用一批带标签的样本继续训练，把这类局部知识压进参数里。和只改提示词相比，它的好处是稳定：同一类输入反复出现时，输出不容易随措辞漂移。
代价也在这里。参数一旦被改动，模型的行为就不再只由提示词决定，而是由训练数据、学习率、训练轮数共同塑造。出了问题，排查路径比调提示词长得多。
八百条数据够不够，取决于问题有多窄
数据量从来不是孤立指标。判断标准更接近：标签体系是否清晰、类别之间是否真的可分、样本是否覆盖了主要表达变体。如果只是把工单分成「咨询、投诉、催办」三类，且每类内部表达相对集中，几百条经过清理的样本有可能支撑一个可用的小模型。反过来，如果类别边界本身模糊，比如「体验问题」和「服务问题」经常同时出现，再多的数据也只是把模糊放大。
我通常建议先做一件看起来笨的事：人工抽一百条，让两个人独立标注，看一致率。分歧大的地方，往往就是微调之后模型最容易出错的地方。这一步不花算力，却能省掉后面大量返工。
评估集比训练集更值得花时间
很多微调项目失败，不是模型没学会，而是没人说得清「学会」的标准。训练损失下降并不代表业务可用。需要准备一份和训练数据不重叠的评估集，按真实分布采样，并且保留那些模棱两可的样本——它们才是上线后最常遇到的输入。
评估指标也要贴着场景选。分类任务里，整体准确率容易被大类稀释，小类别的召回情况反而更关键。工单场景中，把投诉误判成咨询，代价明显高于反过来。这些取舍应该在训练前就想明白，而不是等模型跑完再解释结果。
微调之后的隐形成本
模型上线只是开始。业务话术会变，产品线会调整，新出现的表达方式会逐渐偏离训练分布。一个微调模型如果没人维护，半年后效果下滑是常见现象。所以决定做之前，最好先回答：谁来定期补充样本，谁来判断是否需要重新训练，版本怎么回滚。
另一条常被忽略的路径是，先把问题拆小。与其一次性微调一个多分类模型，不如先用规则或检索处理高频、边界清楚的场景，把微调留给真正需要语义判断的部分。这样即便模型表现一般，整体系统也不至于停摆。
什么时候不必微调
如果任务只是格式转换、关键词抽取，或者样本量少到无法覆盖主要变体，提示词工程加人工复核往往更划算。模型微调的优势在于把稳定的领域判断固化下来，而不是替代对问题的理解。把它当成第一步，容易在一开始就背上不必要的维护负担；把它当成在明确边界后的选择，才更接近它的实际价值。
回到那个工单团队，他们后来先做了标注一致性测试，发现有两类工单在业务定义上本就重叠，于是先改了分类口径，再谈训练。这个顺序调整没有用到任何模型，却可能是整个项目里最关键的一步。