在大型语言模型 (LLM) 飞速发展的世界里，将简单的文本提示转化为可视化图表的能力是一个“杀手级应用”。想象一下，输入“展示过去五年相对于市场营销支出的销售趋势”，然后让 AI 瞬间生成渲染该图表所需的完美 Python 代码。这项任务被称为 Text-to-Vis (文本生成可视化) 。

为了构建这些系统，研究人员依赖于基准测试 (Benchmarks) ——即用于训练和评估性能的标准化数据集。但这就引出了一个关键问题: 这些基准测试真的反映了人类在现实世界中创建可视化的方式吗?

如果基准测试是人为制造的或存在偏差，我们可能是在训练 AI 去通过一项与现实毫无关系的考试。在论文 “Do Text-to-Vis Benchmarks Test Real Use of Visualisations?” 中，来自悉尼大学和 CSIRO Data61 的研究人员进行了一项大规模的实证研究来回答这个问题。通过将流行的基准测试与数百万行现实世界的代码进行比较，他们揭示了学术测试与实际应用之间存在的巨大鸿沟。

合成基准测试的问题

核心问题在于“生态效度 (Ecological Validity) ”——即实验结果能在多大程度上推广到现实环境。在 Text-to-Vis 这个细分领域，基准测试通常是合成生成的。

例如，数据集创建者可能会定义一条规则: “创建一个条形图的提示词”，然后自动生成数千种变体。虽然这创造了一个大型数据集，但它依赖于创建者对用户可能会要求什么的假设，而不是用户实际在做什么。

为了解目前的现状，研究人员审查了三个著名的基准测试:

  1. nvBench: 源自 SQL 查询，专注于根据数据集和提示词生成可视化。
  2. ChartDialogs: 专注于对话交互 (例如，“把柱子变成红色”) 。
  3. PlotCoder: 专注于基于提示词和现有代码上下文来生成代码。

Table 2: Description of benchmark datasets.

如表 2 所示，这些数据集在输入和输出上各不相同。然而，要确定这些输入和输出是否符合现实，需要一个“真实”行为的基准线。

为了建立这个基准线，作者们使用了 The Stack , 这是一个来自 GitHub 的海量开源代码集合。他们提取了跨越四个主要编程生态系统的可视化代码:

  • Python: 特别是使用 Matplotlib 库 (包括标准脚本和 Jupyter Notebooks) 。
  • R: 使用 Graphics 包。
  • Javascript: 使用 ChartJS 。
  • JSON/Schema: 使用 Vega-Lite 。

Table 1: Statistics of real-world and benchmark data.

表 1 突显了这项调查的规模。研究人员分析了超过 385,000 个 Jupyter Notebooks 和 464,000 个 Python 文件，数量远超 nvBench (7,241 个样本) 或 ChartDialogs (3,284 个样本) 等基准测试中的样本。

核心方法: 跨越语言鸿沟

比较 Python 脚本和 Vega-Lite JSON 规范并非易事。不同的库对同一个概念使用不同的名称。例如，要设置图表标题:

  • Matplotlib 使用 plt.title() 或 ax.set_title()。
  • Vega-Lite 在 JSON 对象中使用 title 属性。
  • R 可能会在 plot() 中使用 main 参数。

为了进行公平的比较，研究人员必须将这些数据标准化。他们开发了一个 跨语言映射表 (Cross-Language Mapping Table) 。

第一步: 解析代码

首先，他们使用抽象语法树 (AST) 解析器将原始代码转换为“通用格式”。这涉及提取函数名、参数和赋值，剥离编程语言特定的语法，以揭示用户的意图。

Figure 4: The process of converting JSON to universal format

如上图 4 所示，复杂的嵌套配置 (常见于 Vega-Lite 或 ChartJS) 被扁平化为由函数和关键字参数 (kargs) 组成的标准化结构。

第二步: 映射表

代码解析完成后，研究人员将现实世界数据中使用频率最高的前 500 个参数映射到 8 个类别的 62 个不同属性中 (如坐标轴、图例、标题和网格) 。

Figure 1: Example of the cross-language mapping

图 1 展示了这种映射是如何针对“x 轴标题”属性工作的。无论原始代码是 Python、R 还是 Javascript，只要用户试图标记 x 轴，它就会被映射到这个单一属性。这种严格的标准化过程使得作者能够对数百万个不同的代码文件进行同类比较。

实验与结果: 现实差距

数据标准化后，研究人员将“现实世界”数据集 (来自 GitHub) 与“基准测试”数据集进行了比较。结果显示在三个关键领域存在惊人的差异: 图表类型、外观属性和程序复杂度。

1. 图表类型的脱节

基准测试是否测试了人们实际使用的图表类型？答案在很大程度上是否定的。

Figure 2: Plot type distribution over eight datasets.

图 2 (上图) 揭示了 nvBench 数据集的巨大偏差。虽然 Vega-Lite (nvBench 针对的库) 在现实世界的使用中显示出折线图、散点图和条形图的使用相对平衡，但 nvBench 却被条形图 (超过 80%) 所主导。

