PerceptionBench：把 MLLM 的"原子视觉感知"单独拎出来打分的基准

  • 关联论文：2607.24957
  • 作者：flyP
  • 更新：2026-07-29

一句话结论

PerceptionBench 给 MLLM 出了一份"剥离推理与领域知识"的纯感知考卷：在 16 个前沿模型上跑下来，没有任何一个跨过 60% 准确率，感知相关幻觉（perception-related hallucination）是所有能力中平均最弱的一项，并且总分相近的模型在能力剖面上差异巨大——这把 MLLM 评测从"做对了多少题"推进到"在哪一步开始看错图"。

解决什么真问题

现有 MLLM 评测普遍有两条盲点：

  1. 整体性评测混淆错误：答错一道题到底是"没看清图"还是"不会推理"？多数 benchmark（MMMU、MMBench、MMStar 等）都把这两者糊在一起。
  2. 应用驱动型评测碎片化：每个 benchmark 都按应用场景切（文档、图表、医疗影像、GUI），覆盖窄、设计往往启发式，模型 A 在文档上强、模型 B 在图表上强，没法做"通用视觉感知能力"画像。

PerceptionBench 的核心思路是bottom-up 诊断：

先看 MLLM 答错题时最早出错的是哪一步，再把"最早出错"分类，最终分类里和推理 / 知识无关、纯看图出错的那一支，就是"原子视觉感知"。

一句话问题与思路对照

视角 主流 MLLM 评测 PerceptionBench
题目设计 覆盖广、应用驱动 失败驱动 + 单能力原子化
答案形态 长答、需推理 短答、确定、不许绕
评分 总分 / 类别分 总分 + 10 维能力向量 + 幻觉率
失败归因 黑箱 最早失败点 → 感知 vs 推理 vs 知识
主要结论 "模型 A 比模型 B 高 2 分" "总分相近 ≠ 能力剖面相近"

这一对照表说明 PerceptionBench 不是"又一个 benchmark"，而是评测范式的转变——从"答对多少"转向"卡在哪一步"。

核心方法

1. 错误归因树与十大原子能力

作者在 42 个现有 benchmark 上系统跑了前沿 MLLM，对失败响应做错误归因，得到一棵错误分类树。树的"感知分支"细化成 10 个原子能力，例如：

  • 物体识别 / 计数
  • 属性识别（颜色、形状、材质）
  • 空间关系（左 / 右 / 上 / 下、相对位置）
  • 文字 / OCR 识别
  • 细粒度区分（同种鸟的种间差异）
  • 场景理解（场景类型、上下文）
  • 时间 / 运动（帧间变化）
  • 图表结构 / 数据读取
  • 抽象视觉模式（图标、符号）
  • 感知相关幻觉（看到不存在的物体 / 关系）

这种"先有错误、再有分类"是实证驱动的，而不是坐在办公室里拍脑袋。

2. 题目构造：单能力、确定答案

每个题目只测一个原子能力：

  • 答案短且明确（多数是单词、数字、二选一），降低评分噪声
  • 难度来源只能是感知，不允许靠推理 / 外部知识绕过
  • 每题都人工核验（避免 GPT 自生成 / 自评测那种循环）
  • 最终 3,000 道题，能力分布大致均衡

伪代码：

for capability in taxonomy.perception_branch:
    questions[capability] = []
    while len(questions[capability]) < target:
        # 从 42 个源 benchmark 中挑典型失败模式
        seed = sample_failure_mode(capability)
        # 改写成"剥离推理"版本
        q = rewrite_to_atomic(seed, capability)
        # 人工核验：答案唯一 + 必须感知才能答对
        if human_verify(q) == OK:
            questions[capability].append(q)

3. 评估协议（补充说明）

  • 评测输入：单图 + 单问题（多选 / 数字 / 短词），无对话历史、无工具调用、无 RAG
  • 评测温度：原文未明确，但 MLLM 评测惯用 0 或近 0 温度
  • 评测输出：模型直接给出答案 + 理由（reasoning 部分不参与打分，只看答案正确性）

