什亭之匣

什亭之匣开箱

Fri, 29 May 2026 00:00:00 GMT

这里是什亭之匣。

我会把技术笔记、阅读摘录、日常想法和一些需要慢慢整理的问题放在这里。它不追求很快写完，更像一个可以反复回来的备忘匣：先把材料收好，再慢慢归档、修订和连接。

博客目前基于 Astro 和 Firefly 搭建，后续会继续调整主题、页面和内容结构，让它更适合长期阅读和检索。

SVGenius 论文笔记：Benchmarking LLMs in SVG Understanding, Editing and Generation

Mon, 08 Sep 2025 00:00:00 GMT

1. 背景与动机#

LLMs 和 MLLMs 在处理 SVG 任务上表现出巨大潜力，但现有的测评基准存在真实世界覆盖有限、复杂度分层不足以及评估范式碎片化的问题。

基于此，本文提出了 SVGenius 基准测试，包含理解、编辑和生成三个大类 2377 个查询，基于来自 24 个应用领域的实际数据，总共细分为 8 类任务，使用 18 项指标对模型进行评估。在 22 个主流模型上进行了测评。

SVGenius 与现有 SVG 基准的覆盖范围对比

表 1 是 SVGenius 与现有 SVG-Benchmark 在 4个维度上进行了相关的对比：

构建方法：分为自动化（Automated）和混合（Hybrid）两种样本生成方式；
领域多样性：单一领域（Single）或多领域（Multi），反映样本覆盖的场景广度；
复杂度指标：路径数（Paths）和控制点数（Points），数值越高代表 SVG 结构越复杂；
任务覆盖：分为三大模块：理解（Understanding）、编辑（Editing）、生成（Generation），每个模块下有相关子问题；

如 表 1 所示，现有的 Benchmark 存在三个关键局限性：

范围有限：依赖于合成或过于简化的样本，无法反映真实世界图形在结构和语义上的多样性；
缺乏复杂度分层：对所有样本采取统一处理方式，未考虑对理解模型能力边界至关重要的结构复杂度；
评估碎片化：关注孤立的能力，而非实际应用所需的综合性 SVG 处理能力。

2. 核心贡献#

分析了现有 SVG Benchmark 的不足，并提出了一个全面的解决方案；
提出了 SVGenius，是第一个用户 SVG 处理的大规模、复杂度分层的真实数据基准；
评测了 22 个主流模型，分析了影响 SVG 处理能力的关键因素。

3. 数据构建#

SVGenius 数据构建与复杂度分层流程

本文从 Iconfont 获取了超过 10 万个 SVG 样本，基于结构有效性、语义有效性和表示简洁性进行了系统处理，为了确保语义清晰，十名志愿者人工审核了栅格化版本。

经过标准化处理（几何规范化、中心对齐、属性标准化）之后，最终得到了 927 个高质量样本。

本文通过三个定量指标定义复杂度：

路径数量（结构复杂度）
控制点数量（几何精细度）
复杂指令数量（高级操作）

这些指标通过规范化处理，并使用经验来确定具体的权重进行加权处理，根据得分，分为了简单、中等和困难三个等级（33%/34%/33%划分），从每个等级中选取 200 个候选样本进行人工抽检，每个等级保留 100 个高质量 SVG 文件，最终得到了一个涵盖 24 个实际领域的 300 个 SVG 样本集合。

4. 任务框架#

SVGenius 引入了一个涵盖三个逐步进阶能力维度的综合测评框架，确保能系统性的评估模型在各类实际应用中的全维度的能力。

4.1 理解任务#

本文引入了两个互补的理解任务，逐步评估模型从感知识别道语义解释的能力：

感知问答（PQA）：评估对 SVG 解释至关重要的基本视觉识别能力。模型必须从 SVG 代码中提取视觉线索，以识别包括颜色、形状、空间关系和数量在内的基本属性。以四选一的形式提问，要求直接解读代码，使用准确率作为评估指标。
语义问答（SQA）：评估超过字面属性的复杂视觉-语言理解能力。通过功能识别、意义总结和使用预测这三个类别实现语义理解，准确率作为衡量语义推理能力的主要指标。

4.2 编辑任务#

在理解的基础上，编辑任务用于评估模型执行精确、结构化代码操作的能力，本文设计了三种全面的编辑场景：

缺陷修复（BF）：针对 SVG 特有的错误进行修正，包括标签错误（格式不良的 XML 结构）、属性错误（格式不正确）以及路径命令错误（数据或序列格式不良），与通用程序修复的 Benchmark不同，这个任务是针对 SVG 的特性设计的，要求模型同时具备语法理解与语义保持能力，通过修复准确率来评估模型性能。
代码优化（CO）：评估模型在视觉正确性之外的代码质量提升。现实世界中的 SVG 生成常常会产生结构低效的代码，这个任务要求模型在遵循 SVGO-inspired principle来优化代码，同时保证渲染输出。使用均方误差（MSE）来保证渲染一致性，以及代码压缩率以量化压缩效果。
风格编辑（SE）：通过全局位置调整、局部元素移动、轮廓设置、颜色修改、渐变填充和模糊效果六种代表性操作来评估交互式修改能力。使用相对均方误差（rMSE）来进行质量检测，并将棋昱现有度量指标整合到一个四指标框架中。（这里因为风格编辑大部分都是局部微调，使用 MSE 灵敏度不足，所以增加了一个 rMSE，总共由 MSE、rMSE、RLD、准确率四个指标组成）

补充：

SVGO-inspired principles 具体包括：

