一个常见场景：团队把通用助手接进内部知识库，回答语法通顺，却总在术语和流程上“偏题”。第一反应是找一批问答对做模型微调。这个动作很直观，仿佛把通用能力重新拧一遍，就能贴合业务。实际落地时，真正的问题往往不在模型，而在需求没有被说清楚。
先判断是“不会”，还是“不知道”
通用模型缺少的是能力，还是缺少当前业务里的上下文？如果是后者，检索增强、提示词模板、结构化输出约束通常先能解决不少问题。它们改的是输入与流程，不碰参数，迭代快，出错也容易回退。把这类问题交给模型微调，像用重装修解决门牌号写错：动作大，定位未必准。
它到底改了什么
模型微调的本质，是用一批相对稳定的样本继续训练，让模型在特定任务上形成更固定的表达或判断习惯。它适合风格统一、格式稳定、任务边界清楚且样本可重复的场景。比如把内部工单转成固定字段，或让助手长期遵循某种回复口吻。代价也在这里：样本里的偏差会被一起学进去，后续维护需要版本和评估记录，不能只凭几次聊天感觉。
数据不是越多越安心
准备数据时，常有人追求数量，却忽略样本之间是否一致。同一类问题出现两种相反答案，再大的数据量也会把模型推向模糊。我的做法是先收窄任务，只覆盖高频、边界清晰的场景，把例外留给规则或人工。训练集、验证集要分开，评估不只看答案像不像，还要看字段是否正确、拒答是否合理、异常输入会不会崩。没有这套检查，模型微调很容易变成一次昂贵的碰运气。
边界比热情重要
还有一种情况值得警惕：业务规则还在快速变化。今天整理的样本，下个月流程就可能改。此时把规则压进参数，反而增加维护负担。先用可读的配置、检索和提示词把流程跑顺，等任务稳定后再考虑把训练环节加进来，符合工程节奏。它不是万能按钮，也不是禁区，只是一项有维护成本的技术选择。