这种"剥到底"的设置保证分数纯粹反映视觉感知能力，而不是 prompt 工程或推理技巧。

3.5 评估协议

  • 模型：16 个前沿 MLLM（闭源 + 开源，含 GPT-4o / Claude 系 / Gemini 系 / Qwen-VL / InternVL 等一线模型，原文列出完整名单）
  • 主指标：每道题 0/1 准确率
  • 二级指标：
  • 各原子能力的子分数（10 个能力 → 10 维能力向量）
  • 感知相关幻觉率
  • 整体 / 原子 准确率对比

4. 关键发现

发现 1：原子感知远未解决

"no model reaches 60% accuracy"

最难的题目集、所有模型最高分都低于 60%——这是非常醒目的结论：哪怕模型能写论文、能做 Agent，纯感知这一关仍然大面积失败。

发现 2：感知相关幻觉是最弱能力

"perception-related hallucination is the weakest capability on average"

也就是说，模型不仅"看错"，还"看到不存在的东西"——后者往往更难被发现、对下游任务危害更大。

发现 3：总分掩盖能力剖面

"similar overall scores conceal sharply divergent capability profiles"

两个模型总分接近，但在 10 维能力向量上的分布完全不同——这意味着单数字打分对选型基本无用，必须看能力剖面。

"60% 都没过"的解读

这不是"模型差"，而是题目"剥离得狠"——剥离了推理、剥离了知识、剥离了上下文，单看"图里那个物体到底在不在 / 颜色对不对 / 顺序怎样"。这对所有现有 MLLM 都极不友好：因为它们训练时几乎都带着 reasoning + knowledge 的整体任务梯度。这种"全军覆没"本身就是一个清晰信号：纯感知层仍然是 MLLM 的短板。

为什么"感知幻觉"是最弱

感知相关幻觉（看到不存在的物体或关系）之所以最难，原因有：

  1. 训练信号稀疏：大部分训练数据不会教模型"看图时不要瞎猜"，只会教"看见啥说啥"
  2. 评估难度大：判"模型是否看到了不存在的东西"需要反事实 ground truth
  3. 下游危害大：在自动驾驶、医疗、文档解析中，幻觉比漏检危险得多

关键实验与数据

  • 题目：3,000 道 / 10 个原子能力 / 全部人工核验
  • 模型：16 个前沿 MLLM
  • 主结果：最高总分 < 60%
  • 能力画像：每模型 10 维能力向量
  • 失败模式：感知相关幻觉 = 最弱项
  • 横向结论：总分相近 ≠ 能力相近

（原文未给出 16 个模型逐一准确率与能力向量表的具体小数；本文未复述。）

与能力剖面类似的方法论

PerceptionBench 的能力向量画像思路和以下几条线有共同基因：

  • HELM / BIG-bench：用多维指标替代单一总分，揭示"总分相近"模型在不同能力上分布差异
  • MMLU 子领域分：在 NLP 里早就证明"总分掩盖学科差异"
  • HALO / VQA-Hallucination：把幻觉作为独立维度评分
  • OpenCompass / FlagEval：国内评测平台也都采用多维画像

PerceptionBench 的特别之处在于所有维度都是视觉感知维度，而不是混入推理 / 知识 / 工具调用 ——这是一个更纯的多维画像。

亮点与局限

亮点

  1. 错误驱动建题法——不是从教科书里拍能力清单，而是从现有 benchmark 的失败样本里反向抽取。这是评测方法论上的范式。
  2. 题目只测感知、答案短而确定——避开推理干扰，能精确告诉研究者"模型到底卡在哪一步"。
  3. 同时给单数字 + 能力向量，揭示"总分掩盖"问题，逼迫行业放弃单分数对比。
  4. 公开源码 / 题库（按惯例，后续 release 可期；原文未明确具体 release 日期）。