清理冗余信息：删除 SVG 中的元数据（如生成器版本、作者注释）、隐藏元素、空标签、默认属性
路径优化：简化路径数据（合并重叠路径、删除冗余控制点）、降低坐标小数精度（如保留1-2位小数而非默认的6-8位）、用短命令替代长格式（如 SVG 路径命令的简写）
属性与样式优化：合并重复样式、优化颜色表示（如用#000 替代 #000000，用关键字 black 替代等价十六进制等）
结构优化：移除不必要的分组（如标签等）和嵌套层级、简化 ID / 类名、校准 viewBox等核心属性；
压缩代码：去除多余空格、换行和单位（如可以省略的px），进一步减小文件体积。

RLD（相对莱文斯坦距离），代表修改效率指标：

核心作用：从 SVG 代码层面评估模型修改的精准度和高效性，量化模型修改 SVG代码的最小改动成本。弥补了纯视觉指标的缺陷，确保模型不仅视觉效果达标，代码修改也精准化。
评估逻辑：计算模型输出 SVG 代码与ground truth 的RLD距离（插入、删除、替换的字符数），并做归一化处理；数值越小越好，代表模型仅对指令指定部分进行修改，无多余操作。

4.3 生成任务#

生成任务代表最复杂的能力建模维度，要求模型能够根据文本指令或多模态输入从零开始生成完整 SVG。本文提出了3个逐步增加难度的生成任务：

文本到 SVG（TTS）：评估自然语言到向量图形转换的基本能力。引入了 rCLIP 和 PSS 两个指标来评估语义对齐和代码级差异。和现有指标相结合，形成了一个三维框架：
- 感知质量（HPS，美学），衡量主观视觉吸引力
- 视觉可复现性（PSS），评估代码结构一致性
- 语义一致性（CLIP，rCLIP），评估语义保留程度
图像到 SVG（ITS）：通过要求从图像和文本中生成来解决自然语言到歧义问题，评估采用了两种方法：
- 通过 LPIPS、SSIM 和 DINO 进行感知相似度评估以衡量对齐程度
- 通过 PSS 和 MSE 评估视觉可复现性以检验一致性。
风格迁移（ST）：要求在保持内容的同时实现风格自适应。本文引入一项任务，要求生成保留结构内容的同时符合四种预定义风格类别（卡通、线稿、像素艺术、3D）的 SVG。并开发了一个两层自动化评估框架，利用大模型从全局和局部视角量化迁移质量。

第一层框架：采用 AlpacaEval 框架，以 DeepSeek-R1 为基准参考模型，选取了6个模型作为评估对象：

评估维度：从语义内容保真性、目标风格贴合度、整体视觉质量三个核心维度，将各个模型的输出与基准模型的输出做两两对比；
结果量化：以胜率作为指标，模型输出优于基准模型的样本数占总样本数的比例，胜率越高代表整体风格迁移能力越强。

第二层框架：局部多维度自动评分，本文设计了5个量化指标，并使用 GPT-4o-mini 作为自动化评估模型，对每个输出在每个指标上独立进行评分（范围1 - 5分，0分代表无效/错误的 SVG 输出），评分前模型会参考「原始 SVG、转换后的 SVG、风格描述、指标评分细则」生成详细反馈，再给出分数：

CP（Content Presevation）内容保真性：转换后是否保留原始 SVG 的所有主 / 次要元素、核心结构和语义
DF（Detail Fidelity）细节保真度：风格转换过程中，对原始 SVG 细节的保留程度（非风格相关细节）
SC（Style Consistency）风格一致性：转换后 SVG 与目标风格的贴合程度，是否符合该风格的视觉美学 / 规则
CH（Color Harmony）色彩和谐性：风格转换后的色彩搭配是否协调，是否符合目标风格的色彩特征
CB（Composition Balance）构图平衡性：风格转换后，SVG 的整体构图、元素布局是否保持平衡，无视觉失衡

5. 实验#

本文在 SVGenius 上评估了 22个模型，涵盖理解、编辑和生成任务。

SVGenius 理解任务评测结果

如 表 2 所示，这个是 SVG 理解任务。

闭源模型（Claude 3.7-Sonnet、GPT-4o、Gemini-2.0-Flash）在两个任务中全面领先。
开源模型中推理增强型模型（DeepSeek-R1、DS-R1-Qwen-32B）和Qwen系列（Qwen3-8B/32B）表现较好，但在 Hard 难度下与闭源模型存在明显差距。
SQA 的整体准确率会低于 PQA，这说明语义理解比视觉感知更具有有挑战性。

SVGenius 编辑任务评测结果

如 表 3 所示，这个是 SVG 编辑任务（包含上文提到的三个子任务）。

在 Hard 难度下，多数模型的 BF 任务准确率骤降（如Qwen3-1.7B 在 Hard 难度下准确率直接为0了），这表明，复杂 SVG 编辑任务非常具有挑战性。
闭源模型（Claude-3.7-Sonnet、GPT-4o）在 SE 任务的 RLD 上表现最有，证明其能精准修改代码，减少冗余改动。
CO 任务中，Easy 难度下 CCR 较高，但难度提升后，CCR 和 MSE 都显著下降，这表明复杂的 SVG 任务，目前模型还难以兼顾体积与效果。
开源模型中， Deepseek-R1、DS-R1-Qwen-32B 在 BF 和 SE 上稳定性较强，尤其是 Medium 难度下，基本接近闭源模型。

SVGenius 文本生成与风格迁移任务评测结果

如 表 4 所示，这个是 SVG 生成任务（包含上文提到的两个子任务 TTS 和 ST）。

