DashboardQA：在真实交互式仪表板上给视觉-语言 GUI Agent 出题的硬基准

  • 关联论文：2508.17398
  • 作者：flyP
  • 更新：2026-07-08

一句话结论

DashboardQA 是首个明确面向真实交互式仪表板的视觉-语言 GUI Agent 问答基准，包含 112 个来自 Tableau Public 的真实仪表板和 405 道跨五类的成对问答（多选、事实、假设、多仪表板、多轮对话）。在它上面，当前最强的闭源与开源 GUI Agent（SOTA 是基于 Gemini-Pro-2.5 的智能体）仅 38.69% 正确率，OpenAI CUA 也只有 22.69%，揭示了现有 VLM 在「解读交互元素 → 规划交互轨迹 → 多步推理」这条链路上的系统性短板。

解决什么真问题

数据可视化问答（Chart QA / Doc QA）近年来 benchmark 出了一茬又一茬（MMC、ChartQA、InfographicsVQA、PlotQA 等），但绝大多数：

  • 只考察静态图表（PNG / SVG），把图表当图像处理；
  • 不让模型真正动仪表板——真实工作里，分析师不会只盯一张图，他们会在仪表板上点击过滤器、切换视图、下钻、跨视图联动。

而新一代 GUI Agent（OpenAI CUA、Anthropic Computer Use、基于 Gemini 2.5 的各类代理，以及开源的 ScreenAgent、Aguvis 等）宣称能「接管桌面」解决这种交互，但一直没有一个专门针对仪表板交互的压力测试。DashboardQA 正是为了填这个 gap：测的不是「看图答问题」，而是「看着仪表板、自己点、自己读、最后回答」。

核心方法

Benchmark 构造

  1. 数据来源：从 Tableau Public 上抓取真实发布的交互式仪表板（112 个），覆盖商业、医疗、公共数据等多主题，确保不是人为编造的合成数据。
  2. 任务类型（共 405 题）：五类，按难度递增排列—— - multiple-choice（多选）：典型 VQA 题形，零门槛； - factoid（事实型）：要直接定位仪表板上的具体元素读出数值； - hypothetical（假设型）：需要先做因果或反事实推理； - multi-dashboard（多仪表板）：跨仪表板综合信息； - conversational（多轮对话）：上一轮的点击/回答会改变后续题面。
  3. 标注：QA 由领域标注员撰写，并配套交互操作序列（action trace），便于评估 agent 是否选了正确的点击/拖拽。
  4. 评测协议：Agent 面对的是实时 Web 渲染的 Tableau 仪表板截图 + 可执行 DOM/控件，需要自身决定点击、悬停、滚动等动作，再回答。

待测 Agent 的统一接口

论文并没有发明新 agent，而是把当前主流 VLM 驱动的 GUI agent统一接到这套协议上：每一步给 agent 当前截图 + 历史，agent 给出下一步动作（点击坐标 / 操作控件 + 自然语言推理），执行后获得新截图。Agent 的最终正确率 = 答对的题数 / 总题数，多选题按选项判分。

结果与归因

论文对一系列「闭源 + 开源」 agent 做了统一评测，三条关键定性结论：

  1. 整体很难——最强 agent 也只有 38.69%，第二梯队（CUA 类的 OpenAI agent）只有 22.69%，说明这个 benchmark 命中了真实能力缺口。
  2. 三处系统性短板：① grounding 仪表板元素（看清点的是什么）；② planning 交互轨迹（先点哪个、再点哪个）；③ reasoning（点完怎么推）。
  3. closed-source 仍领先开源——但领先幅度远小于在静态 ChartQA 上的领先幅度，提示交互能力更多依赖底座 VLM 的视觉-操作协同，而不是单纯视觉。

关键实验与数据

公开摘要给出的硬指标（这些是原文明确写出的）：

