一个通用模型接进业务系统后，回答往往很顺，却总有些地方不对味：术语用错，语气不像自家，流程该先确认再执行，它却直接给结论。于是团队里很容易冒出一句：要不要做模型微调？
这个直觉并不奇怪。通用模型见过大量语料，但不了解某家企业的表达习惯和判断边界。问题在于，不对味的原因不止一种，模型微调也不是所有问题的统一答案。先拆开看，能省下不少后续维护。
先分清缺的是知识，还是表达方式
如果模型不知道最新资料、内部文档或产品细节，可以先用检索、上下文注入或外部知识库，而不是立刻改模型参数。知识会变，靠训练写进模型，更新周期长，也容易留下旧答案。若问题出在输出格式、语气、术语偏好、固定流程的判断顺序，那才更接近行为层面的调整，模型微调才有讨论空间。
这里有个容易被忽略的点：微调改变的是模型的行为倾向，不是给模型装一个可随时编辑的资料库。把文档直接喂进去，期待它记住每个细节，通常会失望。数据要能描述目标行为，而不是只堆内容。
数据要能描述目标行为
准备数据时，成对的输入输出能直接描述行为；单篇文档只提供内容。输入要覆盖真实使用中的问法，输出要体现希望模型学会的取舍：哪些信息该确认，哪些话不该说，格式如何收束。若标注口径不一致，模型学到的就是矛盾。数量之外，先检查样本是否稳定、边界是否清楚。
还要接受一个现实：微调之后，模型可能在别处变得迟钝。通用能力与专用行为之间需要权衡，评估集不能只看目标场景，也要保留一部分原有任务，观察是否出现意外漂移。这一步不做，上线后很难判断问题来自数据、提示词还是模型本身。
评估要换一把尺子
模型微调之后，语言流畅不再是主要指标。任务完成率、格式遵守程度、边界拒答是否合理，才贴近实际。评估样本要包含容易混淆的提问和少见但关键的场景。否则，模型可能学会了漂亮话，却没学会在不确定时停下来。
维护成本也要提前算。数据会更新，业务规则会变，模型版本需要记录，回滚路径需要保留。微调不是一次点击，更像一次承诺：承诺后续有人维护数据、重跑评估、管理版本。没有这部分准备，短期效果可能被长期维护拖住。
它更像一次承诺，而不是一次点击
我的判断是，先把问题拆成三类：知识缺失、流程约束、表达偏好。知识缺失先补检索与上下文；流程约束先看规则和工具调用能否解决；表达偏好且长期稳定，再考虑模型微调。这个顺序不是固定公式，但能避免把工程问题误当成训练问题。
把微调留到确实需要改变模型行为的地方；其余问题，先在数据和流程里找答案。这样看，微调不是让模型变聪明的按钮，而是一种有边界、有维护代价的适配手段。