在 TTS 任务上，闭源模型在 Easy 难度下 HPS 和 rCLIP 领先，生成的 SVG 更符合人类便好且文本对齐更精准， Hard 难度下 PSS 普遍下降，说明复杂文本生成的结构正确性很难保障。专用模型（Iconshop 和 LLM4SVG）在Easy难度下表现不错，但在 Medium/Hard 难度下被通用大模型超越，证明了通用模型在复杂场景具有更强泛化性能。
在 ST 任务上，Cluade-3.7-Sonnet 在 Meduim/Hard 难度下的 3D 风格表现突出，而开源模型在 Line art 风格下有一定优势，但整体仍然落后闭源模型。所有模型的 ST 上表现均显著低于 TTS 任务，说明高阶的风格重构任务仍然是模型的核心短板之一。

SVGenius 图像到 SVG 生成任务评测结果

如表 5 所示，这个也是 SVG 生成任务（ITS任务）。

在 Medium/Hard 难度下，所有模型的 LPIPS 和 MSE 显著上升，说明复杂图像转矢量的难度极大。
闭源模型（Claude-3.7-Sonnet、GPT-4o）在所有难度下的 SSIM、DINO、PSS 均领先，生成的 SVG 在结构和视觉上更接近原始图像。
专用模型 StarVector 在 Easy 难度下 MSE 较低，但在 Hard 难度下被闭源模型超越，进一步证明了通用多模态模型在复杂图像转 SVG 任务上的优势。

6. 结论#

根据上述的实验我们可以发现，所有任务在 Easy → Medium → Hard 难度下性能显著下降，证明了 SVGenius 复杂度分层能精准却分模型能力边界。
闭源模型在理解、编辑和生成任务上，都遥遥领先，尤其在高难度任务和精细结构控制场景下。
推理增强型开源模型在理解和编辑任务上表现突出，部分指标接近闭源模型，但在生成任务上仍然有差距。
根据实验结果可以得出任务的难度比较关系：
- 理解维度：语义理解 > 视觉感知
- 编辑维度：CO ≈\approx≈ SE > BF
- 生成维度：ST ≈\approx≈ ITS > TTS
通用模型在复杂场景下，相比专用模型，泛化能力更强，也说明了其在 SVG 处理上的潜力。

7. 不足之处#

虽然论文有 2377 条任务进行评估，但总共只有 300 条 SVG 样本，是否能支持 Benchmark 存疑。
Bug Fixing 的准确率采用和GT的严格等价判断逻辑，这基本等价于去除空白后的字符串完全匹配。这样会存在一定问题，因为 SVG/XML 语义等价非常常见，这样严格等价偏向测试模型猜测原文的能力而不是修复语义。
Image-to-SVG 任务的 Prompt 被作者限制只能使用元素且只能使用 fill 和 d 两个属性，还要求必须使用完全固定的 opening tag/viewBox，这样可能会收缩相关的任务空间，变成几何只靠 d（path数据）来表达，颜色只靠 fill 来表达，这样任务变成了能不能把图像轮廓拆成若干 path，并给出合理的 fill 和 d。
Style Editing 指标设计仍然存在一些问题，如：
- RLD 在 raw XML 同样会受空白、属性顺序、等价写法的影响
Style Transfer 任务的评测高度依赖 LLM-as-a-judge，可能会引入评估器偏置和reference model 选择偏置的问题，也缺乏与人类一致性的定量验证（比如做一些人工抽检）。

UniSVG 论文笔记：A Unified Dataset for Vector Graphic Understanding and Generation with Multimodal Large Language Models

Sun, 07 Sep 2025 00:00:00 GMT

1. 背景与动机#

SVG 是基于 XML 代码的矢量图格式，通过代码精准控制笛卡尔坐标平面图形的形状、大小、路径、颜色和文本等属性，支持无限缩放而不损失图像质量。因其高质量渲染、文件体积小以及动态可编辑性而受到青睐。

近年来，MLLMs 的迅速发展，展现出了复杂的跨模态处理任务的能力，在 SVG 理解与生成任务上有这巨大的潜力，目前研究人员主要设计了三种相关任务：

标量图到SVG代码转换（Image2SVG）
描述文本到SVG代码转换（Text2SVG）
SVG相关理解任务（SVG Understanding）

但这些任务仅仅是用来进行评估，而缺乏相关的训练数据或者聚焦于一两个特定的SVG任务。

基于上述原因，本文构建了一个以 SVG 为核心的综合性数据集（UniSVG），一个包含 52800 个用于训练 MLLMs的多模态数据项。

经过严格的清洗和去重，获得大量适合用于 MLLM 训练的高质量 SVG 样本，基于这些 SVG 代码生成了图片、撰写了详细的描述，以及利用 GPT-4V 构建了相关的 SVG 问答对。

2. 核心贡献#

本文提出了首个大规模、多任务且开源的以SVG为核心的数据集（UniSVG），用于统一生成与理解，支持多模态大模型的训练与评估。
提出了 UniSVG 基准测试，包含多种评估指标，旨在评估模型的 SVG 生成与理解能力。

3. 方法论#

3.1 数据采集#

SVG 在互联网上存在着大量资源，本文从 Kaggle 的 SVG Icons 数据集以及 HuggingFace 的 svgen-500k-instruct 数据集中收集了 52.6 万条 SVG 代码。

www.kaggle.com

huggingface.co

3.2 数据预处理#

主要分为以下几个步骤：

Simple SVG 代码清理：将其转换成 PNG 格式图片，任何无法转换成功的都从数据集中进行移除
Deep SVG 代码清理：删除头部的 DOCTYPE 和 XML 声明、注释，去除冗余的 <g> 标签以及多余的空格，优化了代码。
SVG 代码去重：使用感知哈希（pHash）对由 SVG 生成的 PNG 格式图片进行编码，将其投影到一个表示空间中，然后进行 SVG 去除，直到每对 SVG 之间的距离低于指定阈值（计算两两之间的汉明距离）。
去除含有过多贝塞尔曲线的SVG文件：本文检查数据集的时候发现一些数据包含了过多的贝塞尔曲线，超出了模型的建模能力，为了保证模型训练稳定性，去除掉超过100个贝塞尔曲线的SVG。

