RBench-V: A Primary Assessment for Visual Reasoning Models with Multi-modal Outputs

Authors: Meng-Hao Guo, Xuanyu Chu, Qianrui Yang, Zhe-Han Mo, Yiqing Shen, Pei-Lin Li, Xinjie Lin, Jinnian Zhang, Xin-Sheng Chen, Yi Zhang, Kiyohiro Nakayama, Zhengyang Geng, Houwen Peng, Han Hu, Shi-Min Hu
Affiliations: Tsinghua University; Tencent Hunyuan X; Stanford University; Carnegie Mellon University
Year / Version: arXiv v2, 2025-05-23；论文页标注为 NeurIPS 2025 Datasets and Benchmarks Track 预印本
Code: https://github.com/CHEN-Xinsheng/VLMEvalKit_RBench-V
Code anchor: main@dd03fd1a (2025-05-24)
Dataset: https://huggingface.co/datasets/R-Bench/R-Bench-V

1. Motivation (研究动机)

1.1 为什么现有 VLM benchmark 不够

RBench-V 的出发点很直接：当前 VLM / omni-model 的能力正在从“看图后用文本回答”扩展到“在推理过程中产生、修改或使用视觉内容”，但主流评测仍主要围绕 multi-modal input + text-only output。MMLU 主要测试文本问题；MMMU 虽然引入多模态输入，但大多数题目仍把模型输出压缩为文本答案。对 GPT-4o、Gemini、o3 这类既能处理图像又能生成图像/视觉内容的系统来说，只检查最终文本答案，会遗漏一个关键能力：模型能否在思考过程中画图、连线、标注轨迹、构造辅助线，甚至通过修改图像来完成推理。

作者用 Feynman 的 “What I cannot create, I do not understand.” 做隐喻：人类解决几何、物理、迷宫、计数等问题时，经常不是在脑中只写一段文字，而是画辅助线、标出路径、画受力图、移动拼图或在混乱目标上做标记。这个过程本身就是 reasoning 的一部分。如果模型只能给出自然语言 CoT，却不能产生必要的视觉中间状态，那么它可能在“视觉不可绕过”的问题上暴露出完全不同的短板。

Figure 1 解读：论文把 RBench-V 放在 MMLU / MMMU 之外的位置。MMLU 关注纯文本输入输出，MMMU 强调多模态输入理解，而 RBench-V 的关键是：题目本身要求模型在解题过程中输出视觉操作，例如在图上连线、画出几何变换后的形状、追踪迷宫路径。图中红线不是原始题目的一部分，而是解题时必须产生的视觉推理痕迹。

1.2 论文要填补的评测空白

RBench-V 并不是提出一个新模型，而是提出一个 evaluation benchmark。它试图回答三个问题：

1. 现有 open-source / closed-source VLM 在需要 multi-modal outputs 的视觉推理题上到底能做到什么程度？
2. 单纯扩大模型规模、引入 omni-output 或延长 text-only CoT，是否足以解决这类任务？
3. 如果模型在数学题上看起来做得较好，这是否代表它真的掌握了 multi-modal reasoning，还是只是用代数化、文本化捷径绕开了视觉构造？

这组问题的价值在于把“最终答案正确率”和“推理过程是否需要视觉构造”拆开。模型可能在传统 benchmark 上表现很强，却在需要精确画轨迹、画自由体图、连接点阵、构造图形的任务上失败。RBench-V 通过强制题目依赖视觉中间产物，显式放大这个差异。

1.3 核心结论速览

论文最重要的数字是：在 arXiv v2 的主表中，human experts 达到 82.3% overall，而最佳模型 OpenAI o3 只有 25.8% overall；即便去掉更容易被代数化绕开的 Math 子集，o3 的 w/o Math 也只有 19.5%。Gemini 2.5 Pro-preview-0506 为 20.2% overall，Doubao-1.5-thinking-pro-m 为 17.1%，GPT-4o-20250327 为 14.1%。这说明当前模型的“强文本推理 + 强图像理解”并不自动等于“能在推理中产生精确视觉中间状态”。

2. Idea (核心思想)

2.1 “vision-indispensable reasoning”的定义

RBench-V 的核心概念可以概括为 vision-indispensable reasoning with multi-modal outputs：题目不是简单地给一张图让模型理解，而是要求模型在解题过程中生成或修改视觉内容；如果不做这种视觉构造，问题就很难或不自然地解决。这里的 output 不只指最终交付的图像，也包括 CoT 中的视觉中间步骤，例如：

