一个常见的场景是：业务同事拿着通用模型试了几轮，演示时像模像样，放进真实流程却总在固定位置出错。回复格式少一个字段，术语前后不一致，遇到边界问题又绕回通用答案。于是有人提议，做一次模型微调。
这个提议不算离谱，但容易把问题想简单。模型微调并不是把业务知识整包塞进参数里，它更像用一批示例告诉模型：在这个任务里，什么样的输入对应什么样的输出。它调整的是行为习惯，不是给模型装一个随时可查的资料库。
先分清：错在行为，还是错在知识
如果问题集中在表达方式、输出结构、术语口径、拒答边界，微调有发挥空间。比如工单分类要稳定落到既定类别，文档摘要要遵守固定字段，内部问答要按约定方式说明依据。这类任务的关键是“照着做”，示例能帮上忙。
如果问题来自知识更新频繁、事实经常变化，单靠一次训练很难跟上。今天写入的参数，明天可能就过时。此时检索增强是一条自然路径：把最新资料放在外部，让模型在回答时引用。提示工程则适合约束简单、变化较快的场景，改一版上下文就能验证。三者不是互相替代的关系，边界取决于问题类型和维护成本。
数据会把矛盾一起教给模型
模型微调有一个容易被忽略的副作用：它会放大数据里的习惯，包括坏习惯。同一类问题，如果标注人员给了互相矛盾的答案，训练后的模型也可能在相似输入上摇摆。格式看似统一，实际藏着几种不同口径，上线后就会在长尾输入上暴露出来。
所以数据准备不是“凑够条数”就结束。任务定义要能落到可判断的输入输出；标注规范要覆盖边界情况；脱敏、授权和删除机制要在训练前想清楚。演示集里表现顺滑，不代表真实流量里稳定。评估集需要包含真实场景中的难例，而不是只挑模型已经答得顺的样本。
训练完成只是中间站
很多团队把训练完成当成项目结束，实际维护才刚开始。模型版本、训练数据版本、评估结果要能对应起来，出问题时可以回滚。上线后还要留监控：哪些输入触发拒答，哪些输出格式偏离，哪些类别被频繁误判。业务规则变了，评估集也要跟着变。
- 任务边界是否写清楚：哪些该答，哪些该拒，哪些要转人工。
- 数据是否一致：同类输入有没有互相冲突的标注。
- 评估是否贴近真实流量：难例、长尾、边界输入有没有覆盖。
- 上线是否有退路：版本、回滚、监控和回归测试是否就位。
回到开头那个问题。模型微调该不该上场，先看错在行为还是错在知识，再看数据能不能支撑稳定行为，最后看团队是否愿意承担持续维护。它是一次有代价的参数调整，不是给通用模型加一句“懂业务”的标签。想清楚这些，再决定要不要训练，能减少返工。