Show, Don't Tell: Evaluating Spatial Cognition in Generative Pixels Rather Than LLM Text

  • 关联论文：2607.21072
  • 作者：Tom
  • 更新：2026-07-24

一句话结论

提出 ProVisE 框架，让图像生成模型可以在像素空间中直接「画」出空间判断答案，并被解析为结构化预测与 text-output VLM 在统一 benchmark 下公平比较；发现在像素可外部化的空间任务上生成模型有竞争力，但在组合推理上弱于 VLM。

解决什么真问题

答案接口 mismatch：空间推理评测的核心痛点

Spatial intelligence（空间智能）是 AI Agent 从「理解语义」走向「操控物理世界」的关键能力。空间任务天然是连续视觉场景中的判断——定位某个区域、标记一条路径、比大小——这些操作用「指向/涂抹/画线」远比「报坐标」或「写文字」自然。

然而，现有的空间推理 benchmark（如 SpatialBench、SpatialVLM 等）全部面向 text-output VLMs，要求模型输出坐标、选项标签或文字描述。这带来一个根本性的接口错配：

对于「请标记出图像中最大的红色圆圈」这个问题，图像生成模型能直接在像素上画一个红圈，但 benchmark 要求的答案是 [x1, y1, x2, y2] 坐标列表——两者的输出形式完全不兼容。

结果是：图像生成模型的空间智能无法被公平评测；即使它「画对了」，也无法得分。

现有评测路线的局限

评测路线 代表工作 局限
文生图质量评估 TIFA, GenEval, VQAScore 评测「生成的图是否符合 prompt」，不评测模型对输入图像的空间问答能力
空间 VLM 评测 SpatialBench, SpatialVLMBench 只适用于 text-output VLMs，无法评测图像生成模型
多模态生成评测 Emu3, Show, PixArt 关注生成质量，不专门设计空间任务和解析协议

本文要解决的核心问题：如何构建一套统一的、可比较的框架，让 text-output VLM 和 image-generation model 在相同的空间任务下、用各自最自然的方式作答，并获得可量化的metric-compatible分数？

核心方法

1. ProVisE：协议化的视觉评测框架

ProVisE 的核心思想是 protocol-constrained visual answer + structured parsing：

Step 1：定义协议（Protocol）

每个空间任务被形式化为一个「协议」——规定模型在像素空间中的回答格式（约束）。例如：

  • 「在目标物体上画一个点」→ 模型输出一个高亮像素点，解析器找到局部亮度峰值作为坐标
  • 「标记出区域」→ 模型输出一个 mask，解析器计算连通分量并映射到语义标签
  • 「画出路径」→ 模型输出描边，解析器提取骨架并计算路径长度/方向

协议是 benchmark-agnostic 的——同一套解析器可服务于多个不同 benchmark，只需适配协议。

Step 2：协议约束下的视觉回答

图像生成模型在原始输入图像的基础上，以「加标记」方式生成答案图（answer image）。这与模型的原生输出形式完全一致，无需额外解码器。

Step 3：结构化预测解析（Parsing）

答案图通过一个专用解析器（parser）被转换为结构化预测：bounding box 坐标、mask、深度值、方向向量等。这些结构化输出直接兼容原有 benchmark 的评分标准。

2. Agentic Builder：自动化协议构建

ProVisE 还包括一个 Agentic Builder，用于自动化生成和验证新 benchmark 的协议：

  • 给定一个新 benchmark 的评测指标（metric）和任务描述
  • Builder 自动生成候选协议（candidate protocols）
  • 对每个候选协议，在 benchmark 上做验证（validate），淘汰无法解析或解析结果不 metric-compatible 的协议
  • 最终保留的协议进入 ProVisE 执行流程

作者在 6 个外部空间 benchmark 上验证了 Agentic Builder 的有效性。

3. SpatialGen-Bench：诊断基准

在 ProVisE 框架之上，论文构建了 SpatialGen-Bench：

  • 470 个样本，覆盖 14 个空间子任务
  • 4 个能力等级：Perception（感知）→ Understanding（理解）→ Reasoning（推理）→ Interaction（交互）
  • 多种答案形式：点、框、mask、轨迹、方向向量、数值答案（距离/角度）
  • 来源：Zhejiang University，2026年7月