• 在几何题中画辅助线、画旋转/平移/镜像后的图形；
• 在物理题中画光线路径、受力图、电路等效图、液面变化或力分布；
• 在 counting 题中标记已经数过的目标、连接线段形成图形、想象 3D 物体移动后的状态；
• 在 games 题中连接点阵、走迷宫、画飞镖/钩子/球的轨迹、移动拼图块。

这个定义把 benchmark 的中心从“输入模态是什么”转到“解题过程需要什么输出模态”。因此，RBench-V 可被看成对 multi-modal chain-of-thought (M-CoT) 的初步压力测试：模型不仅要说明思路，还要能通过视觉形式承载思路。

2.2 与 MMLU / MMMU 的对比逻辑

论文没有简单声称 RBench-V 比 MMLU / MMMU 更难，而是用一个 human/model preference-style comparison 来验证“RBench-V 更需要多模态输出”。作者从 RBench-V、MMLU、MMMU 各随机抽取 30 个样本，让 human experts 或模型（o3、Doubao-1.5-thinking-m）比较某个问题在思考过程中是否更需要 drawing / visual construction。

结果非常极端：

对比	评审方	RBench-V win	对方 win	Tie
RBench-V vs. MMLU	Model	92.4	3.8	3.8
RBench-V vs. MMLU	Human	86.4	4.5	9.1
RBench-V vs. MMMU	Model	94.1	5.9	0.0
RBench-V vs. MMMU	Human	83.4	6.6	10.0

这说明 RBench-V 的差异不是“又一个视觉问答数据集”，而是题目设计目标发生了变化：它要求推理过程中的视觉构造，而不是把视觉作为输入材料后再回到文本答案。

Figure 2 解读：示例图把 MMLU、MMMU、RBench-V 放在一起比较。RBench-V 的红线/图形是解题中新增的 visual work，而非题目原始信息。作者想强调：如果一个 benchmark 允许模型只读图并输出文字，那么它无法区分“能理解视觉输入”和“能通过视觉操作进行 reasoning”。

2.3 为什么数学结果容易误导

论文特别指出，Math 子集可能存在“multi-modal reasoning shortcuts”。例如几何题理论上可以通过画辅助线解决，但强模型也可能建立坐标系，把几何问题转为代数计算并直接输出文本答案。这种能力当然有价值，但它不一定证明模型掌握了人类式几何视觉推理。因此论文报告了 w/o Math，把 Physics / Counting / Games 聚合起来作为更能反映真实 multi-modal reasoning 的指标。这个设计很重要：如果只看 Math，o3 达到 48.3%，似乎很强；但去掉 Math 后只有 19.5%，说明很多优势来自可文本化或代数化的绕行路径。

3. Method (方法)

3.1 数据规模与字段

RBench-V 包含 803 道题，覆盖四个领域：Math 176、Physics 157、Counting 195、Games 275。题型上包括 356 道 multiple-choice 和 447 道 open-ended；输入上包括 40 道 text-only questions 和 763 道 multi-modal questions。Hugging Face 数据集卡中的字段为 catagory、question、image、answer，并提供 full / math / physics / game / counting splits。catagory 的拼写在数据卡中保留为原始字段名。

统计项	数量
Total Questions	803
Math	176
Physics	157
Counting	195
Games	275
MC Questions	356
Open Questions	447
Text-only Questions	40
Multi-modal Questions	763

论文强调这是早期探索，当前聚焦 text + image 两类模态；video / audio 等更复杂输出模态留给后续工作。

3.2 数据采集原则

构造 RBench-V 的总原则是：一个问题的解决过程应当需要创建新的视觉内容，或修改/标注已有图像。作者没有把“看图答题”直接纳入，而是筛选那些需要视觉中间步骤的问题。Math 和 Physics 部分由领域专家参与筛选；Counting 和 Games 则通过规则化方式创建、收集、过滤。这个原则避免 benchmark 退化成普通 VQA，也让它更接近 GUI 操作、绘图、路径规划、物理图示推导等现实场景。

3.3 四类任务的具体构成

Math 主要包括 transformation geometry、planar geometry、solid geometry 和 graph theory：

• Transformation Geometry：模型需要画出平移、反射、旋转后的结果图形，再据此回答；
• Planar Geometry：模型需要构造辅助线帮助推理；
• Solid Geometry：模型需要从 2D 组件按规则组装 3D 形体，并画出结果；
• Graph Theory：模型需要根据约束补全图、标记 leaf nodes，再做推理。