具体流程如下：

UniSVG 数据预处理流程

3.3 数据集构建#

UniSVG 数据集整体构建流程

如 图 2 所示，UniSVG 包含了 2 个主要组件：SVG生成（SVGEN）和 SVG理解（SVGUN），两者均由（图像，文本，代码）三种模态组成。

在构建过程中，使用了渲染技术和 GPT-4V，通过 Prompt 生成 SVG 的详细描述（命名为 SVGDES），包含：**整体描述、颜色、类别以及潜在的现实生活中的用途。**基于这些描述，使用预定义规则提取的详细信息来构建数据集。（这里我觉得这样做，一是降低模型输出难度，模型输出结构化数据的能力有限，二也是方便校验，比如模糊字段或者缺失很容易就能发现，三是方便随时调整数据集格式）

UniSVG 数据集的任务组成与样例

此外，在确定各自子数据集的比例时，作者考虑了 SVG 相关任务的不同难度级别，提高了 SVGEN 数据的比例，SVGEN ：SVGUN 的比例调整为了约 6 ：1，各个任务具体数量如表2 所示，作者附录中做了相关的消融实验。

3.3.1 图像到SVG生成（ISVGEN）#

基于 36 万条清洗后到 SVG 数据构建，目的是教会模型从标量图形生成格式化的 SVG 向量图形。将这些 SVG 数据渲染后得到了 36 万组**（位图-SVG）图像对**。

为了避免固定的 Prompt 导致模型过拟合该生成指令，作者构建了 20 个核心意图相同但表述不同的 Prompt，给每一张位图随机分配其中的一个问题。

最后形成了 36 万条（位图-问题-SVG）三元组。

3.3.2 文本到SVG生成（TSVGEN）#

作者从清洗后的数据集中随机挑选了 91k 个文本-SVG对（应该是GPT-4V成本太高了），专门设计用于帮助模型从描述性文本生成格式化的SVG向量图形，每个数据对由 SVGDES（SVG图像描述文本）+ 对应的 SVG 代码组成。

同样，为了避免过拟合问题，也构建了 20 个生成指令，给每条数据随机分配一个生成指令。

3.3.3 SVG理解（SVGUN）#

为了测试 MLLMs 对 SVG 的理解能力，作者将 SVGUN 分成了三个难度等级：简单、中等和困难。

简单级别：包含 4 项任务，从 SVG 代码中提取原始 size、从SVG 图像中提取颜色、统计 SVG 代码中使用的不同形状的数量，以及统计 SVG 代码中 <path> 里用了多少次变换的数量。
中等级别：包含 3 项任务，提取 SVG 图像的类别（图标、几何、装饰等等）、描述 SVG 代码中的矩形，以及描述 SVG 代码中的圆形。
困难级别：包含 2 项主要任务，对整个 SVG 图像进行整体描述，以及推测该 SVG 图像在生活中可能的用途。

SVGUN 包含两个按参考模态划分的子任务：基于图像的 SVG 理解（ISVGUN）和机遇代码的 SVG 理解（CSVGUN），两者的区别在于输入格式，CSVGUN 使用 SVG 代码和问题进行输入，而 ISVGUN 使用图像和问题作为输入。

此外，因为 SVGDES 是由 GPT-4V 生成的，所以为了公平，这些数据条目不能用于测试，被提出了测试基准中。

补充：

<path> 标签：是 SVG 中用来绘制复杂自定义图形的核心标签（比如心形、不规则图标、自定义曲线等）。
transform 属性：是给 <path> 中的图形增加几何变换指令（比如图形平移、旋转、缩放等），本质是不修改 <path> 原始坐标，直接对整个图形做位置/形态调整。
变换次数：指 SVG 代码中，<path>标签的 transform 属性里包含的独立编号操作的数量（多个变换用空格分隔）。

此外，读到这里可能会有一个疑问：ISVGUN 还有必要测吗？普通 MLLMs 不是应该已经做的很好了吗？实际上不一定，「识别图片里红色圆形、蓝色矩形」这类通用视觉任务确实能做的很好，但 ISVGUN 的核心不是看图认形状，而是从 SVG 渲染图中推断代码层面的细节。

普通的 MLLMs 模型只能做通用图形理解，无法从 SVG 渲染图中推断代码层面的细节，这也是 UniSVG 基准设计这个字任务的目的。

4.实验#

作者从 UniSVG 数据集中挑选了 2850 个数据项构建了 UniSVG 测试基准，采用了多样且多维度的评估指标，对各个模型在各类任务中进行了严格评估。

4.1 SVGEN 的评估指标#

比较生成的 SVG 代码渲染出的图像与对应真实 SVG 代码渲染出的图像之间的相似度，一方面采用**结构相似性系数（SSIM）和感知图像块相似度（LPIPS）**作为评估指标，这两者侧重于局部区域以捕捉低级视觉特征，另外还采用了 CLIP 相似度作为评估指标，它利用预训练的视觉-语言模型来捕捉语义相似性，提供对图像内容的语义感知和高级理解。

4.2 SVGUN的评估指标#

对于较简单的任务，可以使用准确率来比较模型输出与真实答案，对于更具有挑战性的任务，以及模型自由生成的输出，本文使用两种流行的基于模型的指标： BERTScore 和 Setence-BERT，来评估模型生成的 response 与真实句子之间的相似度。

4.3 分数的加权#

为了在排行榜上对模型进行排序，需要计算所有评估指标的加权来得到最终得分。在 UniSVG-bench 评分系统中，作者为 ISVGEN 和 TSVGEN 各分配了 45%（因为相比于 SVGUN这两者更难也更重要），SVGUN 占总得分的 10%。