图 2 (下图) 比较了基于 Python 的数据集。

  • 现实世界 (Matplotlib): 用户绝大多数偏好折线图 (蓝色) 和散点图 (橙色) 。
  • ChartDialogs: 该基准测试创造了一种人为的平衡，包含了非常高比例的饼图和流线图 (Stream Plots) ——这些类型在实际 Python 使用中统计上很少见。

结论: 如果一个 AI 主要在 nvBench 上训练，它可能非常擅长制作条形图，但当被要求绘制散点图时却会失败，仅仅是因为基准测试歪曲了不同图表类型的重要性。

2. 缺失的外观属性

除了图表类型，可视化还严重依赖于“属性”——即标题、颜色、图例和坐标轴的自定义。

研究人员计算了斯皮尔曼等级相关系数 (Spearman’s rank correlation coefficient) ，以查看基准测试中属性使用的频率是否与现实世界的使用相匹配。

Figure 3: Spearman’s rank correlation coefficient in terms of frequent attributes

在图 3 中，高相关性 (深蓝色) 表示强匹配。

  • 现实世界数据集 (Matplotlib, Graphics, ChartJS) 之间通常相关性良好 (分数 > 0.7) 。
  • ChartDialogs 和 nvBench 与现实世界数据的相关性较弱。它们未能测试用户高度重视的属性。

基准测试到底缺失了什么？分析表明，现实世界的用户经常自定义 标题、坐标轴限制、刻度标签、图例可见性和网格线 。 然而，像 nvBench 这样的基准测试通常完全忽略这些，只关注数据绑定。

Figure 8: Heat map of the most frequent aesthetic attributes over 7 datasets.

图 8 中的热图将这种频率可视化了。绿色块代表高频使用。注意现实世界数据集 (前几列) 如何在“坐标轴 (Axes) ”和“标题 (Titles) ”上分布着绿色块。相比之下，像 nvBench (最右侧) 这样的数据集有大片的白色空白，表明这些特征在基准测试中很少甚至从未出现。

3. 代码复杂度

最后，该研究考察了生成的代码的复杂度。现实世界的绘图脚本通常不是“单行代码”。它们涉及设置图形、绘制数据、调整坐标轴、添加注释以及保存文件。

Table 3: Average number of functions and parameters

表 3 凸显了复杂度的显著差异。

  • 现实世界的 Matplotlib 代码 平均每个可视化使用 6 个以上的函数 和 10 个以上的参数 。
  • PlotCoder (标红部分) 下降到大约 4 个函数和 6 个参数。
  • nvBench 在函数调用方面甚至更简单。

这表明基准测试正在测试“玩具”问题。一个能解决基准测试问题的 AI 可能会在面对现实世界的数据科学脚本时束手无策，因为后者通常需要多个函数调用才能达到预期的输出效果。

基准测试的困境: PlotCoder 的潜力

在测试的基准中, PlotCoder 脱颖而出，最为现实。它使用从 Notebooks 中提取的数据，因此其图表类型和属性的分布更接近现实世界的 Matplotlib 使用情况 (斯皮尔曼相关系数为 0.7 - 0.9) 。

Figure 7: A sample from the PlotCoder dataset.

然而，PlotCoder 有一个致命缺陷: 可执行性 。 如图 7 所示，PlotCoder 提供了代码上下文和提示词，但它不包含运行该代码所需的实际数据文件。没有数据，就无法执行代码来验证输出图表是否正确。这使得它对于检查 AI 是否能编写语法很有用，但对于检查 AI 是否正确地可视化了数据则毫无用处。

相比之下, nvBench (下图 5) 是端到端可执行的，但受困于前文讨论的生态效度问题 (条形图太多，属性太少) 。

Figures 5,6,and 7 illustrate examples for nvBench, ChartDialogs, and PlotCoder, respectively. Figure 5: A sample from the nvBench dataset.

ChartDialogs (下图 6) 依赖于一种槽位填充 (slot-filling) 方法，虽然可执行，但将 AI 限制在一组非常狭窄的预定义动作中，无法匹配真实编程的灵活性。

Figure 6: A sample in ChartDialogs dataset. This dataset was built in a slot-filling manner. The visualisation is generated by a hard-coded program.

结论与启示

这篇论文的发现为 Text-to-Vis 社区提供了一次现实核查。作者们证明，当前的基准测试通常只关注问题的一个方面——要么是代码合成，要么是数据展示——而且很少能捕捉到在自然环境中看到的完整的“意图分布”。

主要收获:

  1. 优先级偏差: 与专业用途相比，基准测试过度代表了简单的图表类型 (条形图/饼图) ，而未能充分代表复杂的图表类型 (散点图/折线图) 。
  2. 审美盲区: 基准测试通常忽略图表的“润色”——标题、图例和坐标轴缩放——这些对于现实世界的可读性至关重要。
  3. 复杂度差距: 现实世界的代码比基准测试中经过“净化”的代码要复杂和冗长得多。

对于学生和未来的研究人员来说，这篇论文指明了一条清晰的前进道路: 我们不仅需要更多的基准测试，我们需要更好的基准测试。未来的数据集应当通过挖掘现实世界的代码库 (如 The Stack) 来构建，以确保它们捕捉到人类实际可视化数据时那种混乱、复杂且高度定制化的本质。只有这样，我们才能构建出真正能在日常工作流程中辅助用户的 AI 工具。