一个常见场景是：通用模型回答产品问题时像模像样，可一放进工单系统，语气、字段和边界都开始飘。团队第一反应是收集一批问答做模型微调，结果格式稳了，遇到新问题却更爱往旧样本上靠。这个反差，几乎是观察微调项目时最常见的入口。
模型微调改变的不是“知识库容量”，而是模型对任务的行为倾向。它把一批输入输出关系压进参数里，让模型更习惯某种问法、某种结构、某种判断路径。资料随时会变，行为习惯相对稳定，这两件事最好分开看。
先分清记忆和习惯
如果团队想让模型记住最新价格、活动规则、内部文档，检索往往更直接：资料更新，问答跟着更新，出错也容易定位。若目标是让输出稳定成固定字段、固定语气，或者把一段模糊需求转成内部可执行的分类，微调才更接近问题本身。
这不是说检索和提示工程更“高级”，而是它们处理的是不同层面。把资料更新问题硬塞给模型微调，训练完看着顺眼，维护时却要反复补样本，成本和漂移都会回来。
回答变窄，通常窄在数据边界
微调后的回答变窄，常见原因不是模型“学坏了”，而是样本把任务边界画得太死。样本只覆盖少数场景，模型就容易把相似问法都往已知答案上归；样本语气单一，输出也会显得僵硬。更隐蔽的是，样本里的错误和偏见会被一起学进去，表面看是风格统一，实际是把判断口径固化了。
- 样本是否覆盖了任务的主要分支，而不只是常见问法；
- 输出格式是否必须固定，还是可以由提示约束；
- 错误样本有没有被清理，边界案例有没有留下说明；
- 上线后是否有回退路径，能区分资料问题和行为问题。
评估别只看“像不像”
判断一次模型微调是否值得，不能只看几条回答顺不顺眼。更实用的做法是留一组没有参与训练的问题，观察模型在边界处的反应：该拒答时是否拒答，该追问时是否追问，格式稳定之外有没有丢信息。若业务允许，把微调和检索、提示约束放在同一批问题上对照，比单看训练损失更有意义。
我的判断是，模型微调适合解决“行为不稳定”，不适合替代“资料会过期”。先把任务拆成记忆、习惯和边界三层，再决定要不要动参数，很多项目会少走一段弯路。