客服团队把内部工单术语整理成问答，交给通用模型回答，结果经常“语法正确、意思不对”。模型不是不聪明，它只是没在你们的语境里待过。这类落差，往往被归到同一个动作上：模型微调。
它改的是参数，不是把知识塞进去
预训练模型先在大规模语料上学会语言规律，模型微调则是在这组已有参数上，用相对小的领域数据再做一轮训练。数据量不必夸张，但样本得一致：同样的输入，标注口径要稳定。训练的目标不是让模型“知道更多”，而是让它的输出分布向特定任务靠拢，比如固定字段的抽取、内部标签体系的归类、某种语气下的回复。
这里容易混淆的是知识与行为。事实性知识更新频繁，硬写进参数既昂贵也难维护；让模型按你们的格式说话、按你们的判断标准打标，才是微调常被用到的部分。换句话说，它校准的是反应方式，不是百科条目。
先分清：问题是“不会说”还是“不知道”
很多团队一上来就想微调，其实先该判断任务能不能用提示词稳定描述。如果能，提示工程加检索增强往往成本较低；如果输出结构复杂、判断标准藏在老员工的经验里、提示词写到几百字仍不稳定，微调才有讨论价值。检索增强解决“查得到”，模型微调解决“做得像”。两者不冲突，但顺序搞反，容易把预算花在错误的地方。
数据这关，比算力更难绕
领域数据通常不长在标准格式里。标注者对着同一句话给出不同标签，训练出来的模型就会学到一个模糊边界。长尾样本少、负样本缺失，也会让模型在常见输入上表现正常，一遇到边角情况就失准。另一头是过拟合和灾难性遗忘：训练太久，模型可能把训练集背下来，却丢掉原本的通用能力。
这些问题不靠调参就能消失。比较稳妥的做法是先留出与训练集不同来源的验证集，把验收标准写在训练之前，而不是训练之后看着结果找理由。
几个可以先问自己的问题
- 这项任务的正确与否，能不能用几句话稳定判定？
- 相关知识是否经常变化，变化后有没有人负责重新训练？
- 错误输出的代价有多大，能不能用人工复核兜底？
- 团队是否愿意长期维护一份标注规范，而不只是跑一次训练？
如果答案模糊，模型微调大概率不是第一步。它更像把经验固化成参数的手艺，适合边界清晰、变化不快、验收可量化的场景。它的代价不在训练那几天，而在之后持续的数据维护和版本管理。它是一把需要保养的工具，不是万能钥匙。