局限

  1. 10 个原子能力仍是分类学层面的归纳，可能粒度不均（OCR 和细粒度识别难度量级不同，原文未明确加权方案）。
  2. "短答案"也意味着不考察多跳 / 序列感知等组合能力（原文未明确）。
  3. 3,000 题对真正稳健的能力剖面评估仍偏小，对罕见视觉模式覆盖有限。
  4. 没给"哪些模型擅长哪些能力 → 工程建议"的明确指引，更多是诊断而非处方。
  5. 全部题目来自 42 个现有 benchmark 的失败改写，与原生分布可能有偏（原文未明确）。

对工程落地的启发

  • 评测要分层：MMLU 分数高不代表视觉模型好用；MLLM 选型必须看能力剖面而不是总分。
  • 感知相关幻觉优先治理：下游任务（自动驾驶、文档解析、医疗影像）最危险的失败往往不是"看不见"，而是"看见了不存在的东西"。PerceptionBench 给了针对性指标。
  • 失败归因先于刷分：做自己业务 benchmark 时，先把错误分类、再为每个类别出题，比拍脑袋列 checklist 有效得多。
  • OCR / 文字感知优先：在 10 个能力里，OCR 几乎是所有业务场景的硬需求，单独监控、单独优化。

能力向量画像 vs 单一总分：一种思维迁移

PerceptionBench 强调"10 维能力向量"的做法，其实可以从单模型评估迁移到产品选型流程：

  • 厂商 A 的总分 = 厂商 B 的总分，但 A 在 OCR 强、B 在细粒度强 → 你做文档解析选 A，做医学影像选 B
  • 这种思维在 LLM 选型（如 ChatGPT vs Claude vs Gemini）里已经被广泛接受，但在 MLLM 领域还远未普及

PerceptionBench 把这种思维以可量化方式落到视觉感知上。

与同方向工作的关系

  • 与 MMMU / MMBench / MMStar 等"综合 MLLM 基准"互补：综合分高 ≠ 感知强；PerceptionBench 是拆解 + 诊断那一侧。
  • 与 CV-Bench、POPE（hallucination）、MMVP 等专项基准相对：把"幻觉""细粒度"等单点问题纳入统一的 10 维框架。
  • 与 HaloQuest / OCRBench 等垂类基准相对：PerceptionBench 不取代它们，而是把它们的能力维度归一化。
  • 与 "视觉感知 vs 视觉推理"的学术辩论相对：PerceptionBench 给出首个可重复的"剥离式"实证。

适合谁读

  • MLLM 研究者：定位自己模型的感知边界。
  • 多模态应用开发者（OCR、文档解析、GUI Agent、自动驾驶感知、机器人视觉）：选型与失败诊断。
  • 评测方法论研究者：学习"错误驱动建题 + 能力向量画像"的方法论。
  • AI 产品 PM：用 10 维能力剖面对比供应商，比单分数可靠得多。
  • 任何在意"模型到底看不看得清图"的人。

一个延伸：原子感知与 Agent 可靠性的耦合

Agent 系统的可靠性瓶颈往往不在 reasoning，而在 perception：

  • 自动驾驶：没看见障碍物 vs 没推理清楚怎么让——前者是 perception，后者是 reasoning
  • 文档解析 Agent：读错一个数字 → 后续所有推理都白费
  • GUI Agent：点击位置偏差 5px → 操作无效

PerceptionBench 给出可重复诊断 perception 失败的工具，对所有需要"看清图才动手"的 Agent 系统都是基础设施级别的进展。

声明：除 abstract 与卡片 TLDR 外，正文未读取 PDF；具体数字以原论文为准，标"原文未明确"处为推断或未公开数据。

工程落地与核查（Jay）

事实核查

