最近在帮内部一个团队做垂直场景的模型微调项目目标很明确把某电商平台的常见客服问答准确率从60%拉到85%以上。最开始我们按老套路走先攒人工标注数据结果两周过去高质量问答只标了不到八百条成本已经让人心疼。后来我换了个思路——既然要微调一个开源基座模型做学生那就先让更强的LLM当老师批量生成高质量数据再拿这些数据去微调。整个流程跑通之后效果超出预期。这篇就把完整方法论和实操细节拆开讲一遍从数据生成、质量过滤、微调参数到训练监控和常见坑位按我实际执行的顺序来写适合正在做垂直领域小模型微调的开发者参考。先说清楚这文章能给你什么一套可以直接抄作业的“用强模型生成数据→过滤→微调→评估”流程包含我试过有效的提示词模板、生成参数组合、过滤规则和训练超参。你不需要昂贵的标注团队也能在可控成本内搞出一个垂直场景可用的微调模型。1. 整体思路为什么“让强模型当老师”能走通1.1 从人工标注到合成数据一次思路转变传统微调依赖真实标注数据这在大模型时代越来越像一个瓶颈。标注成本高、周期长遇到垂直领域还要养懂业务的标注员普通人根本玩不动。更麻烦的是很多场景下一手数据根本拿不到——涉及用户隐私、内部资料、未公开产品信息合规上就过不去。合成数据的思路其实不神秘说穿了就是知识蒸馏的变种用一个能力更强的模型去生成训练样本然后让小模型在这些样本上做指令微调。为什么能走通因为大模型的泛化能力已经把很多知识“内化”了强模型不是简单重复已知答案而是能把知识以多样化的表述和推理路径“教”给学生模型。我做这个项目的过程中有个很深的体会微调的本质不是让模型记住答案而是让它学会“怎么根据指令给出合格答案”而强模型生成的样本恰好覆盖了这一点。这里有个关键前提需要说明老师模型的综合能力必须明显强于学生模型否则你就是拿一个半斤八两的模型去教另一个属于原地踏步。实践中老师模型的参数量级或能力水平至少要高出一个档次学生模型才有值得学的东西。1.2 目标设定与模型选型先定盘子再动手动手写代码之前先把三件事定下来任务边界、老师模型、学生模型。任务边界决定了数据生成的方向。我们这个项目只做电商客服问答涉及商品咨询、售后处理、物流查询、退换货规则这几类不需要模型会写诗也不要求它懂数学。范围收得窄数据生成才能聚焦微调效果才容易出来。老师模型选的是当前能调用到的能力很强的通用大模型服务通过API批量调用。选它的原因很直接第一综合指令遵循能力够强能根据我们的要求产出结构化样本第二输出质量稳定重复和噪声在可控范围第三按token付费整体成本远低于人工标注。学生模型选了一个7B参数级别的开源基座模型主要考虑是私有化部署方便、推理成本低。一开始也有人问为什么不用更大参数的模型我的回答是如果数据质量到位7B模型在单一垂直场景上的表现完全够用而且部署和推理成本省下来的钱足够你把数据生成做三轮迭代。选型定好之后别忘了先跑一个50条样本的小实验验证可行性。我当时就是拿种子数据先生成了50条人工看了质量又用基座模型试了一次微调确认效果有提升才决定全量铺开。这一步很多人会跳过但它是止损的关键。2. 数据生产用更强LLM批量“造”训练集2.1 种子数据与提示词模板给老师模型一份“作业说明”用强模型生成数据第一步不是直接让它生成一万条而是先准备种子数据。种子数据就是你人工写的一批高质量样本数量不用多几十条到一两百条即可但每条都得是精品。它们的作用有两个一是给老师模型提供few-shot示例让模型理解你要什么格式和风格二是作为数据生成的“锚点”防止生成结果发散到不可控的方向。种子数据准备好之后关键工作就是设计提示词模板。我的模板一般包含四个部分角色设定、任务描述、输出规范、少量示例。角色设定告诉模型“你是一个专业的电商客服问答数据标注员”任务描述说明要生成什么样的问答对输出规范明确格式和边界条件示例则给两条种子样本做参考。这里给出一个我调整过很多次、最终稳定可用的模板{ system: 你是一位资深的电商客服培训师专门负责编写高质量的用户咨询与客服回复样本。你的输出必须专业、准确、简洁符合电商客服的表达习惯。, user: 请基于以下业务规则生成 5 组用户咨询与客服回复的问答对。\n\n业务规则\n- 发货时间现货商品48小时内发货预售商品按页面标注时间发货。\n- 退换货支持7天无理由退货但商品需保持完好且不影响二次销售。\n- 运费质量问题由商家承担退货运费非质量问题由买家承担。\n- 发票默认不开具用户可申请开具电子普通发票。\n\n输出要求\n1. 每组包含一个问题和一个回答格式为 JSON 数组。\n2. 用户提问要口语化覆盖不同表达方式包括直接提问、带着情绪提问、追问细节。\n3. 客服回答要准确引用业务规则不能编造新的政策语气礼貌自然。\n4. 回答长度控制在 50-150 字之间。\n\n示例\n[{\instruction\: \你们家发货怎么这么慢都三天了还没动静\, \output\: \非常抱歉给您带来了不好的体验。您购买的这款商品是现货按规则应在48小时内发货目前已经超出时限我马上为您核实物流状态并催促仓库优先处理请您放心。\}] }注意几个细节。第一输出格式用JSON数组方便后面自动化解析省去大规模正则清洗的麻烦。第二示例很重要模板里必须至少放一条模型看到具体例子之后生成质量会明显提升。第三业务规则要写得明确每条规则独立成句模型才不容易把规则A套到问题B上。2.2 生成参数与采样策略别让老师模型“偷懒抄答案”模板确定之后就到了调参数这一步。我用的是温度0.8、top_p 0.95的组合。温度太低比如0.3以下模型倾向于输出安全但单调的文本多样性不足生成几百条之后你就会发现句子结构高度雷同温度太高比如1.5以上文本开始发散模型甚至会编造业务规则。0.8到0.9之间是一个比较常用的生成区间兼顾多样性与稳定性。top_p我一般保持在0.9到1.0之间和温度配合使用。两个参数一起调的时候注意如果调高温度建议同步降低top_p否则输出容易失控反之如果降低温度top_p可以适当放开。除了采样参数还有一个容易被忽略的策略每条种子样本不要只生成一次而是生成多次取多样。我对每条种子数据调用接口5次温度在0.7到0.9之间随机浮动让模型在同一个指令下产出不同表述的样本。这样做的目的是避免模型生成结果出现“重复模式”——同一类问题永远是用同一套话术在回答这是合成数据最常见的问题之一。生成数量也要提前规划。我当时的计划是200条种子数据平均每条生成5轮每轮产出5组问答理论上能拿到5000条原始数据。但你不要指望这个数字全都能用后面过滤环节会砍掉一大半。另外强烈建议开启接口的流式日志。每次生成请求记录prompt、temperature、返回内容、耗时后面做质量分析和问题回溯时就知道哪一步出了问题。我第一次跑全量生成时没记日志结果发现某批数据格式大面积异常却怎么也定位不到是哪类种子数据引起的非常被动。2.3 质量过滤规则筛一遍、模型评一遍、人眼抽一遍生成数据不等于高质量数据。老师模型再强也会产出重复样本、残缺样本、甚至幻觉内容。我把过滤设计成三层每一层解决一类问题。第一层是规则过滤用脚本处理。这一步主要干掉明显不合格的样本长度小于20字的、长度超过300字的、缺少instruction或output字段的、JSON解析失败的、以及n-gram重合度过高的重复样本。重复检测我用的是simhash加阈值判断简单粗暴但有效重复度超过0.8的直接丢弃。第二层是模型打分过滤让老师模型当“裁判”。我把规则过滤后的样本随机采样一部分构造打分prompt让模型按1到5分从“准确性”“完整性”“格式合规性”“用户意图多样性”四个维度打分然后抽样统计不同分值样本的比例确定一个阈值。实际跑下来3分以下的样本大约占18%直接淘汰。打分prompt也分享一个简化版本{ user: 请评估下面这条客服问答样本的质量按1到5分打分并说明扣分原因。\n评价维度1. 回答是否准确引用业务规则有没有编造2. 回答是否完整覆盖用户问题3. 格式是否符合要求4. 用户提问是否自然口语化。\n\n样本\ninstruction: \你们的退货运费谁出\\noutput: \质量问题我们承担非质量问题您承担。\\n\n请直接输出分数-原因 }第三层是人工抽检。不要偷懒这一步必须做。我每500条抽20条人工看一遍重点检查模型打分是否和人的判断一致。如果发现某批样本模型打分虚高就把这批样本对应的生成参数调低温度重新生成。人工抽检还承担一个任务校准打分prompt的阈值标准发现打3分的样本人觉得其实挺不错就该考虑调整打分规则。三层过滤跑完5000条原始数据大概剩了3200条左右过滤掉36%这个比例很健康。如果过滤率超过50%就要回头检查种子数据质量和生成参数而不是盲目加量。3. 微调落地从JSON到一条能用的模型3.1 数据集配比与格式处理数据过滤完成之后不是直接丢进去训练还有几道处理工序。第一是配比。我的建议是生成数据和真实数据按7:3混合。全用生成数据容易让模型带上“老师腔”——回答风格过于模板化遇到没见过的表达就不适应混入少量真实对话数据模型会更接地气。我们项目里真实数据来自客服工单脱敏后的记录数量不多只有800条左右但混进去之后效果提升非常明显。第二是去重。除了前面过滤时的simhash粗筛我还要在最终训练集上做一次更严格的精确去重和相似去重。方法是把所有样本的instruction做MinHash LSH索引相似度超过0.85的只保留一条。这一步能有效防止同一个问题在训练集中出现几十次导致模型过拟合到固定回答。第三是格式统一。现在主流的微调工具都支持指令微调数据格式最常见的就是JSON格式的instruction、input、output三个字段。我这里统一用{ instruction: 用户咨询的问题, input: 可选的上下文信息没有就留空字符串, output: 期望模型输出的标准回答 }有几个细节容易踩坑input字段如果没用不要删除保留为空字符串有些训练框架读取时会按字段名硬编码instruction和output字段名不要改除非你自己改数据加载逻辑JSON文件用UTF-8编码不要带BOM头否则解析会报错。最后用脚本统计一下每个字段的长度分布确认没有异常长样本混进去。3.2 微调参数配置LoRA与训练超参怎么定接下来就是微调。我用的是参数高效微调方案重点说LoRA。为什么不用全量微调两个原因一是显存不够7B模型全量微调对单卡显存要求很高LoRA只需要训练一小部分参数内存占用小很多二是全量微调在小数据量下非常容易灾难性遗忘把模型原本的通用能力洗掉这在小规模垂直微调场景是很危险的。LoRA的关键参数有这么几个rank、alpha、dropout。rank决定了低秩矩阵的维度影响可训练参数量。我在这个项目里用rank8alpha16dropout0.05。如果你数据量更大、任务更复杂可以适当把rank调高到16甚至32但参数越多过拟合风险也越大。一个小建议先从rank8开始看验证集效果不够再往上加而不是一上来就拉满。训练超参我直接给一套可复用的配置参数取值说明学习率2e-4LoRA常用的学习率量级比全量微调高学习率调度cosine训练后期平稳收敛Batch Size32用gradient accumulation凑到32最大长度1024根据样本长度分布确定Epoch3结合early stopping优化器AdamW标配Warmup比例0.03前几步让学习率平稳上升学习率是最容易出问题的参数。太大会导致loss爆炸太小则模型几乎不更新。我建议先在验证集上小步试找到loss能稳定下降的那个量级。还有一个经验值LoRA微调的学习率通常是全量微调的5到10倍但不要超过5e-4。Epoch不要贪多我第一批实验跑了5个epoch结果验证集上指标先升后降典型过拟合。后来改成3个epoch加early stopping监控验证loss连续2个epoch不下降就停稳定很多。3.3 训练监控与学生模型评估训练过程中的监控有三个重点。第一看loss曲线是否平滑下降如果loss震荡剧烈说明学习率偏高如果下降得特别慢可能学习率偏低或者数据有问题。第二看验证集loss和训练集loss的间距间距太大说明过拟合已经开始了。第三看梯度范数如果出现异常大的值说明有样本数据有问题需要回头清洗。训练完成之后评估是重头戏。我做了两个维度的评估定量和定性。定量评估是用规则脚本跑一批固定测试题统计“准确率”“错误率”“拒答率”。比如我们准备了200道客服测试题覆盖所有业务规则每道题期望匹配某个标准规则答案用关键词匹配加语义相似度双重校验来判断回答是否正确。这套方法虽然简单但能快速给出一个客观数值。定性评估是让老师模型对微调后的模型回答打分维度包括“是否正确引用业务规则”“是否完整回答用户问题”“是否符合客服语气”。这里有个技巧把微调前后模型的回答放一起让老师模型对比打分而不是单独给模型回答打分。对比打分更容易分出高下单打分则倾向于都给高分。最终我们这个项目的结果是微调前7B基座模型的准确率约60%微调后82.5%任务完成度明显提升。而老师模型直接跑同样测试题能到90%以上说明我们还有提升空间主要瓶颈在数据覆盖度有些冷门售后场景的样本量还是不够。4. 实战排雷我踩过的坑和排查方法4.1 数据侧问题重复、模板腔、幻觉污染合成数据最常见的问题是重复。我跑第一批生成的时候发现数据里有大量“亲亲非常抱歉给您带来不便……”开头的回答几乎占了六成。追查下来原因是种子数据里有一条类似的示例模型把它的表述当成了默认风格在复制。解决办法是扩充种子数据的表达多样性人工把同一条业务规则写成五六种不同语气的回答同时把生成温度调高了一档问题明显缓解。模板腔是另一个头疼的问题。模型生成的数据格式上挑不出毛病但读起来一股机器味比如永远用“首先”“其次”“最后”的排比结构或者每条回答都像客服培训手册。我的经验是人工抽检时容易被格式合规蒙蔽忽略了表达自然度。后来我在打分prompt里增加了“表达是否自然口语化”这一维度并且明确要求模型“避免过于正式或模板化的用语”生成结果的自然度提升不少。幻觉污染是合成数据最危险的问题。有一次我发现模型在回答物流问题时编了一个“您的包裹已到达XX中转站”的具体地址这个地址根本不存在。这说明老师模型在生成样本时为了满足用户提问的上下文要求自己补了一段编造的细节。排查之后我在数据生成规则里加了硬性约束“不编造订单号、物流站点、商品库存等具体动态信息涉及动态数据时只给出标准处理流程”。同时规则过滤层加了一条关键词黑名单命中这些动态信息关键词的样本直接降权或淘汰。4.2 训练侧问题过拟合、遗忘、loss震荡微调训练最容易翻车的点是过拟合。我一开始用5个epoch训训练集loss降到很低但验证集测试题准确率比3个epoch版本还低。典型的过拟合信号是训练loss和验证loss之间的差距持续拉大应对手段就是提前停止、增大dropout或减少LoRA rank。灾难性遗忘也很常见。模型学完垂直问答之后你问它“11等于几”或者“写一封邮件”它开始答非所问。这个问题的缓解手段有三个一是在训练数据里混入一定比例的通用指令数据比如5%到10%的通用对话样本二是降低LoRA rank让可训练参数量少一点三是训练时把学习率降到2e-4以下让更新幅度更温和。loss震荡这个问题我排查了很久。现象是loss曲线在训练到第200步左右突然出现一个尖峰随后恢复。后来定位到是某个batch里混进了一条超长样本——长度接近2000字模型在这个样本上计算loss时梯度爆炸了一下。解决方法是训练前统计样本长度把超过max_length的样本截断或直接过滤同时在数据加载器里对长样本做了长度分桶采样让每个batch的长度分布更均匀。4.3 评估侧问题自动打分失真怎么办用老师模型做自动评估是个好方案但它并不完美。我第一次做定性评估时发现老师模型给微调后模型的回答几乎都是4分以上但人工看去明显有几条回答是有问题的。原因在于打分模型容易被“回答长度”带偏长回答天然容易拿高分即使内容有误。这也提醒我自动打分的结果要定期和人工抽检结果做对照校准不能盲目信任。我后来对打分prompt做了约束要求模型先列出回答中引用到的业务规则点再对照规则逐条检查回答是否准确最后才给出分数。这个“先列证据、后打分”的方式让自动打分和人工评分的一致性提高了很多。另外建议每个评估批次都混入几条质量有缺陷的样本作为“探针”如果打分模型给这些问题样本打了高分说明这次打分校准失效需要重新调整。评估还有一个容易被忽视的盲区测试题和训练数据太像。如果测试题的表述方式在你的训练数据里出现过模型的准确率会虚高。我后来专门构造了一批“对抗测试题”把问题换成用户平时根本不会用的书面表达比如“请问退换货的具体政策条款有哪些”模型准确率立刻下降十几个百分点。这个现象说明用户意图多样性做得还不够需要在数据生成阶段继续扩充问题表达方式。最后再分享一个实战中很有用的技巧把过滤后质量最好的几百条数据单独拿出来作为“黄金样本”再做一轮针对性微调。我在项目后期把黄金样本混入训练集并提高其采样权重模型在关键场景上的表现又往上提了一截。这种小步迭代比一次性生成海量数据要可控得多实际效果也好得多。
最近在帮内部一个团队做垂直场景的模型微调项目目标很明确把某电商平台的常见客服问答准确率从60%拉到85%以上。最开始我们按老套路走先攒人工标注数据结果两周过去高质量问答只标了不到八百条成本已经让人心疼。后来我换了个思路——既然要微调一个开源基座模型做学生那就先让更强的LLM当老师批量生成高质量数据再拿这些数据去微调。整个流程跑通之后效果超出预期。这篇就把完整方法论和实操细节拆开讲一遍从数据生成、质量过滤、微调参数到训练监控和常见坑位按我实际执行的顺序来写适合正在做垂直领域小模型微调的开发者参考。先说清楚这文章能给你什么一套可以直接抄作业的“用强模型生成数据→过滤→微调→评估”流程包含我试过有效的提示词模板、生成参数组合、过滤规则和训练超参。你不需要昂贵的标注团队也能在可控成本内搞出一个垂直场景可用的微调模型。1. 整体思路为什么“让强模型当老师”能走通1.1 从人工标注到合成数据一次思路转变传统微调依赖真实标注数据这在大模型时代越来越像一个瓶颈。标注成本高、周期长遇到垂直领域还要养懂业务的标注员普通人根本玩不动。更麻烦的是很多场景下一手数据根本拿不到——涉及用户隐私、内部资料、未公开产品信息合规上就过不去。合成数据的思路其实不神秘说穿了就是知识蒸馏的变种用一个能力更强的模型去生成训练样本然后让小模型在这些样本上做指令微调。为什么能走通因为大模型的泛化能力已经把很多知识“内化”了强模型不是简单重复已知答案而是能把知识以多样化的表述和推理路径“教”给学生模型。我做这个项目的过程中有个很深的体会微调的本质不是让模型记住答案而是让它学会“怎么根据指令给出合格答案”而强模型生成的样本恰好覆盖了这一点。这里有个关键前提需要说明老师模型的综合能力必须明显强于学生模型否则你就是拿一个半斤八两的模型去教另一个属于原地踏步。实践中老师模型的参数量级或能力水平至少要高出一个档次学生模型才有值得学的东西。1.2 目标设定与模型选型先定盘子再动手动手写代码之前先把三件事定下来任务边界、老师模型、学生模型。任务边界决定了数据生成的方向。我们这个项目只做电商客服问答涉及商品咨询、售后处理、物流查询、退换货规则这几类不需要模型会写诗也不要求它懂数学。范围收得窄数据生成才能聚焦微调效果才容易出来。老师模型选的是当前能调用到的能力很强的通用大模型服务通过API批量调用。选它的原因很直接第一综合指令遵循能力够强能根据我们的要求产出结构化样本第二输出质量稳定重复和噪声在可控范围第三按token付费整体成本远低于人工标注。学生模型选了一个7B参数级别的开源基座模型主要考虑是私有化部署方便、推理成本低。一开始也有人问为什么不用更大参数的模型我的回答是如果数据质量到位7B模型在单一垂直场景上的表现完全够用而且部署和推理成本省下来的钱足够你把数据生成做三轮迭代。选型定好之后别忘了先跑一个50条样本的小实验验证可行性。我当时就是拿种子数据先生成了50条人工看了质量又用基座模型试了一次微调确认效果有提升才决定全量铺开。这一步很多人会跳过但它是止损的关键。2. 数据生产用更强LLM批量“造”训练集2.1 种子数据与提示词模板给老师模型一份“作业说明”用强模型生成数据第一步不是直接让它生成一万条而是先准备种子数据。种子数据就是你人工写的一批高质量样本数量不用多几十条到一两百条即可但每条都得是精品。它们的作用有两个一是给老师模型提供few-shot示例让模型理解你要什么格式和风格二是作为数据生成的“锚点”防止生成结果发散到不可控的方向。种子数据准备好之后关键工作就是设计提示词模板。我的模板一般包含四个部分角色设定、任务描述、输出规范、少量示例。角色设定告诉模型“你是一个专业的电商客服问答数据标注员”任务描述说明要生成什么样的问答对输出规范明确格式和边界条件示例则给两条种子样本做参考。这里给出一个我调整过很多次、最终稳定可用的模板{ system: 你是一位资深的电商客服培训师专门负责编写高质量的用户咨询与客服回复样本。你的输出必须专业、准确、简洁符合电商客服的表达习惯。, user: 请基于以下业务规则生成 5 组用户咨询与客服回复的问答对。\n\n业务规则\n- 发货时间现货商品48小时内发货预售商品按页面标注时间发货。\n- 退换货支持7天无理由退货但商品需保持完好且不影响二次销售。\n- 运费质量问题由商家承担退货运费非质量问题由买家承担。\n- 发票默认不开具用户可申请开具电子普通发票。\n\n输出要求\n1. 每组包含一个问题和一个回答格式为 JSON 数组。\n2. 用户提问要口语化覆盖不同表达方式包括直接提问、带着情绪提问、追问细节。\n3. 客服回答要准确引用业务规则不能编造新的政策语气礼貌自然。\n4. 回答长度控制在 50-150 字之间。\n\n示例\n[{\instruction\: \你们家发货怎么这么慢都三天了还没动静\, \output\: \非常抱歉给您带来了不好的体验。您购买的这款商品是现货按规则应在48小时内发货目前已经超出时限我马上为您核实物流状态并催促仓库优先处理请您放心。\}] }注意几个细节。第一输出格式用JSON数组方便后面自动化解析省去大规模正则清洗的麻烦。第二示例很重要模板里必须至少放一条模型看到具体例子之后生成质量会明显提升。第三业务规则要写得明确每条规则独立成句模型才不容易把规则A套到问题B上。2.2 生成参数与采样策略别让老师模型“偷懒抄答案”模板确定之后就到了调参数这一步。我用的是温度0.8、top_p 0.95的组合。温度太低比如0.3以下模型倾向于输出安全但单调的文本多样性不足生成几百条之后你就会发现句子结构高度雷同温度太高比如1.5以上文本开始发散模型甚至会编造业务规则。0.8到0.9之间是一个比较常用的生成区间兼顾多样性与稳定性。top_p我一般保持在0.9到1.0之间和温度配合使用。两个参数一起调的时候注意如果调高温度建议同步降低top_p否则输出容易失控反之如果降低温度top_p可以适当放开。除了采样参数还有一个容易被忽略的策略每条种子样本不要只生成一次而是生成多次取多样。我对每条种子数据调用接口5次温度在0.7到0.9之间随机浮动让模型在同一个指令下产出不同表述的样本。这样做的目的是避免模型生成结果出现“重复模式”——同一类问题永远是用同一套话术在回答这是合成数据最常见的问题之一。生成数量也要提前规划。我当时的计划是200条种子数据平均每条生成5轮每轮产出5组问答理论上能拿到5000条原始数据。但你不要指望这个数字全都能用后面过滤环节会砍掉一大半。另外强烈建议开启接口的流式日志。每次生成请求记录prompt、temperature、返回内容、耗时后面做质量分析和问题回溯时就知道哪一步出了问题。我第一次跑全量生成时没记日志结果发现某批数据格式大面积异常却怎么也定位不到是哪类种子数据引起的非常被动。2.3 质量过滤规则筛一遍、模型评一遍、人眼抽一遍生成数据不等于高质量数据。老师模型再强也会产出重复样本、残缺样本、甚至幻觉内容。我把过滤设计成三层每一层解决一类问题。第一层是规则过滤用脚本处理。这一步主要干掉明显不合格的样本长度小于20字的、长度超过300字的、缺少instruction或output字段的、JSON解析失败的、以及n-gram重合度过高的重复样本。重复检测我用的是simhash加阈值判断简单粗暴但有效重复度超过0.8的直接丢弃。第二层是模型打分过滤让老师模型当“裁判”。我把规则过滤后的样本随机采样一部分构造打分prompt让模型按1到5分从“准确性”“完整性”“格式合规性”“用户意图多样性”四个维度打分然后抽样统计不同分值样本的比例确定一个阈值。实际跑下来3分以下的样本大约占18%直接淘汰。打分prompt也分享一个简化版本{ user: 请评估下面这条客服问答样本的质量按1到5分打分并说明扣分原因。\n评价维度1. 回答是否准确引用业务规则有没有编造2. 回答是否完整覆盖用户问题3. 格式是否符合要求4. 用户提问是否自然口语化。\n\n样本\ninstruction: \你们的退货运费谁出\\noutput: \质量问题我们承担非质量问题您承担。\\n\n请直接输出分数-原因 }第三层是人工抽检。不要偷懒这一步必须做。我每500条抽20条人工看一遍重点检查模型打分是否和人的判断一致。如果发现某批样本模型打分虚高就把这批样本对应的生成参数调低温度重新生成。人工抽检还承担一个任务校准打分prompt的阈值标准发现打3分的样本人觉得其实挺不错就该考虑调整打分规则。三层过滤跑完5000条原始数据大概剩了3200条左右过滤掉36%这个比例很健康。如果过滤率超过50%就要回头检查种子数据质量和生成参数而不是盲目加量。3. 微调落地从JSON到一条能用的模型3.1 数据集配比与格式处理数据过滤完成之后不是直接丢进去训练还有几道处理工序。第一是配比。我的建议是生成数据和真实数据按7:3混合。全用生成数据容易让模型带上“老师腔”——回答风格过于模板化遇到没见过的表达就不适应混入少量真实对话数据模型会更接地气。我们项目里真实数据来自客服工单脱敏后的记录数量不多只有800条左右但混进去之后效果提升非常明显。第二是去重。除了前面过滤时的simhash粗筛我还要在最终训练集上做一次更严格的精确去重和相似去重。方法是把所有样本的instruction做MinHash LSH索引相似度超过0.85的只保留一条。这一步能有效防止同一个问题在训练集中出现几十次导致模型过拟合到固定回答。第三是格式统一。现在主流的微调工具都支持指令微调数据格式最常见的就是JSON格式的instruction、input、output三个字段。我这里统一用{ instruction: 用户咨询的问题, input: 可选的上下文信息没有就留空字符串, output: 期望模型输出的标准回答 }有几个细节容易踩坑input字段如果没用不要删除保留为空字符串有些训练框架读取时会按字段名硬编码instruction和output字段名不要改除非你自己改数据加载逻辑JSON文件用UTF-8编码不要带BOM头否则解析会报错。最后用脚本统计一下每个字段的长度分布确认没有异常长样本混进去。3.2 微调参数配置LoRA与训练超参怎么定接下来就是微调。我用的是参数高效微调方案重点说LoRA。为什么不用全量微调两个原因一是显存不够7B模型全量微调对单卡显存要求很高LoRA只需要训练一小部分参数内存占用小很多二是全量微调在小数据量下非常容易灾难性遗忘把模型原本的通用能力洗掉这在小规模垂直微调场景是很危险的。LoRA的关键参数有这么几个rank、alpha、dropout。rank决定了低秩矩阵的维度影响可训练参数量。我在这个项目里用rank8alpha16dropout0.05。如果你数据量更大、任务更复杂可以适当把rank调高到16甚至32但参数越多过拟合风险也越大。一个小建议先从rank8开始看验证集效果不够再往上加而不是一上来就拉满。训练超参我直接给一套可复用的配置参数取值说明学习率2e-4LoRA常用的学习率量级比全量微调高学习率调度cosine训练后期平稳收敛Batch Size32用gradient accumulation凑到32最大长度1024根据样本长度分布确定Epoch3结合early stopping优化器AdamW标配Warmup比例0.03前几步让学习率平稳上升学习率是最容易出问题的参数。太大会导致loss爆炸太小则模型几乎不更新。我建议先在验证集上小步试找到loss能稳定下降的那个量级。还有一个经验值LoRA微调的学习率通常是全量微调的5到10倍但不要超过5e-4。Epoch不要贪多我第一批实验跑了5个epoch结果验证集上指标先升后降典型过拟合。后来改成3个epoch加early stopping监控验证loss连续2个epoch不下降就停稳定很多。3.3 训练监控与学生模型评估训练过程中的监控有三个重点。第一看loss曲线是否平滑下降如果loss震荡剧烈说明学习率偏高如果下降得特别慢可能学习率偏低或者数据有问题。第二看验证集loss和训练集loss的间距间距太大说明过拟合已经开始了。第三看梯度范数如果出现异常大的值说明有样本数据有问题需要回头清洗。训练完成之后评估是重头戏。我做了两个维度的评估定量和定性。定量评估是用规则脚本跑一批固定测试题统计“准确率”“错误率”“拒答率”。比如我们准备了200道客服测试题覆盖所有业务规则每道题期望匹配某个标准规则答案用关键词匹配加语义相似度双重校验来判断回答是否正确。这套方法虽然简单但能快速给出一个客观数值。定性评估是让老师模型对微调后的模型回答打分维度包括“是否正确引用业务规则”“是否完整回答用户问题”“是否符合客服语气”。这里有个技巧把微调前后模型的回答放一起让老师模型对比打分而不是单独给模型回答打分。对比打分更容易分出高下单打分则倾向于都给高分。最终我们这个项目的结果是微调前7B基座模型的准确率约60%微调后82.5%任务完成度明显提升。而老师模型直接跑同样测试题能到90%以上说明我们还有提升空间主要瓶颈在数据覆盖度有些冷门售后场景的样本量还是不够。4. 实战排雷我踩过的坑和排查方法4.1 数据侧问题重复、模板腔、幻觉污染合成数据最常见的问题是重复。我跑第一批生成的时候发现数据里有大量“亲亲非常抱歉给您带来不便……”开头的回答几乎占了六成。追查下来原因是种子数据里有一条类似的示例模型把它的表述当成了默认风格在复制。解决办法是扩充种子数据的表达多样性人工把同一条业务规则写成五六种不同语气的回答同时把生成温度调高了一档问题明显缓解。模板腔是另一个头疼的问题。模型生成的数据格式上挑不出毛病但读起来一股机器味比如永远用“首先”“其次”“最后”的排比结构或者每条回答都像客服培训手册。我的经验是人工抽检时容易被格式合规蒙蔽忽略了表达自然度。后来我在打分prompt里增加了“表达是否自然口语化”这一维度并且明确要求模型“避免过于正式或模板化的用语”生成结果的自然度提升不少。幻觉污染是合成数据最危险的问题。有一次我发现模型在回答物流问题时编了一个“您的包裹已到达XX中转站”的具体地址这个地址根本不存在。这说明老师模型在生成样本时为了满足用户提问的上下文要求自己补了一段编造的细节。排查之后我在数据生成规则里加了硬性约束“不编造订单号、物流站点、商品库存等具体动态信息涉及动态数据时只给出标准处理流程”。同时规则过滤层加了一条关键词黑名单命中这些动态信息关键词的样本直接降权或淘汰。4.2 训练侧问题过拟合、遗忘、loss震荡微调训练最容易翻车的点是过拟合。我一开始用5个epoch训训练集loss降到很低但验证集测试题准确率比3个epoch版本还低。典型的过拟合信号是训练loss和验证loss之间的差距持续拉大应对手段就是提前停止、增大dropout或减少LoRA rank。灾难性遗忘也很常见。模型学完垂直问答之后你问它“11等于几”或者“写一封邮件”它开始答非所问。这个问题的缓解手段有三个一是在训练数据里混入一定比例的通用指令数据比如5%到10%的通用对话样本二是降低LoRA rank让可训练参数量少一点三是训练时把学习率降到2e-4以下让更新幅度更温和。loss震荡这个问题我排查了很久。现象是loss曲线在训练到第200步左右突然出现一个尖峰随后恢复。后来定位到是某个batch里混进了一条超长样本——长度接近2000字模型在这个样本上计算loss时梯度爆炸了一下。解决方法是训练前统计样本长度把超过max_length的样本截断或直接过滤同时在数据加载器里对长样本做了长度分桶采样让每个batch的长度分布更均匀。4.3 评估侧问题自动打分失真怎么办用老师模型做自动评估是个好方案但它并不完美。我第一次做定性评估时发现老师模型给微调后模型的回答几乎都是4分以上但人工看去明显有几条回答是有问题的。原因在于打分模型容易被“回答长度”带偏长回答天然容易拿高分即使内容有误。这也提醒我自动打分的结果要定期和人工抽检结果做对照校准不能盲目信任。我后来对打分prompt做了约束要求模型先列出回答中引用到的业务规则点再对照规则逐条检查回答是否准确最后才给出分数。这个“先列证据、后打分”的方式让自动打分和人工评分的一致性提高了很多。另外建议每个评估批次都混入几条质量有缺陷的样本作为“探针”如果打分模型给这些问题样本打了高分说明这次打分校准失效需要重新调整。评估还有一个容易被忽视的盲区测试题和训练数据太像。如果测试题的表述方式在你的训练数据里出现过模型的准确率会虚高。我后来专门构造了一批“对抗测试题”把问题换成用户平时根本不会用的书面表达比如“请问退换货的具体政策条款有哪些”模型准确率立刻下降十几个百分点。这个现象说明用户意图多样性做得还不够需要在数据生成阶段继续扩充问题表达方式。最后再分享一个实战中很有用的技巧把过滤后质量最好的几百条数据单独拿出来作为“黄金样本”再做一轮针对性微调。我在项目后期把黄金样本混入训练集并提高其采样权重模型在关键场景上的表现又往上提了一截。这种小步迭代比一次性生成海量数据要可控得多实际效果也好得多。
