先丢一个反直觉的结论在桌面上在垂直场景里微调后的 2B 小模型是可以正面击败未微调的 27B 大模型的。参数规模差了 13 倍训练成本只花了一台单卡机器和几千条标注数据但拼特定任务上的输出稳定性小模型反而赢了。这不是标题党是我最近在一个工单意图识别与字段抽取项目里反复验证过的结果微调后的 Qwen 3.5-2B在字段级 F1 和输出格式合法率这两个核心指标上同时压过了走提示词工程路线的 Qwen 3.5-27B。这篇文章不给你灌鸡汤我尽量把整个实验拆得能直接抄作业任务怎么选、基线怎么设、数据怎么喂、LoRA 参数怎么配、评测口径怎么定以及最容易被忽略的——什么情况下这套打法会彻底翻车。1. 先说结论2B 想赢 27B靠的是任务收敛而不是能力碾压1.1 一次对比实验是怎么开始的先说背景。我手头的项目是从中文运维工单里抽取四个字段故障代码、维修类别、设备型号、紧急程度顺便做一个意图分类。这种任务在真实业务里非常常见——工单系统每天产生海量非结构化文本需要转成结构化数据进下游流程。最开始我也默认27B 肯定比 2B 强毕竟参数在那里摆着。于是我把 Qwen 3.5 系列的 2B 和 27B 都拉下来设了四组对比2B 基座加简单提示词、2B 基座做 QLoRA 微调、27B 基座加认真写的提示词、27B 基座加 few-shot 示例。跑完评测之后微调后的 2B 在字段级 F1 上比我预期的高出一截连着复跑两轮都是这个结果。注意我特意用了同系列的 2B 和 27B 做对照而不是拿不同厂牌的模型硬比。同系列意味着 tokenizer、指令格式、预训练数据分布都对齐了这样赢出来的结论才能归因到参数规模 微调上而不是这个词表更懂我的数据。1.2 为什么小模型能赢分布对齐加上容量冗余这里有个核心逻辑理解了它你就能自己判断什么任务适合这么打。大模型的参数是花在广度上的它的能力分布是弥散的、广谱的而你的业务任务是一条尖峰状的分布。27B 当然会做字段抽取但它不需要稳定地、格式统一地、每次都不漏字段地做这件事。它的目标是通用文本预测输出多样性对它来说是优点对你是灾难。微调做的事就是把小模型的权重往你的任务尖峰上做定向收缩。两三千条高质量数据足以让模型把输出格式字段定义缺省规则这些模式内化成权重层面的习惯。参数规模方面一个字段抽取任务要学的本质是一套有限状态映射几百个有效模式、几十个枚举值这个复杂度对 2B 参数来说完全冗余。容量不够这句判断在窄任务上基本是伪命题。更关键的是学习行为差异。小模型学得死一旦学会了就非常顽固输出稳定大模型知道得太多在窄任务上容易过度泛化遇到模糊输入就自由发挥。结构化抽取这种任务怕的不是不聪明怕的就是自由发挥。1.3 先泼三盆冷水这个结论只在任务边界清晰、输出空间有限、评测集与训练分布同源的条件下成立。出了这个范围2B 被 27B 完虐一点不奇怪。对照组里如果把 27B 也拿去微调它大概率还是比 2B 强。所以本文的真实结论严格来说是微调收益大于裸奔的规模收益不是小模型比大模型聪明。别拿这份结果出去吹2B 全面超越 27B。评测口径一旦被人拆穿信誉就没了。第 5 节我会专门讲口径问题。2. 实验前必须定死的三件事任务、基座和对照口径2.1 为什么选结构化抽取当试验田字段抽取、意图分类、JSON 结构化输出这类任务是最适合验证小模型逆袭的试验田原因就四条字段有限、枚举值固定、输出 schema 明确、评测可量化。任务一旦可量化你就能把赢和输拆到具体字段上方便迭代。这里特别提醒一个容易被忽略的指标输出格式合法率。27B 在这种任务上最大的问题恰恰是格式漂移——回答了但并不符合 schema下游解析直接报错。这个指标在开放任务里没法定义但在结构化抽取里是生死线。我后面会给你看实测数据27B 在这个指标上被微调 2B 甩开得最惨。2.2 基座选型同系列 2B 和 27B 才公平这次选 Qwen 3.5 的 2B 和 27B 做对比核心原因就一个同系列模型的 tokenizer 和指令跟随习惯是一致的。换成不同厂牌的模型去比你会引入词表、训练数据、对齐策略等一堆变量赢了也不知道赢在哪这就是典型的不可归因实验。另外一个现实因素就是部署成本差异。2B 的 bf16 权重大约 4GB 出头加上 KV cache 和激活值一张 24GB 显存的常规加速卡能轻松跑起来27B 的 bf16 权重接近 55GB单卡根本放不下得上多卡或者 4bit 量化降级运行。这个差异本身就算进了最终的成本账。2.3 对照组设四组而不是两组很多人做这种实验只比微调后的 2B和裸奔的 27B赢了就发博客。两组对照最大的问题是你没法解释赢在哪儿。我的做法是四组组别配置AQwen 3.5-2B 基座 一段简单系统提示BQwen 3.5-2B 基座 QLoRA 微调CQwen 3.5-27B 基座 认真写的系统提示和字段说明DQwen 3.5-27B 基座 few-shot 示例每条两到三组完整样例A 和 B 的差距是微调的增量C 和 D 的差距是提示词工程的增量B 对 C/D 才是公平的2B 微调 vs 27B 基座的对决。少任何一组结论都会被质疑。2.4 评测口径先定好再动手我在实验第一天就把评测口径写成文档后面一个字没改。我用三个核心指标加一个人工复核环节整条 EMExact Match输出和标准答案完全一致才算对。字段级 F1按字段粒度算精确率和召回率。这个指标很关键因为 EM 太苛刻——漏一个字段整条就判错你会分不清模型是不会还是太懒。格式合法率输出能否被 JSON 解析、枚举值是否合法。前面说了这是结构化任务的生死指标。人工复核随机抽 100 条由两个人独立判断不一致的提交讨论。评测集是 500 条人工标注样本和训练集严格隔离另外做了 100 条对抗样本包含缺字段、错别字、口语化表达、超长文本这些真实干扰。所有推理统一温度设为 0用 greedy 解码每次评测跑一轮记录数字再跑一轮确认稳定。3. 数据才是真正的胜负手给 2B 喂什么、怎么喂3.1 数据量到底需要多少窄任务微调的数据量遵循一个先陡后平的曲线。500 条你就能看到明显变化2000 到 3000 条通常已经进入边际收益拐点超过 5000 条收益就非常小了。原因很简单窄任务的有效模式有限更多数据主要是在覆盖稀有实体和边界情况。我的做法是两轮迭代。第一轮人工标注 1200 条微调完跑一遍对抗样本把错误按类型归类然后针对错误集中的类型再补 800 条。总共 2000 条左右就已经能把字段 F1 推到 93% 以上。不要一上来就砸一万条标注费那是浪费钱。3.2 样本格式系统提示加固定 schema这就是纪律小模型微调时格式本身就是学习信号。如果训练数据里一半样本字段顺序是乱的模型永远学不会 rigid 输出。我的样本格式是标准三段式系统提示把 schema 写死字段含义、枚举值、缺省规则全部列清楚系统提示: 你是工单意图识别与参数抽取助手。请从用户提交的报障文本中提取以下字段以 JSON 格式输出字段顺序固定: - fault_code: 故障代码字符串没有则填 unknown - repair_category: 维修类别取值只能是 [设备重启, 配件更换, 网络故障, 软件升级, 其他] - device_model: 设备型号字符串没有则填 unknown - urgency: 紧急程度取值只能是 [低, 中, 高] 用户输入: 设备 AE-200 昨天下午报错 code 501间歇性重启影响产线请尽快处理。 标准输出: {fault_code: 501, repair_category: 设备重启, device_model: AE-200, urgency: 高}注意字段顺序固定这几个字。模型在训练中会把字段顺序当成一种隐式约束这比任何解码层面的规则都管用。你还可以在部分样本里故意留一个字段缺省教它输出 unknown而不是硬编一个值。3.3 负样本和边界样本小模型最怕自由发挥训练数据里一定要混入不该抽取出东西的样本。真实工单系统里总有闲聊、通知、无关文本混进来。我给每个批次都会配约 8% 的负样本例如用户输入: 今天天气不错食堂的饭也好吃。 标准输出: {fault_code: unknown, repair_category: 其他, device_model: unknown, urgency: unknown}这类样本在告诉模型两件事一是输出里不能有编造的字段二是无关输入走统一的 unknown 路径。没有这部分数据模型在推理时遇到不相关文本就会硬抽编出一堆幻觉字段。除此之外还要加多实体样本——一条工单里出现两个设备、两个故障码的情况教模型区分主要对象加口语化和带错别字的样本训练分布里必须包含推理时实际会遇到的噪声。只用干净语料训练上线必死。3.4 清洗、去重和测试集隔离这条很多人翻过车。我先做了 n-gram 级去重因为同一条文本被标了两次且标签不一致模型会被教坏。然后做了标签一致性检查凡是相同输入对应不同输出的样本全部拉出来人工复核。最要命的是测试集隔离。我见过有人图省事从同一批导出的原始数据里随机切分训练集和测试集结果两边的样本高度重复评测分数虚高得离谱。正确做法是先把原始数据按时间或 ID 分桶保证同一来源的相似文本只出现在一个集合里再分别抽样。评测分数只有经得起隔离检验才有说服力。4. 微调配置实测QLoRA 参数、训练口诀与损失曲线读法4.1 为什么用 QLoRA 而不是全参微调2B 全参微调其实也跑得起单卡 24GB 显存够用。但全参微调在数据只有两三千条时有个实际问题灾难性遗忘。基座模型本来具备的通用语言能力会被训练目标冲掉一部分导致模型在训练分布外表现退化得更快。LoRA 的做法是冻结基座权重只训练低秩增量。对窄任务来说这个增量空间完全够用又能保留基座的通用能力。QLoRA 则是在 LoRA 基础上用 4bit 量化加载基座进一步压低显存占用。实测下来在窄任务上 QLoRA 和全参微调的差距很小但显存和训练时间省了一大截。我这次直接用 QLoRA 跑完整个实验。4.2 一组可复现的超参数下面这组参数是这次实验最终敲定的一组你可以直接抄走当起点再按自己的数据量微调参数取值说明target_modulesq_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj全部线性层都挂 LoRA比只挂注意力层更稳r秩16数据量 3000 以内 16 够用加到 32 边际收益很小lora_alpha32按 alpha 2 倍 r 来配lora_dropout0.1防过拟合learning_rate1.5e-42B 小模型在这个区间表现稳定lr_schedulercosine末尾平滑降到 0warmup_ratio0.03大约 300 步级别per_device_train_batch_size824GB 显存级别gradient_accumulation_steps4有效 batch 约 32max_seq_length1024超长样本直接截断窄任务不需要长上下文num_train_epochs3配合 eval loss 早停bf16true用 bf16 混合精度避免 fp16 溢出weight_decay0.01常规配置训练时长方面单卡 24GB 显存跑 Qwen 3.5-2B2000 条数据 3 个 epoch 大约 1.5 到 2 小时。是的你没看错就是小时级。这是整个方案里最让人舒服的部分——小模型的实验周期短你可以一天迭代好几轮。4.3 训练中的三个关键信号第一个信号是训练 loss。2B 微调一个字段抽取任务训练 loss 通常从 1.8 附近起步3 个 epoch 内能压到 0.3 左右。如果某个 epoch 结束时训练 loss 还在 0.8 以上大概率是学习率太大或者样本格式不统一先别加 epoch去查数据。第二个信号是 eval loss。训练 loss 降但 eval loss 回升就是过拟合的铁证立刻早停。窄任务对过拟合比通用任务更敏感因为你的训练分布和评测分布之间的差异可能很小模型一旦开始背训练集评测分数立刻掉。第三个信号是我个人非常依赖的人工过样。每 100 步保存一个 checkpoint然后固定用同一批 50 条样本跑一遍生成结果肉眼看输出格式有没有漂移。我最常发现的问题是某个字段开始输出中文而不是枚举值这种问题 loss 看不出来只有人工过样能抓出来。4.4 微调后的第一个检查训练集还原度模型训练完不要直接上测试集评测先看训练集还原度。这一步是定位问题用的如果训练集上的准确率不到 95%说明模型根本没学会问题在数据格式或训练配置如果训练集 99% 但对抗样本掉得厉害说明过拟合了要加正则或者补数据。我用的是现成的推理框架把微调后的模型导出先跑一遍训练集看错误集中在哪。这一步做完再上正式评测集你的评测才有意义。5. 评测复盘2B 到底在哪些维度反超了 27B5.1 四组实测数据对照下面这组数字是我那一轮跑出来的结果环境是单张 24GB 显存的常规加速卡推理温度 0greedy 解码仅作为量级参考组别整条 EM字段级 F1格式合法率平均单条响应A2B 基座 简单提示24.6%58.3%47.2%0.8sB2B 基座 QLoRA 微调76.2%93.8%98.6%0.8sC27B 基座 提示词工程47.5%74.6%60.4%2.4sD27B 基座 few-shot62.8%86.9%78.3%2.7sB 组在字段级 F1 上比 C 组高了将近 20 个百分点比 D 组也高了 7 个百分点。最扎眼的其实是格式合法率27B 即使认真写了提示词格式合法率也只有 60% 左右微调后的 2B 是 98.6%。参数越大、越聪明在窄约束下反而越容易自由发挥——这不是它不懂 JSON而是它在面对模糊输入时倾向于用常识补全而不是严格遵守 schema。5.2 反超的三个具体形态拆开看微调 2B 的反超集中在三个地方。第一是格式稳定性它几乎不会输出多余文本开场白、解释、废话全都没有直接给 JSON。第二是漏字段27B 经常漏掉紧急程度这种需要从语境推断的字段而微调 2B 把它当成必填项处理缺了就往 unknown 走。第三是拒绝逻辑遇到无关文本27B 会硬抽字段微调 2B 学会了走统一的 unknown 路径。这三个形态本质上都是同一个原因微调把任务约束写进了权重而不是让它靠临场发挥。5.3 必须承认27B 仍然占优的维度诚实地说27B 也有它明显占优的地方。最典型的是分布外鲁棒性——换一种完全没见过的表达习惯、新增一种故障类型时27B 靠通用理解还能顶一下微调 2B 会退化得比较快。另外就是知识性字段某个故障码在训练数据里没出现过27B 可能靠常识猜个大概微调 2B 只能老老实实输出 unknown。所以我在做这个系统的时候最终的部署策略不是用 2B 替换 27B而是2B 前置处理大部分样本低置信度样本路由给 27B 兜底。小模型负责稳定和便宜大模型负责边界情况。这个思路后面第 6 节还会展开。5.4 成本账显存、延迟、单条推理成本最后算一笔账。为什么说这不是花架子而是有实际意义的降本维度2B 微调27B 基座加载显存bf16 含运行时约 5GB单卡可跑接近 55GB需多卡或 4bit 量化单条延迟512 输入 / 256 输出约 0.8s约 2.5s 起推理成本折算1x约 5 到 10 倍训练成本单卡数小时不做微调无训练成本27B 模型在显存和延迟上的开销是数量级的差异。如果每天要解析几十万条工单这个成本差直接体现在账单上。小模型赢了指标又赢了成本这才是逆袭的真实含义。6. 什么任务别指望 2B 逆袭三条红线与快速适配测试6.1 三条红线我把不适合这套打法的任务归纳成三类碰到直接绕道。第一是知识密集型任务比如法律条款解释、医疗诊断建议、领域术语问答。2B 参数装不下这种外部知识微调最多让它背住训练数据里出现过的那部分遇到新问题就会打回原形。第二是多步推理和长逻辑链任务比如复杂数学题、因果链分析、深度代码排错。这类任务对模型的中间表示能力和注意力跨度要求很高2B 的容量确实不够微调解决不了根本问题。第三是开放性生成任务比如创作类写作、开放域对话。输出空间无限评测没法收敛模型的学习目标都不清楚逆袭自然无从谈起。三条红线之外的任务才值得用这套打法。6.2 快速适配测试100 条样本定生死我一般先做 100 条样本的快速测试再决定要不要投入。拿 100 条真实输入直接丢给基座 2B带上你准备好的系统提示然后看错误模式分类。如果错误集中在格式不对、漏字段、枚举值用错这类规则性错误说明模型理解能力够用只是不遵守约束微调能救大胆开跑。如果错误集中在这个词它不认识、这个业务逻辑它完全没概念这类知识性错误那就是任务分布太宽或太深微调救不了趁早换大模型或者加检索。我自己的经验阈值是格式类错误占比超过 60%试微调知识类错误占比超过 40%别跳坑。6.3 扩展思路蒸馏、路由和增量更新这套打法的后续扩展方向有三个。一是用蒸馏思路做数据获取让 27B 先生成一批标注人工修正后再喂给 2B形成一个大模型辅助建数据、小模型低成本上线的正循环。二是混合路由部署2B 前置处理低置信度样本转发给 27B用路由把成本和质量调到最优。三是定期增量更新每月用线上真实数据做一次继续微调让 2B 始终贴合最新分布。最后说点个人体会。这个实验做完我最大的感受是模型选型不应该用参数量投票而应该用任务分布与模型能力的重合度投票。把 27B 的预算省下一半一半花在高质量标注管线上一半花在推理部署上很多垂直任务的综合收益反而更高。当然碰到上面说的三类红线任务该上大模型就上别硬省——省钱的前提是先选对战场。
先丢一个反直觉的结论在桌面上在垂直场景里微调后的 2B 小模型是可以正面击败未微调的 27B 大模型的。参数规模差了 13 倍训练成本只花了一台单卡机器和几千条标注数据但拼特定任务上的输出稳定性小模型反而赢了。这不是标题党是我最近在一个工单意图识别与字段抽取项目里反复验证过的结果微调后的 Qwen 3.5-2B在字段级 F1 和输出格式合法率这两个核心指标上同时压过了走提示词工程路线的 Qwen 3.5-27B。这篇文章不给你灌鸡汤我尽量把整个实验拆得能直接抄作业任务怎么选、基线怎么设、数据怎么喂、LoRA 参数怎么配、评测口径怎么定以及最容易被忽略的——什么情况下这套打法会彻底翻车。1. 先说结论2B 想赢 27B靠的是任务收敛而不是能力碾压1.1 一次对比实验是怎么开始的先说背景。我手头的项目是从中文运维工单里抽取四个字段故障代码、维修类别、设备型号、紧急程度顺便做一个意图分类。这种任务在真实业务里非常常见——工单系统每天产生海量非结构化文本需要转成结构化数据进下游流程。最开始我也默认27B 肯定比 2B 强毕竟参数在那里摆着。于是我把 Qwen 3.5 系列的 2B 和 27B 都拉下来设了四组对比2B 基座加简单提示词、2B 基座做 QLoRA 微调、27B 基座加认真写的提示词、27B 基座加 few-shot 示例。跑完评测之后微调后的 2B 在字段级 F1 上比我预期的高出一截连着复跑两轮都是这个结果。注意我特意用了同系列的 2B 和 27B 做对照而不是拿不同厂牌的模型硬比。同系列意味着 tokenizer、指令格式、预训练数据分布都对齐了这样赢出来的结论才能归因到参数规模 微调上而不是这个词表更懂我的数据。1.2 为什么小模型能赢分布对齐加上容量冗余这里有个核心逻辑理解了它你就能自己判断什么任务适合这么打。大模型的参数是花在广度上的它的能力分布是弥散的、广谱的而你的业务任务是一条尖峰状的分布。27B 当然会做字段抽取但它不需要稳定地、格式统一地、每次都不漏字段地做这件事。它的目标是通用文本预测输出多样性对它来说是优点对你是灾难。微调做的事就是把小模型的权重往你的任务尖峰上做定向收缩。两三千条高质量数据足以让模型把输出格式字段定义缺省规则这些模式内化成权重层面的习惯。参数规模方面一个字段抽取任务要学的本质是一套有限状态映射几百个有效模式、几十个枚举值这个复杂度对 2B 参数来说完全冗余。容量不够这句判断在窄任务上基本是伪命题。更关键的是学习行为差异。小模型学得死一旦学会了就非常顽固输出稳定大模型知道得太多在窄任务上容易过度泛化遇到模糊输入就自由发挥。结构化抽取这种任务怕的不是不聪明怕的就是自由发挥。1.3 先泼三盆冷水这个结论只在任务边界清晰、输出空间有限、评测集与训练分布同源的条件下成立。出了这个范围2B 被 27B 完虐一点不奇怪。对照组里如果把 27B 也拿去微调它大概率还是比 2B 强。所以本文的真实结论严格来说是微调收益大于裸奔的规模收益不是小模型比大模型聪明。别拿这份结果出去吹2B 全面超越 27B。评测口径一旦被人拆穿信誉就没了。第 5 节我会专门讲口径问题。2. 实验前必须定死的三件事任务、基座和对照口径2.1 为什么选结构化抽取当试验田字段抽取、意图分类、JSON 结构化输出这类任务是最适合验证小模型逆袭的试验田原因就四条字段有限、枚举值固定、输出 schema 明确、评测可量化。任务一旦可量化你就能把赢和输拆到具体字段上方便迭代。这里特别提醒一个容易被忽略的指标输出格式合法率。27B 在这种任务上最大的问题恰恰是格式漂移——回答了但并不符合 schema下游解析直接报错。这个指标在开放任务里没法定义但在结构化抽取里是生死线。我后面会给你看实测数据27B 在这个指标上被微调 2B 甩开得最惨。2.2 基座选型同系列 2B 和 27B 才公平这次选 Qwen 3.5 的 2B 和 27B 做对比核心原因就一个同系列模型的 tokenizer 和指令跟随习惯是一致的。换成不同厂牌的模型去比你会引入词表、训练数据、对齐策略等一堆变量赢了也不知道赢在哪这就是典型的不可归因实验。另外一个现实因素就是部署成本差异。2B 的 bf16 权重大约 4GB 出头加上 KV cache 和激活值一张 24GB 显存的常规加速卡能轻松跑起来27B 的 bf16 权重接近 55GB单卡根本放不下得上多卡或者 4bit 量化降级运行。这个差异本身就算进了最终的成本账。2.3 对照组设四组而不是两组很多人做这种实验只比微调后的 2B和裸奔的 27B赢了就发博客。两组对照最大的问题是你没法解释赢在哪儿。我的做法是四组组别配置AQwen 3.5-2B 基座 一段简单系统提示BQwen 3.5-2B 基座 QLoRA 微调CQwen 3.5-27B 基座 认真写的系统提示和字段说明DQwen 3.5-27B 基座 few-shot 示例每条两到三组完整样例A 和 B 的差距是微调的增量C 和 D 的差距是提示词工程的增量B 对 C/D 才是公平的2B 微调 vs 27B 基座的对决。少任何一组结论都会被质疑。2.4 评测口径先定好再动手我在实验第一天就把评测口径写成文档后面一个字没改。我用三个核心指标加一个人工复核环节整条 EMExact Match输出和标准答案完全一致才算对。字段级 F1按字段粒度算精确率和召回率。这个指标很关键因为 EM 太苛刻——漏一个字段整条就判错你会分不清模型是不会还是太懒。格式合法率输出能否被 JSON 解析、枚举值是否合法。前面说了这是结构化任务的生死指标。人工复核随机抽 100 条由两个人独立判断不一致的提交讨论。评测集是 500 条人工标注样本和训练集严格隔离另外做了 100 条对抗样本包含缺字段、错别字、口语化表达、超长文本这些真实干扰。所有推理统一温度设为 0用 greedy 解码每次评测跑一轮记录数字再跑一轮确认稳定。3. 数据才是真正的胜负手给 2B 喂什么、怎么喂3.1 数据量到底需要多少窄任务微调的数据量遵循一个先陡后平的曲线。500 条你就能看到明显变化2000 到 3000 条通常已经进入边际收益拐点超过 5000 条收益就非常小了。原因很简单窄任务的有效模式有限更多数据主要是在覆盖稀有实体和边界情况。我的做法是两轮迭代。第一轮人工标注 1200 条微调完跑一遍对抗样本把错误按类型归类然后针对错误集中的类型再补 800 条。总共 2000 条左右就已经能把字段 F1 推到 93% 以上。不要一上来就砸一万条标注费那是浪费钱。3.2 样本格式系统提示加固定 schema这就是纪律小模型微调时格式本身就是学习信号。如果训练数据里一半样本字段顺序是乱的模型永远学不会 rigid 输出。我的样本格式是标准三段式系统提示把 schema 写死字段含义、枚举值、缺省规则全部列清楚系统提示: 你是工单意图识别与参数抽取助手。请从用户提交的报障文本中提取以下字段以 JSON 格式输出字段顺序固定: - fault_code: 故障代码字符串没有则填 unknown - repair_category: 维修类别取值只能是 [设备重启, 配件更换, 网络故障, 软件升级, 其他] - device_model: 设备型号字符串没有则填 unknown - urgency: 紧急程度取值只能是 [低, 中, 高] 用户输入: 设备 AE-200 昨天下午报错 code 501间歇性重启影响产线请尽快处理。 标准输出: {fault_code: 501, repair_category: 设备重启, device_model: AE-200, urgency: 高}注意字段顺序固定这几个字。模型在训练中会把字段顺序当成一种隐式约束这比任何解码层面的规则都管用。你还可以在部分样本里故意留一个字段缺省教它输出 unknown而不是硬编一个值。3.3 负样本和边界样本小模型最怕自由发挥训练数据里一定要混入不该抽取出东西的样本。真实工单系统里总有闲聊、通知、无关文本混进来。我给每个批次都会配约 8% 的负样本例如用户输入: 今天天气不错食堂的饭也好吃。 标准输出: {fault_code: unknown, repair_category: 其他, device_model: unknown, urgency: unknown}这类样本在告诉模型两件事一是输出里不能有编造的字段二是无关输入走统一的 unknown 路径。没有这部分数据模型在推理时遇到不相关文本就会硬抽编出一堆幻觉字段。除此之外还要加多实体样本——一条工单里出现两个设备、两个故障码的情况教模型区分主要对象加口语化和带错别字的样本训练分布里必须包含推理时实际会遇到的噪声。只用干净语料训练上线必死。3.4 清洗、去重和测试集隔离这条很多人翻过车。我先做了 n-gram 级去重因为同一条文本被标了两次且标签不一致模型会被教坏。然后做了标签一致性检查凡是相同输入对应不同输出的样本全部拉出来人工复核。最要命的是测试集隔离。我见过有人图省事从同一批导出的原始数据里随机切分训练集和测试集结果两边的样本高度重复评测分数虚高得离谱。正确做法是先把原始数据按时间或 ID 分桶保证同一来源的相似文本只出现在一个集合里再分别抽样。评测分数只有经得起隔离检验才有说服力。4. 微调配置实测QLoRA 参数、训练口诀与损失曲线读法4.1 为什么用 QLoRA 而不是全参微调2B 全参微调其实也跑得起单卡 24GB 显存够用。但全参微调在数据只有两三千条时有个实际问题灾难性遗忘。基座模型本来具备的通用语言能力会被训练目标冲掉一部分导致模型在训练分布外表现退化得更快。LoRA 的做法是冻结基座权重只训练低秩增量。对窄任务来说这个增量空间完全够用又能保留基座的通用能力。QLoRA 则是在 LoRA 基础上用 4bit 量化加载基座进一步压低显存占用。实测下来在窄任务上 QLoRA 和全参微调的差距很小但显存和训练时间省了一大截。我这次直接用 QLoRA 跑完整个实验。4.2 一组可复现的超参数下面这组参数是这次实验最终敲定的一组你可以直接抄走当起点再按自己的数据量微调参数取值说明target_modulesq_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj全部线性层都挂 LoRA比只挂注意力层更稳r秩16数据量 3000 以内 16 够用加到 32 边际收益很小lora_alpha32按 alpha 2 倍 r 来配lora_dropout0.1防过拟合learning_rate1.5e-42B 小模型在这个区间表现稳定lr_schedulercosine末尾平滑降到 0warmup_ratio0.03大约 300 步级别per_device_train_batch_size824GB 显存级别gradient_accumulation_steps4有效 batch 约 32max_seq_length1024超长样本直接截断窄任务不需要长上下文num_train_epochs3配合 eval loss 早停bf16true用 bf16 混合精度避免 fp16 溢出weight_decay0.01常规配置训练时长方面单卡 24GB 显存跑 Qwen 3.5-2B2000 条数据 3 个 epoch 大约 1.5 到 2 小时。是的你没看错就是小时级。这是整个方案里最让人舒服的部分——小模型的实验周期短你可以一天迭代好几轮。4.3 训练中的三个关键信号第一个信号是训练 loss。2B 微调一个字段抽取任务训练 loss 通常从 1.8 附近起步3 个 epoch 内能压到 0.3 左右。如果某个 epoch 结束时训练 loss 还在 0.8 以上大概率是学习率太大或者样本格式不统一先别加 epoch去查数据。第二个信号是 eval loss。训练 loss 降但 eval loss 回升就是过拟合的铁证立刻早停。窄任务对过拟合比通用任务更敏感因为你的训练分布和评测分布之间的差异可能很小模型一旦开始背训练集评测分数立刻掉。第三个信号是我个人非常依赖的人工过样。每 100 步保存一个 checkpoint然后固定用同一批 50 条样本跑一遍生成结果肉眼看输出格式有没有漂移。我最常发现的问题是某个字段开始输出中文而不是枚举值这种问题 loss 看不出来只有人工过样能抓出来。4.4 微调后的第一个检查训练集还原度模型训练完不要直接上测试集评测先看训练集还原度。这一步是定位问题用的如果训练集上的准确率不到 95%说明模型根本没学会问题在数据格式或训练配置如果训练集 99% 但对抗样本掉得厉害说明过拟合了要加正则或者补数据。我用的是现成的推理框架把微调后的模型导出先跑一遍训练集看错误集中在哪。这一步做完再上正式评测集你的评测才有意义。5. 评测复盘2B 到底在哪些维度反超了 27B5.1 四组实测数据对照下面这组数字是我那一轮跑出来的结果环境是单张 24GB 显存的常规加速卡推理温度 0greedy 解码仅作为量级参考组别整条 EM字段级 F1格式合法率平均单条响应A2B 基座 简单提示24.6%58.3%47.2%0.8sB2B 基座 QLoRA 微调76.2%93.8%98.6%0.8sC27B 基座 提示词工程47.5%74.6%60.4%2.4sD27B 基座 few-shot62.8%86.9%78.3%2.7sB 组在字段级 F1 上比 C 组高了将近 20 个百分点比 D 组也高了 7 个百分点。最扎眼的其实是格式合法率27B 即使认真写了提示词格式合法率也只有 60% 左右微调后的 2B 是 98.6%。参数越大、越聪明在窄约束下反而越容易自由发挥——这不是它不懂 JSON而是它在面对模糊输入时倾向于用常识补全而不是严格遵守 schema。5.2 反超的三个具体形态拆开看微调 2B 的反超集中在三个地方。第一是格式稳定性它几乎不会输出多余文本开场白、解释、废话全都没有直接给 JSON。第二是漏字段27B 经常漏掉紧急程度这种需要从语境推断的字段而微调 2B 把它当成必填项处理缺了就往 unknown 走。第三是拒绝逻辑遇到无关文本27B 会硬抽字段微调 2B 学会了走统一的 unknown 路径。这三个形态本质上都是同一个原因微调把任务约束写进了权重而不是让它靠临场发挥。5.3 必须承认27B 仍然占优的维度诚实地说27B 也有它明显占优的地方。最典型的是分布外鲁棒性——换一种完全没见过的表达习惯、新增一种故障类型时27B 靠通用理解还能顶一下微调 2B 会退化得比较快。另外就是知识性字段某个故障码在训练数据里没出现过27B 可能靠常识猜个大概微调 2B 只能老老实实输出 unknown。所以我在做这个系统的时候最终的部署策略不是用 2B 替换 27B而是2B 前置处理大部分样本低置信度样本路由给 27B 兜底。小模型负责稳定和便宜大模型负责边界情况。这个思路后面第 6 节还会展开。5.4 成本账显存、延迟、单条推理成本最后算一笔账。为什么说这不是花架子而是有实际意义的降本维度2B 微调27B 基座加载显存bf16 含运行时约 5GB单卡可跑接近 55GB需多卡或 4bit 量化单条延迟512 输入 / 256 输出约 0.8s约 2.5s 起推理成本折算1x约 5 到 10 倍训练成本单卡数小时不做微调无训练成本27B 模型在显存和延迟上的开销是数量级的差异。如果每天要解析几十万条工单这个成本差直接体现在账单上。小模型赢了指标又赢了成本这才是逆袭的真实含义。6. 什么任务别指望 2B 逆袭三条红线与快速适配测试6.1 三条红线我把不适合这套打法的任务归纳成三类碰到直接绕道。第一是知识密集型任务比如法律条款解释、医疗诊断建议、领域术语问答。2B 参数装不下这种外部知识微调最多让它背住训练数据里出现过的那部分遇到新问题就会打回原形。第二是多步推理和长逻辑链任务比如复杂数学题、因果链分析、深度代码排错。这类任务对模型的中间表示能力和注意力跨度要求很高2B 的容量确实不够微调解决不了根本问题。第三是开放性生成任务比如创作类写作、开放域对话。输出空间无限评测没法收敛模型的学习目标都不清楚逆袭自然无从谈起。三条红线之外的任务才值得用这套打法。6.2 快速适配测试100 条样本定生死我一般先做 100 条样本的快速测试再决定要不要投入。拿 100 条真实输入直接丢给基座 2B带上你准备好的系统提示然后看错误模式分类。如果错误集中在格式不对、漏字段、枚举值用错这类规则性错误说明模型理解能力够用只是不遵守约束微调能救大胆开跑。如果错误集中在这个词它不认识、这个业务逻辑它完全没概念这类知识性错误那就是任务分布太宽或太深微调救不了趁早换大模型或者加检索。我自己的经验阈值是格式类错误占比超过 60%试微调知识类错误占比超过 40%别跳坑。6.3 扩展思路蒸馏、路由和增量更新这套打法的后续扩展方向有三个。一是用蒸馏思路做数据获取让 27B 先生成一批标注人工修正后再喂给 2B形成一个大模型辅助建数据、小模型低成本上线的正循环。二是混合路由部署2B 前置处理低置信度样本转发给 27B用路由把成本和质量调到最优。三是定期增量更新每月用线上真实数据做一次继续微调让 2B 始终贴合最新分布。最后说点个人体会。这个实验做完我最大的感受是模型选型不应该用参数量投票而应该用任务分布与模型能力的重合度投票。把 27B 的预算省下一半一半花在高质量标注管线上一半花在推理部署上很多垂直任务的综合收益反而更高。当然碰到上面说的三类红线任务该上大模型就上别硬省——省钱的前提是先选对战场。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
