把一段内部工单描述贴给通用模型，让它判断问题类型。模型回答得很流畅，却把一句行话理解成另一个意思。这时很容易冒出一个念头：是不是得做个微调？这个反应很常见：一旦通用模型在具体业务里露出偏差，微调就会被端上桌。但端上桌之前，值得先问一句，偏差到底来自哪里。
很多偏差并不来自模型“懂得少”，而是任务没有被讲清楚。提示词含糊、输入格式漂移、分类口径前后不一致，都会让模型在边界上摇摆。此时先补任务说明、固定输入结构、用检索把内部资料带进上下文，往往能暴露真正的问题。模型微调更像是把这些前置工作做完之后，仍然存在稳定偏差时的一种手段。它不负责替人定义业务规则，只负责让模型更贴近一组已经定义清楚的示例。
微调改变的是习惯，不是知识库
把模型微调理解成“往脑子里塞资料”，容易失望。它更接近用一批输入与输出示例，调整模型对任务形式、语气、标签边界的反应。比如同样的工单，希望模型按内部字段输出，而不是自由发挥；同样的客服回复，希望语气稳定、格式固定。这类“习惯性”要求，适合用示例去塑造。若目标是让模型记住不断更新的产品文档，微调未必顺手，检索和版本管理更直接。两者并不互斥，只是解决的问题不同。
数据准备是微调里常被低估的部分。示例不需要多到夸张，但需要一致。同一类问题，标注口径今天一个样、明天另一个样，模型学到的就是摇摆。一个实用做法是先做小批量试标，把分歧摊开讨论，再决定标签体系。否则训练损失看起来顺眼，上线后仍会在真实输入上犯错。这里没有神秘技巧，更多是耐心。
验证要回到业务现场
微调之后，离线指标好看并不等于可用。需要把模型放回具体流程里看：它是否在边界样本上稳定，是否学会了不该学的捷径，是否对输入噪声过度敏感。验证集要尽量贴近真实分布，也要保留一些“不常见但重要”的样本。否则模型可能把高频模式学得很熟，却在少数关键场景里失手。
另一个常被忽略的问题是维护。业务口径会变，示例也会过期。模型微调不是一次交付就结束的动作，它需要版本记录、回归检查和退出机制。若团队没有准备好吃这些维护成本，先把提示词、检索和规则约束做扎实，可能更务实。
所以，当通用模型听不懂行话时，模型微调可以是答案之一，但不该是条件反射。先判断偏差是表达问题、知识更新问题，还是任务习惯问题。不同问题对应不同工具，混在一起谈，容易把微调变成一把看起来很专业的锤子。