通用模型写一段产品介绍，往往像模像样；可一旦进入客服对话、工单分类或内部知识问答，它又常冒出“听得懂却答不准”的尴尬。有人把原因归给提示词，有人干脆提议做模型微调。先别急，这个动作值得拆开看。
模型微调不是给模型“补课”那么简单。它像是拿一批贴近任务的样本，让通用模型在输出风格、格式约束和判断边界上向业务现场靠拢。它擅长处理稳定、重复、有明确输入输出关系的任务，比如固定口径的意图分类、结构化抽取、语气统一的回复草稿。如果问题核心是资料太新、太多、经常变，单靠微调未必顺手，检索或知识库更新可能是一条直接路径。
先分清：要它“知道”，还是让它“照着做”
很多需求听起来像知识问题，实际是行为问题。业务人员说“模型不懂我们的流程”，可能指它不知道新政策，也可能指它总把回答写得太长、漏掉必填项、用错称呼。前者可以交给检索，后者才接近微调要解决的范畴。把两类问题混在一起，容易得到一种错觉：样本喂了不少，上线后还是不对。
另一个常被忽略的点是任务边界。微调适合边界相对清楚的任务；如果业务规则每天变、例外情况层出不穷，模型很难靠一次训练追上变化。此时反复训练未必有效，先把规则拆成可维护的流程，再决定哪一段交给模型。
数据准备容易只盯着数量
标注时，数量容易占满注意力。但微调真正吃的是样本和任务是否同构。一条样本如果标注口径不一致，或者只覆盖顺利场景，模型学到的可能只是表面格式。相反，少量高质量、覆盖关键边界的样本，也可能让输出稳定下来。这里没有通用配方，只有一条朴素原则：样本要能代表上线后真正会遇到什么。
还要留出一部分不参与训练的数据做检查。不是为了追求漂亮数字，而是看模型有没有把不该学的东西学进去，比如把某类固定话术套到所有问题上。评估集需要包含正常问题、边界问题和容易混淆的问题，否则上线后的偏差很难提前发现。
微调之后，维护才刚开始
很多人把训练完成当作终点。实际使用中，业务话术会变，产品名称会调，用户提问方式也会漂移。微调留下的是一版参数，不是一套自动更新的业务规则。需要有人记录训练数据版本、评估结果和上线表现，出现偏差时能判断是数据旧了、任务变了，还是输入分布变了。
成本也常被低估。数据清洗、标注、评估、回归检查，都是持续投入。如果任务低频、变化快，维护成本可能超过收益。反过来，如果任务高频、边界稳定、错误代价可控，微调就有机会成为流程里安静的一环。
决定开训之前，可以先问几个问题
- 模型现在错在哪：是缺少资料，还是不遵守输出约束？
- 任务边界是否稳定，例外情况能否被清楚描述？
- 是否有能代表真实场景的样本，并留出独立评估集？
- 上线后由谁维护数据、版本和回归检查？
这些问题没有统一答案，但它们能帮团队避开“先训练再说”的惯性。模型微调是一种适配手段，不是所有业务问题的默认解。它适合放在任务清楚、数据能反映现场、维护责任明确的位置；如果这些前提还不成立，先把问题拆清楚，再决定是否开训，往往能省下不少返工。