Physics 包含 optics、mechanics、electromagnetism、thermodynamics。它不是泛泛收集物理题，而是挑选那些必须视觉化的题目：光学题需要追踪反射、折射、衍射路径；力学题需要画受力图、运动轨迹和平衡关系；电磁题可能要求简化电路或画电/磁场线；热学题则涉及液面、流体受力、表面张力、静水压力、浮力等视觉变化。

Counting 被设计为避免“直接看图数清楚”的简单目标检测。论文列出三类：一类需要先根据描述画几何图形或连接图中线段，再数三角形等对象；一类是在混乱背景和大量目标中逐个标记已数对象；另一类依赖空间关系和想象，需要在脑中移动 3D 物体并可视化移动后的状态。

Games 包括 connect-the-dots、mazes、dart-and-balloon、Gold Miner、puzzles、ball-and-brick 等。它们的共同点是必须画出动作路径或状态变化：连接点阵才能识别图像；走迷宫必须追踪路径；飞镖和钩子题要画轨迹并判断是否击中目标；弹球题要考虑多次碰撞和反弹；拼图题要移动组件完成整体。

3.4 评测协议

论文默认采用 zero-shot evaluation。对 open-source models，作者使用 vLLM 和 VLMEvalKit 部署，temperature 设置为 0，其余参数保持默认，并在 8 x NVIDIA H20 GPUs 上运行。对 closed-source models，作者遵循官方 API 使用方式；若 API 允许设置 temperature，也设为 0。由于题目同时包含 multiple-choice 和 open-ended，论文使用统一的 LLM-as-a-Judge 框架，judge model 为 GPT-4o，报告 Top-1 accuracy。

这个评测协议的关键点是：模型被要求产生解题过程和最终答案，但最终统计仍落在可比较的 Top-1 correctness 上。因此 RBench-V 同时有两层含义：数据设计层面要求 visual thinking / multi-modal output；评分层面则用 GPT-4o judge 将输出归一为正确/错误。这个设计让 benchmark 易于大规模比较，但也带来一个限制：视觉中间过程本身的质量未必被完全结构化评分。

3.5 评测流程伪代码

# Evaluation logic reconstructed from paper + VLMEvalKit_RBench-V code.
for sample in RBench_V:
    image = sample["image"]
    question = sample["question"]
    answer = sample["answer"]
 
    prompt = build_prompt(
        image=image,
        question=question,
        final_answer_format="\\boxed{...}"
    )
    prediction = model.generate(prompt, temperature=0)
 
    extracted_answer = gpt4o_extract_final_answer(prediction)
    score = gpt4o_score(
        question=question,
        ground_truth=answer,
        model_answer=extracted_answer
    )
 
accuracy = mean(score == "correct")

3.6 代码实现锚点与映射

Code anchor: main@dd03fd1a (2025-05-24)；仓库为 CHEN-Xinsheng/VLMEvalKit_RBench-V，基于 open-compass/VLMEvalKit。

代码位置	作用	与论文的对应关系
vlmeval/dataset/rbench_v.py	定义 RBench_V(ImageBaseDataset)；TYPE = 'VQA'；DATASET_URL = {'RBench_V': 'datasets/RBench-V.tsv'}	把论文数据集接入 VLMEvalKit 的 image QA pipeline
RBench_V.build_prompt()	读取样本中的 image/question，dump image，并追加最终答案必须使用 \boxed{...} 的指令	规范不同模型输出，方便后续抽取 final answer
RBench_V.evaluate()	对模型输出进行 stage-1 answer extraction 与 stage-2 scoring；默认使用 api_openai_chatgpt-4o-latest 的 InternalAPI，代码中 API key 位置为 MY_API_KEY placeholder	对应论文“统一 LLM-as-a-Judge，judge model 为 GPT-4o”的评测设定
run.py	暴露 --data RBench_V、--model、--api-nproc、--mode all/infer、--reuse、--judge 等参数	对应复现实验入口；README 示例为 python run.py --model <MODEL_NAME> --data RBench_V --api-nproc ... --verbose
datasets/RBench-V.tsv	本地 TSV 数据文件路径	对应 803 题的 benchmark 数据落盘格式

