有人拿通用大模型做客服回复，提示词改了十几版，格式还是时对时错，语气也在正式和随意之间摇摆。团队里大概率会有人提出：是不是该做一次模型微调？
这个反应可以理解。但微调经常被当成一个万能按钮，按下去就期待问题消失，实际情况往往不是这样。
模型微调改的是权重，不是需求
它做的事情很朴素：在一个已有模型的基础上，用自有数据继续训练一轮，让模型的输出行为往某个方向偏一点。和写提示词的区别在于，提示词在推理时起作用，随时可改；微调把偏好写进了参数里，改起来要重新训练。
它和检索增强也不是一回事。后者是在提问的那一刻把资料喂进去，模型本身不动。这个区别带来一个直接后果：微调适合承载“行为”层面的一致性，比如输出结构、语气、术语习惯；不适合承载会频繁变动的事实。把产品价格表训进权重里，明天改价就得重来。
什么情况下值得投入
- 输出结构固定，对稳定性要求高，靠提示词反复约束仍然会漂移。
- 领域里存在大量专有表达，通用模型经常用错词、说外行话。
- 受部署条件限制，需要在参数规模较小的模型上补齐一部分能力。
这几条的共同点是：问题稳定、样本可得、好坏有明确的判断标准。三条缺一条，投入就容易变成一次性实验，做完没人维护。
代价常常不在训练本身
数据是最容易被低估的部分。几百条样本听起来不多，但要覆盖真实输入的分布，清洗、去重、剔除互相矛盾的标注，往往要来回筛好几轮。样本质量差，训练过程照样能跑完，只是结果没法用。
另一个容易忽略的点是遗忘。模型在专门数据上训练久了，原本的通用能力会退化，通常的做法是在训练数据里混入一部分通用样本，但混多少、怎么混，没有通用答案，只能试。
还有评估。模型改完之后是变好还是变坏，如果没有一套固定的评测集，判断就只能靠感觉。感觉在小规模试用时够用，到了要持续迭代的时候会不断放大成本——你无法确认下一次改动到底动了什么。
维护成本同样实在。基础模型版本更新甚至下线，微调产物往往要重做一遍。这笔账在立项时很少有人认真算。
先排除那些不是模型的问题
需求本身没写清楚、同一类输入在业务上就有两种处理方式、流程里缺了人工校验环节——这些都不是训练能解决的。把含糊的需求喂给模型，得到的只是一个更稳定地含糊的输出。
比较务实的顺序是：先把提示词和外部检索做到位，收集失败样本，看它们集中在哪里。如果错误集中在知识内容上，那是资料供给的问题；如果集中在表达形式和风格一致性上，模型微调才真正进入考虑范围。
说到底，微调不是让模型变聪明，而是让它更贴合你定义清楚的那套行为规范。它值得做，但值得在被想明白之后再做。