💬 NLP

StructEval: Benchmarking LLMs' Capabilities to Generate Structural Outputs

本文介绍了 StructEval，这是一个涵盖 18 种格式和 44 种任务类型的综合性基准，旨在通过生成和转换两种范式系统评估大语言模型在生成非渲染（如 JSON、YAML）及可渲染（如 HTML、React）结构化输出时的结构保真度，并揭示了当前模型在此类任务上仍存在显著的性能差距。

原作者： Jialin Yang, Dongfu Jiang, Lipeng He, Sherman Siu, Yuxuan Zhang, Disen Liao, Zhuofeng Li, Huaye Zeng, Yiming Jia, Haozhe Wang, Benjamin Schneider, Chi Ruan, Wentao Ma, Zhiheng Lyu, Yifei Wang, Yi Lu

发布于 2026-04-06

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Jialin Yang, Dongfu Jiang, Lipeng He, Sherman Siu, Yuxuan Zhang, Disen Liao, Zhuofeng Li, Huaye Zeng, Yiming Jia, Haozhe Wang, Benjamin Schneider, Chi Ruan, Wentao Ma, Zhiheng Lyu, Yifei Wang, Yi Lu, Quy Duc Do, Ziyan Jiang, Ping Nie, Wenhu Chen

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文介绍了一个名为 StructEval 的新工具，它的核心任务就像是给大语言模型（LLM）举办一场"格式规范大考"。

为了让你更容易理解，我们可以把大语言模型想象成一位才华横溢但有点“粗线条”的超级厨师。

1. 背景：厨师的“摆盘”难题

过去，我们主要测试这位厨师能不能把菜做得好吃（内容是否通顺、逻辑是否清晰、知识是否准确）。比如，让他写一首诗或回答一个历史问题，他做得很好。

但在现实世界中，很多任务不仅要求“好吃”，还要求摆盘必须极其精准：

非渲染格式（StructEval-T）：就像要求厨师把食材按特定的清单（JSON、YAML、CSV）列出来，不能多一个字，也不能少一个逗号，否则电脑系统就“读不懂”了。
渲染格式（StructEval-V）：就像要求厨师不仅要把菜做好，还要把盘子摆成特定的形状（HTML、React、SVG、LaTeX），甚至要能直接“端上桌”让人看到漂亮的网页或图表。如果摆错了，网页就乱码了，图表就画不出来了。

StructEval 就是为了解决这个问题而诞生的“考官”。它不再只问“菜好不好吃”，而是问：“你的摆盘是否符合严格的规格说明书？”

2. 考场设置：两大“赛区”

这个考试分成了两个主要赛区，涵盖了 18 种不同的“摆盘风格”：

赛区 A：纯文本结构（StructEval-T）
- 任务：让模型生成像 JSON、XML、TOML 这样的代码。
- 比喻：就像让厨师写一份购物清单。清单必须严格遵循格式：{ "苹果": 5, "香蕉": 3 }。如果厨师写成了 { "苹果": 5, "香蕉": 3 }（少个引号），或者把香蕉写成了“香蕉：3"，系统就崩溃了。
- 子任务：
  - 生成：直接根据“我要买 5 个苹果”这句话写出清单。
  - 转换：把一份手写的清单（CSV）翻译成电脑能读的清单（JSON）。
赛区 B：视觉渲染（StructEval-V）
- 任务：让模型生成能直接显示在屏幕上的代码，如 HTML 网页、SVG 图标、React 组件、甚至 LaTeX 论文排版。
- 比喻：就像让厨师现场搭建一个微缩景观。你让他“画一个红色的圆”，他不仅要画出圆，还要确保圆是红色的、位置在中间、大小合适。如果圆歪了，或者颜色不对，考试就不及格。
- 子任务：同样分为“生成”（直接画图）和“转换”（把一张手绘草图变成标准的工程图纸）。

3. 评分规则：不仅看“像不像”，还要看“对不对”

以前的考试可能只看“大概像不像”，但 StructEval 的评分非常死板且严格，就像用精密仪器在测量：

语法分（Syntax Score）：代码能不能跑通？就像检查清单有没有写错别字，或者网页能不能打开。如果代码报错，直接 0 分。
关键词匹配（Keyword Matching）：你要求的元素都在吗？比如要求“标题必须是 H1 标签”，如果模型用了 H2，扣分。
视觉问答（VQA Score）：这是最厉害的一招。系统会把模型生成的网页或图片“拍下来”，然后让另一个 AI（像 GPT-4.1）当质检员，对着图片提问：“标题文字是什么？”“表格里有几行？”。如果质检员答对了，说明模型真的画对了。

4. 考试结果：高手也有“手抖”的时候