从更细节的角度看，在 SVGEN 中，CLIP 相似度具有更重要的意义，所以为其分配了更高的权重，CLIP 相似度在 ISVGEN 和 TSVGEN 中各占 60%，而 SSIM 和 LPIPS 各占 20% 。

SVGUN 内部的指标权重也进行了相应调整，其中简单准确率、困难准确率、BERT 和 SBERT 的比例分别为 1:2:3.5:3.5。

5. 消融实验#

5.1 微调范式的消融#

作者在 LLaVA 和 LLaVA-LLaMA 模型上进行了各种微调实验，以确定最佳的微调范式，如 表 5 所示：

不同微调范式在 UniSVG 上的消融结果

因为 LLaVA 与大多数多模态模型一样，采用两阶段训练范式：预训练（第一阶段：对齐视觉与语言）和 SFT（第二阶段：训练投影器和 MLLM 以遵循指令）。

上表中是三种不同的策略，根据仓库的开源代码可以得到：

策略 1 是直接未做 Stage1 和 Stage2 的模型原始 CheckPoint 直接在 UniSVG 上进行微调。
策略 2 是拿做过 Stage1 的模型 CheckPoint 在 UniSVG 上进行微调。
策略 3 是拿同时做过 Stage1 和 Stage2 的模型 CheckPoint 在 UniSVG 上进行微调，目的是测试 Stage2 对 SVG 任务是不是多余甚至有害的。

上表中表明，在 UniSVG 数据集上微调第一阶段的模型，能够在所有与 SVG 相关的指标上取得更优表现，而第二轮微调可能对 SVG 后续训练产生不利影响。（我猜想一个可能的原因是，这里SFT阶段的数据可能偏日常对话，而对代码类问题没有帮助，可能反而有害）

5.2 SVG 的 MLLM 训练效率消融#

SVG 代码压缩对训练效率与生成质量的影响

SVG 格式中，包含了大量冗余的逗号和小数点，显著降低了训练效率，作者在 ISVGEN 任务上进行了消融实验，如 表 6 所示，实验表明，去除这些冗余符号可以使训练 token 降低 35%，训练时间约缩短了40%，但这个优化轻微降低了生成质量。（我猜想一个可能原因是，基础语言模型预训练见过的数据很多都是冗余的，这里去除之后破坏了部分的预训练先验知识）

作者认为这个消融实验非常有价值，它为未来如何平衡计算成本与模型性能提供了一个参考方向。

6. 结论#

多种模型在 UniSVG 基准上的性能对比

为了验证 UniSVG 数据集再提升 MLLMs 处理相关 SVG 任务的有效性，作者选择了多种开源模型在 UniSVG 数据集上进行了3 轮微调，如 表 4 所示，在微调后，多个 MLLMs 的性能已经达到甚至超过了当前最优的闭源模型。

可以看到：

Qwen2.5 VL 微调后取得了整体的最佳性能，Claude 3.7 在所有闭源 SOTA 模型中表现最佳。
Claude 3.7 的 CLIP 相似度在所有模型中最高，但与微调后的模型对比，生成的 SVG 图像其像素级的评估指标相当差，这说明 Claude 3.7 生成的 SVG 图像在语义上与目标图像高度相似，但在视觉细节和结构准确性方面存在不足。
使用 LLaMA 3.1 作为其 LLM 的 LLaVA-LLaMA 模型和使用 Vicuna 1.5 作为其 LLM 的 LLaVA 1.5 的模型，表现出显著更优的性能，这说明，在相同的多模态大模型框架内，集成一个更先进的大模型，尤其是擅长代码生成的大模型，能有效提升以 SVG 为核心的任务表现。

7. 不足之处#

同一个矢量图，可能有不同的实现方式（SVG代码）文中没有考虑相关情况。
使用的感知哈希算法去重存在：
- 细粒度的区分能力严重不足，无法区分「完全重复」和「同源衍生但内容有本质差异」的情况，会被误判为相同图片。
- 感知哈希丢弃了色彩信息，也会导致图像相同但色彩不同的被误判为重复图片。
- 降维空间的大小、以及汉明距离阈值需要调整，文中并没有提到相关信息。
文中的 benchmark 没有排除掉数据泄露的风险。
数据过滤过于暴力，直接去除了超过 100 条贝塞尔曲线的数据文件，无法代表真实世界中复杂、高质量的矢量图形。
所有标注完全依赖 GPT-4V，存在幻觉的风险。
缺乏代码质量本身的评估，两个视觉上极其相似的 PNG，实现过的 SVG 代码可能完全不一样（一个优化的非常好，一个存在大量冗余），缺乏对代码结构相似度的评估。
对比方式也不是很公平，Baseline 中没有去对比专门处理 SVG 的领域 SOTA 模型，且闭源模型是 zero-shot 的，得出的结论也不是很可靠。

SWE-bench 论文笔记：Can Language Models Resolve Real-World GitHub Issues?

Mon, 01 Sep 2025 00:00:00 GMT

1. 背景与动机#

当前大语言模型的 benchmark 已经饱和，需要能覆盖更加前沿与大语言模型边界的benchmark。

一个好的 benchmark 构建起来非常困难，一是所选的任务需要有挑战性，二是模型输出的结果要方便验证。

现实的软件工程任务就非常满足这个要求，其本身就是一个很有挑战性的任务，需要理解庞大的代码库，定位问题并进行修复。修复的结果使用单元测试就能很好的验证。

而 HumanEval 等 benchmark 中，大部分只涉及几行代码就能解决的问题，无法满足当前要求，基于此，SWE-Bench 就被提出。

2. 核心贡献#

