一张工单背后的期待
客服团队把过去一年的工单整理出来，想训练一个“懂业务”的助手：用户问退货规则，它能直接引用条款；问接口报错，它能按排查路径追问。听起来像模型微调能解决的事。但把数据交给团队之前，有个问题更值得先问：我们缺的是模型里的知识，还是模型使用知识的方式？
模型微调常被当作“让通用模型变成行业专家”的捷径。实际做起来，它更像一次有明确边界的教学：用一批输入与期望输出，调整模型在特定任务上的行为。它擅长学习表达格式、判断口径、回答风格，却不一定适合用来塞进大量会变化的事实。产品价格、政策条款、接口字段，今天改一版，明天就可能过期；把这些内容压进参数里，维护成本往往被低估。
先拆任务，再谈训练
如果目标是把用户问题分类到几个固定队列，这条路径可以是一个自然选项，因为标签稳定、任务边界清楚。若目标是让助手按知识库回答，检索增强往往更直接：知识更新时改文档，不必反复训练。两者并不互斥，很多场景会先用检索把事实找出来，再用模型微调把回复组织成团队习惯的语气和结构。
数据准备是最容易被轻看的一步。工单里充满口语、错别字、情绪化表达和未写全的上下文。直接拿去训练，模型学到的是噪声，而不是业务判断。更稳妥的做法是先定义“好回答”长什么样：要引用来源吗，要不要承认不知道，遇到越权请求怎么拒答。把这些规则写成少量但一致的样本，比堆很多互相矛盾的对话更有用。
微调之后，问题才刚开始
一次模型微调结束，训练指标下降并不等于上线可用。需要看它在真实问题上的表现：该追问时是否追问，该引用时是否引用，遇到没见过的请求会不会编造。评估集最好来自真实工单的分布，而不是只挑顺手的例子。还要留出人工复核的通道，因为模型在边界处的错误，往往比明显错误更难发现。
另一个常被忽略的成本是版本管理。训练数据换了、基座模型更新了、业务规则调整了，都会让原来的模型行为发生变化。没有记录数据版本和评估结果，团队很难判断一次回复变差是模型问题，还是知识本身过期。模型微调不是一次性项目，更像一段需要持续维护的工程流程。
所以，面对“让模型懂业务”的冲动，不妨先把问题缩小：哪些任务有稳定输入输出，哪些知识必须实时可改，哪些错误可以接受。想清楚这些，再决定要不要训练、训练什么、如何验收。模型微调能做成事，但它不适合替团队回答一个更前置的问题——我们到底想让模型承担哪一段工作。