一个内部知识问答项目里，通用助手回答制度流程时总绕开公司缩写。团队下意识想“微调一下”。先别急，得看清问题属于哪一类。
先分清：要它记住，还是要它改变回答方式
模型微调是用一批输入输出示例继续训练，让模型形成任务习惯：语气、格式、拒答边界、特定映射。若只是补最新文档、产品参数，检索增强可能直接；知识频繁变化时，把事实压进参数会带来更新负担。
数据不是堆出来的，边界要清楚
准备样本时，一种省事做法是把历史聊天全倒进去。模型微调需要的是干净、稳定、能代表目标任务的示例。要标注什么该答、什么该拒答、答到什么颗粒度。样本里混着旧口径和互相矛盾的回复，模型学到的也是摇摆。少量高一致样本能说明问题，前提是前期有人做清洗和判断。
评估要像验收，不像许愿
训练损失下降不代表业务可用。把真实任务拆成小测试集：格式遵循、术语解释、拒答边界、长尾表达。每次改动前留一组固定问题，观察输出是否稳定。模型微调之后，若只盯着几个顺眼回答，容易忽略回归问题。要记录失败样本，判断是数据缺口、提示词还是检索上下文导致。
维护成本常被漏算
- 版本管理：数据、配置、模型产物要能追溯；上线不是终点。
- 更新节奏：业务口径变了，是改数据重训，还是先用检索补？先设规则。
- 责任边界：谁审批样本、谁验收输出、谁处理误答，别等上线后再分工。
所以模型微调更像一项产品决策，不是一次训练脚本。它适合把稳定任务的行为收敛，不适合替代知识库，也不负责解决所有幻觉。先回答三个问题：任务是否稳定、样本是否可信、评估是否可重复。答案含糊时，先把提示词、检索和流程做扎实，再考虑动参数。这个顺序能省下不少返工。