要判断一个多模态大模型是否真正读懂了一张图最直接的办法是把它放进一个足够难、足够接近真实场景的任务里。面向科学图表的 Diagram-MMU 这一类多模态基准测试做的就是这件事用论文里常见的折线图、散点图、流程图、显微照片和模型结构图去检验模型在坐标轴理解、数值读取、空间对齐和多步推理上的综合能力。很多人把 benchmark 理解为跑分和胜率但在科学图表评测里它更接近一套诊断工具。这篇文章会围绕 Diagram-MMU 的设计思路从数据格式、难度分层、评估脚本、指标计算、错误归因到生产环境复现完整拆解一次多模态科学图表评测的工程实现。1. Diagram-MMU 到底在评测什么从通用 VQA 到科学图表理解1.1 一张论文图表比一张生活图片难在哪日常图像问答中模型常见的任务是识别物体、描述场景、判断位置关系。这类任务更接近“看图说话”对空间、符号和数值的要求不高。一旦切换到论文图表问题性质就变了。科学图表通常由坐标轴、刻度、图例、单位、阴影区域、误差棒、箭头和标注文字组成。模型不能只“看到”图里有一个点还要判断这个点对应的 x 轴值和 y 轴值要区分实线和虚线代表的不同实验组要理解误差棒是标准差还是置信区间。这个过程中的任何一环出错最终答案都会偏。下面用一张对比表说明三类图像之间的差异对比维度自然图片通用信息图论文中的科学图表信息密度低到中主要依赖视觉语义中依赖排版和配色高符号、坐标、单位、注释并存坐标系统通常不出现可能不出现必须理解轴、刻度、坐标对应关系符号系统物体为主图例和简单图标图例、缩写、单位、误差棒、统计标记推理类型描述和识别检索和概括数值比较、趋势归纳、结构判断、外推领域知识通常不需要少量需要往往需要实验设计和学科背景正因为这些差异通用图文评测无法回答一个关键问题模型到底是真正“理解”了图表还是仅仅用常识和训练语料在猜答案。Diagram-MMU 把评测对象收窄到科学图表目的就是让每一个题目的判断都建立在图表本身的信息之上。1.2 能力维度拆解评测要覆盖哪六类理解能力设计多模态评测基准时最忌讳只给出一堆题目而没有能力分层。这样得到的总分无法指导后续改进。Diagram-MMU 这类评测通常把能力拆成六个维度。第一类是图表元素识别。例如“这张图的 x 轴标签是什么”或“图中哪些组使用虚线表示”。这类题目考察模型能否找到并读取图表中的结构化标记。第二类是数值读取和计算。例如“x 等于 3 时 y 的近似值是多少”或“B 组的均值比 A 组高多少”。这类题目要求模型把视觉位置转换为数值并完成基础运算。第三类是趋势与规律归纳。例如“从 2005 年到 2010 年误差条是变大还是变小”。模型需要在多个数据点之间建立关系而不是只看单个点。第四类是结构关系推理。适合流程图、架构图、状态图。例如“满足条件 A 后应当进入哪个模块”。这类题要求模型理解箭头、分支和循环结构。第五类是科学知识结合。例如“图中曲线接近饱和增长还是指数增长”。回答这类问题不仅需要读图还需要知道这些术语在学科中的定义。第六类是不确定性判断。例如“根据现有图能否确定两个指标之间存在因果关系”。模型要能识别证据不足而不是强行给出结论。这六个维度不要求完全独立但题目在入库时必须标注自己主要考察哪一个维度否则后续无法做错误归因。1.3 评测闭环的最小概念模型一个可运行的 Diagram-MMU 评测闭环可以简化为六步。第一步构造或挑选一组科学图表。它可以是论文配图、课程材料、或程序生成的合成图表。第二步为每张图编写题目和参考答案。题目建议包含单选、填空和判断题避免只使用一种题型。第三步让模型在只看到图像和问题的前提下输出文本答案。这里要控制检索、外部知识和多轮上下文的影响。第四步对模型输出做归一化处理。包括大小写、空格、单位、标点和格式。第五步将归一化后的答案与参考答案比对按题目类型计算准确率。第六步按类别、难度和错误类型拆解指标生成逐样本错误文件。每一步都有对应的工程问题。数据格式设计不当后面的脚本就要频繁改提示词不一致最终得分就会偏移指标口径不统一模型之间就无法比较。下面先从数据层开始。2. 数据是评测的地基先确定目录、Schema 和难度分层2.1 目录结构让图片、题目和答案分开存放评测数据必须可复制、可审计。最简单有效的做法是把图片、题目和答案分成三个独立目录。这样评估脚本只读题目和答案不会在构造 prompt 时不小心把答案带进去。下面是一个参考目录结构diagram-mmu/ ├── images/ │ ├── scatter_001.png │ ├── line_037.png │ ├── bar_012.png │ └── flow_102.png ├── questions/ │ ├── train.jsonl │ ├── dev.jsonl │ └── test.jsonl ├── answers/ │ └── test.answers.jsonl ├── config/ │ └── evaluation.yaml └── scripts/ ├── evaluate.py └── summarize.py把 train、dev、test 分开是为了防止模型在开发阶段反复接触测试集。图片文件名使用语义化前缀加序号比如scatter_001表示第一张散点图flow_102表示第 102 张流程图。命名规则要统一后面按类别统计时才能直接解析。2.2 用 JSONL 描述一个评测样本题目文件建议使用 JSONL 格式每一行是一个样本。相比一个大的 JSON 数组JSONL 更容易增量追加、断点续跑也方便用grep和jq快速排查。一个评测样本可以长这样{ id: dia-001, image_id: scatter_001, category: scatter_plot, difficulty: hard, question: 图中 x 轴约为 2 时y 值落在哪个范围, answer_type: numeric_range, reference: [ { value: 18-22, type: range } ] }这里有几个字段需要特别注意。id是样本唯一标识。image_id引用 images 目录下的文件而不是直接写完整路径。这样脚本可以在不同平台和不同数据根目录之间迁移。category表示图表类型比如scatter_plot、line_chart、flow_diagram。difficulty用于难度分层。answer_type决定了评分方式比如numeric_range表示答案是一个数值区间option表示多选题选项short_text表示短语答案。reference是一个数组而不是单个字符串。原因是一个科学图表题往往存在多个可接受答案。比如“图中哪条曲线代表实验组”参考答案可能是“实线”也可能是“深色线”二者都算对。注意参考答案不应该只由出题人一个人确定。至少要两个标注者独立给出答案再合议差异否则基准本身就带主观偏差。2.3 任务类型与难度分层题目入库前要打上任务类型标签。不同任务类型对模型能力的要求差异很大混在一起统计会掩盖问题。可以按下面的粒度划分任务类型任务类型问题示例主要考察能力建议难度element_extraction这张图的 x 轴标签是什么元素识别easyvalue_readingx 等于 3 时 y 值约为多少数值读取easy 到 mediumtrend_inference曲线在 2005 年后是上升还是下降趋势归纳mediumstructure_reasoning条件 A 满足后进入哪个模块结构关系mediumnumeric_comparisonB 组均值比 A 组高多少倍数值计算hardscientific_knowledge曲线更接近对数增长还是指数增长知识与图表结合hard难度分层的建议比例是 easy 占 30%、medium 占 50%、hard 占 20%。这个比例不是固定的但不要让 easy 题占比太高否则总分容易被简单题目拉高看不出模型在真正难点上的表现。难度定义要写进评测协议不能由题目创作者凭感觉标注一遍就过。2.4 构建样本时的坑构建科学图表评测集时最常见的几个问题都出在“题目的可判定性”上。一个是参考答案没有给出容差。比如问“x 为 3 时 y 是多少”如果实际值是 19.3参考答案只写一个19.3模型输出19就会被判错。更好的做法是允许一个相对误差范围例如19.3 /- 0.5或写成区间18.8-19.8。另一个问题是同一张图生成过多雷同题目。比如让模型反复读取同一批点的坐标评测结果会偏向“数值抽取”能力而弱化“关系推理”。建议每张图最多只设计三到五个题目且尽量覆盖不同难度。还有一个问题容易被忽略图表来源的版权和使用许可。论文图表可以用作学术评测但发布数据集时要确认授权方式否则后续开源会受限。3. 用评估脚本跑通闭环加载、预测、归一化、打分3.1 依赖准备评测脚本不需要复杂框架只需要稳定的基础依赖。下面是一个可以运行的依赖组合。依赖用途建议版本Python运行脚本3.10 及以上Pillow图像读取和尺寸检查10.xtransformers加载开源多模态模型4.40 及以上torch模型运行后端2.1 及以上pandas结果统计2.0 及以上openpyxl导出 Excel 结果3.1 及以上openai 或类似 SDK调用 API 型多模态模型按服务商要求创建一个虚拟环境并安装依赖mkdir -p diagram_mmu_eval cd diagram_mmu_eval python -m venv venv source venv/bin/activate pip install pillow torch transformers pandas openpyxl openai这里要注意安装torch和transformers之前先确认本机是否有 GPU、CUDA 版本是多少。没有 GPU 时可以用 CPU 运行小模型做调试但正式评测速度会很慢。评测脚本应该把“模型推理”和“结果统计”分开这样即使中途断掉也能从已有预测结果继续打分。3.2 评估主流程评估主流程可以分成加载样本、模型预测、答案归一化、匹配打分四个阶段。下面是一段加载评测样本的示例代码import json def load_samples(question_path): samples [] with open(question_path, r, encodingutf-8) as f: for line in f: line line.strip() if line: samples.append(json.loads(line)) return samples加载完成后逐条调用模型预测。预测结果最好先落盘再统一评分。不要边预测边打分否则一旦其中一个样本的参考答案格式写错整个流程都要重跑。答案归一化是决定评分稳定性的关键步骤。一个简单的归一化函数如下import re def normalize_answer(text): if text is None: return text text.lower().strip() text re.sub(r\s, , text) text re.sub(r[.,。;:、], , text) text re.sub(r[$_], , text) return text.strip()归一化要解决的问题是模型可能输出“约 19.5”参考答案写“19.5”两者在字面上不同但在语义上应该判对。归一化处理的是标点、空格、单位符号等表面差异不处理语义差异。对于数值范围题匹配逻辑略有不同def match_range(pred_text, reference): value extract_numeric_value(pred_text) if value is None: return False low, high parse_range(reference) return low value high这段代码只是一个示例。实际项目要根据题目的answer_type分发到不同的匹配函数比如option走选项匹配short_text走归一化后的字符串匹配numeric_range走数值区间匹配。3.3 指标计算Acc、EM、F1 与 LLM-judge科学图表评测最常用的是准确率accuracy但只有准确率不够。Exact Match要求模型输出与参考答案在归一化后完全一致适合选项题和短答案题不适合数值范围题。Accuracy把有容差的答案也计为正确适合大多数科学图表题。F1适合答案由多个词组成、但顺序可能不同的情况例如“x 轴标签是时间单位是天”模型可能输出“时间单位是天”或“单位是天时间”。LLM-judge用一个文本模型判断答案是否语义等价。它能解决“参考答案只是多种正确说法之一”的问题但自身也有偏好和漂移必须作为辅助指标而不是唯一指标。准确率的计算可以这样写def calculate_accuracy(predicted_scores): return sum(predicted_scores) / len(predicted_scores) if predicted_scores else 0.0更完整的统计会把结果按category和difficulty分组后面单独展开。3.4 零样本 VLM 调用示例评测中不一定要先做微调。先用零样本方式调用一个多模态模型得到的基线结果非常有价值。下面是一个使用transformers的示例from PIL import Image from transformers import pipeline model_id your-vlm-model-id vlm pipeline(image-to-text, modelmodel_id) def predict_with_vlm(image_path, question): image Image.open(image_path).convert(RGB) prompt ( 请基于这张科学图表回答问题。 不要猜测不要展开解释只输出最终答案。 问题 question ) out vlm(image, promptprompt) return out[0][generated_text]这里把提示词分为三个部分身份约束“基于这张科学图表”、输出约束“只输出最终答案”、实际题目。这样做的目的是减少模型长尾解释对答案匹配的干扰。如果使用 API 型模型也要保持相同的约束逻辑。评测脚本要记录每次调用的模型版本、提示词文本和采样温度。温度建议固定为 0避免相同输入产生不同输出影响可复现性。4. 看懂结果从总分到错误归因4.1 落盘结果保留逐样本记录评测完成后不能只打印一个总分。一份可检查的评测结果至少应包含样本 ID、图像路径、类别、难度、问题、模型输出、参考答案和是否得分。结果可以导出为 CSVid,image_id,category,difficulty,question,predicted,reference,score dia-001,scatter_001,scatter_plot,hard,图中 x 轴约为 2 时 y 值落在哪个范围,19.5,18-22,1 dia-002,line_037,line_chart,medium,曲线在 2005 年后是上升还是下降,上升,上升,1 dia-003,flow_102,flow_diagram,medium,条件 A 满足后进入哪个模块,模块 C,模块 B,0保存逐样本记录的价值在于重算指标时不需要再次调用模型同时可以通过查看错题文件快速定位错误类型。结论是预测结果是一种中间产物必须落盘指标是事后从中间产物计算的。4.2 按类别和难度拆解总准确率只说明整体水平不说明模型擅长什么。真正的分析要从两个维度展开按图表类型按难度。使用 pandas 可以快速生成透视表import pandas as pd df pd.read_csv(results.csv) pivot df.pivot_table( indexcategory, columnsdifficulty, valuesscore, aggfuncmean ) print(pivot)如果发现模型在scatter_plot上很好但在flow_diagram上很差说明问题更可能出在空间路径理解而不是数值读取。如果 easy 题准确率很高、hard 题断崖式下降说明模型具备基础识别能力但缺少多步推理能力。这两个判断对后续优化方向的指导意义远大于一个总分。4.3 错误类型分析把错题翻出来按错误现象归类是评测中最有价值的一步。以下是常见的错误类型错误现象可能原因改善方向数值输出与坐标刻度不一致图像分辨率不足坐标轴文字和刻度被压缩提高输入分辨率分段裁剪图表再推理读错图例线型把实验组和对照组弄反图例颜色相近或提示词没有要求先读图例提示词中增加先读图例的步骤或对图像做颜色增强单位被忽略输出数字没有带单位模型没有关注坐标轴标签中的单位字段评测规则允许数字加单位或提示要求必须包含单位流程分支判断错误箭头和指向关系未被模型识别使用结构推理提示或对箭头和节点做目标检测后输入文本回答与图表无关来自训练语料模型直接依赖领域先验没有盯住图表在评测中增加“证据不可用”类样本或使用更复杂图表降低先验命中率错误归因的目的不是给模型贴标签而是给评测集和模型改进提供输入。每发现一个新错误类型就应该把它加进评测协议的错误标签字典。4.4 对比表怎么看展示多个模型对比时建议用一张分组明细表而不是只给一个总排名。下面的表格仅用于说明结果展示形式数字为示例不是真实评测数据模型总准确率element_extractionvalue_readingstructure_reasoning随机猜测基线22.025.018.020.0通用多模态模型 A58.271.563.041.2图表微调模型 B67.869.074.358.6从这个表格可以看出模型 A 的元素识别不差但结构推理弱模型 B 的元素识别略低于 A但结构推理明显强。只看总准确率B 比 A 高不到 10 个点看分项才能判断 B 的提升主要来自哪里。5. 复现评测中最常见的六个坑5.1 图像缩放导致细粒度文字丢失现象是模型在图上本来能识别的大块区域都对唯独坐标轴数字、小号图例文字容易读错甚至把 3 看成 8。原因是很多多模态模型调用前会把图像缩放到固定尺寸比如 224x224 或 336x336。论文图表本身信息密度高缩小后细粒度文字会被压缩成无法辨认的色块。检查方式是保存模型实际看到的那张预处理图像而不是原图。用肉眼确认坐标轴数字是否还能看清。处理方式是保持宽高比提高输入分辨率或者在预测前把图表按坐标区域裁剪成多个局部图分别读轴标签、图例和主体。预防建议是在评测配置中记录最终输入尺寸。同一模型不要在一次评测中使用不同输入尺寸否则结果不可比。5.2 提示词不一致现象是同一个模型只换了一句提示词分数可以差十几个点。比如“请直接回答”和“请先描述图表再回答”会把模型的输出格式和推理路径带向不同方向。原因是语言模型对提示词的敏感度高。多模态模型在理解图像之后仍然要依赖语言层组织答案。检查方式是每次实验保存提示词模板和提示词 hash。处理方式是固定一套提示词不允许不同评测成员各自发挥。预防建议是把提示词写进评测配置文件和数据集版本一起管理。注意提示词和数据集一样需要版本化。改提示词就等于换了一个评测任务。5.3 闭卷与开卷混淆现象是有些评测允许模型调用外部工具或检索网页有些只允许看图答题但最后的分数放在同一个表格里比较。原因是评测协议没有明确“是否为闭卷”这个约束。科学图表领域知识多模型一旦能检索论文等于多了额外信息源分数就不再只代表读图能力。检查方式是查看每个模型的调用日志确认是否存在检索或联网动作。处理方式是在评测配置里增加knowledge_source: closed或knowledge_source: open字段。预防建议是默认关闭外部检索只有专门做检索增强评测时才打开。5.4 指标口径不统一现象是同一个评测结果有人用 EM 算有人用范围匹配算有人用 LLM-judge 算得到三个不同分数。原因是数值题和短语题天然存在多种正确答案而不同评分函数对“正确”的定义不同。检查方式是重新阅读评分代码确认数值题的容差是多少、多选题的判定条件是交集还是包含。处理方式是在结果文件里同时输出多个指标列比如score_em、score_acc、score_llm_judge。预防建议是评测报告必须写明指标定义否则后续任何人都无法复现。5.5 数据泄漏现象是测试集里的图表本身就在模型的预训练数据中出现过模型可能已经“见过”原图甚至见过原图的答案讨论。原因是很多公开论文图表在网络上传播范围广容易进入通用爬虫语料。检查方式是随机抽几张测试图用图中文字和图像特征做近似搜索。处理方式是优先使用新合成图表或对公开图表做颜色、坐标范围和标注文字的强扰动。预防建议是构建一个私有测试集或者在论文公开时明确声明测试集需要留出隔离期。5.6 多轮对话评测污染现象是同一个会话中先问了几道其他题再问目标题模型可能受前文影响而改变答案。原因是评测时如果使用带上下文的对话接口前一轮的问题和模型回答会成为后一轮的隐含提示。处理方式是每条评测样本都启用独立 session避免上下文串扰。预防建议是将采样温度固定为 0并记录请求的唯一会话 ID便于复现。6. 从评测到改进最佳实践、检查清单与扩展方向6.1 一套可复用的评测设计检查清单每次发布或更新 Diagram-MMU 评测结果前建议按下面这份清单逐项检查。清单要具体能勾选而不是一句话带过。[ ] 每张图表是否确认了来源和使用许可[ ] 每道题的参考答案是否经过至少两名标注者独立标注并合议[ ] 数值类题目是否定义了容差或数值区间[ ] 题目是否覆盖了至少六类能力维度[ ] easy、medium、hard 的样本比例是否记录在评测配置中[ ] 训练集、验证集、测试集是否严格分离[ ] 是否保存了模型实际输入的图像预处理版本[ ] 提示词模板是否固定并保存了 hash[ ] 模型版本、采样温度、推理后端是否记录[ ] 是否明确评测为闭卷或开卷[ ] 逐样本预测结果是否落盘为 CSV 或 JSONL[ ] 是否同时计算 EM、准确率、必要时加 LLM-judge[ ] 是否输出按 category 和 difficulty 拆分的透视表[ ] 是否对错题做过错误类型分析[ ] 是否存在测试集泄漏风险评估过是否需要扰动或私有化这份清单可以粘贴到评测仓库的 README 或 CI 检查脚本中。6.2 开发环境与生产评测环境的差异开发时大家习惯用小批量样本快速验证脚本正式发布评测结果时就必须切换到严格的生产模式。维度开发环境生产评测数据规模10 到 50 个样本用于调试链路全量测试集固定版本不可变数据管理允许临时修改带 checksum修改必须升级版本号随机性为了调参可以临时调整温度固定温度为 0固定推理 seed日志打印关键样本即可记录每个请求的完整输入输出、耗时和模型版本权限本机运行权限宽松需要审计日志防止测试集被误改失败处理报错后人工看断点续跑保留已完成预测回滚代码回滚即可数据和模型版本都纳入回滚范围生产评测不是简单地把批量调大而是要把“不可复现”的风险降到最低。最安全的策略是把评测拆成 predict 和 score 两步预测完成后先生成不可变的中间产物再基于中间产物反复计算不同指标。6.3 下一步扩展方向Diagram-MMU 这类科学图表基准的扩展方向可以从数据、任务和用途三个角度考虑。数据层面可以增加更多学科领域比如医学影像图、材料相图、气候模型输出图。不同学科共享坐标轴和数值语义但符号体系差异很大正好用来检验模型的知识迁移能力。任务层面可以从“回答问题”扩展到“给出依据”。模型回答后需要指出图中哪条曲线、哪个坐标范围支撑了它的结论。这样评测的不仅是最终答案还有模型定位证据的能力。用途层面可以把评测结果直接接入数据处理流程。统计出模型易错的图表类型后将这些错题作为微调训练集中的困难样本或者用来生成偏好数据进一步做对齐优化。还有一个值得关注的方向是图表生成与反事实测试。给定一个描述让模型生成对应的图表然后修改描述中一个变量再次生成。评测生成图表是否和描述一致可以反向验证模型对图表语义是否真正理解。回到评测的本质Diagram-MMU 这类科学图表多模态评测的核心价值不是给模型排名而是给出可诊断的信号。数据质量、参考答案的容差、提示词固定、指标口径和错误归因每一项都比单纯的总分更重要。如果你刚开始搭建类似的评测建议先用 30 到 50 个样本跑通完整协议确认每一层都能落盘和复现再逐步扩大规模。评估脚本要保留中间产物评测配置要版本化错题要按分析维度归类。有了这样一套稳定闭环后面换模型、换提示词、换任务都能快速得到可信结论。