这个代码版本的一个可复现实用点是它继承 VLMEvalKit，所以已有模型适配、并行 API 调用、输出缓存和结果表格都可复用。一个需要注意的点是 judge API 在代码中写成 api_openai_chatgpt-4o-latest，并且 README 提醒需要把 API key 配到代码中；因此严格复现实验时应记录 judge model 的实际服务版本和调用日期，否则后续 chatgpt-4o-latest 变化可能导致分数轻微漂移。

4. Experimental Setup and Results (实验设置与结果)

4.1 主结果：模型与人类仍有巨大差距

Figure 3 解读：performance highlight 展示了 open-source models、closed-source models 与 human experts 的整体差距；它对应论文主表中 o3 25.8% vs. human 82.3% 的核心结论。

论文主表显示，人类专家在整体上达到 82.3%，其中 Math 84.7%、Physics 69.4%、Counting 81.0%、Games 89.1%。相比之下，模型分数明显偏低：

Model	Overall	w/o Math	Math	Physics	Counting	Games
Human Experts	82.3	81.7	84.7	69.4	81.0	89.1
OpenAI o3	25.8	19.5	48.3	20.4	22.1	17.1
OpenAI o4-mini	20.9	14.6	43.2	12.7	17.4	13.8
Gemini 2.5 pro-preview-0506	20.2	13.9	42.6	9.6	19.0	12.7
Doubao-1.5-thinking-pro-m	17.1	11.0	38.6	13.4	9.7	10.5
GPT-4o-20250327	14.1	11.2	24.4	3.2	13.3	14.2
Qwen2.5VL-72B	10.6	9.2	15.3	3.8	6.2	14.5
Qwen2.5VL-7B	8.3	7.0	13.1	2.5	3.6	12.0

最大结论不是某个模型领先多少，而是所有模型都远低于人类。尤其是 Games 和 Counting 这类很难用文本捷径绕开的任务，模型成绩更能暴露问题：o3 在 Games 只有 17.1%，Counting 22.1%；Gemini 2.5 Pro 在 Games 12.7%，Counting 19.0%。这些题要求精确路径、连接、标记和空间操作，恰好是 text-only CoT 不擅长承载的内容。

4.2 scaling 并不能自动解决 multi-modal output reasoning

作者比较了同系列不同规模模型：Qwen2.5VL 从 7B 到 72B，overall 从 8.3% 到 10.6%，提升很有限；InternVL-3 的 8B / 14B / 38B 也在 8.0–10.0% 之间波动；LLaVA-OneVision-7B 为 8.5%，72B 为 9.0%。论文据此提出：如果模型缺少 M-CoT 或能真正写入/修改视觉状态的机制，单纯参数 scaling 可能无法跨过这个 benchmark 的核心瓶颈。

这个发现与普通 VLM benchmark 上“更大通常更好”的直觉不同。RBench-V 的错误往往不是语义知识不足，而是模型没有把“画出来并根据图继续推理”作为可执行过程。例如迷宫题需要逐格追踪路径，球反弹题需要准确画反射轨迹，物理题需要把力和场线落在图上；这些都不是靠更多文本 token 就稳定解决的。

4.3 omni-model 和 long text-only CoT 的收益也有限

论文还比较了 omni-model 与普通 VLM：Qwen2.5-Omni-7B 为 7.7%，低于 Qwen2.5VL-7B 的 8.3%；MiniCPM-2.6-o 为 9.7%，仅略高于 MiniCPM-2.6-V 的 9.1%。这说明“输出解码阶段支持图像”并不等价于“具备可用于推理的精确视觉工作区”。如果生成图像只是语言后接图像，而不是把图像作为可读写的 reasoning state，那么它仍然可能不能解决这类任务。

Long text-only thinking models 的提升也有限。Doubao-1.5-thinking-pro-m (17.1%) 强于 Doubao-1.5-vision-pro (15.6%)，o3 (25.8%) 明显领先，但距离人类仍远。论文因此倾向于认为未来需要新的范式，例如真正的 M-CoT、agent-based reasoning、可变视觉画布、工具调用式绘图与验证循环，而不是只让模型输出更长文字解释。

4.4 案例分析：模型会用文本/代数捷径，而不是人类式画图

Figure 4 解读：error comparison 展示了同一强模型在“可被代数化的几何题”和“必须连线的游戏题”上的差异。

论文展示了 o3 的两个代表案例。左侧 Math case 中，o3 能答对，但它采用的是建立 coordinate system、把几何问题代数化的方法；人类专家更常用几何辅助线。这说明数学高分可能来自强大的符号/代数能力，而不是视觉构造能力。右侧 Games case 中，o3 失败的关键是没有按要求把点连接起来，而是试图描述点的位置或关系；它没有真正执行题目要求的视觉操作。

