多模态微调实战(05):微调前后的评测对比
没有评测的微调,只是「loss 在下降」。对 OCR,建议至少同时看三个指标:完全匹配、字符级准确率、编辑距离。这一篇讲怎么把基座和 LoRA 摆到同一把尺子下对比。
这是「多模态微调实战」的第 05 篇。评测是决定「要不要投入全量训练时间」的依据。
一、评测原则
- 同一验证集、同一提示词、同一解码参数;
- 先评基座,再评 LoRA(或合并后模型);
- 指标脚本与业务规则一致(是否忽略空格、大小写等要事先约定)。
二、指标定义
| 指标 | 含义 |
|---|---|
| Exact Match | 预测字符串与标签完全一致的比例 |
| Character Accuracy | 基于编辑距离的字符级正确率均值 |
| Avg Edit Distance | 平均 Levenshtein 距离(越小越好) |
伪代码直觉:
1 | exact = mean(pred == label) |
三、推荐流程
3.1 基座推理
用 swift infer(或封装脚本)对验证 JSONL 批量推理,输出 output/eval_base.jsonl。每行建议包含:id / label / predict / 可选图片路径。
3.2 LoRA 推理
加载同一基座 + --adapters <checkpoint>,输出 output/eval_lora.jsonl。
3.3 汇总指标
1 | python3 script/eval_ocr_accuracy.py \ |
四、一组演示集结果(脱敏示例)
验证集规模:200 条(演示子集)。
微调前(基座)
| 指标 | 值 |
|---|---|
| Exact Match | 约 3% |
| 字符级准确率 | 约 74% |
| 平均编辑距离 | 约 2.0 |
常见失败模式:模型「看起来认对了」,但擅自补全省份简称或改变格式,导致 Exact Match 崩掉。
微调后(LoRA)
| 指标 | 值 |
|---|---|
| Exact Match | 接近 100% |
| 字符级准确率 | 接近 100% |
| 平均编辑距离 | 约 0 |
解读
- 提升主要来自 输出格式与领域对齐,不是魔法;
- 演示集同分布、规模小,指标会被放大;
- 真正上线仍需全量验证集 / 业务抽检。
五、评测时的解码建议
保持简单,便于复现:
- 关闭无必要的采样(或固定 temperature);
max_new_tokens设够车牌长度即可(例如 16~64);- 不要在评测阶段临时改提示词。
六、全量训练后如何评
全量阶段验证集可达数万条:
- 训练中的
eval_loss/eval_token_acc适合监控收敛; - 业务验收仍建议另跑一遍「Exact Match 脚本」;
- 合并模型与 GGUF 模型要用同一脚本对比,避免框架差异造成假象。
七、小结
评测完成标志:
- 有基座 vs LoRA 的并排报告;
- 你能解释失败样本属于「识别错」还是「格式错」;
- 决定是否值得投入全量训练时间。
多模态微调实战第 05 篇完。下一篇:全量训练的后台运行、断点续训与监控。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 WALL-E's Blog!











