有个场景反复出现：团队在通用模型上试了两周，输出时好时坏，会议结论很快落到一句话——「做个模型微调吧」。这句话说得太顺，以至于很少有人停下来追问：现在的毛病，究竟是模型不知道，还是模型知道却没照着做。
先分清「不知道」和「不照做」
前者是知识缺口。内部流程、产品口径、刚改过的规则，通用模型没见过，硬问只能得到似是而非的答案。后者是行为约束，模型其实懂，只是输出格式、语气、判断尺度不合你的要求。模型微调擅长的是后者：把某种输出习惯压进权重里，让它在同类输入上稳定复现。
如果你要的其实是新知识，检索增强往往省事一些——文档改了，效果跟着改，不必重训一遍。把这两件事混在一起谈，是很多方案走偏的起点。
微调改的到底是什么
通俗讲，是在已有权重的基础上，用一批「输入—期望输出」的样本继续训练，让参数朝你的任务偏移。全参微调动全部权重，算力开销大；参数高效的方法只训练少量附加参数，对资源有限的团队更现实。选哪种取决于任务形态和数据规模，没有一个放之四海的答案。
比方法更决定结果的，是数据。几百条干净、边界清晰、口径统一的样本，常常比几千条来源混杂的样本管用。动手前值得自查一遍：这些「正确答案」是唯一解，还是一类解？如果几个标注的人自己都谈不拢，模型学到的只会是噪声。样本里的重复句式和模板化表达也要清理，否则模型会连这些一起记住。
两笔容易被低估的代价
- 遗忘。模型在你给的数据上变得听话，也可能在别处变得迟钝。训练结束后，除了目标任务，最好抽一批通用问题做回归，看看有没有被带偏。
- 维护。微调不是一次性交付。数据分布变了、基座模型迭代了，旧权重可能不再匹配，流程要重跑一遍。这笔长期成本在立项时常常被忽略。
什么时候值得动手
我倾向于三个条件同时成立再开始：任务形态相对稳定，输出格式和判断标准短期内不会反复改；提示词怎么调都差一口气；手头有可持续产出的标注数据。缺一个，都建议先用更轻的方式验证，比如把需求拆细、把示例写足。
反过来，如果业务还在快速试错、需求每周翻新，微调带来的那点稳定性，很快会被迭代成本吃掉。模型微调本质上是把经验固化下来的手段，它解决的是「反复叮嘱也没用」的问题，不是「模型不够聪明」的问题。想清楚这一点，往往能省下几周时间。