提出了 SWE-Bench 用来评估真实软件工程任务上的解决能力，每个任务都需要LLM生成一个描述对现有仓库的修改的patch，修改后的代码会使用当前仓库的测试框架进行评估。

发布了一个SWE-bench-train数据集，包含 37 个仓库的 19000 个非测试任务实例。

3. 方法论#

3.1 挑选 SWE-Bench 实例的方法#

SWE-bench 数据筛选流程

三步走，首先挑选 12 个 Python 代码比例在 90% 以上的流行仓库；

接下来从这些仓库中，挑选出满足：

PR必须明确 resolve 至少 1 个 issue
已经被 merge 的 PR
PR 必须修改/新增仓库件的测试文件

最后从候选的 PR 中，进行以下操作：

把 PR 涉及的所有相关测试用例（包括新增和修改的）提取出来的到 test_patch，并将其应用到base_commit 上；
在没有应用修复（新增）代码的情况下，运行这些测试：
- 预期：应该失败，证明 Bug 确实存在。
在应用修复（新增）代码的情况下，再次运行这些测试：
- 预期：测试应该**通过，**证明代码修复确实有效。

筛选标准：至少有1个测试用例在运行前失败，运行后通过，就保留，即至少需要一个

Fail_to_Pass，但不要求所有失败测试都被修复成功。

根据上述的操作，从 90000 多个 PR 中，最终过滤出了 2924 个符合要求的 PR 组成了SWE-Bench。

这里，选择至少通过 1 个测试用例的任务，是为了避免一些 trivial 的任务（没有实质性修改BUG、只是调整代码格式或者文档等），只要符合，就可以入选 SWE-Bench 中，这个是 SWE-Bench 的筛选标准，而不是 PR 的合并标准，一个合格 PR 被 merge 应该能通过所有的测试用例。

总结来说：

SWE-bench 实例构建流程总结

3.2 任务制定方法#

SWE-bench 任务输入与补丁评测流程

模型会获得相应的 issue 文本以及完整的代码库，任务是模型基于当前代码库进行修改以修复当前 issue。在实际操作中，以 patch 文件的方式来体现模型为了解决 issue 修改了代码库中的哪些行的代码。

使用 unix 的 patch 命令将解决方案应用到原始代码库中，然后执行与之相关的测试用例，如果补丁应用成功并且所有测试用例都通过，则认为解决了问题。

3.3 执行验证#

前面筛选只保证了 PR merged、看起来关联 issue，也修改了测试文件，但这仍然可能出现很多坏样本，如：

这个版本根本装不上/依赖对不上（跑不了）；
PR 加的测试并不能稳定复现问题（测不出来）；
测试失败是因为缺包/缺符号/名字不对，而不是因为bug（不公平、也不能代表修复能力）

所以，这里构建的时候做了执行验证：对每个候选任务，放到一个确定的执行上下文中，真实安装+打补丁+跑测试，任意一步失败就丢弃。

核心的执行流程是：

checkout 到 base commit （PR 合入前的代码 C)
在对应的 conda 环境中安装
先打上 test patch T（PR 新增/修改的测试）
跑测试，得到 logpre （修复前的测试日志）
再打上 solution patch δ\deltaδ（PR 的非测试代码改动，也就是 gold 修复）
再跑一次测试，得到 logpost（修复后的测试日志）

在 logpre 里，至少要有一个测试是 fail，在 logpost 里，这个测试变成 pass，如果找不到任何这样的测试，就认为这个任务测不出 PR 解决了什么，或者是 PR 改的是重构/风格/不影响测试的内容，所以剔除。

PR diff 的 .patch 由很多文件 block 组成，每个 block 对应一个文件的改动，在提取的过程中，用路径关键词（如test/testing/test等），把测试文件路径的 blocks 捞出来合并成 test patch（T），其余 blocks 合并成 solution δ\deltaδ。

这里跑测试的范围并不是全量测试用例，而是从 test patch 中的 file blocks 里提取出的相关路径。

此外，还会排除一种不公平情况：测试调用了 PR 才新建的函数/类（因为命名可能完全没在 issue 里出现，这样等于让模型猜名字）。

论文中提到他们会在 logpre 里检查是否出现了ImportError/AttributeError ，并把这类任务实例移除掉。

3.4 任务实例的四大组件#

最终，我们按照上述流程，得到了任务实例的4大组件：

C(Codebase)：代码库快照（仓库 + base commit）
P(Problem statement)：问题描述（相关 issue 文本与评论，这里需要截断到 PR 首次提交前，避免泄露解法）
T(test Patch)：测试（从 PR 的测试改动中提取，作为验证目标）
δ\deltaδ：gold patch（PR 的飞测试改动部分，作为参考解）

并且测试补丁和 gold patch 都用 .patch格式保存。

3.5 优势#

所有的任务实例都来自真实软件工程任务，传统的 benchmark 只涉及很短的输入和输出，而 SWE-Bench的任务实例每一个都是一个庞大的代码仓库+与之相关的一个issue。
能持续更新，在Python仓库上的更新的操作几乎不需要人工参与，可以挑选更新日期在模型发布之后的实例来保证模型从未见过。
issue的描述文本长而详细，平均达到了195个词，并且代码仓库通常包含成千上万个文件，解决这些实例需要在海量代码中找出那些需要被修改的少数几行代码。
对于每个实例，至少有一个 fail_to_pass 的 test case，其中 40%的实例至少包含 2 个这类case，此外，还会运行 51 个（中位数）测试用例，以确保系统的原有功能不出问题。
跨上下文的代码编辑任务，任务实例不仅要求模型生成简短的代码片段，还要求它们在大型代码库的多个位置进行修改，SWE-Bench参考解决方案平均修改了1.7个文件、3.0个函数以及32.8行代码。
任务实例的解决方法多样，不局限于一种解决方法。

