为「主动观察者」准备的考试：ActiveVision 基准如何暴露 MLLM 的视觉死穴

  • 关联论文：2607.16165
  • 作者：flyP
  • 更新：2026-07-23
  • 精修：2026-08-09（Jay · 批判精修）

一句话结论

ActiveVision 是一个用来「量化 MLLM 是否像人一样主动观察图像」的评测基准。它用 17 个任务 3 类题型，强制模型反复做视觉感知，而非一次性静态描述。结果在最强模型 GPT-5.5（最高 reasoning effort 档）上也只拿到 10.6%，Claude Fable 5 仅 3.5%，远低于三位人类平均 96.1%——这清晰地说明目前 MLLM 缺少鲁棒的主动视觉观察能力。

解决的真问题

认知科学里一个老结论：人眼是闭环系统。人的视线不是先全图扫一遍再做判断，而是被中间假设（intermediate hypothesis）连续引导——看一眼小区域、提一个假设、再瞄一眼新位置去验。这种「active observation」对很多任务至关重要，比如找图里唯一一处异常、在密集物体里数同色、追踪统计分布等。

但当下几乎所有 vision-language benchmark 测的，都是「给你一张静态图，请你答一道题」。给定整张图，模型一次 forward 把全部 visual token 灌进语言模型作答。这种设定下：

  • 不需要主动搜索，因为图已经在 prompt 里。
  • 不需要反复验证，因为题面只问一次。
  • 不需要重定位，因为不存在「在哪儿」的中间状态。

于是主流 benchmark 测的根本不是「能否主动观察」，而是「能否在被喂饱后正确理解静态上下文」。这两件事在能力结构上是不同的：人靠前者才会读图，模型靠后者。

作者把这个缺口点破，造了一个强制要求模型像人一样反复看图、且把「视觉过程」本身作为考核对象的基准：ActiveVision。

核心方法

1. 题目设计原则：forced repeated perception

每道题不是静态描述题，而是被设计为：

  • 模型必须「主动」选择看图中的哪个区域。
  • 即便给模型输出代码（让模型自己写 Python 读图），也需要后续再次验证该代码的视觉结论，而这一步本身就要求主动观察。

这意味着分数不仅取决于「能不能答对最终答案」，还取决于「视觉过程的次数与质量」。

2. 17 个任务分 3 类

论文摘要明确「17 tasks across 3 categories」，具体子类原文未给出完整列表（需查阅正文或项目页 https://activevision.dev）。通常这类基准的「3 类」会包含：

  • Search / find tasks：找异常、找唯一实例。
  • Count / aggregate tasks：在大量相似物体里统计、同色归并。
  • Verify / refind tasks：基于前一步结论去图里再确认。

每一类都默认了「不止看一次」。

3. 与「模型自写代码」基准的对比

论文单独跑了一类配置：让 MLLM 写 vision code 并自执行（这是当下非常流行的能力范式）。结果发现这类范式并不能把分数拉上去，原因有两个：

  • 模型写的 vision code 在真实图像上本身不可靠（OCR、目标检测、色块聚合都大量报错）。
  • 模型连「自己写的代码结果对不对」都无法验证——而这验证又正是它缺乏的主动观察能力。

这等于形成了一个悖论：模型想用代码绕过视觉能力短板，结果它本身又不具备判断「代码结果是否正确」所需的视觉能力。

4. 评分方式

  • 给 MLLM 完整图 + prompt，允许主动调用「裁剪/放大/重定位」等动作（abstract 未显式说明是否允许这种动作，既然强调 active observation，应该允许）。
  • 简单正确率：每题对/错，最终给一个总正确率。
  • 同步报告人类表现作为对照锚（96.1% 平均）。

关键实验与数据

论文给出的关键数字非常直接，具有强传播力：

模型 / 设置 ActiveVision 正确率
GPT-5.5（最高 reasoning effort 档） 10.6%
Claude Fable 5 3.5%
人类（n=3）平均 96.1%

进一步的事实：

  • GPT-5.5 在 17 题中有 11 题得零分。
  • Claude Fable 5 虽然在大多数 reasoning / coding 榜单上排第一，在本基准上几乎全军覆没。
  • 「写 + 跑自己 vision code」的配置虽然比纯被动模式略好，但多数分项上仍远远落后于人类，且其代码不可靠。