论文对目前最顶尖的模型（包括 OpenAI 的 o1-mini、GPT-4o，以及开源的 Llama、Qwen 等）进行了测试，结果令人深思：

没有满分选手：即使是目前最强的商业模型 o1-mini，平均分也只有 75.58 分。这意味着，即使是顶级厨师，在严格的格式要求下，也会经常“摆盘”失败。
开源 vs 闭源：商业模型（闭源）普遍比开源模型强，大概领先 10 分 左右。这就像大餐厅的厨师比家庭厨师更擅长处理复杂的摆盘。
生成难，转换更难？：
- 让人“从零开始写代码”（生成任务）比“把一种格式转成另一种”（转换任务）更难。
- 最难的挑战：生成视觉内容（如画图、做网页）比生成纯文本结构更难。
- 特别“坑”的格式：有些格式（如 TOML、Mermaid 图表、TikZ 绘图）是所有模型的噩梦，很多模型在这些任务上得分极低，甚至不及格。

5. 总结与启示

StructEval 告诉我们：
大语言模型虽然“博学多才”，能写诗、能聊天，但在严格遵守格式规范和精准控制视觉结构方面，它们还像个还没出师的小学徒。

对于开发者：如果你指望模型直接生成完美的、可运行的代码或数据格式，目前还需要人工检查，不能直接“甩手不管”。
对于未来：这篇论文就像一面镜子，指出了模型需要改进的方向。未来的模型不仅要“聪明”，还要“细心”，能够像老练的工匠一样，精准地控制每一个字符和每一个像素。

简单来说，StructEval 就是给 AI 戴上了“紧箍咒”，逼着它们学会在严格的规则下跳舞，而不仅仅是自由发挥。

StructEval: 大语言模型结构化输出能力基准测试技术总结

1. 研究背景与问题定义

随着大语言模型（LLM）在软件开发工作流中的深度集成，模型生成结构化输出（Structured Outputs）的能力变得至关重要。现实应用场景（如软件开发生命周期、数据管道、用户界面生成、科学出版等）不仅要求模型生成的内容语义通顺，更要求其输出严格遵循特定的格式规范（如 JSON, YAML, XML, HTML, React, SVG 等）。

然而，现有的基准测试（Benchmarks）主要关注模型的语义质量或推理能力，缺乏对结构化输出能力的系统性评估。现有研究存在以下局限性：

覆盖范围窄：大多仅针对单一模态（如仅代码生成或仅文本结构），缺乏跨多种格式的综合评估。
评估指标单一：难以统一评估纯文本结构（如 JSON）与可渲染视觉结构（如 HTML/SVG）的正确性。
技术实现困难：构建支持多种渲染环境和执行验证的框架具有极高的技术门槛。

StructEval 正是为了解决上述问题而提出的，旨在全面评估 LLM 在生成非可渲染（Non-renderable）和可渲染（Renderable）结构化格式方面的能力。

2. 方法论与数据集构建

2.1 数据集概览 (StructEval Dataset)

StructEval 包含 2,035 个精心构建的样本，覆盖 18 种结构化输出格式和 44 种任务类型。数据集分为两个互补的子集：

StructEval-T (Text-only)：评估纯文本结构的生成，无需渲染。涵盖格式包括 JSON, XML, YAML, Markdown, CSV, TOML 等。
StructEval-V (Visual)：评估可执行代码的生成，需渲染为视觉内容。涵盖格式包括 HTML, React, Matplotlib, Canvas, LaTeX, SVG, Mermaid, TikZ 等。

每个子集进一步细分为两类任务：

生成任务 (Generation)：根据自然语言描述生成结构化输出。
转换任务 (Conversion)：将一种结构化格式转换为另一种（如 JSON 转 YAML）。

2.2 标注流水线 (Annotation Pipeline)

为了确保数据的高质量与多样性，作者设计了三阶段标注流程：

任务策划 (Task Curation)：定义涵盖 18 种格式和 44 种任务类型的规范，包括输入输出约束及转换规则。
LLM 辅助合成 (LLM-based Synthesis)：利用 LLM 生成初始的任务查询（Query）和评估指标（Metrics）草案，包括关键词（Keywords）和视觉问答对（VQA Pairs）。
专家审查 (Expert Review)：采用两轮人工审查机制。第一轮由标注员验证并优化任务清晰度；第二轮由独立审查员验证一致性与正确性。最终数据集经过 LabelStudio 工具管理，确保每个样本平均包含 14.7 个关键词和 8.5 个 VQA 对。

2.3 评估指标体系

StructEval 提出了一套自动化的评估框架，结合语法检查、关键词匹配和视觉问答：

