Edit2TikZ：用TikZ科学图表编辑基准评测多模态大模型

写论文或做科研时最磨人的往往不是实验本身而是“图又改版了”。也许你只是想把柱状图里第二个柱子改成红色、把横坐标标签换个说法就得回到绘图脚本、找到对应参数、重新编译输出再贴回 Word/LaTeX 文档里确认一遍。如果遇到审稿人提出“把图中某块逻辑单独拆出来做成子图”前前后后耗费的时间很容易超过一小时。大模型已经有了较强的“从文本生成代码”能力让模型直接画一个柱状图已不算新鲜。但“基于一张已有图做局部编辑”是难度更高的任务模型必须先看懂图里有哪些元素、它们各自在坐标空间里的位置然后把一句人类指令精确映射到代码中的某个对象上同时保证图上其余部分不被破坏。这恰恰是科研成果转化为生产力的场景论文图表大多是“在现成图基础上反复改”而不是每次从零画一张。Edit2TikZ 这个 Benchmark 正是冲着这个空白来的。它把科学图表的“编辑任务”落到 TikZ 代码上让“能不能改好一张图”成为一个可以被量化、可复现、可以横向对比模型能力的问题。本文会先解释为什么 TikZ 适合承担这种评测任务再拆解 Edit2TikZ 在任务设计上的难点最后给出一条可以自己动手搭建的最小验证流程帮助你判断这种“代码化图表编辑”思路能否用在自己的项目里。1. 为什么“能画图”不等于“能改图”现在很多多模态大模型都能根据一句话生成 SVG、HTML、Mermaid 图甚至直接输出 matplotlib 代码。但生成一张新图和修改一张已经存在的图在能力要求上差异很大。生成新图时模型只需要在大致正确的画布上摆放元素。它不需要知道这个图表原本的坐标范围、配色习惯、文字长度和整体排版意图即使模型自由发挥生成的图也常常“看起来还可以”。修改图时则完全不同模型要先从图片中定位目标元素。例如“把第二根柱子的颜色改成红色”这里的“第二根”是一个需要结合视觉上下文才能确定的概念而不是代码里的参数名。模型必须保留其他元素。很多时候模型会把整张图重新生成一遍结果虽然满足了“红色”但旁边区域的文字、线条、坐标轴全变了这在真实工作中不可接受。模型还要理解目标图背后的结构逻辑。普通 PNG 图片对模型来说只是像素集合但 TikZ 代码是一棵结构树。模型如果读不懂结构就没法做“最小范围修改”。正因如此“能画图”的能力评测很容易做得虚高。模型只要能生成一个像样的柱状图在传统文本到图的评测里就能拿高分但把这个标准放到“编辑已有论文图”的场景很多模型会立刻露馅。测量这种差异就是 Edit2TikZ 存在的理由。从命名就能看出它的思路Edit 强调“编辑”TikZ 强调“以代码形式表达图”Benchmark 强调“系统化评估”。它衡量的是模型在真实科研写作场景中最需要的图表操作能力而不是孤立地看模型会不会写一段好看的绘图代码。2. TikZ 是什么为什么它适合做图编辑基准TikZ 是 LaTeX 生态中最常用的矢量绘图语言广泛用于学术论文中的流程图、示意图、数据图和时间线图。它本质上是基于 TeX 宏包实现的一套“程序化绘图 DSL”。一张 TikZ 图从代码到成品通常需要经过 LaTeX 编译生成 PDF 后再转成 PNG 或直接插入文档。TikZ 能成为图编辑 Benchmark 的载体有几层原因非常关键。第一图是精确的、可编译的。TikZ 代码里每个节点的坐标、颜色、线型都是显式属性编译后可以得到稳定的矢量结果。评测时只要把模型输出的代码用 LaTeX 编译成功就能确认代码本身在语法层面有效。相比之下直接拿 PNG 做编辑很难自动化判断结果。第二图是可 Diff 的。原始图的代码和修改后图的代码都是文本改动会体现在具体几行代码上。研究者可以计算代码级差异判断模型是否做了“最小修改”而不是把整张图推倒重来。这一点对评估编辑质量非常重要。第三TikZ 在科研圈有真实使用场景。它和 LaTeX 文档天然兼容字体、公式、引用的处理都很好因此被大量论文作者使用。以 TikZ 作为编辑对象意味着评测任务直接贴近科研写作的真实需求。下面是一个极简的 TikZ 图示例方便没接触过的读者建立直观印象。% 文件路径example_figure.tex \documentclass[tikz,border5pt]{standalone} \begin{document} \begin{tikzpicture} \draw[thick] (0,0) rectangle (8,4); \fill[blue!20] (1,0) rectangle (2.5,2); \fill[orange!40] (3.5,0) rectangle (5,3); \draw[-] (6,1) -- (6,3) node[midway,right] {$y$}; \node[below] at (1.75,0) {A}; \node[below] at (4.25,0) {B}; \end{tikzpicture} \end{document}编译这段代码后你会得到一张包含矩形边框、两根柱子和一条箭头的简单示意图。所谓编辑就是在这种结构化的代码上进行有意图的修改例如把第一个矩形颜色改成红色、把 A/B 标签互换位置、移动箭头方向等。对比其他格式也能看出 TikZ 的优势PDF 适合阅读但不适合作为编辑中间产物PNG 只是像素模型很难对像素做可验证的结构化修改SVG 虽然也是文本但在科研论文里的使用场景不如 TikZ 普遍。因此选择 TikZ 作为 Benchmark 语言具有任务设计的合理性。3. Edit2TikZ 在任务设计上会集中解决哪几个难点虽然目前公开材料里没有完整披露这套 Benchmark 的全部数据细节但从任务命名、TikZ 技术特性以及同类图编辑评测的通用设计逻辑来推断Edit2TikZ 要解决的核心难点可以归纳为四类。3.1 编辑指令与视觉元素的对齐人类描述一张图时通常会说“把图上左边的蓝色箭头换成虚线”而不是说“把第 17 行代码里的 arrow 属性改成 dashed”。Benchmark 的任务需要模型完成视觉理解和代码操作的桥接。这是“视觉定位”层面的难点。比如一张包含多条折线的图指令只说“把表示训练误差的那条线变粗”模型必须先看懂图例知道哪条线是训练误差然后再去 TikZ 代码里找到对应的\draw命令。如果任务数据里充分覆盖这类“指代消解 视觉定位”的组合评测就会很有区分度。3.2 局部修改与全局一致性的平衡高质量编辑追求的是“只动该动的地方”。模型如果直接把整张图重新生成结果虽然可能满足指令但会产生大量与任务无关的变动。在代码层面这表现为 diff 过大、无关颜色变化、节点间距漂移等问题。一个好的图编辑 Benchmark 应该在评估中惩罚这种“过度修改”。它会更偏好那些在功能上完成指令、在结构上保留原图布局和样式的输出。这个约束比单纯让模型创作一张图要严格得多也是图编辑任务的核心挑战之一。3.3 TikZ 代码风格的多样性TikZ 实现同一种视觉效果的写法非常多有人习惯用\node有人喜欢用\draw加circle有人把样式封装成\tikzset有人直接在命令里写参数。模型读到的原始图代码风格各异它必须适应这些差异而不是只对某一种固定模板有效。这种代码风格多样性直接决定了 Benchmark 的“综合”程度。3.4 结果评估的客观性文本生成任务可以借助 ROUGE/BLEU 做粗粒度评估但 TikZ 编辑任务不同完全一样的图可以用完全不同的代码写出来而看起来相似的代码可能编译出差异巨大的图。因此合理的评估不能只看代码字符串相似度还需要引入编译验证、视觉属性比对、甚至人工评估。设计一套能自动化、低成本、与人类判断对齐的评估方案是这类 Benchmark 最难的部分。如果 Edit2TikZ 能在任务设计上同时覆盖上述四个难点那么它就有机会成为继代码生成、数学推理之后又一个能充分检验多模态模型“结构化视觉理解能力”的 testbed。4. 这类基准真正检验的是模型的哪些能力理解 Edit2TikZ 的评测取向可以帮助我们预判什么样的模型会在这种任务上表现更好。4.1 精确的视觉定位模型必须知道指令中提到的元素在图中对应哪个 TikZ 对象。这种能力不能靠“整体生成一张相似图”蒙混过关。当图里有多个柱状图、多条折线、多个图例时模型需要对目标元素有坐标级别或结构路径级别的理解。这考验的是模型把视觉特征与代码对象进行对齐的能力。4.2 指令跟随的稳定性编辑指令通常带有明确约束比如“只修改 A 组的颜色”“保留其他所有柱子的样式不变”。如果模型忽略了“只”和“其他不变”即使它把目标颜色改对了任务也没有完成。这里要求模型具备一定的“差异敏感度”能识别指令中的排除性条件和范围限定词。4.3 代码生成与结构保留模型输出一段 TikZ 代码后既要能被 LaTeX 成功编译也要在语义上属于“对原图的修改版本”。这意味着模型要理解 TikZ 的语法、节点坐标系和样式继承机制而不是简单地插入一行命令。对很多纯自然语言模型来说这种代码层面的“外科手术式”操作比从头生成困难得多。4.4 跨模态推理Edit2TikZ 任务的输入通常包含原始图像、原始 TikZ 代码和一句编辑指令输出是修改后的 TikZ 代码。模型需要在像素、代码、语言三种模态之间来回跳转。比如看到图中某个区域颜色偏浅推断出代码里对应的颜色值是blue!15再把用户说“加深一点”转译成blue!30。这种跨模态推理能力正是当前多模态大模型评测中稀缺的部分。从这个角度看Edit2TikZ 不仅是给科研绘图场景做评估它更像是给“可视化编程”能力设计的一个压力测试。如果模型能稳定完成这类编辑任务说明它已经不只具备“读图说话”能力还具备“读图操作代码”的能力。5. 自己搭一套最小图编辑评测流程无论官方后续是否公开完整代码和数据集理解这套评测思路后我们完全可以在本地搭建一个小规模的图编辑验证流程用来观察手头模型的表现。下面给出一个可运行的 Python 脚本思路它读取一张原始图、一段编辑指令并通过支持视觉输入的大模型接口获取 TikZ 代码。# 文件路径minimal_edit_eval.py import base64 import os from openai import OpenAI client OpenAI( api_keyos.environ.get(OPENAI_API_KEY), base_urlos.environ.get(OPENAI_BASE_URL), # 可选兼容代理网关 ) def encode_image(image_path: str) - str: with open(image_path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) def edit_figure_with_tikz( figure_path: str, instruction: str, original_tikz: str, ) - str: 输入原图指令原始TikZ代码让模型输出编辑后的TikZ代码。 b64_image encode_image(figure_path) response client.chat.completions.create( modelgpt-4o-mini, # 请按实际可用模型调整 temperature0.0, messages[ { role: system, content: ( You are an expert in scientific figure editing. You will receive an image, its original TikZ code, and an edit instruction. Return ONLY the complete, compilable LaTeX/TikZ code after the edit. Do not add explanations. ), }, { role: user, content: [ { type: text, text: ( fOriginal TikZ:\n{original_tikz}\n\n fEdit instruction: {instruction} ), }, { type: image_url, image_url: { url: fdata:image/png;base64,{b64_image} }, }, ], }, ], ) return response.choices[0].message.content if __name__ __main__: result edit_figure_with_tikz( figure_pathfigures/source.png, instruction把A组柱子的填充色改成红色高度不变, original_tikzopen(tikz_codes/source.tex, encodingutf-8).read(), ) print(result)这段脚本的核心价值是“把评测流程自动化”。注意几个细节提示词中强制要求模型只输出完整代码不要附带解释避免后续解析困难。将原始 TikZ 代码和原图同时送入模型是为了让模型既能看到视觉表现也能直接操作代码结构。temperature0.0可以减少随机波动提高多次评测的可比性。如果你使用的是开源模型或其他推理服务只需要替换client的初始化方式和model参数即可整体流程保持一致。6. 如何验证模型生成的 TikZ 是否真正可用拿到模型输出的 TikZ 代码后第一件事不是人工看效果而是先跑编译。只有能成功编译成 PDF 的代码才具备进一步评估的基础。6.1 编译环境准备在 Ubuntu/Debian 系统上可以使用下面的命令安装基础 TeX Live 环境。TikZ 宏包位于texlive-pictures如果代码里用到额外库需要再安装texlive-latex-extra。sudo apt update sudo apt install -y texlive-latex-base texlive-pictures texlive-latex-extra然后在代码所在目录执行编译。建议使用-interactionnonstopmode这样遇到错误时不会一直暂停等待输入便于后续程序化解析日志。cd tikz_codes pdflatex -interactionnonstopmode generated.tex如果编译成功当前目录会出现generated.pdf。如果编译失败日志文件中会写明错误类型。常见的错误包括缺少\end{document}、宏包缺失、特殊字符未转义等。6.2 用程序化方法批量编译并记录结果实际评估中可能有几十上百个样本。逐个手动编译不现实可以用一个简单的 shell 脚本批量处理。#!/bin/bash # 文件路径compile_all.sh for tex in outputs/*.tex; do out_dircompiled/$(basename $tex .tex) mkdir -p $out_dir cp $tex $out_dir/ cd $out_dir || exit pdflatex -interactionnonstopmode $(basename $tex) compile.log 21 cd - /dev/null || exit done echo 编译流程结束请检查 compiled/ 下的 compile.log这个脚本会把所有待编译的.tex文件放到独立目录中执行避免辅助文件互相覆盖。编译生成的compile.log是排查问题的主要依据。6.3 从“代码能编译”到“编辑质量达标”能编译只是第一步。要判断模型是否真的完成了编辑指令可以从三个维度设计验证手段。第一层是代码结构检查。比如指令是“把 A 组柱子的填充色改成红色”可以解析输出的 TikZ 代码确认fillred或fill{rgb,255:red,255;green,0;blue,0}这类属性确实出现在目标节点或路径上。这一层可以用正则或简单字符串匹配实现。第二层是渲染结果检查。将编译得到的 PDF 转为 PNG再通过像素差判断指令相关区域的颜色是否变化以及无关区域是否保持原样。这种方法更接近真实视觉评估但需要先设计好区域坐标映射。第三层是模型或人工语义评估。拿原始图和编辑后的图同时给评估模型看询问“模型是否完成了指令、是否产生了多余的修改”。这一层最接近用户感受但成本较高。在个人实践里建议至少完成第一层和编译验证再做人工抽检。这能过滤掉大量明显不合格的输出让后续细致评估只集中在有希望的候选上。7. 常见误区与排查思路用 TikZ 做图编辑评测时你可能会遇到下面这些典型问题。提前了解它们可以避免在错误方向上浪费时间。问题现象可能原因排查方式解决方案模型输出里混入了解释文字提示词约束不足检查返回内容开头是否有非代码文本在提示词中强调“只返回代码”或对输出做代码块抽取编译时提示File not found缺少对应宏包查看日志中缺失的.sty文件安装texlive-latex-extra必要时使用tlmgr安装编译生成 PDF但视觉上没变化模型输出的 TikZ 和原图结构一样对比原始代码与输出代码的 diff抽取指定区域做像素差检查确认指令是否被忽略模型生成的是整张新图而非局部修改模型没有理解“编辑”约束检查输出代码与原图的语义重合度在提示词中强调“只修改与指令相关的部分保留其他内容”中文字符在 PDF 中显示为空白或乱码LaTeX 编译器不支持中文查看运行日志中字体相关警告改用xelatex编译配合ctexart等文档类同一指令多次运行结果差异大采样参数较高或模型不稳定固定temperature0或seed设置低随机参数必要时跑多次取投票结果模型把坐标系统一平移了对坐标计算不够精确比较输出前后所有坐标变化量检查是否误动了scope或全局坐标变换建立一套清晰的排查顺序很重要。最优先看编译日志它决定了输出是否具备下一步评估资格其次看代码 diff定位模型是否做了“最小修改”最后看渲染效果判断视觉结果是否符合预期。按照这个顺序排查大多数问题都能定位到源头。8. 想让图编辑跑进真实工作流的几条建议如果你希望把“模型帮你改科研图”这件事真正落到日常工作中下面几条工程建议值得参考。第一控制修改范围而不是全图重生成。实际使用中可以先把原始 TikZ 代码按结构拆分成若干片段例如把每个柱子、每条折线对应的\draw命令单独标记。模型只需要修改目标片段其余片段原样保留这样能最大程度降低无关改动风险。第二建立代码规范。原始图的 TikZ 代码越规范模型修改的成功率越高。建议团队在写 TikZ 时统一缩进、统一注释、避免过度使用嵌套 scope。即使没有团队规范个人绘图时也应尽量给关键节点加%注释这样模型更容易建立“视觉对象到代码对象”的映射。第三把编译与验证做进自动化 pipeline。不要每次手动复制代码去编译而应写一个脚本输入为原始图、原始代码和指令输出为编译后的 PDF 和代码 diff 报告。把人工判断集中在少量样例上效率会高很多。第四警惕提示词“假成功”。有时模型生成的代码看起来语法完整、编译通过但根本没有执行指令。要避免这种假阳性评估指标里至少包含一条属性级检查。例如修改颜色的任务必须确认目标填充色真的出现变化修改标签的任务必须确认标签文本真的被替换。只靠“编译成功”来定义任务完成评测结果会严重失真。第五保持对数据集偏见的敏感。图编辑 Benchmark 的难度很大程度上取决于原始图的代码风格分布。如果模型的训练数据里恰好包含大量同款 TikZ 模板它在评测中可能表现很好但不代表通用编辑能力强。因此选择评测集时要注意多样性或者在自建评测时加入多种不同风格的原始图。9. 从 Edit2TikZ 延伸出去的思考Edit2TikZ 只是“用代码来规约图表编辑”的一种具体实现但它提供了一个值得关注的信号下一代多模态模型评测正在从“让模型描述世界”转向“让模型按结构化方式修改世界”。TikZ 能承载这种任务是因为它是代码代码天然适合编译验证、diff 比较和局部修改。顺着这个思路往下走类似的评测还可以扩展到 SVG 图表、HTML 可视化、Mermaid 流程图乃至更复杂的工程设计稿。它们共同的特点是输出对象不是自然语言而是有语法、有结构、可以被机器精确验证的形式语言。如果你正在研究多模态大模型可以重点关注这类 Benchmark 里的失败样本它们往往比成功样本更能暴露模型的薄弱环节例如长指令下的一致性、细粒度视觉定位、约束条件的遵循能力。如果你只是论文写作中需要经常改图的用户也可以尝试把 TikZ 作为中间语言把“看图改图”这类繁琐体力活交给模型处理把一个可编译的 LaTeX 文件作为最终交付物。代码化图表编辑这条路刚刚开始。懂 TikZ 的人越多数据积累越快后续评测也越有生命力。建议有时间的话先从一张简单图、一句明确指令、一次编译验证开始建立自己的最小实验闭环跑通之后再逐步增加图表复杂度与编辑类型。那时再看 Edit2TikZ 的设计你会有比“读懂了”更深一层的体会。