这个现象解释了为什么论文强调 w/o Math。Math 子集中的很多题可以被文本化或代数化绕过，但 Counting / Games 更依赖实际标记、连接和路径追踪，难以用纯语言替代。因此，w/o Math 更像是对“视觉不可绕过”能力的压力测试。

4.5 项目页后续 leaderboard 与论文表的关系

项目主页在论文后继续更新 leaderboard，例如后续出现 DreamPRM-1.5 (GPT-5-mini)、GPT-5-mini 等条目；这类条目不属于 arXiv v2 主实验。阅读论文时应以 arXiv v2 的表格为准；看当前 benchmark 进展时可以参考项目页 leaderboard。这个区分对复现实验尤其重要，因为 benchmark 的 public leaderboard 会随模型和策略更新而变化。

5. Discussion / Limitations (讨论与局限)

5.1 贡献总结

RBench-V 的主要贡献有三点。第一，它把 VLM evaluation 的关注点从 multi-modal input 推到 multi-modal output，明确提出“推理过程中能否画/改/标注”这一能力维度。第二，它构建了 803 道跨 Math、Physics、Counting、Games 的题目，并用 MMLU / MMMU 对比验证其确实更需要 visual construction。第三，它系统评估 open-source、closed-source、omni、thinking models 和 human experts，显示当前最强模型与人类仍有大差距。

5.2 局限一：评分仍然依赖 LLM-as-a-Judge

RBench-V 的题目设计强调视觉中间过程，但最终评分采用 GPT-4o judge 抽取和判定答案。这让 benchmark 易于运行，但也意味着视觉过程质量没有完全被结构化度量。一个模型可能画错但文本答案碰巧正确，或者视觉过程有价值但 final answer 格式不符合要求。未来更理想的评测可能需要把 visual trace 本身作为可验证对象，例如检测连接线是否经过正确节点、轨迹是否满足反射定律、辅助线是否符合几何约束。

5.3 局限二：Math 子集存在可绕行路径

论文自己也承认，数学题尤其是几何题可以被 algebraic shortcut 绕开。这个问题并不削弱 RBench-V 的价值，反而说明 benchmark 内部需要分层解释：overall 分数衡量广义表现，w/o Math 更接近视觉不可绕过能力。若未来要进一步强化 benchmark，可以增加更多无法通过代数化转写解决的几何/图论任务，或把解题过程中产生的图形纳入强制评分。

5.4 局限三：当前只覆盖 text + image output

论文明确说明这是 early exploration，当前聚焦 text 和 image。真实 multi-modal output reasoning 还包括 video、audio、3D、GUI 操作、机器人动作等更复杂输出。RBench-V 的 conceptual contribution 可以迁移到这些方向，但数据集本身还不能覆盖。例如动态物理推理可能需要视频轨迹输出；交互式任务可能需要模型在多步环境中画、点、拖动、验证，而不是一次性生成答案。

5.5 局限四：复现受 judge 和代码细节影响

代码公开在 VLMEvalKit fork 中，便于运行，但 rbench_v.py 默认 judge marker 为 api_openai_chatgpt-4o-latest，API key 用 MY_API_KEY placeholder。由于 latest 服务可能随时间更新，严格复现实验应记录 judge 后端、调用日期、temperature、并行数和是否复用缓存。对 open-ended 题而言，judge 漂移会比 multiple-choice 更敏感。

5.6 对后续研究的启发

RBench-V 对模型设计提出的启发是：仅靠 language CoT 或更大的 VLM backbone 可能不够，模型需要一个可读写的视觉工作区。可行方向包括：

• M-CoT / Canvas-of-Thought：让模型在中间状态中显式创建图形、连线、标注、擦除和修改；
• Tool-augmented visual reasoning：把绘图、几何验证、路径搜索、物理仿真交给工具，模型负责规划和检查；
• Verifier / PRM for visual traces：不只奖励最终答案，还奖励中间视觉状态是否满足约束；
• Agentic loop：模型先画，再读取自己画出的状态，发现错误后迭代修正。

从评价角度看，RBench-V 更像一个“诊断性 benchmark”而非只用于排名的 leaderboard。它告诉我们：当前 VLM 的瓶颈不一定在看图，也不一定在长文本推理，而是在把视觉状态当作可操作、可验证、可迭代的 reasoning medium。