一个团队把通用模型接进内部问答，试了几轮后发现问题很具体：回答读起来通顺，却总在关键术语上绕开，输出格式也时好时坏。于是有人提议做模型微调。这个反应很自然，但我会先停一下：眼前要改的，究竟是模型不知道，还是它没有按你的方式说？
先把“答得不对”拆成几类
知识缺失、格式不符、判断标准不同，看起来都像“模型不够聪明”，处理路径却不一样。频繁变化的制度、产品参数和内部文档，靠检索把最新内容带进上下文通常更稳妥；如果问题是语气、字段顺序、固定分类口径，或者同一类输入需要稳定的输出模式，模型微调才值得进入讨论。
- 它是否知道这条信息，还是知道但不会按你的格式表达？
- 错误是否集中在少数边界场景，能否用规则或提示先覆盖？
- 团队是否有一批一致、可复核的输入输出样本？
微调改的是倾向，不是知识库
模型微调用带标注的样本继续训练，让模型更倾向于某种回答方式。它更像在教模型形成习惯，而不是把一堆文档原样塞进参数里。因此，样本里如果混入互相矛盾的标注，模型学到的也会是模糊的边界。清理数据时，反例和边界样本往往比漂亮的标准答案更有信息量。
评测没想清楚，训练越久越难收场
做模型微调之前，至少留出一批不参与训练的检查样本，按业务关心的维度逐项看：字段是否齐全、术语是否一致、遇到不确定问题时是否肯说不知道。上线后还要观察输入分布有没有变化，因为用户提问方式会漂移，原本有效的样本会慢慢偏离真实场景。基础模型更新时，旧适配也需要重新跑一遍评测，不能默认它仍然适用。
边界比效果更值得先写下来
微调不能保证事实正确，也不适合承担实时信息的准确性。涉及高风险判断或合规要求的环节，仍要保留人工复核和可追溯记录。对小团队来说，更实际的做法是先做小规模实验：限定任务、限定输入范围、设定停止条件。如果试验只提升了格式一致性，却没有减少人工返工，那它还不算解决问题。
我会把模型微调放在问题界定、数据整理和基线评测之后。它不是起点，而是一种工程选择：当任务稳定、样本可控、评测能说清楚时，它才有意义；否则，先修数据和流程，往往比急着训练更接近答案。