14 个空间子任务涵盖：目标定位、区域标记、路径规划、距离估计、方向判断、深度排序等。

4. 解析协议示例（原文未完整列出，仅据框架推断）

根据 ProVisE 论文描述，典型的解析流程为：

Answer Image (pixel-space visual output)
    ↓ [Protocol-specific parser]
Structured Prediction (bbox / mask / depth map / path)
    ↓ [Benchmark metric]
Score

解析器的设计由 Agentic Builder 自动生成，针对不同任务类型（点定位、区域分割、路径提取）有不同的视觉特征提取逻辑。

关键实验与数据

评测设置

论文在 SpatialGen-Bench 上评测了代表性的 text-output VLMs 和 image-generation models，评测方式为 unified setting（同一套任务语义，同一套评分标准），但各自以自己的原生方式作答：

  • Text-output VLMs（GPT-4V 等）：直接以文字/坐标输出
  • Image-generation models（DALL-E 3, Stable Diffusion, 等）：通过 ProVisE 协议在像素空间作答，再由解析器转为结构化预测

主要发现

场景 图像生成模型 Text-output VLMs
空间答案可外部化为像素（点标记、区域涂色、路径描线） 有竞争力，部分超越 VLM 需通过文字序列化精确坐标，处于劣势
组合空间推理（多步关系、相对位置推理） 明显弱于 VLM，像素表示难以表达逻辑组合 明显优势，符号化推理能力强

典型数据（原文未给出完整数值表，以下为原文摘要层面的定性描述）：

  • 当空间答案形式与像素表达匹配时（标记连续区域、画点等），生成模型与 VLMs 差距不大，部分任务持平或略优
  • 在「相对位置 A 在 B 的东北方向、C 在 A 和 B 之间」这类组合推理任务上，VLMs 保持显著领先

Agentic Builder 验证

  • 在 6 个外部 benchmark 上验证了 Builder 的有效性
  • Builder 能自动生成与 benchmark 原生 metric 兼容的协议
  • 生成的协议在解析成功率上达标（原文未明确具体成功率数值）

与外部 benchmark 的兼容性

  • ProVisE 支持直接接入现有 benchmark（仅需提供 metric 定义）
  • Builder 在 6 个外部 benchmark 上自动生成了兼容协议
  • 支持 text-to-image 和 image-conditioned 两种任务类型

亮点与局限

亮点

  1. 填补评测空白：首次系统解决了「图像生成模型在空间任务上的可评测性」问题，设计了完整的 protocol → parser → metric 流程
  2. Benchmark-agnostic：ProVisE 不是为某一个 benchmark 设计的，而是通用框架，可接入任意空间推理 benchmark
  3. Agentic Builder：将协议构建自动化，降低了在新 benchmark 上应用 ProVisE 的门槛
  4. 揭示互补性：论文没有简单地说「谁更好」，而是揭示了像素空间表达和文本符号推理各有优势，为未来多模态 Agent 设计提供了方向性指引
  5. 引用古语增强说服力：开篇引用《周易·系辞》「立象以尽意」，为「用图像而非文字表达空间意图」提供了哲学层面的呼应

局限

  1. 协议设计仍需人工介入：虽然 Builder 自动化了部分工作，但完整的协议设计和验证仍需要领域专家审核（原文未明确自动化程度）
  2. 解析器的准确性本身是误差来源：Parser 的漏检/误检会直接影响最终分数；Parser 的鲁棒性未作为独立模块充分评测
  3. 组合推理弱的根因未深入分析：论文发现生成模型在组合推理上弱于 VLMs，但未深入分析是生成模型本身推理能力不足，还是像素表示无法表达多步逻辑关系（缺乏消融实验）
  4. 评测模型数量有限：摘要提到「representative」模型，但具体评测了哪些模型、各模型参数量和版本未在摘要/简介中明确
  5. 14 个子任务是否足够代表空间智能全貌：470 样本/14 子任务/4 能力级别的覆盖度是否充分，存在讨论空间；大规模空间智能评测可能需要更丰富的任务库

