内部评审会上，有人把一份问答清单推到桌边：通用模型回答行业术语时总像隔着一层玻璃，能不能用模型微调解决？这个问题听起来直接，实际要先拆一层。
微调改变的是模型对任务形式的适应，不是把一批文档塞进参数里就自动获得事实库。若缺的是新近规则、产品参数、内部流程，检索增强往往合适；若缺的是稳定语气、输出结构、领域表达习惯，模型微调才有发挥空间。两者混在一起谈，项目容易从“试试看”变成“反复打补丁”。
先分清，缺的是知识还是表达习惯
一个常见的误判，是把所有“答得不对”都归因于模型不懂业务。实际排查时，可以把问题分成几类：答案里有没有不存在的事实，格式是否稳定，术语是否统一，遇到长上下文时会不会漏掉关键条件。事实类问题可以交给外部知识源；格式和表达习惯，则落在微调擅长处理的范围内。
数据准备也不只是“多找些样本”。指令与回答是否对应、边界条件有没有写清、错误示范会不会被一起学进去，这些细节决定结果是否可用。若样本里混着互相矛盾的口径，模型学到的不是业务能力，而是混乱。此时先做数据清理和任务定义，再决定是否启动模型微调。
把评估和维护放在开始之前
微调不是一次交付。业务话术会变，产品说明会改，用户提问方式也会漂移。若没有一组可重复的评估问题，团队很难判断一次更新是改善了任务适配，还是只让输出看起来像样。评估集不必宏大，但要覆盖常见任务、边界输入和容易混淆的说法，并保留人工复核的空间。
- 先确认问题类型：缺事实、缺格式，还是缺表达习惯。
- 再检查数据一致性：口径、边界和错误示范是否可控。
- 把评估与维护写进计划，避免上线后只靠感觉调参。
所以，模型微调更像一种有边界的工程手段，而不是让模型“懂行”的快捷按钮。它适合处理稳定的任务形式和表达偏好，却替代不了知识更新、权限控制和流程约束。把适用条件说清楚，才算负责任的做法。