3.6 讨论#

在执行验证阶段，本文将同一批测试用例跑了2次：

logpre：base commit + test patch T（只上测试，不上修复）
logpost：base commit + T + δ\deltaδ（再上 gold patch 修复）

对每个被运行到了测试 tit_iti，根据修复前/后的pass/fail，就会形成一个2×22 \times 22×2 分类：

logpre	logpost	类别	类别含义
fail	pass	FAIL_TO_PASS	有效修复：表明测试用例成功捕获Bug，并且被补丁完美修复。
pass	pass	PASS_TO_PASS	回归保护：补丁未对现有正确逻辑造成破坏，保证了系统的向后兼容性。
fail	fail	FAIL_TO_FAIL	无关错误/噪声：补丁未能改变失败状态。通常意味着该报错与当前Bug无关，或由环境及解析早上引起。
pass	fail	PASS_TO_FAIL	负面影响/不稳定：打补丁后反而使原有功能报错。通常代表测试用例不稳定（噪声）、验证集不一致，或补丁引入了新 Bug

环境噪声：测试失败并不是因为代码逻辑没修复，而是因为运行环境导致的失败/不稳定，如版本不兼容、依赖问题等。

解析噪声：测试实际上跑了，也有结果，但把日志转成哪些测试pass/fail的过程中可能出错或不完备，这就会把某个测试的状态判错，或者漏掉。通常以下原因可能导致：

不同仓库/框架日志格式差异很大
测试名可能带参数化/动态生成、输出里可能截断/折行
有些结果不是简单的pass/fail，如（error、skipped、xfail/xpass等），本文中明确说了，无论状态是什么，最终都必须被映射成 pass 或 fail。

验证集合出现不一致：可以理解为，再定义的测试集合中，出现了连参考修复 δ\deltaδ 都无法让它保持良性的测试行为。

过滤掉 F2F 和 P2F，本质上是为了提高评测的信噪比。作者宁可接受漏掉模型引发的一些深水区 Bug（假阳性），也不愿意接受因为环境问题错杀模型写的好代码（假阴性）。

所以，论文明确，评测时不把 FAIL_TO_FAIL 和 PASS_TO_FAIL 纳入计分，最终只要求模型让 FAIL_TO_PASS（该修好的必须修好）与 PASS_TO_PASS(别引入回归）全部通过。

4. 实验方法#

每个任务的 issue 描述通常都很短（平均 195 个words），但整个代码库非常庞大（平均438K lines），整个输入会导致上下文过于庞大，超出了大部分模型的上下文窗口，为了解决这个问题，文章中提出使用基于上下文检索的方案，且因为自然语言查询代码与文档这种场景，使用向量检索的方式不合适，所以最终采用了 BM25 检索方法来为每个任务提供上下文。

同时，使用了 Oracle 检索来作为理论对照（因为实际大部分情况我们无法预先知道），即直接提取 Github上解决该 issue 的 patch 中所有被编辑的文件。

最终，我们将任务指令、问题文本、检索到的文件和文档、示例补丁文件以及补丁生成提示词（如要求模型按 diff 格式生成、仅修改指定代码段等）一起构建成模型最终的输入。

输入的结构大致长这样：

1
1. 开头：指令 + <issue> ... </issue> 包住 issue 文本
2
2. Code区块：<code> ... </code> 包住若干检索到的文件内容，每个文件用[start of ...] /[end of ...] 标记边界
3
3. 示例patch文件, 并解释patch file里会包含：文件名、行号范围、删除行/新增行，且一个 patch可以修改多个文件。
4
4. 最后是patch 提示词：
5
  - 要模型解决上面的 issue
6
  - 生成一个单独的 patch file
7
  - 这个 patch file 要能用 git apply 直接应用到仓库中
8
  - 并且要求输出必须是上面示例的格式
9
  - 然后让模型从 Respond below： 之后开始输出

因为要处理长序列，所以论文选取了 ChatGPT-3.5（gpt-3.5-turbo-16k-0613)、GPT-4（gpt-4-32k-0613)、Claude2 和 SWE-Llama，下面是相关的实验结果。

不同上下文长度下的模型解决率与 BM25 召回率

表 2 是使用 BM25检索，不同上下文长度下的模型解决率，可以看到，长上下文上，SWE-Llama的解决率为0，说明这个模型在长上下文上存在明显短板。

在做 BM25检索的时候，作者把每个文件的内容在进入检索系统之前，在文件内容前面拼上文件路径，这样 issue 中如果直接提到了文件名/路径， BM25 更容易把它检索出来。

表 3 是不同最大上下文长度下，相对于基准文件（Oracle 文件，解决问题所需的关键文件）的 BM25召回率，可以观察到，上下文越长，召回率越高，说明更长的上下文能容纳更多检索到的相关文件，为模型提供更加充分的问题背景。

不同模型上下文窗口覆盖的任务比例

表 4 对比了不同模型最大 Token 数（上下文窗口大小），以及它们能覆盖的 SWE-Bench 任务实例比例，可以观察到，上下文窗口越大，覆盖的实例越多，ChatGPT-3.5 仅能覆盖 58.1%的任务实例，而Claude2 和 SWE-Llama 能覆盖 95% 以上，这直接影响了模型在 SWE-bench 上的可评估范围。表4 的 Caption 中也提到了：Llama-tokenized sequences are 42% longer on average than the equivalent sequence tokenized for GPT-4。

