客服团队把一段对话记录丢给通用模型，让它按内部规范回复。模型措辞礼貌，格式也对，但把“工单闭环”理解成“问题结束”，忽略了回访确认。类似偏差不常出现在公开语料里，却会反复出现在日常业务中。于是有人提议做模型微调。这个动作听上去直接，真正落地前却要先回答一个问题：缺的到底是知识，还是行为。
先分清“知道”和“照做”
通用模型见过大量文本，对常见概念并不陌生。它缺的往往不是名词解释，而是组织内部约定俗成的表达、固定输出格式和判断顺序。把产品手册塞进提示词，可以缓解一部分问题；当提示词越写越长、示例越堆越多，仍难以稳定复现时，模型微调才值得进入讨论。它更像是在既有能力上调整习惯，而不是往模型里灌一套实时知识库。
- 如果问题是信息更新频繁，优先考虑检索或外部数据接入；
- 如果问题是语气、格式、步骤长期固定，微调才有发挥空间；
- 如果问题是事实准确性要求高，评估与兜底机制不能缺席。
数据不是“越多越安心”
准备训练样本时，容易陷入两个极端：一是把聊天记录原样导出，二是只挑漂亮回答。前者混入噪声、重复和前后矛盾；后者让模型学到理想化表达，却见不到真实边界。更稳妥的做法是先定义任务，再收集能覆盖典型输入与边缘输入的样本，统一标注口径，并留出独立验证集。样本量不必追求夸张，但一致性要经得起复查。对于参数高效微调，小规模高质量数据也可能带来可见变化；具体效果仍取决于任务、基础模型和训练配置，不能一概而论。
评估要盯住失败方式
微调后的模型可能更贴合格式，却在陌生问题上更自信地犯错。因此评估不能只看回答像不像样例，还要看它在未见过输入上的表现、拒答边界和稳定性。可以设置人工复核，把“格式正确但事实错误”“语气合适但遗漏步骤”分开记录。模型微调不是一次性交付，它需要和提示词、检索、审核流程一起迭代。若缺少持续观察，训练损失下降并不等于业务风险下降。
回到开头那个客服场景，真正要修的可能是流程定义和样本标注，而不只是模型参数。模型微调可以成为整理业务经验的一种方式，但它不该替代对问题的拆解。先想清楚要改变哪种行为，再决定是否动训练。