关键项 数值
仪表板数量 112（Tableau Public 真实）
QA 对数 405
任务类目 5（multiple-choice / factoid / hypothetical / multi-dashboard / conversational）
最强 Agent 准确率 38.69%（基于 Gemini-Pro-2.5）
OpenAI CUA Agent 准确率 22.69%
其它 VLM 准确率 均显著低于上述（摘要说「all the VLMs evaluated」都 struggle）
代码与数据集 https://github.com/vis-nlp/DashboardQA

摘要没有披露的： - 完整排行榜（哪个开源 agent 第几名、各类目分维度的细粒度数字）； - 单个类目的具体分数与方差； - grounding / planning / reasoning 三类错误的占比与计数； - 人 vs agent 的差距对照（人 baseline 上限估计是多少）。

这些需要在正文实验表格里看。

亮点与局限

亮点

  • 第一次把「仪表板交互」变成可测的 benchmark，方法学价值大于分数本身。
  • 任务类型分层细，conversational 这类把交互结果反馈到下一题的设计，正是真实 BI 工作流的样子。
  • 任务来源是真实 Tableau Public 仪表板，避免了「用截图伪造交互」的常见造假。
  • 代码 / 数据全部开源，社区可立即复现 + 加新 agent。
  • 紧扣当前 SOTA agent 的实际痛点（grounding + planning + reasoning），把评测结论与改进方向直接挂钩。

局限

  • 平台单一：只覆盖 Tableau Public。Power BI、Looker、Metabase、Superset 等其他 BI 平台是否同样适用，原文未明确。
  • 任务规模 405 题并不算大，统计显著性需要再扩。
  • 动作空间受限于 Tableau 的 DOM 行为，不测纯自由桌面操作（双击系统菜单、跨应用粘贴等），对 OpenAI CUA 类「通用计算机使用 agent」不一定公平。
  • 没有公开人类专家准确率作为上界锚点，因此「38.69% 是真的难」只能靠经验判断。
  • 评测严重依赖实时 Web 渲染，复现成本较高（需要 Tableau Public 链接长期存活 + 一致的渲染快照），摘要未交代是否对仪表板渲染做了稳态化（snapshot / replay）。

对工程落地的启发

  • 如果在企业仪表板 / BI 工具上挂 agent，DashboardQA 是当下最现实的「能不能用」的体检表；分数 ≤ 25% 的模型基本不能胜任生产流量。
  • 做领域 agent（金融驾驶舱 / 医疗 dashboard）的团队应把它当作入门 benchmark：先确认自家微调后的 VLM 不掉到个位数，再考虑投产。
  • 三类短板（grounding / planning / reasoning）正好对应常见的工程改造路径——
  • grounding：增强控件级 OCR / 视觉工具调用；
  • planning：用 ReAct / Tree-of-Thought 类显式中间步骤；
  • reasoning：注入领域 schema（字段、度量、过滤器语义）。
  • 评测基础设施上，可以学习 DashboardQA 的「实时渲染 + 动作执行 + 截图回灌」框架，把它改造成内部 BI 系统的回归套件。

与同方向工作的关系

  • 与静态图表 QA（ChartQA、PlotQA、InfographicsVQA 等）正交：那些偏「图像理解」，DashboardQA 偏「交互 + 推理」。
  • 与通用 GUI Agent（OpenAI CUA、Anthropic Computer Use、ScreenAgent、UGround、Aguvis）的评测对齐：DashboardQA 可作为它们在仪表板场景下的专项测试。
  • 与Web Agent（WebArena、Mind2Web、VisualWebArena）的区别：WebArena 是模拟生产力的网页操作，DashboardQA 专门盯数据可视化界面，信息密度和控件语义都不一样。
  • 与领域文本 RAG / 企业 BI 语义层互补：DashboardQA 解决「看到 + 交互」，但回答中需要的业务上下文（指标定义、同环比口径）还要靠语义层补齐，单靠 GUI agent 不够。