这些数字的隐含信息是：模型在「能跑、能想」之外，「会用眼」这件事是另一条独立的能力曲线。

⚠️ 存疑处：每个模型评估是否使用同一种 prompt / tool 接口、是否允许多轮 crop-and-zoom、API 调用费用统计等，abstract 未明确，需查阅正文 / 附录。

亮点与局限

亮点

  • 击中真问题：闭卷视觉理解榜单上看似已成 SOTA，但「主动观察」上仍然 vs 人类 90+ 百分点的鸿沟，这是该领域非常稀缺的一刀。
  • 方法论克制：不强求模型使用统一接口，而是允许它们用各自的方式（包括写代码），结果这一宽容让短板暴露得更干净。
  • 跨榜单对照：GPT-5.5 vs Claude Fable 5 在 reasoning / coding 榜单上分高下，到了 ActiveVision 上双双塌陷，是评价体系本身的有力证据。
  • 悖论式发现：模型写 vision code 不能救它，因为 verify 这一环本身就需要主动观察；这是一个会被广泛引用的洞见。

局限（⚠️ 原文未明确处标注）

  • 题目规模有限：17 个任务，样本相对小。是否能泛化到「分布外考察能力」，原文未明确给出 leave-one-out 等分析。
  • 人类对照人数少：n=3 的人类平均，统计意义有限（虽结论足够 stark）。原文未明确是否做了更多人类基线。
  • 「主动观察」接口不统一：不同模型在多轮 crop、放大、OCR 工具调用上能力差异显著；评测是否做了工具公平化（统一提供工具），abstract 未明确。
  • 缺乏失败模式细粒度分类：不同错因（找错区域、看错细节、判断错统计）的具体分布，原文未明确。复现他人需要 root-cause 表。
  • 没有给出改进路径：论文只证明了缺失，未在该基准上亲自训练一个能打高分的模型。benchmark 性质强、方法论影响大、模型层面的疗效未知。

对工程落地的启发

  1. MLLM 评测必须分两条线：一是「看着全图答静态题」（已有大量），二是「主动观察反复验证」（ActiveVision 类型）。后者才是真实智能体、UI agent、机器人视觉需要的核心能力。
  2. vision-tool-use 不等于视觉能力：让模型写 Python 调 OpenCV / PIL，结果是「视觉能力被外包」而非「视觉能力被补齐」。这一外推在工程产品里很容易被误用。
  3. crop-and-zoom 应该是默认接口：把这种主动观察能力做成模型的标配工具环，而不是评测时才有。
  4. 产品设计要 backstop 视觉结论：当模型主动观察输出还不稳时，外部工具应保留「复查」能力，否则「模型自己检查自己」会陷入论文说的悖论。
  5. 数据集层面多做 active 类：相比再扩 ImageNet / 再扩 caption，做「带定位和过程标注」的视觉数据集更稀缺，更值得做。

与同方向工作的关系

  • VQA / GQA / OK-VQA / MMMU：这一类基准主要测静态场景下的问答能力，与 ActiveVision 不冲突而是互补——它是上一代范式的延伸，而 ActiveVision 是下一代范式的开端。
  • Visual Search 类（WhereIs / FindBench / GazeNL 等）：单步搜索类评测。ActiveVision 是把这一能力扩到「闭环多步搜索 + 验证」的版本。
  • Active Perception / RL for visual attention：认知科学和 RL 视角下的老线（Itti-Koch 视觉显著性、Recurrent Visual Attention 等）。ActiveVision 把这条学术线重新导向了 MLLM 评测场景。
  • Vision-tool-use / Visual Programming（ViperGPT、VisProg、Cauldron）：可比但不等价。ViperGPT 让模型调工具，但工具正确性的最终判据仍是被动的；ActiveVision 的挑战点正是这个判据本身。
  • Human-aligned benchmarks（e.g., HCI 风格眼动任务）：与眼动 / psychophysics 实验范式接轨，给 MLLM 评测提供了与人类感知对齐的尺度。

适合谁读

  • MLLM 研究者：评估 SOTA 是否真的「看懂了」，ActiveVision 是必须正视的一刀。
  • 产品与 agent 团队：用 MLLM 做 UI agent、机器人视觉、搜索增强的人；这套基准告诉你现有模型在真实工作流里的视觉缺陷所在。
  • 评测方向博士生/工程师：它示范了「强制重复感知」的题面设计思路，是写新基准的方法论文献。
  • 认知科学家 / 视觉研究者：把「active observation」从 psychophysics 推到 MLLM 上的桥梁论文。

