Step3 报告：Qwen2.5 SFT 最终对比¶
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 的变化¶
3B 在 rank 1 达到最高 best score，之后整体下降。7B 的瞬时最高分出现在 rank 32，但这个结果不能直接作为推荐，因为 rank 32 的 final score 低，JSON 字段完整率也掉到 0。
最终分随 rank 的变化¶
final score 更能反映训练后期稳定性。3B rank 1 的 final score 是 3.4000，明显高于 7B rank 2 的 1.5875。7B rank 4、16、32 在后期回落更明显。
best 与 final 的差距¶
这个图主要看模型是否在训练后期退化。3B rank 32 和 7B rank 32 都有较大回落。7B rank 2 的 score drop 很小，说明它是 7B 里更稳的选择。
邮政业务信号¶
邮政业务词和下一步建议命中并不是越高越好，但它们能反映模型是否学到了客服场景里的基本表达。3B rank 1 在邮政业务词命中上更强，7B rank 2 在下一步建议上也不错。两者都能给出“查询、核实、联系官方渠道”这类相对稳妥的处理方向。
推荐配置¶
推荐配置没有只看最高 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 是更稳、更省、更适合交付的选择。