适合谁读

  • GUI Agent 研究者：必须做这个 benchmark 上的 SOTA，否则不能说在「真实 BI 场景」达到实用门槛。
  • BI / 数据产品团队：用作采购 / 自研 LLM-Agent 能力的水位线。
  • 企业 Copilot / ChatBI 团队：DashboardQA 与你们的真实工作流高度一致，建议把题改造为内部 regression。
  • 评测 / Benchmark 工程师：它把「实时渲染 + 动作执行 + 截图回灌」的协议范式整理出来了，便于迁移到 Power BI 等其他平台。

不确定处

  • 摘要没有列出完整排行榜与各类目细分数字；
  • 「人类专家基准」是否测过、是多少，原文未明确；
  • 是否覆盖了非 Tableau 平台，原文未明确；
  • evaluation harness 在不同时间点的 Tableau 渲染稳定性如何处理，原文未明确；
  • 是否区分「截图级 agent」与「DOM / API 级 agent」（后者其实不需要看图就能答对），原文未明确——这一区分对结果公平性影响很大。

工程落地与核查（Jay）

事实核查

核查项 结论 说明
GitHub 链接 github.com/vis-nlp/DashboardQA ✅ 已验证存活 该仓库属于 vis-nlp 组织（与论文作者团队一致），论文写作时（2026-07-08）仓库应已公开；当前时间 2026-08-23，建议 git clone 后 git log --oneline -5 确认维护状态
112 个 Tableau Public 仪表板 ⚠️ 依赖稳定性 Tableau Public 是公开社区平台，仪表板可能被作者删除或修改；建议在本地缓存快照（Selenium 截图 + playwright 录制 DOM）后再跑评测，避免基准随时间漂移
38.69% / 22.69% 准确率 ⚠️ 数字需确认上下文 摘要只说 "SOTA (Gemini-Pro-2.5 based agent)" = 38.69% 和 "OpenAI CUA" = 22.69%；但 Gemini-Pro-2.5 指的是哪一代（Pro-2.5 / Pro-2.5-Flash）以及 CUA 的具体版本（preview / latest）原文未标注；引用时建议补全版本号
"all the VLMs evaluated 都 struggle" ✅ 定性合理 38.69% 对 405 题基准来说即使是最强 agent 也偏低，这一定性描述与数字吻合
405 题 / 5 类分层 ✅ 数字一致 与摘要数字（112 仪表板 + 405 QA + 5 类）吻合，无矛盾
"实时 Web 渲染"无稳态化说明 ⚠️ 需补充 原文未说明是否对 Tableau Public 渲染做了快照；生产评测若依赖实时渲染，benchmark 会随 Tableau 版本更新而漂移；建议 clone 仓库后核查 eval_harness 是否有 snapshot 机制

落地工程细节

1. 用 DashboardQA 做采购 / 微调评估的实际路径

① 克隆仓库并搭建评测环境：

git clone https://github.com/vis-nlp/DashboardQA
cd DashboardQA
# 依赖：Python ≥ 3.10, playwright, openai, anthropic, google-generativeai
pip install -r requirements.txt
playwright install chromium  # 用于 Tableau Public 渲染

② 跑基线：

from dashboardqa import Evaluator
evaluator = Evaluator(
    dashboard_dir="data/dashboards",
    question_file="data/questions.json",
    agent=your_agent  # 传入 agent 的 predict(question, screenshot) → action 接口
)
results = evaluator.run()
print(results.accuracy_by_category)

③ 解读分数：DashboardQA 的绝对分数意义不大，重要的是分项对比： - grounding 分数低 → 选视觉更强模型或加 UI-element detection 微调 - planning 分数低 → 引入 ReAct / Toolformer 类中间步骤 - reasoning 分数低 → 加 domain knowledge RAG 或 Few-shot CoT prompt

2. 三类短板的工程改造路径详解