对工程落地的启发

  1. 多模态 Agent 评测：在做视觉 Agent（用于机器人操控、AR/VR 交互）时，ProVisE 提供了一套可用的空间能力评测方案，值得参考
  2. 生成模型 + VLM 组合设计：论文的发现暗示了一种混合架构的价值——用图像生成模型处理「感知级」空间任务（定位、分割），用 VLM 处理「推理级」空间任务（多步关系判断）；两者互补而非竞争
  3. Pixel-space Spatial Output 作为接口：未来在做 Agent Tool Use 时，若模型具备生成能力，直接「画答案」可能比「输坐标」对人类更直观
  4. Benchmark 建设方法论：Agentic Builder 的思想——用 Agent 自动化构建评测协议——可推广到其他模态（如视频、3D 点云）的评测框架设计
  5. 对比评测的标准化：做视觉生成模型时，可参考 ProVisE 的 unified评测setting，避免用自己的 metric 与 VLMs 的 metric 不兼容而无法横向比较

与同方向工作的关系

方向 代表工作 与 ProVisE 的关系
空间 VLM 评测 SpatialBench (Xu et al., 2026), SpatialVLMBench 继承其任务设计，但扩展到图像生成模型；ProVisE 解决接口兼容问题
文生图质量评估 TIFA (Hu et al., 2023), GenEval (Ghosh et al., 2023) ProVisE 不评测「图是否符合 prompt」，而评测「模型能否回答空间问题」，维度不同
空间推理 benchmark SpatialGenEval (Wang et al., 2023), SpatialWorld SpatialGen-Bench 的命名与 SpatialGen（场景生成）相关但不同；ProVisE 评测的是空间认知而非场景生成
VLM 组合推理 TangramPuzzle, TableVision 与 ProVisE 同属空间推理评测，但均只针对 VLMs；ProVisE 首次覆盖图像生成模型
多模态统一生成 Emu3, PixArt-σ, Show-o 这些是多模态生成模型，ProVisE 是评测框架，互补而非竞争

相关背景知识补充： - SpatialGen（与本文无直接作者关联）是浙江大学 Multi-View Multi-Modal 扩散模型，做「布局引导的 3D 室内场景生成」，发布于 ECCV 2026，与 SpatialGen-Bench 为同期工作但独立 - SpatialBench 是本文引用的同类评测工作，同样来自 2026 年，两者在任务层面互补（VLM only vs. VLM + 图像生成）

适合谁读

  • VLM / 视觉生成模型研究者：必读，了解如何系统评测空间智能，尤其是跨模态统一评测的设计方法
  • Agent 构建者：关注「感知 + 推理分工」的多 Agent 协作设计；ProVisE 揭示了生成模型与 VLMs 的能力边界
  • Benchmark 设计者：Agentic Builder 的自动化协议构建流程值得借鉴
  • 机器人/AR 交互研究者：若应用场景涉及空间定位、路径标记，ProVisE 的 pixel-space 答案形式更接近真实交互模态
  • 多模态评测标准化推动者：ProVisE 提供了一个「benchmark-agnostic + 协议兼容」的评测框架思路，值得在视频、3D 等其他模态上推广

信息来源

  • arXiv 摘要页：https://arxiv.org/abs/2607.21072
  • arXiv HTML 全文页：https://arxiv.org/html/2607.21072v1
  • 作者项目页：https://zju-omniai.github.io/ProVisE/
  • 论文卡（/shared/research-kb/organized/paper_cards/565-2607-21072.md）
  • 相关搜索：SpatialBench (Semantic Scholar), SpatialGenEval (OpenReview), SpatialGen (Manycore Research), Awesome-Spatial-Intelligence-in-VLM (GitHub)

不确定处（原文未明确）： - 具体各模型（名称、版本、参数量）在 SpatialGen-Bench 各子任务上的精确分数 - Agentic Builder 生成的协议在外部 benchmark 上的解析成功率具体数值 - Parser 模块的架构设计细节（是否基于某个特定 VLM 或专用网络） - 470 样本的构建方式（人工标注 / 自动生成 / 已有数据集筛选）

工程落地与核查（Jay）

事实核查摘要

