一个客服团队想把回复写得像自己人：少一点模板腔，多一点业务语境。他们先想到模型微调，仿佛只要喂进一批历史对话，模型就会自动学会。真做起来，问题往往不在训练脚本，而在训练之前：要改的是知识，还是表达习惯？
先分清“知道什么”和“怎么说”
通用模型缺的常常是私有资料，这种情况下，检索或把资料放进上下文是直接路径。模型微调改变的是模型参数，它常被用来教一种稳定的行为：固定格式、特定口吻、对边界情况的处理方式。换句话说，它像把操作规程写进手感里，而不是临时翻手册。知识频繁变化时，微调未必跟得上；行为需要长期一致时，它才有位置。
数据要像任务本身
准备样本时，数量不是唯一尺度。需要看的是覆盖：用户会怎么问，模型该怎么答，哪些答法必须避免。只收“标准答案”，模型可能学会漂亮的结论，却没见过真实提问里的省略、错别字和前后矛盾。样本里如果混入过时规则，微调也会把这些偏差固化下来。数据清洗、标注口径、边界样例，这些工作在训练前值得花时间。
- 这条样本对应的是哪类真实任务？
- 答案里的语气和格式，是否代表团队想长期保持的做法？
- 遇到不确定的问题，期望模型拒答、追问，还是给出范围？
评估要放在训练之前
不少团队等到模型训完才想怎么验收，结果只能凭几段对话“感觉还行”。一种做法是先写评估集：把常见问题、边界问题、容易混淆的问法放进去，明确可接受和不可接受的反应。模型微调不是一次性的开关，它需要和提示、检索、人工复核一起被观察。若评估只看回答是否流畅，很容易忽略格式漂移或过度自信。
我的判断是，模型微调适合任务形状相对稳定、且已有可靠样本的场景。它不该成为“别人都在做”的默认动作。先问清楚要改变的是知识还是习惯，再决定要不要动参数；很多问题，在数据和使用方式上就能找到别的解法。