一个常见场景是：团队把通用大模型接进内部知识库，演示时回答得像模像样，真正开始处理售后工单、设备说明书或渠道政策，却开始露怯。于是有人提议：做模型微调吧。这个判断不算错，但往往跳过了关键一步——先弄清楚模型缺的是知识、格式，还是判断标准。
先分清“不会答”和“答得不对”
如果模型压根不知道某个产品型号的停售时间，问题多半出在知识供给：检索是否覆盖、文档是否更新、切分是否合理。此时上模型微调，等于让模型背下可能很快过期的信息，成本不低，维护也麻烦。一种稳妥做法，是先把知识库和检索链路理顺。
另一种情况不同。资料都在，模型也能找到，却总把内部术语说得似是而非，或者回答格式忽长忽短，这才属于微调能发挥作用的地方。它像是给模型一个稳定的行为示范：遇到某类问题，按什么口径组织答案，用什么结构，哪些话不该展开。
数据不是越多越好，而是要像“工作现场”
准备训练样本时，常见毛病是只收漂亮问答。真实业务里的提问常常带着错别字、省略主语、前后矛盾，甚至把两个问题混在一起。样本如果过于干净，模型学到的是考试卷，不是工作现场。与其堆量，不如把典型任务拆清楚：哪些需要查资料，哪些需要按模板回复，哪些应该明确说不知道。
- 先定义任务边界：模型要完成的是改写、分类、抽取，还是多轮问答。
- 保留真实表达：在不泄露敏感信息的前提下，让样本保留业务语言的自然粗糙感。
- 留出验证集：训练前就分好，不要等训练完再临时找题。
还有一点常被忽略：模型微调不是一次性工程。业务口径变了，样本也要跟着变。把它当成需要定期回看的流程，而不是一锤子买卖。
评估要盯住失败方式
看评估结果时，别只看平均表现。真正要问的是：它在哪些问题上错得离谱？是漏掉关键限制条件，还是把不确定说成确定？如果错误集中在高风险环节，哪怕整体看起来不错，也不该急着上线。可以先让微调后的模型做辅助，给建议、出草稿，由人确认后再发出。
边界也要说清楚。模型微调能改善风格、格式和特定任务上的稳定性，却不能自动带来事实准确，也不适合替代权限控制、流程校验和人工复核。把这些责任全压给模型，后面往往要花时间补窟窿。
所以，面对要不要动手这个问题，我更愿意先反问：现在的失败，究竟是因为模型不懂语言，还是因为系统没给对信息？想清楚这一点，再决定是否动手，通常能省下急着训练一个版本的成本。