Skip to content

Step3 / Qwen2.5 SFT Final Comparison

The current site directly includes the original Chinese report source below. English translation can be added later without changing the source organization.

Qwen2.5 邮政客服 SFT 最终对比报告

结论先行

在当前这批训练数据、自动评估集和 MLX LoRA 参数下,3B 的结果比 7B 更适合作为现阶段交付候选。

当前推荐:

Qwen2.5-3B-Instruct + LoRA rank 1
adapter: ../mlx_qwen_sft/runs/20260703_021130_qwen2.5-3b-lora_rank_sweep/rank_1/best_adapter/qwen2.5-3b-lora-r1/

7B 当前最合适的候选是:

Qwen2.5-7B-Instruct + LoRA rank 2
adapter: ../mlx_qwen_sft/runs/20260703_045302_qwen2.5-7b-lora_rank_sweep/rank_2/best_adapter/qwen2.5-7b-lora-r2/

但从当前自动评估结果看,7B rank 2 的综合分明显低于 3B rank 1。这个结论只对当前实验条件成立。由于缺少更大规模的内部业务数据,评估集也偏小,后续如果数据质量、数据规模或训练参数发生变化,3B 和 7B 的相对表现可能会明显改变。

数据来源

本报告使用结构化训练监控数据,不从图片反推指标。

../mlx_qwen_sft/runs/20260703_021130_qwen2.5-3b-lora_rank_sweep/
../mlx_qwen_sft/runs/20260703_045302_qwen2.5-7b-lora_rank_sweep/
../mlx_qwen_sft/global_compare/global_rank_summary.csv

每个 rank 的结果来自 rank_*/logs/train_monitor_*.jsonl,其中记录了每个评估 step 的综合分、JSON 可解析率、字段完整率、安全风险、邮政业务词命中和下一步建议命中等指标。

横向结果

Model Rank Best Step Best Score Final Score JSON Valid JSON Keys Safety Risk Postal Terms Next Steps
3B 1 500 3.6313 3.4000 1.0000 0.3333 0.0000 2.8750 3.5000
3B 2 400 3.4062 2.6875 1.0000 0.3333 0.0000 1.8750 3.1250
3B 4 200 3.2750 2.6500 1.0000 0.3333 0.0000 1.5000 2.7500
3B 8 100 3.4000 2.6750 1.0000 0.3333 0.0000 2.0000 3.0000
3B 16 400 3.1125 2.5938 1.0000 0.3333 0.0000 1.2500 2.1250
3B 32 500 2.9062 0.3875 1.0000 0.3333 0.0000 0.8750 1.3750
7B 1 900 1.5875 1.5625 1.0000 0.3333 0.0000 2.2500 3.7500
7B 2 700 1.6125 1.5875 1.0000 0.3333 0.0000 2.2500 3.8750
7B 4 300 1.5688 0.6771 1.0000 0.3333 0.0000 2.1250 3.7500
7B 8 100 1.5688 1.3500 1.0000 0.3333 0.0000 2.1250 3.7500
7B 16 200 1.5438 0.6875 1.0000 0.3333 0.0000 2.1250 3.6250
7B 32 500 2.5063 0.7688 1.0000 0.0000 0.0000 0.8750 1.8750

图表

综合分随 rank 的变化

Best score by rank

3B 在 rank 1 达到最高 best score,之后整体下降。7B 的瞬时最高分出现在 rank 32,但这个结果不能直接作为推荐,因为 rank 32 的 final score 低,JSON 字段完整率也掉到 0。

最终分随 rank 的变化

Final score by rank

final score 更能反映训练后期稳定性。3B rank 1 的 final score 是 3.4000,明显高于 7B rank 2 的 1.5875。7B rank 4、16、32 在后期回落更明显。

best 与 final 的差距

Score drop by rank

这个图主要看模型是否在训练后期退化。3B rank 32 和 7B rank 32 都有较大回落。7B rank 2 的 score drop 很小,说明它是 7B 里更稳的选择。

邮政业务信号

Postal terms by rank

Next steps by rank

