如果你把通用模型接进内部知识库，常会看到一种落差：它能聊得头头是道，却总在业务口径上差半句。此时有人提议做模型微调，把样本喂进去，让模型“学会”你们的说法。这个判断不算错，但真正要问的是：差的那半句，究竟来自知识缺失、提示不清，还是模型的行为习惯不合拍？
先别急着改参数
模型微调改变的是模型参数，让它在给定输入下更接近训练样本呈现的做事方式。它擅长处理风格、格式、判断边界和固定流程，却不天然适合塞进大量随时变化的事实。把产品手册、制度条款硬灌进去，短期看似有效，更新时却容易留下旧痕迹。若问题主要是“不知道”，检索增强或知识库整理往往足够；若问题是“知道了但答得不像”，才轮到微调出场。
数据决定的是方向，不是音量
准备数据时，数量容易给人安全感，但方向更重要。样本要能覆盖真实输入里的含糊表达、边界请求和常见误解，而不是只挑漂亮问答。标注标准也要先对齐：同一类问题，什么算合格回答，什么必须拒答，什么需要转人工。若这些没有共识，模型学到的只是标注者之间的摇摆。对不少团队来说，先用小规模样本验证行为变化，再决定是否扩大投入，相对稳妥。
- 先写清任务定义：模型要改变的是语气、格式、判断，还是知识范围。
- 留出验证集：不要用训练时看过的样本判断效果。
- 记录失败类型：是胡编、漏答、越界，还是表达不合口径。
模型微调不是一次性交付
上线之后，业务话术会变，产品会迭代，用户提问也会漂移。微调后的模型不会自动知道这些变化，需要有人定期查看失败样本，判断是补数据、改提示，还是回退到通用能力加检索。这里容易被忽略的是回归检查：新样本修正了一个问题，可能让另一类回答变得生硬。把评估做成日常动作，比把微调当成一次性项目更接近现实。
所以，模型微调更像一次有边界的校准，而不是给模型装上新大脑。它值得做，但前提是任务清楚、数据可信、评估可持续。若这三件事还没准备好，先修流程和知识入口，往往比急着改参数更划算。