也就是说，最大 Token 数是模型自身 Token 体系下的数值，不同模型的分词器不同，导致同一段原始代码/文本，切出来的 Token 数不一样，比如SWE-Llama 的 10k 最大 Token 数和 GPT4 的 10k 最大 Token 数，虽然表明数值相同，但实际上能容纳的原始代码量不同，Llama 的分词器切的更细，10k Llama token，只相当于约 7k 的GPT4 token。

不同模型在 SWE-bench 与 SWE-bench Lite 上的性能

表 5 这里对比了不同模型在 SWE-bench 和 SWE-bench Lite 上的性能，其中：

% Resolved：模型成功解决问题的比例，即成功应用的补丁中，能够完全解决目标 issue 的比例。
% Apply：成功应用补丁的比例，模型生成的补丁文件能够成功应用到原始代码库的比例，仅关注补丁格式是否合法、能否被代码库接收，不涉及功能是否正确。

如果 % Apply低，说明模型对补丁格式（如diff语法、文件路径规范）、代码库结构（如文件层级、行号对应关系）不熟悉，生成的补丁存在语法错误或路径不匹配，这个属于格式层面的失败。

如果 % Apply 高但 % Resolved 低，说明模型能生成格式合规的补丁，但缺乏核心的软件工程推理能力，如找不到真正的Bug 位置、修复逻辑不完整、破坏了原有功能（PASS TO PASS 测试失败），属于逻辑层面的失败。

Oracle 检索下各模型在不同仓库中的解决率

图4 这里是 SWE-bench 在 Oracle检索下，三个模型在 12 个仓库中的解决率对比。

5. 结论#

在表 5 中可以看到，使用BM25检索的模型解决SWE-bench 任务实例的性能，总体来看，这些模Ω在解决问题时都遇到了很大的困难，即使表现最好的 Claude 3 Opus 也只有 3.79% 的解决率。

Oracle 检索设置下 Claude 2 的解决率对比

附录中的 表 18 使用了 Orcale检索的情况下，Claude2 的解决率从 1.97% → 4.80%。

Oracle-collapsed 上下文设置的实验结果

总体结论：

作者测试的这些模型在 SWE-bench 上几乎不会修真实的 issue。
检索器非常关键，给到对的文件，成绩会明显上升，这也说明瓶颈之一是，模型常常没有拿到关键上下文/没定位到要改的文件。但同时作者也提到了，就算BM25 在更大窗口下能包含提高 Oracle文件的概率，但模型也未必能用好这些上下文。
不同仓库的难度差异明显，但每个模型解决的具体实例集合不一定重叠，在 Oracle设置下，Claude2 解了 110个、SWE-Llama 解了 91 个，但 Cluade2 只覆盖了 SWE-Llama 解集合的 42%。
上下文越长反而越糟，模型会被噪声代码干扰，定位能力不足。以 Claude2 为例子，在BM25 下 13k 上下文最好，27k/50k 反而下降。为了进一步验证噪声问题，它们做了一个 oracle-collapsed：只保留 PR 真正改动行附近（±15行）的上下文，结果显著提升。
新旧问题不是关键，作者把 Oralce 设计下的任务按 PR 年份（是否在 2023 之前）切分，发现多数模型前后差异不大，只有 GPT-4 在这个切分下表现出明显差异（表 7）。
微调模型对上下文分布移位敏感，训练时看 Oracle，测试时用 BM25 结果会意外的差，作者猜测，它们训练用的 Oracle 风格上下文（基本都是要修改的文件）微调的，而 BM25 会塞进很多无需修改的文件，模型却被训练成了看到的文件都要修改，所以导致结果变差。
直接生成 Patch 比重写整个文件更可行，但模型依然常输出不规范的 Patch。
模型给出的补丁倾向少改、改小。补丁远短于人类的 Gold Patch，且经常只改动 1 个文件，作者进行了对比，发现 Gold Patch 平均 74.5 行，而模型成功 apply 的 Patch 平均只有 30.1 行，且很少改超过 1 个文件。
典型的失败模式是：定位对了函数，但漏掉关键条件/约束，以及不按项目风格写代码，作者也总结了一些共性文件：
- 模型经常写更原始/直接的 Python，不太利用代码库已有工具或第三方库；
- 解决问题更“贪心化”（之图把眼前的问题解决），不太顾及代码风格或隐含约束；
- 相比之下，Gold Patch 往往会做更结构化、更大范围的改动，甚至提前规避未来问题。
此外，本文还用 Radon 之类的工具来计算 Cyclomatic complexity 和 Halstead complexity，对比模型 patch 和 gold patch 改动后代码的复杂度变化，图 10 展示了一个典型的现象：模型可能用更少行数修复了bug，但把条件逻辑塞进了核心类中，导致圈复杂度上升；而 gold patch 虽然更长，但改在更合适的位置、结构也更加清晰，还引入了更语义化的错误类型等，这也说明了，测试过了 ≠ 工程质量好。

模型补丁与 Gold Patch 的复杂度对比

6. 论文的不足#

论文中所有的仓库均选自 Python 仓库，且只有 12 个仓库，项目、编程语言和任务范围覆盖面不够全。
论文中全部选择热门项目，这会系统性的低估长尾仓库/维护较差的仓库/测试稀缺项目等的真实难度与分布。
构造任务实例要求 PR Merged + resolves issue + 修改测试文件，并在执行过滤阶段要求能安装/运行，这会把大量没补充测试的真实修复、未合并但高质量的修复以及依赖复杂导致难复现的修复等case排除在外。
测试的范围并不是全仓库回归测试，而是部分相关的测试用例。
可复现环境构建仍然需要人工操作。
多模态信息没被系统性处理，部分 issue 含图片或者链接，目前处理的都是纯文本任务。
训练集的质量控制更加宽松，不需要 PR 提供测试改动，会混入更多的难以通过测试验证的修复/重构/不完全修复等，影响训练质量的一致性。