知识库刚改完，问答机器人仍然把旧流程背得滚瓜烂熟。有人第一反应是“做个模型微调”，把它按新资料重新训一遍。这个念头很自然，却常常把问题带偏：如果变的是频繁更新的业务事实，微调未必是合适的入口；如果变的是表达方式、判断口径和输出格式，它才更值得摆上桌面。
先分清“不知道”和“不会说”
模型答错，原因不止一种。资料没给到，是检索和知识组织的问题；资料给了却答得散，是提示设计和上下文组织的问题；资料清楚、要求也明确，输出仍然带着一股通用助手的腔调，或者总在格式上漏项，这才接近模型微调擅长的范围。它更像在教模型一种稳定的做事习惯，而不是往脑子里塞一份随时会过期的文件。
它改的是习惯，不是数据库
把微调理解成“给模型补课”，容易忽略它真正改变的东西。示例数据反复呈现某种回复结构、术语习惯和边界处理方式，模型会沿着这些痕迹调整输出。但它不保证记住每一条新事实，也不擅长承担高频变动的知识查询。把产品价格、政策条款、库存状态这类内容压进参数里，后续维护会变得笨重；用检索把最新信息放到上下文里，通常更直接。这里的判断不涉及技术新旧，只关乎维护成本。
另一个常被低估的点是数据。一批随手整理的问答，很难覆盖真实使用中的长尾表达。用于模型微调的样本需要一致的口径、清楚的边界和足够的反例，否则模型学到的可能是标注者的口头禅，而不是业务要求。数据清洗和评估设计听起来不热闹，却决定了这次训练是在解决问题，还是把问题藏得更深。
训练之后，别只看“像不像”
评估阶段容易陷入主观印象：回答更像客服了，语气更顺了，于是判断训练成功。但上线后真正要看的，是格式是否稳定、关键信息是否遗漏、遇到不该回答的问题是否收住、旧能力有没有被挤掉。可以准备一组固定问题，覆盖常见请求、边缘表达和拒答场景，在训练前后做对照。这里不需要复杂仪式，关键是别用几条演示样例替代真实分布。
还有一个现实边界：模型微调不是一次性工程。业务口径变了、输出模板改了、用户提问方式迁移了，训练数据也得跟着维护。若团队没有持续整理样本和复评结果的耐心，微调带来的收益很快会被新的偏差抵消。与其把它当作“上线前的一次性动作”，不如视为一套需要版本记录和回归检查的日常机制。
所以，当通用模型答非所问时，先别急着训练。把知识更新、提示约束、数据质量逐项排开，确认问题确实落在稳定行为上，再考虑模型微调。它解决的是“习惯”问题，不是所有“不知道”的问题。这个边界想清楚，训练才不至于变成一场昂贵的自我安慰。