一个常见的场面是：业务同事把几段失败对话贴过来，问“能不能微调一下就好了”。这句话背后往往混着两个问题：模型没听懂指令，还是它听懂了却不知道你们业务里的“正确”长什么样。前者可能靠提示词、检索或流程约束解决，后者才更接近模型微调要处理的范围。
它不是给模型补知识，而是改行为倾向
把微调理解成“往模型里灌资料”很容易失望。参数更新更像是在大量示例中调整模型对任务形式的反应：同样的问题，应该按什么口径回答，遇到模糊信息时先追问还是先假设，输出要保持怎样的语气和结构。它擅长让行为更稳定，却不保证事实新鲜，也不天然解决知识覆盖不全。若答案依赖经常变化的信息，检索、数据库或规则层往往更直接。
所以判断要不要做模型微调，可以先看任务是否稳定、输入输出是否可描述、错误是否集中在“做法”而不是“资料”。如果每次失败都来自不同原因，先补评估集比急着训练更有用。没有一组能反复验证的样本，微调很容易变成对少量例子的过拟合，表面顺滑，换个问法就露出原形。
数据质量决定它是修边还是添乱
微调的数据不一定要多，但一致性很重要。同一类问题，如果标注口径互相打架，模型学到的就是摇摆。与其收集大量“差不多”的问答，不如把边界样本写清楚：什么情况下必须拒答，什么情况下需要拆分问题，什么情况下要给出处。这些细节往往比漂亮的示范答案更能决定上线后的手感。
- 先定义可验收的输出，再决定是否训练。
- 把失败样本按原因分组，不要混在一起喂给模型。
- 留出未参与训练的测试集，观察它是否只会背答案。
- 记录数据版本和训练配置，方便回滚与复盘。
另一个容易被低估的成本是维护。业务规则变了，提示词可以当天改，模型微调却要重新整理数据、训练和验证。它更像一次有惯性的调整，不是随手拧一下的开关。团队若没有持续维护的打算，初期效果再好也可能在几周后变得尴尬。
先问清楚：非它不可吗
我的判断是，模型微调适合那些“风格与决策边界长期稳定、且能用示例表达”的任务，比如固定格式的文本整理、特定角色的回复规范、内部流程中的分类与抽取。它不适合拿来掩盖需求不清，也不适合替代实时查询。很多时候，提示词、检索增强和输出校验的组合更便宜，也更容易解释。
如果决定做，先把问题缩到一个小范围，用少量高质量样本验证方向，再谈扩大。不要用一次训练解决所有抱怨，也不要因为一次失败就否定它。模型微调只是工具箱里的一件工具，真正难的是把“我们希望它怎么做”说清楚。