客服团队把通用模型接进内部问答，最初几轮往往还算顺：寒暄、改写、总结都能应付。真正让人皱眉的是术语和口径——同一个业务名词，模型一会儿这样解释，一会儿那样解释；遇到内部流程，它会给出听起来合理却并不存在的步骤。于是有人提议：拿一批问答做模型微调，让它“更懂我们”。这个直觉不算错，但容易把微调当成万能补丁。
先分清：提示词、检索和模型微调
把资料塞进提示词，解决的是“这次回答时看什么”；检索增强，解决的是“回答前能不能找到新鲜资料”；模型微调更像是在一批示例上继续训练，让模型对某类输入形成更稳定的反应模式。它改变的是参数里的倾向，不是给模型外挂一个随时可查的文件夹。若需求只是补充几条产品说明，提示词或检索通常更轻；若同一类任务反复出现，格式、语气、判断边界都需要统一，微调才有讨论价值。
它改的是反应模式，不是事实仓库
模型微调常被误解为“把知识灌进去”。更准确地说，示例在教模型：面对这类输入，应该按什么结构回应、在哪些地方收住、如何区分相近概念。它适合风格稳定、任务边界清楚、输入输出关系相对一致的场景。若知识每天变化，或者答案依赖大量实时查询，单靠微调会吃力；把微调与检索搭配，反而更接近实际工作流。
做模型微调之前，先问三个问题
- 任务是否真的稳定？如果需求每周换方向，示例集很难覆盖，模型也会学得摇摆。
- 数据是否干净且一致？示例里的矛盾口径会被一并学走，后面很难用一句提示词纠正。
- 有没有可重复的评估？不能只看几条顺眼的回答，要准备一组覆盖常见与边界情况的测试问题。
我的判断是，模型微调的价值不在“让模型无所不知”，而在“让模型在特定任务上少犯同类错误”。它需要像维护一份工作手册那样维护数据：定期检查、删改、补边界。对多数团队来说，先跑通提示词和检索，再判断是否值得微调，往往比一上来就训练更稳妥。