要在几个多模态模型之间做选择，PerceptionBench 更适合当成一张体检表，而不是排行榜：把参与对比的模型放进同一批题型，先只在感知类题目上比“图有没有读对”，再单独看多步推理题目，两个层次的分数分开记录、分开解读。这样做覆盖的维度会变窄，但换回来的是可复现、可解释的对比——每一分都能落回到具体题目和你自己的判分规则上。下面这套流程的前提是：你能拿到题库、能跑起候选模型、能把原始输出落盘保存，不依赖任何平台的官方榜单或宣传口径。

适用场景：正在几个多模态模型之间二选一或三选一，官方总体分数无法反映你的业务题型。操作动作：固定同一批题型和同一套判分规则，先单独统计感知类题目，再单独统计推理类题目。验证方式：抽一条结果，人工比对题面、模型回答、参考答案与判定结果是否一致。风险边界：题库覆盖不到的维度不参与比较，也不能据此下结论。

确定体检范围：只比同一批题型

对比不公平最常见的原因不是模型差异，而是题目集不同。开始跑之前，先把三件事写进一份范围说明，放在 run 目录里随结果一起归档。

• 参与对比的模型：列出模型名、接入方式（本地权重还是接口）、版本标识。同一轮对比里不要中途换版本，换了就另起一轮 run。
• 统一的题目子集：从题库里抽一个固定子集，给子集一个版本号（例如 subset_v1），每条题带稳定 id 和 category 字段（perception / reasoning）。子集一旦确定，本轮所有模型跑同一份文件，不因某个模型答得差而临时删题。
• 统一判分方式：明确是严格字符串匹配、规则校验，还是模型判分。三种方式口径不同，同一轮里只用一种，并在结果里记录用的是哪种。

同时要写明哪些维度不参与比较。如果子集里没有长文档理解、多图关系、工具调用、结构化输出这类题型，那么这些维度在本次体检里就是空白，不能因为某模型总分高就推断它在这些维度也更好。空白项要写进结论的前提条件，而不是省略。

准备可复现的运行环境

可复现的关键不是环境多干净，而是别人拿到你的目录后能知道当时装了什么、跑了什么。依赖用锁文件固定，Python 版本、推理框架版本、模型权重或接口版本标识都写进 README；推理参数（温度、最大输出长度、是否采样）写进配置文件，不要靠默认值蒙混过去。

建议的目录骨架如下，具体文件名可以按团队习惯调整，但“每次运行一个独立目录、原始输出与判定结果同放”这条不要改：

perception-bench-run/
├── configs/
│   ├── models.yaml        # 参与对比的模型列表与推理参数
│   └── judge.yaml         # 判分方式与匹配口径
├── data/
│   └── subset_v1.jsonl    # 统一题目子集：id / category / 题面 / 图片路径 / 参考答案
├── scripts/
│   ├── run_eval.py        # 逐题调用模型，写出原始回答
│   └── judge.py           # 读取原始回答，写出判定结果
├── runs/
│   └── run01/
│       ├── raw.jsonl      # 模型原始输出
│       ├── judged.jsonl   # 判定结果
│       └── notes.md       # 环境版本、参数、本轮范围说明
└── README.md              # Python 版本、依赖锁文件、模型版本标识

调用部分只给骨架，具体 SDK 方法和参数以所用模型的仓库文档为准，不要照抄网上的参数名：

# scripts/run_eval.py（骨架，call_model 需按实际接入方式实现）
import json, pathlib, yaml

cfg = yaml.safe_load(open("configs/models.yaml", encoding="utf-8"))
out_dir = pathlib.Path("runs/run01")
out_dir.mkdir(parents=True, exist_ok=True)

def call_model(model_cfg, item):
    """占位：按实际使用的接口实现，返回模型的纯文本回答"""
    raise NotImplementedError

with open("data/subset_v1.jsonl", encoding="utf-8") as fin, \
     open(out_dir / "raw.jsonl", "w", encoding="utf-8") as fout:
    for line in fin:
        item = json.loads(line)
        for m in cfg["models"]:
            ans = call_model(m, item)
            fout.write(json.dumps({
                "id": item["id"],
                "category": item["category"],
                "model": m["name"],
                "answer": ans,
            }, ensure_ascii=False) + "\n")

跑第一批并校验输出完整性

先跑一个小批次（比如十几条），确认链路通了再全量跑，比跑完几百条才发现字段缺失省事。结果文件至少要能回答四个问题：这是哪道题、哪个模型答的、模型说了什么、判定结果是什么。判定记录建议长这样：

{
  "id": "perc_0042",
  "category": "perception",
  "model": "model_a",
  "answer": "图中左侧仪表读数为 3.5",
  "judge": {"result": "wrong", "reason": "参考答案为 5.3，读取顺序看反"}
}

落盘后做一次手工核对：抽一条感知题，同时打开题面图片、模型原始回答、参考答案、判定结果，四者对得上，说明判分链可用；对不上，先修判分脚本，不要急着扩大样本。如果判分是交给模型做的，至少再各抽一条被判“正确”和一条被判“错误”的人工复核，因为模型判分的偏差通常集中在措辞接近但结论相反的答案上。

把感知类与推理类结果分开看

汇总时不要只出一个总分。按题型分两张统计口径相同的表，字段保持一致，方便横向对照：

解读规则可以按下面顺序走：先确认感知类题目是否达到你的下限，再去看推理类。感知题大量出错时，推理题的分数参考价值有限——题干信息没读对，后面的推理即使流程正确也建立在错误输入上，这类样本要在备注里单独标出来。反过来，感知题表现正常而推理题明显偏低，通常说明瓶颈在多步组织而非读图。

两类结果接近时，有几件事仍然不能下结论：不能得出“该模型感知与推理能力均衡”这种能力刻画，题型覆盖有限，均衡与否取决于你抽的题；不能因为两个模型总分接近就认为它们可以互换，错例分布可能完全不同；样本量很小时也不能外推到业务分布。能说的只是：在这个子集、这套判分口径下，两个模型的表现接近。

按实际使用场景做取舍

权重不该拍脑袋定，而应该从线上任务反推。做法是先列出手上真实的多模态任务清单，逐条标注“如果图读错了，这个任务是否直接失败”。读票据金额、读仪表、读界面状态这类任务，失败原因几乎都落在感知层，感知类题目就该占主要权重；而“对比两张图里哪张更符合要求”“根据图中信息多步判断”这类任务，感知是前置条件，推理类题目的权重要相应提高。清单按这个判断排序后，权重分配自然就有了依据，也不需要编造具体比例。

写选型结论时，把前提条件一并写上，缺一条结论就可能被误用：

• 题库与子集版本（例如 subset_v1）及题目数量；
• 参与对比的模型版本标识与推理参数；
• 本轮采用的判分方式，是规则匹配还是模型判分；
• 没有覆盖到、因此未参与比较的维度；
• 结论只在这批题型上成立，换题型需要重跑。

可以用的句式是：“在 subset_v1 的感知类题目上，model_a 的错例集中在读数顺序，model_b 集中在计数遗漏；若你的任务以读数为准，先选 model_a，但需要补一批计数题目再确认。”这种写法把取舍和验证动作一起交代了，比一句“综合表现更好”有用得多。