邮政业务词和下一步建议命中并不是越高越好,但它们能反映模型是否学到了客服场景里的基本表达。3B rank 1 在邮政业务词命中上更强,7B rank 2 在下一步建议上也不错。两者都能给出“查询、核实、联系官方渠道”这类相对稳妥的处理方向。

推荐配置

Recommended configuration by model

推荐配置没有只看最高 best score,而是同时要求:

json_keys > 0
score_drop <= 0.5
safety_risk = 0

按这个约束,3B 推荐 rank 1,7B 推荐 rank 2。

为什么当前 3B 更好

3B rank 1 的优势比较直接。

第一,它的综合分最高。best score 是 3.6313,final score 是 3.4000,两项都高于当前 7B 的推荐配置。

第二,它没有明显后期崩坏。best step 在 500,训练到 800 step 后仍然保持 3.4000。相比之下,7B rank 4、rank 16 和 rank 32 都有较明显的 final 回落。

第三,它的格式和安全指标没有出问题。JSON 可解析率是 1.0,安全风险是 0。JSON 必需字段完整率仍然只有 0.3333,这是两组模型共同的问题,不是 3B 单独的问题。

第四,它的训练和部署成本更低。对于实习项目里的本地 MLX 环境,3B 的速度、显存压力和反复试验成本都更可控。如果当前自动评估已经显示 3B 更强,就没有必要为了模型尺寸继续推 7B。

7B 的位置

7B 不是完全不可用。当前最稳的 7B 配置是 rank 2:

best_step=700
best_score=1.6125
final_score=1.5875
json_valid=1.0000
json_keys=0.3333
safety_risk=0.0000
postal_terms=2.2500
next_steps=3.8750

它的优点是 final 分和 best 分接近,说明训练后期没有明显崩。下一步建议命中也高,回复倾向比较稳。

问题是综合分不够。当前 7B rank 2 的 best score 只有 1.6125,远低于 3B rank 1 的 3.6313。这可能不是 7B 模型能力差,而是当前训练数据和评估函数没有让 7B 的优势发挥出来。也可能是 7B 需要不同的学习率、训练步数、rank 范围或更高质量的数据。

rank 32 不能推荐。它的 best score 有 2.5063,看起来不低,但 final score 只有 0.7688,JSON 必需字段完整率为 0。这个结果说明它在某个中间 step 有短暂收益,但后期输出结构已经不稳。

为什么会出现这个结果

当前结果不是“3B 天生比 7B 强”,更像是当前数据、训练参数和评分函数共同作用后的结果。

首先,当前数据量偏小。小数据集更容易让 3B 这种较小模型快速贴合目标格式和客服话术。3B rank 1 在 500 step 达到最佳点,800 step 仍然稳定,说明这组数据对它来说已经足够形成有效更新。7B 参数更多,原始能力也更强,但在小规模 SFT 下不一定更容易被推到正确方向。数据不够时,大模型可能只是学到一部分话术,而没有稳定学到完整任务边界。

其次,7B 对训练设置更敏感。当前 7B 使用的是和 3B 类似的 sweep 方式:同样的 rank 列表、同样每 100 step 评估、同样的自动评分逻辑。这个设置能做横向探索,但不代表已经把 7B 调到最好。7B 可能需要更细的学习率、训练步数、batch/累积步数和 rank 范围搜索。现在 rank 2 是 7B 里最稳的,但它的分数还没有追上 3B rank 1。

第三,当前综合分更像工程护栏分,不是纯能力 benchmark。它奖励 JSON 可解析、字段完整、邮政业务词、下一步建议,同时惩罚安全风险和通用任务污染。这个评分函数适合筛选“能不能作为客服流程节点使用”的 adapter,但不等于全面衡量 7B 的语言能力。7B 可能在开放式表达、复杂推理或长上下文上更强,但这些优势没有在当前小评估集里充分体现。

第四,7B 的高 rank 出现了后期漂移。rank 32 的 best score 到过 2.5063,但 final score 只有 0.7688,JSON 必需字段完整率掉到 0。这说明高容量 LoRA 在当前数据下确实能短暂学到一些东西,但继续训练后会破坏结构化输出。这个现象也解释了为什么不能只看某个中间 best 分数,更要看 final score、score drop 和 JSON keys。

