不少团队第一次想到模型微调，是因为通用模型在业务语境里总差一口气：话都懂，落到具体流程却答得泛。于是有人期待把内部文档喂进去，让模型从此“学会”业务。这个期待里有一半对，也有一半需要拆开看。
它改变的是回答习惯，不是知识库存
模型微调用的是带示例的训练数据，让模型在已有能力上调整输出倾向。它影响的是“怎么答”，比如用哪种语气、按什么格式、在什么情况下收住，而不是保证“知道所有事实”。把文档直接倒进训练数据，模型未必能准确复述，还可能把零散说法学成固定口吻。
如果目标只是让模型回答最新制度、产品参数或常见流程，检索增强是另一条路径：资料更新时改知识库，不必重训。它适合把一种稳定的表达方式、判断边界或任务格式固化下来。两者并不互斥，很多场景会先用检索补知识，再用训练调行为；顺序取决于任务，而不是概念本身。
数据准备先管住一致性
准备数据时，容易陷入“越多越好”的惯性。示例要覆盖真实任务，包含普通问法、含糊问法、边界问法；答案风格要一致，格式要能复核。如果标注者各自发挥，模型会学到摇摆的口吻。另一个常被忽略的点是边界样本：告诉模型什么不该做，和告诉它什么该做同样重要。
还要留意数据里的旧说法。微调不会自动纠偏，如果训练材料混入过时规则，旧习惯可能被学得更牢。所以数据整理不是把文件堆进表格，而是先定义什么算合格回答，再决定拿哪些示例去训练。
上线之后才是麻烦的开始
微调不是一次交付。业务规则变化、产品迭代、用户问法迁移，都会让训练数据慢慢过期。每次调整都要留下版本记录，保留评估集，观察模型在新问法上的表现。评估不能只看“像不像人写的”，还要看任务是否完成、边界是否守住、格式是否稳定。缺少标注和评估的人力时，可以先做提示词和检索，再决定是否动手。
先拆任务，再决定要不要动手
一个务实的判断方法是：把任务拆成知识、格式、判断三层。知识靠检索和知识库；格式靠提示词和少量示例；判断若涉及稳定的业务边界和表达风格，才考虑模型微调。这样看，模型微调不是万能开关，也不是过时手艺，它只是把行为调得更贴近业务的一种手段。真正要回答的问题不是“要不要微调”，而是“哪一层真的需要被改变”。