给小学数学 App 喂数据：一次多模态微调实录

示例素材声明：下文 before/after 对比框里的模型输出为脱敏示例数据，用于演示「微调前后差异」的呈现方式；真实评估文本与准确率指标待站主补充后替换（见文末「TODO」）。

问题：拍照批改为什么总判错

我在做一个给小学生用的数学批改 App（math_app，Flutter + 火山引擎 Doubao-Seed-1.6-flash 多模态接口）。最初的流程很朴素：拍一张作业照片，连同一句通用提示词发给模型，让它读题、算答案、判对错。

听起来简单，跑起来全是坑：

• 手写体识别差：小学生的「7」常被读成「1」，竖式里进位的小数字直接被忽略。
• 批改逻辑错位：模型经常自己算出正确答案，然后拿这个答案跟图里学生写的答案比，结果却给出「无法判断」。
• 输出格式飘：有时返回大段散文，有时返回 JSON，App 端没法稳定解析。

核心不是「模型不够聪明」，而是通用模型没有被对齐到「批改」这个具体任务。

数据准备：把「批改」拆成可标注的样本

我没有去做参数级微调（小项目、成本不划算），而是走了多模态提示工程 + 少样本对齐的路线，先把任务标准定死：

1. 收集真实作业照片（题目截图 + 学生手写答案），脱敏后约 200 张。
2. 给每张图写结构化标注：题目文本 / 学生答案 / 正确答案 / 错因标签。
3. 把标注里反复出现的失败模式（进位漏读、答案错位）整理成负例提示，明确告诉模型「不要这样做」。

数据准备阶段最耗时，但它是后面所有改进的地基——模型的上限由你定义任务的清晰度决定。

做法：把提示词当成程序来写

关键改动有三处：

• 强制 OCR 与判断分离：先让模型只做一件事——逐字符转写学生手写内容，禁止它「顺手」算答案；拿到转写结果后，再在第二轮里做对错判断。
• 锁死输出 schema：要求严格返回固定字段的 JSON，App 端按 schema 解析，飘格式问题消失。
• few-shot 注入失败模式：在系统提示里放 2-3 个「进位漏读」的负例，显著降低同类错误。

评估：用同一批盲测题量化

我留了 50 道没进过提示词的盲测题，分别用「微调前（通用提示）」和「微调后（对齐提示）」各跑一遍，人工核对。

下表为示例占位指标，真实数值待站主用线上盲测集回填。

Before / After：同一道竖式题

下面是同一张「23 × 7」竖式作业照片，微调前后模型的真实风格对比（已脱敏）：

识别到算式：23 x 1 = 161
（注：学生「7」被误读为「1」）
判断：这道题学生算错了，
正确答案应该是 23×1=23……
但图中写的是 161，无法确定。
输出：一段不定长度的中文说明，
无固定字段。

{
  "题目": "23 × 7",
  "学生答案": "161",
  "正确答案": "161",
  "是否正确": true,
  "错因": null,
  "讲评": "竖式书写规范，进位正确。"
}

微调前把「7」读成「1」、自我矛盾、格式不可控；微调后逐字符转写正确、判断与答案一致、严格 JSON。这就是「对齐任务」带来的差距——模型没换，任务定义和约束换了。

收获

• 先把任务说清楚，再谈模型强弱。多数「模型不行」其实是「任务没定义清楚」。
• 拆步骤比堆提示有效：OCR 与判断分离，单步可控，错误可定位。
• schema 是工程的护栏：锁死输出格式，下游解析才稳。