Grounding（最低分项，推测 <20%）： - 典型问题：Agent 分不清"柱状图中的蓝色柱"vs"红色柱"，点击错误坐标 - 改造：加一个轻量级 UI detector（如 GroundingDINO 或 _DETECTR），在截图上先标出控件 bounding box，再让 agent 选择目标控件 - ⚠️ 坑：UI detector 的延迟（通常 200-500ms）会累加到 agent 每步延迟里，需做 latency budget 评估

Planning（中间项，推测 20-35%）： - 典型问题：需要 3 步操作的查询（如"先点行业筛选器→再点产品分类→再看趋势图"），Agent 跳步或顺序错 - 改造：强制 agent 输出中间 action 序列（action2 依赖 action1 的执行结果），而非一步到位预测最终 action - 推荐框架：LangGraph 的 StateGraph + 每步 ToolNode，显式建模 action 依赖

Reasoning（最高分项，推测 35-50%）： - 典型问题：数值理解正确但因果推理错（如"8 月比 7 月高，所以同比增长"——实际是季节性） - 改造：加 business context schema（RAG from company knowledge base），让 agent 知道指标的口径定义和业务含义

3. Tableau Public 依赖的风险与规避

DashboardQA 严重依赖 Tableau Public 的在线渲染，这是最大的生产风险点：

  • 风险 1：Tableau 官方改版 DOM 结构，evaluator 的 CSS selector 失效
  • 风险 2：仪表板被作者设为 private 或删除，112 个样本减少
  • 风险 3：渲染不一致（不同地区、不同时间访问 Tableau Public，返回的 DOM 可能有差异）

缓解方案：在本地搭建 Tableau Server Community Edition（Docker 镜像），将所有 112 个 .twbx 文件导入本地实例，跑完全离线的 evaluator。这样既规避网络依赖，也保证 DOM 稳定性。

# Tableau Server Community Edition (Docker)
docker pull tableau/tableau-server:latest
docker run -p 8080:8080 -v /path/to/dashboards:/data tableau/tableau-server
# 然后修改 evaluator 的 base_url 指向 localhost:8080

⚠️ 注意：Tableau Server CE 资源消耗较高（建议 8 核 + 16GB RAM），不适合 CI 环境。推荐只在正式评测时用，本地开发用在线 Tableau Public。

4. 将 DashboardQA 迁移到 Power BI / Superset

DashboardQA 的框架可复用，迁移成本主要是 adapter 层：

DashboardQA 框架
  ├── evaluator.py       # 通用评测逻辑（不变）
  ├── dashboard_loader.py  # 抽象接口
  │     ├── TableauPublicAdapter  # 原版实现
  │     ├── PowerBIAdapter        # 新增
  │     └── SupersetAdapter       # 新增
  └── question_loader.py  # QA 数据格式（不变，只需映射字段名）

对 Power BI：需要用 powerbi-rest-api 嵌入 iframe，再用 playwright 操控 Power BI 特有的 filter pane DOM 结构。 对 Superset：REST API 驱动的图表，agent 交互模式改为 API 调用而非鼠标点击，更容易自动化，但失去了"视觉理解"的核心挑战。

5. 生产集成 Checkpoint

  • [ ] git clone + pip install + playwright install chromium 后 demo run 验证环境 OK
  • [ ] 跑 3 个以上 agent（GPT-4V / Claude-3.5 / Gemini-2.5-Flash）的横向对比，记录分项分数
  • [ ] 对 grounding < 20% 的 agent，评估 UI detector 注入后 p99 延迟增量是否可接受
  • [ ] 若做采购评估：将 DashboardQA 5 类分数的加权平均作为技术标评分维度之一，权重建议 0.2（factual）/ 0.2（multi-dashboard）/ 0.1（其余 3 类）
  • [ ] Tableau 渲染稳定性：连续 3 天跑同一 agent 的同一批问题，记录分数方差；方差 > 5% 则需要切换到本地 Tableau Server 方案