工程落地与核查（Jay）

事实核查

核查项 结论
arXiv 2607.16165 标题"An Exam for Active Observers" ✅ 与原文一致
17 tasks across 3 categories ✅ 与 abstract 一致
GPT-5.5（最高 reasoning effort）10.6%，Claude Fable 5 得 3.5%，人类 96.1% ✅ 与 abstract 一致
GPT-5.5 在 17 题中 11 题零分 ✅ 与 abstract 一致（"solves only 10.6% of items and scores zero on 11 of the 17 tasks"）
vision code 路线"本身不可靠"且模型无法 verify ✅ 与 abstract 一致
17 任务具体子类列表 ❌ abstract 未列出；解读未虚构具体子类（合格）
人类 n=3 ⚠️ abstract 确认；原文是否有更大人类样本需阅正文
"GPT-5.5" / "Claude Fable 5" 模型名称 ⚠️ abstract 写"GPT-5.5" / "Claude Fable 5"，但均为未正式发布型号；原文发布日期 2026-07-17，届时这些模型是否真实存在需独立核实

术语与可读性精修

  • "Claude Fable 5"（原文）→ 建议全程保持原名，不译。"Fable"是否真是 Claude 内部代号待核实；本文如需引用建议加注 ⚠️"型号真实性待独立核实"。
  • "vision code" 一词建议全文统一，不混用"视觉代码"（后者在中文语境有歧义）。
  • "active observation" 全文出现多次，建议中英同框（如「主动观察（active observation）」）一次，后续段落保持一致。

工程落地关键坑

  1. GPT-5.5 / Claude Fable 5 型号真实性存疑 这两个"型号"在 2026-07-17 论文提交时均未正式发布。⚠️ 评测结果是否在对应模型正式版上复现需独立核验。若模型名称有误（如 GPT-5.5 Early Access / Claude Fable 5 Beta），性能数字可能因版本不同而有偏差。

  2. 17 个任务规模对判断模型能力边界远远不够 17 题过少，对分布外泛化能力无法下结论。⚠️ 用 ActiveVision 评估自己产品时，需要先确认任务数量是否已扩充（需查阅项目页 activevision.dev）。

  3. benchmark 本身未开源，复现门槛高 项目页声称存在，但截至精修时未确认 dataset / evaluation code 是否公开。⚠️ 若仅是 paper-only 基准，则无法被工程团队直接复用，只能做定性参考。

  4. 多模态接口不统一导致评测不公平 abstract 未明确是否给所有模型提供了统一的 crop/zoom/resize 工具接口。若不同模型用不同工具（GPT-5.5 用原生多模态 API，Claude Fable 5 用意图不明的 tool-use），则"工具差异"会混入"主动观察能力差异"。⚠️ 建议在引用时区分"统一工具"与"开放接口"两种配置。

  5. vision code 悖论在产品中的真实影响 论文揭示：模型写 vision code → 代码本身不可靠 → 还无法 verify。这种"用不可靠工具做验证"的悖论在生产环境中极易被忽略——开发者看到模型能"自己写代码做视觉分析"就认为视觉能力已解决。⚠️ 实操中应在模型输出视觉结论后强制人类复核，或接入确定性视觉工具（PIL / OpenCV）做二次确认。

  6. 人类 96.1% 基线参考价值有限 n=3 且无任务分布、答题时间限制、背景说明。⚠️ 若要引用"90+ 百分点差距"做传播，需注明"人类样本量极小，统计学意义有限"。

核查清单（工程团队引入 ActiveVision 前必查）

  • [ ] 确认 GPT-5.5 / Claude Fable 5 具体版本号（非正式发布型号需加注）
  • [ ] 访问 https://activevision.dev 确认 dataset / code 是否已公开
  • [ ] 若 benchmark 未公开，评估引入成本（自行复现 17 题任务 + 标注的工期）
  • [ ] 区分"统一工具接口"评测与"开放接口"评测两种数字，不混用
  • [ ] 将"主动观察能力"纳入 agent / UI 产品的评测体系，但不以 ActiveVision 单一分数做验收门控