语法分数 (Syntax Score, $s_s$ )：
- 对于文本格式（JSON, YAML 等），使用解析器检查语法有效性。
- 对于视觉格式（HTML, SVG 等），使用无头渲染器检查代码是否能成功渲染。
- 成功得 1 分，失败得 0 分。
关键词匹配分数 (Keyword Matching Score, $s_k$ )：
- 检查输出中是否包含预期的结构元素（如特定的键名、嵌套层级、列表项）。
- 支持基于点路径（Dot-path）的复杂规则（如 planet.moons[0].name 或 csv::header）。
- 计算正确匹配的关键词比例。
视觉问答分数 (VQA Score, $s_v$ )：
- 仅用于 StructEval-V 子集。
- 利用多模态模型（GPT-4.1-mini）作为裁判，根据渲染后的图像回答预设的视觉问题（如“标题文字是什么？”、“表格有几行？”）。
- 计算回答正确的比例。

最终得分计算：

StructEval-T: $s = 0.2 \cdot s_s + 0.8 \cdot s_k$
StructEval-V: $s = 0.2 \cdot s_s + 0.1 \cdot s_k + 0.7 \cdot s_v$ $s = 0.2 \cdot s_{s} + 0.1 \cdot s_{k} + 0.7 \cdot s_{v}$
- 该加权方案强调了视觉任务中内容正确性（VQA）的重要性。

3. 实验结果

研究团队在 12 个主流模型上进行了评估，包括开源模型（Llama-3, Phi 系列, Qwen 系列）和商业闭源模型（GPT-4o, o1-mini, Gemini 系列）。

3.1 总体性能

最佳模型：商业模型 GPT-4o 以 76.02% 的平均分位居榜首。
开源模型表现：最佳开源模型 Qwen3-4B 得分为 67.04%，落后 GPT-4o 约 10 个百分点。
性能差距：即使是表现最好的商业模型（o1-mini 得 75.58%），在结构化生成任务上仍有显著提升空间。开源模型平均落后闭源模型约 10 分。

3.2 任务类型分析

生成 vs. 转换：总体而言，转换任务（Conversion）比生成任务（Generation）更容易。但在 StructEval-T 的生成任务中，商业模型表现显著优于开源模型。
文本 vs. 视觉：生成可渲染的视觉内容（StructEval-V）比生成纯文本结构（StructEval-T）更具挑战性。
格式难度差异：
- 饱和任务：JSON, HTML, CSV, Markdown 等常见格式的生成，多数模型得分超过 90%。
- 困难任务：Text→TOML, Text→SVG, Text→Mermaid, Matplotlib→TikZ 等任务，所有模型得分普遍较低（部分低于 50%），显示出模型在处理复杂结构或特定领域格式时的短板。

3.3 错误分析

Phi-3-mini 表现最差（40.79%），主要错误包括：
- 在 TOML 转 YAML 任务中产生错误的结束标签（|<|END_CODE|>）。
- 在 CSV 转 JSON 任务中无法正确捕捉层级关系。
结构错误：许多模型在生成复杂嵌套结构或特定语法（如 TOML 的特定格式要求）时容易出错，导致解析失败。

4. 关键贡献

首个综合性结构化输出基准：StructEval 是目前首个同时覆盖非可渲染（文本）和可渲染（视觉）格式，并包含生成与转换双重任务类型的基准测试。
创新的评估框架：提出了结合语法解析、基于路径的关键词匹配以及基于 VLM 的视觉问答的混合评估指标，解决了多模态结构化输出难以自动评估的痛点。
揭示性能差距：量化了当前 SOTA 模型在结构化生成任务上的局限性，特别是开源模型与商业模型之间的差距，以及在处理复杂/冷门格式（如 Mermaid, TikZ）时的普遍困难。
高质量数据集：构建了包含 2000+ 样本、经过严格专家审查的高质量数据集，为后续研究提供了可靠的数据基础。

5. 意义与未来展望

StructEval 的研究表明，尽管 LLM 在自然语言理解上取得了巨大进步，但在严格遵循格式规范和生成可执行的结构化代码方面仍存在显著瓶颈。这对于依赖结构化输出的实际应用场景（如自动化 API 开发、数据工程、前端代码生成）构成了直接挑战。

局限性：

当前基准主要针对静态渲染格式，未涵盖动态交互（如按钮点击、页面跳转）。
数据集中部分内容由 LLM 生成，尽管经过人工审查，仍可能存在潜在的偏见。

未来方向：

扩展基准以包含动态交互和响应式 UI 的评估。
进一步优化模型在复杂格式（如 TOML, Mermaid）上的生成能力。
缩小开源模型与商业模型在结构化生成任务上的性能差距。

综上所述，StructEval 为评估和提升 LLM 的结构化输出能力提供了重要的工具和基准，推动了大模型在工程化落地方面的研究进展。