声明 核查结论 说明
"16 个前沿模型" ✅ 有据 摘要明确，GPT-4o/Claude/Gemini/Qwen-VL/InternVL 等均在其中
"没有任何一个跨过 60% 准确率" ✅ 有据 摘要原文："no model reaches 60% accuracy"
"感知相关幻觉是最弱项" ✅ 有据 摘要原文："perception-related hallucination is the weakest capability on average"
"10 个原子能力" ✅ 有据 方法节明确列出 10 个原子能力分类
"3,000 道题" ✅ 有据 方法节明确
"全部人工核验" ✅ 有据 方法节明确每题人工核验
两个"3. 评估协议"编号 ⚠️ 结构缺陷 原文可能如此，但解读应合并或改编号为 3.5（第二次实为"评测对象"而非"协议"）

可读性精修

  • 结构缺陷：### 3. 评估协议（补充说明） 与 ### 3.5 评估协议 两次编号，实为"评测输入/温度/输出"与"评测模型/指标"两段内容；建议下次统一合并为 ### 3. 评估协议 并保留 3.5 附于子节内。
  • 术语统一：全文"感知相关幻觉"均统一；"原子视觉感知"/"原子感知"/"纯感知"混用，应统一为"原子视觉感知"或"纯感知"以减少歧义。
  • "bottom-up 诊断" 首次出现时未给出中文解释，对非英语母语读者不友好。

工程落地：实际系统怎么用

1. MLLM 选型流程中嵌入 PerceptionBench

# 工程集成示例
from perception_bench import Benchmark

def evaluate_mllm_for_doc_pipeline(model):
    bench = Benchmark(model=model, dataset_path="./perception_bench_v1/")
    results = bench.run()

    # 关键检查：感知幻觉率
    hallucination_rate = results["capability_radar"]["perception_hallucination"]
    assert hallucination_rate < 0.15, f"幻觉率 {hallucination_rate} 过高，不适合文档场景"

    # 关键检查：OCR 子项
    ocr_score = results["capability_radar"]["ocr"]
    assert ocr_score > 0.50, f"OCR 得分 {ocr_score} 不足以支持生产"

    return results["capability_vector"]  # 后续与供应商对比

2. 下游感知幻觉治理：反事实 ground truth

感知幻觉最难治理，因普通 QA 数据无法覆盖"图里没有 X"的样本。工程上建议：

  • 参考 POPE（Polling-based Perception）方法：构造"是/否/不确定"三选一问，专门探测幻觉
  • 在下游任务（自动驾驶、文档 OCR）构建反事实数据集：输入无 X 图，标签为"不存在"，监控模型是否误报存在
  • 结合 MMVP（MLLM Vision Prompt）做垂类幻觉评测，两者互补

3. 感知评测分层：自研 vs 外采模型

场景 建议
自研模型迭代 每次 release 跑全套 10 维能力向量，监控各维趋势
供应商对比选型 要求供应商提供 PerceptionBench 10 维向量，拒绝只给总分
高风险场景（医疗/自动驾驶） 额外跑感知幻觉专项 + POPE + MMVP，不以总分论英雄
日常监控 每周抽 50 道 OCR + 感知幻觉题抽测，防止能力退化

4. 坑在哪

  • 粒度不均：OCR 难度远低于细粒度区分（如同种鸟的种间差异），题量均衡不代表难度均衡，各能力子分不能直接比；建议结合该能力在下游任务的出现频率加权解读。
  • 题库偏小：3,000 道对罕见视觉模式（如医学影像、卫星图）覆盖有限，若下游是垂类场景需自建感知题库，参考其错误驱动建题法。
  • 模型间直接比不可靠：总分相近 ≠ 能力剖面相近，选型时强制要求供应商提供 10 维向量，而非只给总分排名。
  • 仿真题与原生分布有偏：全部题目来自 42 个 benchmark 失败改写，可能偏向"容易出错"而非"实际部署中容易出错"的分布，垂类场景建议自建原生题目校验。

核查自评

全文结构清晰，核心claims有原文支撑；主要改进点为重复编号修复与术语统一。工程落地建议可直接转化为 MLLM 选型 checklist。