去年整理论文复现笔记的时候我遇到过一件很受挫的事。我把一张实验对比曲线图发给一个多模态模型请它判断“第三条曲线在训练到 200 步时大概处于什么量级”。模型回答得很有礼貌语言也非常流畅列出了完整结论。可当我把答案和原图坐标逐一对上时发现它引用的刻度、曲线位置和分组信息基本是错的。那一刻我意识到一个问题今天的多模态模型确实能描述自然图片、识别物体、读懂照片里的场景可一旦面对科学图表它常常处于一种“表面上读懂了实际上只读了个轮廓”的状态。最近我注意到一个叫 Diagram-MMU 的多模态基准。单看标题它不太像一个模型更像一把尺子。这把尺子把评估对象设定成了“科学图表”而不是常见的自然图像或 OCR 文本。这件事值得展开聊因为它背后正好戳中了多模态模型从“视觉感知”走向“科学理解”时最容易被忽略的能力缺口。1. 科学图表为什么一直是多模态模型的高危区1.1 自然图像和科学图表的认知逻辑完全不一样大多数公开评测里的视觉问答本质上是在做一件事根据图片判断“画面里有什么”。比如一张照片里有一只狗、一个人、一片草地模型只要完成了物体识别就能生成合理的回答。因为自然图像的语义很大程度附着在物体本身和场景关系上看到的颜色、纹理和轮廓本身就等于大量答案信息。科学图表不是这样。论文里的柱状图、折线图、热力图、流程图、机制图真正的信息不在“画面好看”而在坐标轴、刻度、图例、单位、标注和符号之间的关系。一张折线图里曲线位置代表数值斜率代表变化趋势两条线距离代表差异大小。想要准确回答“哪一组在后期增长更快”模型必须完成一串非常不自然的工作先在图上定位出两条线再沿着像素坐标把位置映射回数值还要理解横纵轴单位最后做比较和推理。这就是为什么很多模型在自然图上表现不错到了科学图表却开始“胡言乱语”。它不是不聪明而是缺少一种能把像素、符号、数值和语义绑定在一起的处理机制。自然图像可以在低分辨率下凭整体轮廓回答科学图表一旦看不清刻度或图例结论就很容易靠猜。1.2 科学图里的信息不是“画面”而是“数据”如果只把图表当成一般图片那模型看到的就是“一些线段”“几块颜色”“粗细不一的文字”。可在一个科学图表场景里这些视觉元素每一个都有明确数值或语义约束。最常见的一类失败就是模型能说出“柱状图中蓝色柱子最高”但当问题变成“蓝色柱子代表的数值相比前一年增加了多少”它就必须先完成 OCR 识别、数值读取、单位换算和算术运算。模型只要任何一个环节出错最终答案就会错而且经常错得很有迷惑性——它会给出一个看起来合理的数字但那个数字并不在图上也不是由任何柱子推导出来的。这也是 Diagram-MMU 这类基准值得关注的原因。它把科学图表单独拎出来相当于告诉社区别再只拿自然图片测多模态模型了那只是检验视觉感知能力要检验模型能不能“读懂数据”必须把图表理解作为专门任务来设计。1.3 Diagram-MMU 标记的是哪一类能力从命名看Diagram-MMU 的三个关键信息是Diagram图表、Multi-Modal多模态、MMU 对应的理解或基准属性。如果把它放到多模态评测的谱系里它想强调的并不是“又多了一组图片”而是把科学图表理解单独变成一种可测量的任务。我会把它理解成一种能力标尺重点标记四件事模型能否识别图表的基本构成比如坐标轴、图例、标签、单位模型能否把视觉位置和数值对应起来完成“读数”模型能否理解图例和语义的关系知道图里的每条线代表什么模型能否基于图表信息完成比较、排序、区间判断和多步推理。这四层能力越往后越接近“科学阅读”也越能区分不同模型之间的真实差距。一个模型如果只擅长识别物体可能在前两层勉强过关但要在 Diagram-MMU 这类评测里拿到好结果必须同时具备视觉编码、符号理解和数值推理能力。你可能会问这些能力不正是多模态模型应该具备的吗其实恰恰是“应该具备”和“实际具备”之间的落差让科学图表评测变得很有价值。它不是故意出难题而是把真实学术阅读场景里的基本要求搬到了测试集里。2. 一个科学图表 benchmark 通常从哪些维度设置题目我没办法在缺少官方数据集的详细文档时替 Diagram-MMU 确认它具体包含多少张图、多少道题、覆盖多少学科这些信息要以后续公开版本为准。但从这类基准的常见设计思路看它一般会围绕几条能力线来设置题目。2.1 表层任务识别、定位、读数第一类任务是模型相对容易上手、也是最基础的任务面对一张科学图表回答“这是什么类型的图”“坐标轴代表什么”“图例里有哪几组数据”“某个点在图像里的位置在哪里”。这些任务看似简单却是后续一切推理的前提。如果一个模型连坐标轴名称都识别不出来那么它根本不可能正确回答“温度在 60 度以后是否继续上升”。这类任务在评测中通常以选择题为主因为答案是确定且可枚举的适合做快速能力筛查。模型做这一类题目时最常见的错误来源不是推理而是视觉编码分辨率太低、OCR 不完整、图例颜色相近时误判。2.2 深层任务比较、区间判断、趋势推理真正把模型区分开的是第二类任务。举例来说题目可能问“两条曲线在哪个时间点开始出现显著差异”“2005 年到 2010 年之间上升最快的是哪一组”“如果横轴再往后延长一个单位根据现有趋势更可能发生什么”这些题目没有标准答案直接写在图里至少不会以文字形式出现。模型需要自己从视觉信息里提取多条曲线进行比较再结合上下文做推断。这比单纯看图说话难很多因为它要求模型把视觉证据转化为数值证据并且不能只看局部。在这一层模型经常犯的错误是读到了正确的趋势但忽略了图例导致两条线对应关系反转或者比较的区间判断错误把整张图的趋势当成某个区间内的趋势再或者理解了曲线但没注意单位产生量级错误。这些错误在人类读者身上也会发生但对模型而言它们往往不是偶然的“手误”而是系统性的表示缺陷。2.3 从符号识别到科学推理的能力阶梯如果把这类 benchmark 的题目按难度排列可以看见一条比较清晰的能力阶梯第一层基本视觉识别判断图片内容第二层符号解码读取刻度、标签、单位第三层语义映射把图例和视觉元素对应起来第四层多步推理综合多个元素完成比较和判断。我比较看重第四层因为它是科学图表理解真正难的地方。很多模型在第一层已经做得很好第二层也能靠 OCR 系统辅助但到第三层和第四层就开始不稳定。真正想在科学文献阅读、论文解析、实验记录自动化这些场景里落地恰恰需要第三层和第四层的能力。所以当你看到一个模型在某类科学图表基准上准确率很高时不要只看总分还要看它到底输在哪一层。如果你只关心自然图像描述第一层强就够了但如果你想让它帮你分析实验数据图那么第四层的能力才是关键。2.4 输出形式为什么会影响评测结果评测的难点不只是题目内容还有答案输出形式。如果题目是多选题模型只要从 A/B/C/D 里选一个评测脚本可以精确判断。但科学图表题目里很多问题天然是开放式的比如“某条曲线的最大值出现在哪个时间点”模型可能需要输出数字、时间段、坐标也可能是文字描述。这时候答案归一化就成了大问题。“0.5”和“50%”可能是同一个意思“2005 年”和“2005 到 2010 年之间”是否算对取决于评分规则“在 100 步左右”和“100”也可能存在允许误差。同一个模型在开放生成评测下的分数普遍低于选择题评测原因不一定是它能力更弱而是它的回答格式不稳定。这也是 benchmark 设计里最微妙的部分评测分数往往是被评测对象和评测规则共同作用的结果。如果评测规则对“一半”和“50%”的映射处理得不好模型就算理解正确也可能被判错。反过来如果规则过于宽松又会出现模型“答得接近但没真正理解”却被判对的情况。这是 Diagram-MMU 这类基准需要认真解决的核心问题之一。3. benchmark 胜率不是“模型战斗力”榜单背后隐藏着三件事现在很多产品和论文会用“benchmark 胜率”来宣传模型看多了会让人产生一个错觉分数越高模型越强越可以放心使用。但这个判断需要打一个折扣。跑分是有意义的可它更像一个“受控条件下测出的参考值”而不是一个绝对战斗力标签。3.1 同样的准确率背后能力分布可能完全不同两个模型在不同表格基准上拿到相近的准确率不代表它们一样强。一个模型可能简单题做得很好但复杂推理题几乎全错另一个模型可能简单题略有失分但复杂推理题表现很稳。聚合到一个分数后你只看到一条接近的水平线无法看出能力结构差异。在科学图表评测里这种差异尤其明显。因为题目难度的跨度很大从“图例里有几个元素”到“结合多个子图推断实验结论”简单题和难题的分数权重如果相同一个模型可以靠简单题拉高总分掩盖它在复杂推理上的短板。所以拿 Diagram-MMU 这类 benchmark 去对比模型时我通常不会只看总分数而是会看分项得分尤其是最高难度层级的得分。那样更能说明模型在真实科学阅读场景里的可用性。3.2 提示词、采样参数、答案归一化都会影响分数同一个模型在 benchmark 上的成绩可能因为几个看起来很小的问题产生明显波动。提示词里多一句“请先指出图例内容再回答问题”可能提升答题稳定性解码时把温度调高开放生成题的随机性会变大分数可能下降输出格式限制为 JSON 之后模型可能把大量精力花在格式合规上反而降低答对率答案归一化脚本里如果没有处理单位换算相同答案可能被判错。这些问题并不是模型“变强了”或“变弱了”而是评测链路里的噪声。当你看到两个模型在同一个 benchmark 上相差 2 个百分点时先别急着下结论先确认两边的提示词、解码参数和评分脚本是否完全一致。这也是我每次复现类似评测时最重视的部分。3.3 用 U 盘跑分来理解 benchmark 的适用边界要理解 benchmark 的意义和局限可以拿一个更常见的例子给 U 盘跑分。U 盘跑分工具会测出顺序读写的速度、随机读写的速度、4K 小块读写的表现。这个分数能说明 U 盘在特定测试环境下的性能但很难完全预测它在某台老旧电脑上、某个特定文件系统里、某类压力负载下的真实体验。跑分高不代表所有场景都有优势跑分低也不代表它在某些实际使用里不够用。模型 benchmark 也是同一个道理。Diagram-MMU 这类基准的价值在于它提供了一个相对可控、可复现的测量环境。但它测的是“在这个测试集、这套题目、这套评分规则下模型的表现”不是“模型在真实论文阅读场景、现实数据分析工作流里的完整表现”。所以跑分应该用来帮助横向对比、版本回归、问题定位而不应该用来给某个模型直接颁发“生产环境可用”的认证。真实用得好不好还要看在具体工作流里的表现包括图片分辨率处理、上下文长度、输出格式稳定性、异常输入容错、延迟和成本。3.4 榜单是快照不是终局另一个常被忽略的点是榜单会过期。模型版本更新迭代非常快今天排第一的模型下个月可能已被超过。而 benchmark 本身也可能被“刷”训练数据污染、测试题被收录进模型训练集、提示词被针对性优化这些都会让分数虚高。一个负责任的团队会持续维护评测数据、定期更新题目并且在公布成绩时说明模型版本和提示词版本。但即便如此任何单个榜单都只是一个时间点上的快照。真正有效的长期策略是把 benchmark 当作一个可追踪的回归基线而不是盲目追求某一场比赛的排名。今天这个模型分数高但如果换个更难、更接近真实场景的测试集优势可能瞬间消失。你要看的是模型在同类任务里是否持续稳定而不是某一次榜单上的位置。4. 想在自家模型上复现 Diagram-MMU 这类评测建议按这个流程走如果你所在的团队也想评估一下自己的多模态模型在科学图表理解上的能力不一定非要完整复现某一个公开 benchmark完全可以按同样的思路搭一个最小评测流程。下面这个流程是我在类似评测任务里验证过、比较稳妥的路径。4.1 前置条件模型接口、数据格式、算力和存储开始之前先确认几件事模型接口你调用的是开源模型还是云端 API你需要知道单张图输入是否支持图片上传是否有大小限制数据格式统一图片路径、问题、参考答案的存储格式建议用 JSON 或者 JSONL方便批量读取算力与成本如果跑全量几百条题目会导致很长的排队或很高的 API 费用那就要设计采样策略输出目录把所有预测结果、日志、错误样本统一落盘不要一边跑一边手工看。如果原始材料没有给出明确的环境配置不要急着搭复杂环境。先拿最小样例确认链路畅通再逐步扩展。4.2 最小样例验证先跑 20 条不要直接全量我看到很多人一上来就执行全量评测结果跑到一半发现图片路径错了、提示词格式有问题、输出编码异常浪费了时间也浪费了成本。更稳妥的做法是先从测试集里抽 20 条涵盖简单和复杂两档题目跑通一次完整流程。重点检查这几项模型能不能正常读到图片和问题返回结果有没有被截断输出内容和图片是否在同一对话上下文里答案归一化脚本能不能正确处理这些样例。只有当这 20 条全部走通、你确认结果符合预期再跑全量。这个过程看起来多了一步实际上能省下大量后续排查时间。4.3 批量评测与结果落盘批量评测时可以按下面的“示例结构”来组织。这里不绑定任何具体模型库只是给一个常见写法参考# 示例结构以你的模型 SDK 为准 def run_single_question(sample): prompt ( 请根据这张科学图表回答问题。\n f问题{sample[question]}\n 请先给出你的结论再简要说明依据。 ) answer model_chat( promptprompt, image_pathsample[image_path], max_tokens256, temperature0.0, ) return answer for sample in small_test_set: prediction run_single_question(sample) record { id: sample[id], question: sample[question], ground_truth: sample[answer], prediction: prediction, } save_result(record)每次跑完建议记录提交时的代码版本、模型版本、提示词版本、采样参数和日期。否则一个月后你看到一份结果文件很难判断它是用哪个版本的模型跑出来的也就失去了回归对比的意义。4.4 错误分析与结果归因的排查链路如果模型在 benchmark 上的分数异常低或者某些题目反复出错不要急着换提示词先按顺序排查。先看数据样本图片和问题是否对齐图片路径是否正确参考答案是否准确再看出题分类别统计错误比如是不是集中在读数题、比较题还是推理题再看输入图片分辨率是否被压缩刻度文字是否因为太小而模糊再看提示词模型是否误解了任务比如被要求“描述图表”而不是“回答问题”再看解码温度过高、输出截断、格式限制是否影响答案最后看评分答案归一化是否忽略了同义表达、小数与百分比、区间表达。这个排查链路的核心原则是从数据到模型、从输入到输出、再从输出到评分逐层定位。大多数看似“模型能力差”的问题最后会发现是分辨率、提示词或评判标准的问题。真实世界里的错误很少只有一个元凶。4.5 把单次评测变成可持续的评测基线一次评测结束如果只是得到一份分数报告这个工作就浪费了一半。更好的做法是把它沉淀成一个可持续运行的评估基线固定一个评测子集训练或微调后自动回归每个版本模型都记录同一组提示词和参数下的分数把常见错误样本收集成“坏例集”用来指导下一步优化当模型在新版本上有提升时检查提升是不是集中在某一类题目上定期抽取少量新题加入评测集防止模型过拟合到测试题。这样Diagram-MMU 这类基准对你团队的价值就不再是“刷一个宣传数字”而是一个能持续发现模型短板、验证优化方向的项目基础设施。5. 读图能力提升不等于科学推理能力提升评测的结果往往会显示模型经过一些优化后分数提高了。这时要冷静一点。分数提升可能来自很多地方但它们对真实任务的价值并不一样。5.1 从“看到”到“看懂”之间还有三层间隔多模态模型理解科学图表的完整链条可以拆成四步看到把图像编码成视觉特征识别识别出文字、图例、坐标轴、刻度线理解把识别出的符号映射到语义含义推理结合多个信息点完成比较、判断或推导。很多优化工作只是提升了第 2 步。比如把图像分辨率调高、把 OCR 能力增强都能让读数类题目明显提分。但第 4 步的推理能力并没有发生质变。模型仍然不会做“如果统计量翻倍图像会怎样变化”这类需要领域知识的推理。如果只拿一个总分数来看你可能误以为模型“更懂科学图表”了但实际它只是“看”得更清楚。这也是我建议在做错误分析时一定要按题目类型拆分的根本原因。分数提高了 10 个点并不等于复杂推理的短板补齐了。5.2 科学图表场景真正需要的输出安全感在真正想使用这类模型的场景里比如辅助阅读论文、整理实验记录、自动提取图表数值用户需要的其实不只是“答案对”还有三个更实际的东西可验证性模型给出一个结论后用户能不能很快定位到图里的证据。如果答案无法对应到某个坐标、区间或曲线那这个答案就很难采信。可追溯性当答案错了用户能不能判断错误来自识别、理解还是推理。如果模型只会给出一个最终结论不展示依据那它出错了也难以修正。可解释性模型能说出“我根据哪条曲线、哪个区间得出了结论”比只给出“答案是 0.45”更有价值。尤其是在论文阅读和实验分析场景里一句解释往往比一个孤立数字更重要。Diagram-MMU 这类评测如果能进一步考察结构化输出和可解释性会比只看最终准确率更有工程参考价值。因为在实际工作流里用户不是只想知道答案而是想知道答案是怎么来的、可不可信、要不要人工复核。5.3 适合与不适合用这轮评测结果做决策的场景最后说边界。科学图表基准的分数适合做这些事情对多个候选模型做初筛对比同一个模型在不同版本之间的能力变化定位模型在哪种题型上存在系统缺陷作为数据标注质量和提示词优化的反馈信号。但它不太适合做这些事情仅凭一个 benchmark 直接决定生产模型选型用一张榜单判断模型在医疗图表、工业检测、金融数据图等具体领域的可靠性认为分数高就不会出现低分辨率、极端刻度、复杂多子图等异常输入下的失败。现实世界里的科学图表远远比测试集多样。论文里有细到看不清的脚注、有跨页的大图、有旋转过的文字、有嵌套的子图。一个模型在测试集上做到 80 分不代表它在真实 PDF 里提取到的低清图片上也能保持同样水准。这一点一定要在项目开始前就明确。6. 一个更现实的建议用 benchmark 校准预期而不是买排名聊到这里我想把结论收敛回一个比较实际的建议Diagram-MMU 这类多模态科学图表基准最重要的价值也许不是“谁排第一”而是帮助我们逼着自己把“模型能理解科学图表”这句话拆得更具体。6.1 我建议的三类使用姿势如果你是一个模型选型者多关注分项得分尤其是最高难度题组的得分。一个在复杂推理题上明显的模型通常比一个靠简单题拉高总分的模型更适合真实任务。选型时还要带着自己的样例去验证而不是完全信任榜单。如果你是一个模型开发者把 benchmark 变成一条回归测试命令。每次微调或改版本都能自动跑一遍输出结果对比。不要让评测变成一次性的论文材料要让它成为持续监督模型能力变化的仪表盘。如果你是一个研究者真正值得投入的不是把分数刷高而是对错误样本做聚类分析。当你能解释“这个模型为什么在区间比较题上系统性出错”时你对模型的理解就比看一张排行榜要深入得多。6.2 后续可以重点观察的三个方向科学图表评测接下来还有几个值得关注的方向。第一更细粒度的能力维度。不只是总准确率还要按读数、比较、推理、跨图综合等维度分别报告才能帮助使用者定位问题。第二更贴近真实工作流的评测方式。比如直接给模型一份论文页面截图让模型在完整版面里定位图表并回答问题。这比单独给一张干净图表更有现实意义因为真实场景里的图表很少独自出现。第三评测本身的鲁棒性。好的基准需要持续更新、防止污染并且发布清晰的数据卡和评测脚本。这样社区才能长期相信它的结果而不是把它当成一个短暂的热点。6.3 回到起点让边界变得可见说实话多模态模型已经走得很远但“读懂科学图表”这件事离真正的可靠还有距离。Diagram-MMU 这类 benchmark 的价值不在于把某个模型捧成“全能冠军”而在于让问题变得可观测、可对比、可迭代。如果下次你再看到一个多模态模型面对图表“振振有词”地输出一个错误答案别急着下结论说它不行先回想一下它是不是也在“看图”而不是“读图”。通过评测把这一步区别出来我们才有可能继续往前走。对日常开发和使用来说这大概就是 benchmark 最值得被认真对待的地方。 从读图到读数据：科学图表理解为何是多模态模型的试金石
去年整理论文复现笔记的时候我遇到过一件很受挫的事。我把一张实验对比曲线图发给一个多模态模型请它判断“第三条曲线在训练到 200 步时大概处于什么量级”。模型回答得很有礼貌语言也非常流畅列出了完整结论。可当我把答案和原图坐标逐一对上时发现它引用的刻度、曲线位置和分组信息基本是错的。那一刻我意识到一个问题今天的多模态模型确实能描述自然图片、识别物体、读懂照片里的场景可一旦面对科学图表它常常处于一种“表面上读懂了实际上只读了个轮廓”的状态。最近我注意到一个叫 Diagram-MMU 的多模态基准。单看标题它不太像一个模型更像一把尺子。这把尺子把评估对象设定成了“科学图表”而不是常见的自然图像或 OCR 文本。这件事值得展开聊因为它背后正好戳中了多模态模型从“视觉感知”走向“科学理解”时最容易被忽略的能力缺口。1. 科学图表为什么一直是多模态模型的高危区1.1 自然图像和科学图表的认知逻辑完全不一样大多数公开评测里的视觉问答本质上是在做一件事根据图片判断“画面里有什么”。比如一张照片里有一只狗、一个人、一片草地模型只要完成了物体识别就能生成合理的回答。因为自然图像的语义很大程度附着在物体本身和场景关系上看到的颜色、纹理和轮廓本身就等于大量答案信息。科学图表不是这样。论文里的柱状图、折线图、热力图、流程图、机制图真正的信息不在“画面好看”而在坐标轴、刻度、图例、单位、标注和符号之间的关系。一张折线图里曲线位置代表数值斜率代表变化趋势两条线距离代表差异大小。想要准确回答“哪一组在后期增长更快”模型必须完成一串非常不自然的工作先在图上定位出两条线再沿着像素坐标把位置映射回数值还要理解横纵轴单位最后做比较和推理。这就是为什么很多模型在自然图上表现不错到了科学图表却开始“胡言乱语”。它不是不聪明而是缺少一种能把像素、符号、数值和语义绑定在一起的处理机制。自然图像可以在低分辨率下凭整体轮廓回答科学图表一旦看不清刻度或图例结论就很容易靠猜。1.2 科学图里的信息不是“画面”而是“数据”如果只把图表当成一般图片那模型看到的就是“一些线段”“几块颜色”“粗细不一的文字”。可在一个科学图表场景里这些视觉元素每一个都有明确数值或语义约束。最常见的一类失败就是模型能说出“柱状图中蓝色柱子最高”但当问题变成“蓝色柱子代表的数值相比前一年增加了多少”它就必须先完成 OCR 识别、数值读取、单位换算和算术运算。模型只要任何一个环节出错最终答案就会错而且经常错得很有迷惑性——它会给出一个看起来合理的数字但那个数字并不在图上也不是由任何柱子推导出来的。这也是 Diagram-MMU 这类基准值得关注的原因。它把科学图表单独拎出来相当于告诉社区别再只拿自然图片测多模态模型了那只是检验视觉感知能力要检验模型能不能“读懂数据”必须把图表理解作为专门任务来设计。1.3 Diagram-MMU 标记的是哪一类能力从命名看Diagram-MMU 的三个关键信息是Diagram图表、Multi-Modal多模态、MMU 对应的理解或基准属性。如果把它放到多模态评测的谱系里它想强调的并不是“又多了一组图片”而是把科学图表理解单独变成一种可测量的任务。我会把它理解成一种能力标尺重点标记四件事模型能否识别图表的基本构成比如坐标轴、图例、标签、单位模型能否把视觉位置和数值对应起来完成“读数”模型能否理解图例和语义的关系知道图里的每条线代表什么模型能否基于图表信息完成比较、排序、区间判断和多步推理。这四层能力越往后越接近“科学阅读”也越能区分不同模型之间的真实差距。一个模型如果只擅长识别物体可能在前两层勉强过关但要在 Diagram-MMU 这类评测里拿到好结果必须同时具备视觉编码、符号理解和数值推理能力。你可能会问这些能力不正是多模态模型应该具备的吗其实恰恰是“应该具备”和“实际具备”之间的落差让科学图表评测变得很有价值。它不是故意出难题而是把真实学术阅读场景里的基本要求搬到了测试集里。2. 一个科学图表 benchmark 通常从哪些维度设置题目我没办法在缺少官方数据集的详细文档时替 Diagram-MMU 确认它具体包含多少张图、多少道题、覆盖多少学科这些信息要以后续公开版本为准。但从这类基准的常见设计思路看它一般会围绕几条能力线来设置题目。2.1 表层任务识别、定位、读数第一类任务是模型相对容易上手、也是最基础的任务面对一张科学图表回答“这是什么类型的图”“坐标轴代表什么”“图例里有哪几组数据”“某个点在图像里的位置在哪里”。这些任务看似简单却是后续一切推理的前提。如果一个模型连坐标轴名称都识别不出来那么它根本不可能正确回答“温度在 60 度以后是否继续上升”。这类任务在评测中通常以选择题为主因为答案是确定且可枚举的适合做快速能力筛查。模型做这一类题目时最常见的错误来源不是推理而是视觉编码分辨率太低、OCR 不完整、图例颜色相近时误判。2.2 深层任务比较、区间判断、趋势推理真正把模型区分开的是第二类任务。举例来说题目可能问“两条曲线在哪个时间点开始出现显著差异”“2005 年到 2010 年之间上升最快的是哪一组”“如果横轴再往后延长一个单位根据现有趋势更可能发生什么”这些题目没有标准答案直接写在图里至少不会以文字形式出现。模型需要自己从视觉信息里提取多条曲线进行比较再结合上下文做推断。这比单纯看图说话难很多因为它要求模型把视觉证据转化为数值证据并且不能只看局部。在这一层模型经常犯的错误是读到了正确的趋势但忽略了图例导致两条线对应关系反转或者比较的区间判断错误把整张图的趋势当成某个区间内的趋势再或者理解了曲线但没注意单位产生量级错误。这些错误在人类读者身上也会发生但对模型而言它们往往不是偶然的“手误”而是系统性的表示缺陷。2.3 从符号识别到科学推理的能力阶梯如果把这类 benchmark 的题目按难度排列可以看见一条比较清晰的能力阶梯第一层基本视觉识别判断图片内容第二层符号解码读取刻度、标签、单位第三层语义映射把图例和视觉元素对应起来第四层多步推理综合多个元素完成比较和判断。我比较看重第四层因为它是科学图表理解真正难的地方。很多模型在第一层已经做得很好第二层也能靠 OCR 系统辅助但到第三层和第四层就开始不稳定。真正想在科学文献阅读、论文解析、实验记录自动化这些场景里落地恰恰需要第三层和第四层的能力。所以当你看到一个模型在某类科学图表基准上准确率很高时不要只看总分还要看它到底输在哪一层。如果你只关心自然图像描述第一层强就够了但如果你想让它帮你分析实验数据图那么第四层的能力才是关键。2.4 输出形式为什么会影响评测结果评测的难点不只是题目内容还有答案输出形式。如果题目是多选题模型只要从 A/B/C/D 里选一个评测脚本可以精确判断。但科学图表题目里很多问题天然是开放式的比如“某条曲线的最大值出现在哪个时间点”模型可能需要输出数字、时间段、坐标也可能是文字描述。这时候答案归一化就成了大问题。“0.5”和“50%”可能是同一个意思“2005 年”和“2005 到 2010 年之间”是否算对取决于评分规则“在 100 步左右”和“100”也可能存在允许误差。同一个模型在开放生成评测下的分数普遍低于选择题评测原因不一定是它能力更弱而是它的回答格式不稳定。这也是 benchmark 设计里最微妙的部分评测分数往往是被评测对象和评测规则共同作用的结果。如果评测规则对“一半”和“50%”的映射处理得不好模型就算理解正确也可能被判错。反过来如果规则过于宽松又会出现模型“答得接近但没真正理解”却被判对的情况。这是 Diagram-MMU 这类基准需要认真解决的核心问题之一。3. benchmark 胜率不是“模型战斗力”榜单背后隐藏着三件事现在很多产品和论文会用“benchmark 胜率”来宣传模型看多了会让人产生一个错觉分数越高模型越强越可以放心使用。但这个判断需要打一个折扣。跑分是有意义的可它更像一个“受控条件下测出的参考值”而不是一个绝对战斗力标签。3.1 同样的准确率背后能力分布可能完全不同两个模型在不同表格基准上拿到相近的准确率不代表它们一样强。一个模型可能简单题做得很好但复杂推理题几乎全错另一个模型可能简单题略有失分但复杂推理题表现很稳。聚合到一个分数后你只看到一条接近的水平线无法看出能力结构差异。在科学图表评测里这种差异尤其明显。因为题目难度的跨度很大从“图例里有几个元素”到“结合多个子图推断实验结论”简单题和难题的分数权重如果相同一个模型可以靠简单题拉高总分掩盖它在复杂推理上的短板。所以拿 Diagram-MMU 这类 benchmark 去对比模型时我通常不会只看总分数而是会看分项得分尤其是最高难度层级的得分。那样更能说明模型在真实科学阅读场景里的可用性。3.2 提示词、采样参数、答案归一化都会影响分数同一个模型在 benchmark 上的成绩可能因为几个看起来很小的问题产生明显波动。提示词里多一句“请先指出图例内容再回答问题”可能提升答题稳定性解码时把温度调高开放生成题的随机性会变大分数可能下降输出格式限制为 JSON 之后模型可能把大量精力花在格式合规上反而降低答对率答案归一化脚本里如果没有处理单位换算相同答案可能被判错。这些问题并不是模型“变强了”或“变弱了”而是评测链路里的噪声。当你看到两个模型在同一个 benchmark 上相差 2 个百分点时先别急着下结论先确认两边的提示词、解码参数和评分脚本是否完全一致。这也是我每次复现类似评测时最重视的部分。3.3 用 U 盘跑分来理解 benchmark 的适用边界要理解 benchmark 的意义和局限可以拿一个更常见的例子给 U 盘跑分。U 盘跑分工具会测出顺序读写的速度、随机读写的速度、4K 小块读写的表现。这个分数能说明 U 盘在特定测试环境下的性能但很难完全预测它在某台老旧电脑上、某个特定文件系统里、某类压力负载下的真实体验。跑分高不代表所有场景都有优势跑分低也不代表它在某些实际使用里不够用。模型 benchmark 也是同一个道理。Diagram-MMU 这类基准的价值在于它提供了一个相对可控、可复现的测量环境。但它测的是“在这个测试集、这套题目、这套评分规则下模型的表现”不是“模型在真实论文阅读场景、现实数据分析工作流里的完整表现”。所以跑分应该用来帮助横向对比、版本回归、问题定位而不应该用来给某个模型直接颁发“生产环境可用”的认证。真实用得好不好还要看在具体工作流里的表现包括图片分辨率处理、上下文长度、输出格式稳定性、异常输入容错、延迟和成本。3.4 榜单是快照不是终局另一个常被忽略的点是榜单会过期。模型版本更新迭代非常快今天排第一的模型下个月可能已被超过。而 benchmark 本身也可能被“刷”训练数据污染、测试题被收录进模型训练集、提示词被针对性优化这些都会让分数虚高。一个负责任的团队会持续维护评测数据、定期更新题目并且在公布成绩时说明模型版本和提示词版本。但即便如此任何单个榜单都只是一个时间点上的快照。真正有效的长期策略是把 benchmark 当作一个可追踪的回归基线而不是盲目追求某一场比赛的排名。今天这个模型分数高但如果换个更难、更接近真实场景的测试集优势可能瞬间消失。你要看的是模型在同类任务里是否持续稳定而不是某一次榜单上的位置。4. 想在自家模型上复现 Diagram-MMU 这类评测建议按这个流程走如果你所在的团队也想评估一下自己的多模态模型在科学图表理解上的能力不一定非要完整复现某一个公开 benchmark完全可以按同样的思路搭一个最小评测流程。下面这个流程是我在类似评测任务里验证过、比较稳妥的路径。4.1 前置条件模型接口、数据格式、算力和存储开始之前先确认几件事模型接口你调用的是开源模型还是云端 API你需要知道单张图输入是否支持图片上传是否有大小限制数据格式统一图片路径、问题、参考答案的存储格式建议用 JSON 或者 JSONL方便批量读取算力与成本如果跑全量几百条题目会导致很长的排队或很高的 API 费用那就要设计采样策略输出目录把所有预测结果、日志、错误样本统一落盘不要一边跑一边手工看。如果原始材料没有给出明确的环境配置不要急着搭复杂环境。先拿最小样例确认链路畅通再逐步扩展。4.2 最小样例验证先跑 20 条不要直接全量我看到很多人一上来就执行全量评测结果跑到一半发现图片路径错了、提示词格式有问题、输出编码异常浪费了时间也浪费了成本。更稳妥的做法是先从测试集里抽 20 条涵盖简单和复杂两档题目跑通一次完整流程。重点检查这几项模型能不能正常读到图片和问题返回结果有没有被截断输出内容和图片是否在同一对话上下文里答案归一化脚本能不能正确处理这些样例。只有当这 20 条全部走通、你确认结果符合预期再跑全量。这个过程看起来多了一步实际上能省下大量后续排查时间。4.3 批量评测与结果落盘批量评测时可以按下面的“示例结构”来组织。这里不绑定任何具体模型库只是给一个常见写法参考# 示例结构以你的模型 SDK 为准 def run_single_question(sample): prompt ( 请根据这张科学图表回答问题。\n f问题{sample[question]}\n 请先给出你的结论再简要说明依据。 ) answer model_chat( promptprompt, image_pathsample[image_path], max_tokens256, temperature0.0, ) return answer for sample in small_test_set: prediction run_single_question(sample) record { id: sample[id], question: sample[question], ground_truth: sample[answer], prediction: prediction, } save_result(record)每次跑完建议记录提交时的代码版本、模型版本、提示词版本、采样参数和日期。否则一个月后你看到一份结果文件很难判断它是用哪个版本的模型跑出来的也就失去了回归对比的意义。4.4 错误分析与结果归因的排查链路如果模型在 benchmark 上的分数异常低或者某些题目反复出错不要急着换提示词先按顺序排查。先看数据样本图片和问题是否对齐图片路径是否正确参考答案是否准确再看出题分类别统计错误比如是不是集中在读数题、比较题还是推理题再看输入图片分辨率是否被压缩刻度文字是否因为太小而模糊再看提示词模型是否误解了任务比如被要求“描述图表”而不是“回答问题”再看解码温度过高、输出截断、格式限制是否影响答案最后看评分答案归一化是否忽略了同义表达、小数与百分比、区间表达。这个排查链路的核心原则是从数据到模型、从输入到输出、再从输出到评分逐层定位。大多数看似“模型能力差”的问题最后会发现是分辨率、提示词或评判标准的问题。真实世界里的错误很少只有一个元凶。4.5 把单次评测变成可持续的评测基线一次评测结束如果只是得到一份分数报告这个工作就浪费了一半。更好的做法是把它沉淀成一个可持续运行的评估基线固定一个评测子集训练或微调后自动回归每个版本模型都记录同一组提示词和参数下的分数把常见错误样本收集成“坏例集”用来指导下一步优化当模型在新版本上有提升时检查提升是不是集中在某一类题目上定期抽取少量新题加入评测集防止模型过拟合到测试题。这样Diagram-MMU 这类基准对你团队的价值就不再是“刷一个宣传数字”而是一个能持续发现模型短板、验证优化方向的项目基础设施。5. 读图能力提升不等于科学推理能力提升评测的结果往往会显示模型经过一些优化后分数提高了。这时要冷静一点。分数提升可能来自很多地方但它们对真实任务的价值并不一样。5.1 从“看到”到“看懂”之间还有三层间隔多模态模型理解科学图表的完整链条可以拆成四步看到把图像编码成视觉特征识别识别出文字、图例、坐标轴、刻度线理解把识别出的符号映射到语义含义推理结合多个信息点完成比较、判断或推导。很多优化工作只是提升了第 2 步。比如把图像分辨率调高、把 OCR 能力增强都能让读数类题目明显提分。但第 4 步的推理能力并没有发生质变。模型仍然不会做“如果统计量翻倍图像会怎样变化”这类需要领域知识的推理。如果只拿一个总分数来看你可能误以为模型“更懂科学图表”了但实际它只是“看”得更清楚。这也是我建议在做错误分析时一定要按题目类型拆分的根本原因。分数提高了 10 个点并不等于复杂推理的短板补齐了。5.2 科学图表场景真正需要的输出安全感在真正想使用这类模型的场景里比如辅助阅读论文、整理实验记录、自动提取图表数值用户需要的其实不只是“答案对”还有三个更实际的东西可验证性模型给出一个结论后用户能不能很快定位到图里的证据。如果答案无法对应到某个坐标、区间或曲线那这个答案就很难采信。可追溯性当答案错了用户能不能判断错误来自识别、理解还是推理。如果模型只会给出一个最终结论不展示依据那它出错了也难以修正。可解释性模型能说出“我根据哪条曲线、哪个区间得出了结论”比只给出“答案是 0.45”更有价值。尤其是在论文阅读和实验分析场景里一句解释往往比一个孤立数字更重要。Diagram-MMU 这类评测如果能进一步考察结构化输出和可解释性会比只看最终准确率更有工程参考价值。因为在实际工作流里用户不是只想知道答案而是想知道答案是怎么来的、可不可信、要不要人工复核。5.3 适合与不适合用这轮评测结果做决策的场景最后说边界。科学图表基准的分数适合做这些事情对多个候选模型做初筛对比同一个模型在不同版本之间的能力变化定位模型在哪种题型上存在系统缺陷作为数据标注质量和提示词优化的反馈信号。但它不太适合做这些事情仅凭一个 benchmark 直接决定生产模型选型用一张榜单判断模型在医疗图表、工业检测、金融数据图等具体领域的可靠性认为分数高就不会出现低分辨率、极端刻度、复杂多子图等异常输入下的失败。现实世界里的科学图表远远比测试集多样。论文里有细到看不清的脚注、有跨页的大图、有旋转过的文字、有嵌套的子图。一个模型在测试集上做到 80 分不代表它在真实 PDF 里提取到的低清图片上也能保持同样水准。这一点一定要在项目开始前就明确。6. 一个更现实的建议用 benchmark 校准预期而不是买排名聊到这里我想把结论收敛回一个比较实际的建议Diagram-MMU 这类多模态科学图表基准最重要的价值也许不是“谁排第一”而是帮助我们逼着自己把“模型能理解科学图表”这句话拆得更具体。6.1 我建议的三类使用姿势如果你是一个模型选型者多关注分项得分尤其是最高难度题组的得分。一个在复杂推理题上明显的模型通常比一个靠简单题拉高总分的模型更适合真实任务。选型时还要带着自己的样例去验证而不是完全信任榜单。如果你是一个模型开发者把 benchmark 变成一条回归测试命令。每次微调或改版本都能自动跑一遍输出结果对比。不要让评测变成一次性的论文材料要让它成为持续监督模型能力变化的仪表盘。如果你是一个研究者真正值得投入的不是把分数刷高而是对错误样本做聚类分析。当你能解释“这个模型为什么在区间比较题上系统性出错”时你对模型的理解就比看一张排行榜要深入得多。6.2 后续可以重点观察的三个方向科学图表评测接下来还有几个值得关注的方向。第一更细粒度的能力维度。不只是总准确率还要按读数、比较、推理、跨图综合等维度分别报告才能帮助使用者定位问题。第二更贴近真实工作流的评测方式。比如直接给模型一份论文页面截图让模型在完整版面里定位图表并回答问题。这比单独给一张干净图表更有现实意义因为真实场景里的图表很少独自出现。第三评测本身的鲁棒性。好的基准需要持续更新、防止污染并且发布清晰的数据卡和评测脚本。这样社区才能长期相信它的结果而不是把它当成一个短暂的热点。6.3 回到起点让边界变得可见说实话多模态模型已经走得很远但“读懂科学图表”这件事离真正的可靠还有距离。Diagram-MMU 这类 benchmark 的价值不在于把某个模型捧成“全能冠军”而在于让问题变得可观测、可对比、可迭代。如果下次你再看到一个多模态模型面对图表“振振有词”地输出一个错误答案别急着下结论说它不行先回想一下它是不是也在“看图”而不是“读图”。通过评测把这一步区别出来我们才有可能继续往前走。对日常开发和使用来说这大概就是 benchmark 最值得被认真对待的地方。