第五,JSON 字段完整率是两边共同短板。3B rank 1 和 7B rank 2 的 json_keys 都只有 0.3333。也就是说,当前数据还没有把结构化输出约束教稳。3B 现在赢在综合分和稳定性,但它并不是已经完全满足结构化客服助手的要求。

按目前情况怎么做

现阶段不要继续盲目加模型、加 rank 或加训练步数。当前最稳的交付路径是:

主候选:3B rank 1
备选:7B rank 2
不推荐:7B rank 32、3B rank 32

3B rank 1 适合先进入人工抽检和流程联调。它分数最高,后期没有明显崩坏,本地推理成本也低。对于当前资源条件,先把它接到客服流程里看真实样例,比继续堆 7B rank sweep 更有价值。

7B rank 2 应该保留,但不建议现在继续跑高 rank。下一轮如果要优化 7B,优先围绕 rank 2 做小范围实验,例如:

rank: 2
step: 500 / 700 / 900 / 1000
learning_rate: 5e-6 / 1e-5
重点观察:score_drop、json_keys、safety_risk

数据侧比模型侧更重要。下一步最该补的是三类样本:

数据类型 目的
JSON schema 专项样本 提高 json_required_keys_rate,让模型稳定输出必需字段
真实邮政客服边界样本 覆盖延误、赔付、禁限寄、改地址、国际件、网点营业时间等高频问题
非邮政问题和隐私安全样本 避免把电商、优惠券、手机号查地址等问题错误接成邮政业务

评估侧也要加人工抽检。自动评估能快速发现格式崩坏和明显风险,但它不能判断客服语气是否自然、解释是否够具体、是否绕开了用户真正的问题。建议固定一张人工抽检表,至少看这些项:

是否过度承诺
是否虚构政策或时效
是否明确建议官方渠道核实
是否保护隐私
是否能拒答非邮政问题
是否保持客服语气
JSON 字段是否完整

如果后续拿到更多内部数据,再重新比较 3B 和 7B。更大、更干净、更贴近真实工单的数据可能会改变结果。到那时,7B 可能会重新体现出更大模型的优势;但以当前数据和资源看,3B rank 1 是更稳的交付选择。

当前限制

这次实验有几个限制,报告结论要按这个边界理解。

第一,缺少真实内部业务数据。目前训练和评估更多依赖整理后的邮政客服样例、格式题、安全题和小规模通用回归题。它能帮助快速筛掉坏配置,但不能完全代表真实客服场景。

第二,数据量偏小。当前评估集适合做训练过程监控,不适合作为最终上线评测。特别是 JSON 字段完整率、政策边界和非邮政问题拒答,都需要更多样本。

第三,计算资源有限。rank sweep 是串行跑的,7B 成本明显高于 3B,所以当前没有对 7B 做更细的学习率、step 和数据配比搜索。7B 如果换训练策略,结果可能会变。

第四,评分函数是工程指标。它把 JSON、邮政业务信号、安全风险和通用污染放在一个综合分里,适合筛选 adapter,但不能替代人工评审。

最终建议

现阶段建议把 3B rank 1 作为主候选:

../mlx_qwen_sft/runs/20260703_021130_qwen2.5-3b-lora_rank_sweep/rank_1/best_adapter/qwen2.5-3b-lora-r1/

7B rank 2 作为备选和后续优化对象:

../mlx_qwen_sft/runs/20260703_045302_qwen2.5-7b-lora_rank_sweep/rank_2/best_adapter/qwen2.5-7b-lora-r2/

如果后续能拿到更高质量、更大规模的内部数据,应重新跑一轮实验。重点不是盲目扩大 rank,而是先提高数据质量,补足 JSON schema 样本、真实业务边界样本和非邮政问题拒答样本。到那时,7B 可能会重新体现出更大模型的优势;但在当前条件下,3B rank 1 是更稳、更省、更适合交付的选择。