经对照 arXiv 摘要原文（2607.21072）核查： - ✅ SpatialGen-Bench = 470 样本 / 14 空间子任务 / 4 能力等级（原文一致） - ✅ Agentic Builder 在 6 个外部 benchmark 上验证（原文一致） - ✅ 核心结论「像素可外部化时生成模型有竞争力，组合推理弱于 VLM」（原文一致） - ⚠️ 解读中「发现部分超越 VLM」属摘要"competitive"的合理引申，但原文未给出具体超越哪个模型或哪些任务，留有余地 - ⚠️ 解析协议示例（Step 1-3 的具体格式描述）为解读作者根据框架推断，非论文原文直接陈述，标注清楚

工程落地分析

1. Parser 是整条评测链路的单点故障

ProVisE 的评分精度直接由 Parser 决定，而 Parser 本质上是一个图像处理模块（峰值检测、连通分量、骨架提取等）。在工程实现中，这意味着：

  • Parser 对噪声、遮挡、低对比度图像的鲁棒性直接决定评分可信度
  • 不同任务类型需要不同的 Parser 实现——点检测 vs. mask 解析 vs. 路径骨架提取，是三套完全不同的视觉算法
  • 建议：如果要在生产环境使用 ProVisE，Parser 应作为独立模块做专项评测，并建立对抗样本集（如故意在图像中加干扰标记）

2. 像素答案的尺度敏感性问题

图像生成模型输出答案图时，标记的尺度（点大小、线宽、mask 边缘精度）会显著影响 Parser 的解析结果。目前论文未充分讨论这一敏感性。

落地坑点： - 如果生成模型输出的「点」过小，Parser 的局部峰值检测可能漏检 - 如果 mask 边缘模糊，连通分量算法得到的区域与实际语义区域偏差较大 - 解决思路：协议设计时需对输出尺度设约束（类似 VLM 输出的坐标范围约束），或者在 Parser 前加一个超分辨率/锐化预处理

3. Agentic Builder 的实际可用性存疑

Builder 自动生成协议听起来很美，但在工程实践中： - 新 benchmark 的 metric 定义往往不是机器可解析的格式（通常是文本描述或公式），Builder 需要先做 metric parsing，这一步的鲁棒性未经充分验证 - 候选协议的搜索空间可能很大，自动验证的 compute cost 不容忽视（每个候选协议都要在 benchmark 上跑一遍） - 建议先用固定协议集做基线，Builder 作为协议设计的辅助工具而非全自动替代

4. 实际部署的端到端延迟

如果用 ProVisE 做在线评测（比如在机器人控制循环中实时评测空间能力），整个 pipeline 的延迟值得关注：

当前帧图像 → 生成模型（~数百毫秒）→ 答案图 → Parser（~数十毫秒）→ 评分

其中生成模型是延迟大头，比直接让 VLM 输出文字/坐标慢 1-2 个数量级。如果评测是离线 batch 模式则无影响；在线场景需特别注意。

5. 真实机器人系统集成建议

论文已验证 sim-to-real，但具身场景的工程细节值得补充：

  • 相机规格（前向单目）：论文明确，在实际部署时应确认相机内参与协议中预设的像素坐标系是否对齐
  • 生成答案图时，模型是对原始输入图像做 inpainting，还是额外输出一个独立的 answer overlay？后者更容易与下游控制解耦，前者则对原图有侵入性
  • 若目标被遮挡，pixel-space 的「画答案」操作可能在当前帧无法完成，协议需要规定这种情况的 fallback 行为

6. 评测公平性问题（工程师视角的注意事项）

解读中提到 ProVisE 实现了「公平比较」，但实际上两种模型的答案转换路径不对称：

  • Text-output VLM：文字/坐标 → 直接 metric
  • 图像生成模型：像素答案 → Parser → 结构化预测 → metric

Parser 本身带来的系统性误差可能让 VLM 天然占优（因为 VLM 的输出链更短）。解读中未提及这一不对称性，工程复现时需注意控制 baseline——比如用一个「理想 Parser」（Oracle）跑一遍，看实际 gap 有多少是来自 Parser 误差而非模型本身的能力差异。