先把缺口分清楚
把一个通用模型接进内部系统，最常见的失望是它答得“隔一层”：产品代号认不出，流程顺序记不住，输出格式每次都不一样。遇到这种情况，很多人第一反应是拿去训练，但这里其实混着两类问题——模型没读过你的资料，和模型读懂了却不肯按你的方式来。
如果是前一类，靠检索把文档放进上下文通常更划算：改文档就生效，不用重训，出错也容易追查。后一类才轮到模型微调：固定字段、收住语气、按内部那套判断顺序走。这些要求写进提示词也能奏效，但常常是几十条规则互相打架，换个问法就散架。
它教的是形式，不是事实
微调调整的是权重，效果是让模型在相似输入下更倾向某类输出。它能学会“看到这种问题先给结论再给依据”，学会把一段自由文本压成固定字段，学会在模糊时主动追问。但它不适合用来灌入会变动的知识：价格改了、流程改了、条款改了，权重里的东西没法单点修改，只能重来一遍。
数据这一环最容易被低估。几百条高质量样本，常常比几千条随手攒的有用，因为模型学的是标注里的一致性，而人工标注时的分歧会原样变成模型的摇摆。在把这批样本拿去做模型微调之前，值得先用提示词跑一遍，看看问题究竟出在知识缺失，还是出在表达约束。
- 样本要覆盖真实会遇到的长尾问法，而不是只挑好答的；
- 同一类问题给出结构一致的答案；
- 留一部分不进训练集，专门用来验收。
代价往往在训练之后才浮现
微调过的模型会往你的任务上偏移，代价是通用能力可能被拉低，也就是常说的灾难性遗忘。表现出来未必是明显错误，而是一些原本能做好的事情变得迟钝。所以除了任务本身的验收集，还需要一批通用任务做回归，确认没有把别处弄坏。
还有维护：数据更新要重训，重训要评估，评估要有基线，版本要能回滚。这些工作在项目立项时几乎不会被写进去，却决定了三个月后这套东西还能不能用。
所以在顺序上，我的倾向是：能用规则和结构化约束解决的，先用规则；能把资料放进上下文的，先做检索；只有当输出风格和判断路径本身成为瓶颈，再考虑模型微调。它更像一块收尾的补丁，而不该是起点。