一个做工业设备售后的团队曾遇到这样的场景：通用模型能解释常见故障，却总把内部工单里的缩写认错，回复格式也忽长忽短。有人提议“上模型微调”，仿佛训练一轮就能解决。真正开工前，更值得先问：问题出在知识缺失，还是出在表达习惯？
如果模型不知道最新备件编号，微调未必合适，检索增强更直接；如果它知道概念，却总不按工单模板回答，或者对行业语气把握不稳，模型微调才更有用武之地。它像给模型补一段专门的行为训练，而不是把整本手册塞进参数里。
它改的是“怎么做”，不只是“知道什么”
预训练让模型获得通用语言能力，微调则用一批带示例的输入输出，把某种任务模式压进模型。比如把口语描述改写成工单摘要，把长文压缩成固定字段，或让客服回复更贴近团队语气。样本不需要海量，但必须干净、一致，能代表真实输入。若示例本身混杂，模型会学到模糊甚至矛盾的规则。
这也是模型微调常被误解的地方：它不保证事实永远正确，也不替代权限、审核和知识更新。它擅长让输出更稳定地符合某种格式和判断边界，却不擅长凭空记住频繁变化的信息。
准备数据时，先准备评估
不少团队把精力放在收集样本，却忽略“怎样算变好”。如果没有一组固定的验证问题，训练完成后只能凭感觉判断。更稳妥的做法是先定义可观察的失败类型，再准备少量对照样本：格式是否合规、术语是否准确、拒绝是否得当、语气是否越界。
- 样本要覆盖真实分布，而不只是容易回答的问题。
- 输入输出要统一，别让相似问题对应互相冲突的答案。
- 保留一部分不参与训练的样本，用来观察泛化表现。
- 把事实更新交给外部知识源，别指望一次训练解决所有变化。
边界清楚，微调才不变成负担
模型微调有维护成本。数据分布变化、业务规则调整、基础模型升级，都可能让原有训练结果需要重新检查。对小团队来说，先尝试提示词、结构化输出约束和检索，再判断是否值得进入训练流程，往往更务实。它适合那些任务边界相对清楚、样本可积累、错误代价可承受的场景。
回到开头那个售后团队，他们后来先把工单字段拆成模板，再用少量高质量示例做模型微调，同时保留检索来查最新备件信息。效果并非一劳永逸，但至少每次调整都有依据。模型微调不是“万能按钮”，而是一项需要问题定义、数据纪律和评估耐心的工程选择。