Kimi发布PerceptionBench，榜首准确率59.7%
42个旧基准用于找失败，3000题组成诊断集；16款模型结果仍待独立复测。
本文要点
- 评测入口从整题答对与否，推进到回答链中最早的视觉失败点。
- 视觉能力从单一总分拆为10类可定位、可补数据的原子能力。
- 发布团队开放同一项目的数据与评测脚本，使榜单开始具备第三方复测条件。
阅读辅助
先看数字、证据和来源，再读正文。
42个既有基准承担的是发现失败模式的作用，PerceptionBench另建3000题诊断集。
2026-07-23 07:36 UTC · GitHub API记录PerceptionBench仓库创建；这是建仓时间，不作为公开发布日。
总分相近，但感知能力分叉，是 PerceptionBench 最值得看的信号。Kimi 公布的自建榜单里，GPT-5.6-Sol 得 59.7%，Kimi K3 得 58.5%，Claude-Fable-5 得 57.2%；三者只差 2.5 个百分点。把总分拆开后，差异迅速放大：GPT-5.6-Sol 的定位分项为 76.7%，感知相关幻觉却只有 26.9%；Kimi K3 的对应两项是 70.3% 与 41.7%；Claude-Fable-5 的 OCR 达到 64.3%。同一个“接近六成”背后，模型会在完全不同的视觉环节失手。
这套评测的新闻增量发生在本期窗口内。Kimi 于北京时间 7 月 28 日 02:45 发出正式发布帖，开放博客、GitHub 与 Hugging Face 入口。GitHub 的 master 分支此前在 7 月 27 日 18:31 UTC 完成初始提交，随后更新论文链接；仓库元数据的最后推送时间为 19:40 UTC。仓库创建时间则是 7 月 23 日 07:36 UTC，它只能说明准备工作已经开始，不能替代正式发布时点。官网 HTML 里的部分图像资源路径还带有 7 月 22 日至 24 日日期，那同样只是静态资源上传路径，不是新闻发布时间。
目前可以确认的是：团队从 42 个既有基准里的模型失败出发，归纳 10 类原子感知能力，再构造 3000 道经核验的问题；公开 README 称，团队选取的 16 款多模态模型在这套数据上都没有达到 60%。仍需保留的边界是，题目、错误分类、模型选择和榜单均由发布团队设计，尚未看到独立复现。“16 款均未过 60%”只适用于这 16 款模型、这套自建评测与当时的运行设置，不能外推为所有前沿模型都过不了 60%。
对模型研发者，这个项目提供的是错误定位坐标，而不只是新榜单。对采购和产品团队，它提示验收时要把“图像看清了没有”与“看清后有没有推理对”拆开。一个模型在总分上领先，并不保证它更适合 OCR、空间定位、计数或拒绝视觉幻觉。
证据矩阵：哪些材料能证明什么
| 证据 | 能直接支持 | 不能直接支持 |
|---|---|---|
| Kimi 官方文章 | 方法动机、42 个基准、10 类能力、3000 道题与榜单口径 | 独立复现、真实业务收益、训练数据无污染 |
GitHub master README | 题目构成、模型名单、分项得分、裁判设置与复现命令 | 其他提示词、其他服务版本下得分不变 |
| GitHub API | 建仓、提交、推送时间，默认分支为 master，仓库标记 Apache-2.0 | 建仓时即已公开，网页资源日期就是发布日期 |
| Hugging Face 数据卡 | 数据文件入口、60%/40%构成、榜单交叉核对 | 内部 1.7 万余题题池的完整选择过程 |
| 官方 X 发布帖 | 本期 news peg 与对外开放入口 | 方法有效性和榜单公平性 |
这里有一个来源层面的现实限制：公开材料几乎全部来自 Moonshot AI 自己。GitHub、官网、论文入口与 Hugging Face 可以互相检查数字是否一致，却不能算作多家独立机构的效果验证。因此本稿把项目“发布了什么”视为高置信事实，把“这套评测准确刻画了前沿模型的感知边界”维持在中等置信。
诊断入口：从最早失败点反推能力分类
PerceptionBench 没有先拍脑袋列十个能力，再去搜题填格子。团队描述的流程是：观察前沿多模态模型在 42 个既有基准上的回答，定位响应中最早出现的失败点，再建立错误分类树；分类树里的感知分支最终收敛为 10 类原子能力。
这 42 个基准的作用必须说准确。它们用于发现失败模式和建立错误分类，不是被直接拼接成 PerceptionBench 的 42 项综合分，也不是“42 个基准共同证明所有模型低于 60%”。最终公开计分对象是另一套 3000 道题。
十类能力分别是：视觉关系、计数、属性、深度与三维感知、定位、比较、细粒度识别、上下文整合、OCR，以及感知相关幻觉。所谓“原子”，不是说视觉系统天然只有十块，而是每道题尽量只要求一种能力，答案短且唯一，难度应来自看图本身，不依赖外部知识或长链推理。
这个设计试图处理传统多模态评测的归因混乱。例如，一道题要求先识别仪表盘读数，再理解行业规则，最后进行计算。模型答错后，很难知道它是数字没看清、规则不知道，还是计算出错。PerceptionBench 会把这类失败尽量拆到最早断点：若模型连字符都没有读对，就先记为 OCR 问题，而不是把后续错误一并归入“推理能力不足”。
方法的价值取决于“最早失败点”能否被稳定识别。公开 README 没有逐项给出 42 个源基准清单、每个源贡献多少失败、归因者之间的一致率，也没有说明感知与语言理解的边界案例如何裁决。这些缺口不否定评测，但决定第三方复现不能只重跑榜单，还要重做一部分错误归因审计。
样本构造：60%拆失败，40%补盲区
公开的 3000 道题不是全部从旧基准原样搬运。README 与 Hugging Face 数据卡给出的构成一致：
| 构造来源 | 题量 | 占比 | 用途 | 主要风险 |
|---|---|---|---|---|
| 归因失败拆成原子子题 | 1800 道 | 60% | 保留真实模型已经暴露的失败模式 | 受最初模型与源基准选择影响 |
| 基于补充图像新写 | 1200 道 | 40% | 填补原有失败样本未覆盖的能力与难度 | 出题者偏好与合成分布偏差 |
| 内部经核验题池 | 1.7 万余道 | 未公开 | 按能力平衡和难度分层后抽取公开集 | 未完整开放，无法复算抽样过程 |
因此，“60%由失败样本拆解、40%新写”是样本来源比例，不是训练集与测试集切分，也不是模型错误中 60% 属于感知。把这个比例误写成错误归因比例，会改变结论。
失败驱动构造有一个优势：题目来自模型真实犯错的地方，比单纯由专家列能力清单更容易碰到系统薄弱处。但它也有选择偏差。如果最初用于找失败的模型、提示词或源基准偏向某类视觉任务，后续分类树就可能围绕这些模型的短板生长。新增的 1200 道题能补覆盖，却也引入出题团队自己的判断。
数据泄漏是另一条需要独立检查的线。部分图像或母题来自既有基准，模型可能见过相关素材；即使问题被拆成新的原子形式，视觉内容近重复仍可能影响成绩。README 说明题目经过核验、按能力平衡和难度分层抽样，但没有公开完整去重报告、参评模型训练数据可见性或污染检测结果。
分项读法：低于60%到底说明了什么
团队使用统一提示，并为参评模型开启可获得的最高推理预算。全部问题采用开放式短答案，再由 GPT-oss-120B 对照参考答案给出 0/1 判断。发布方称，裁判在 300 个样本的人审中达到 99.7% 一致率。
这个设置比多选题更接近自然回答，也避免选项泄露线索。99.7% 是积极信号，但它只覆盖 300 题审计，约占公开集的十分之一；高总体一致率也可能掩盖某个能力类别上的系统性误判。第三方复测最好公开裁判分歧样本、按类别的一致率，并用不同裁判模型交叉评分。
榜单中的前四名足以说明“总分相近、能力分叉”：
| 模型 | 总分 | 定位 | OCR | 感知相关幻觉 | 读法 |
|---|---|---|---|---|---|
| GPT-5.6-Sol | 59.7% | 76.7% | 54.9% | 26.9% | 定位强，幻觉分项明显拖后 |
| Kimi K3 | 58.5% | 70.3% | 61.2% | 41.7% | 总分接近第一，短板结构不同 |
| Claude-Fable-5 | 57.2% | 70.4% | 64.3% | 45.0% | OCR与幻觉分项高于前两名 |
| Gemini-3.1-Pro | 56.2% | 52.7% | 64.3% | 40.6% | OCR较强，定位差距更大 |
“没有模型达到 60%”在这张表里成立，且最高分确为 59.7%。但它不是一条关于全行业的永久上限。参评集只有发布团队选取的 16 款模型，其中 10 款闭源、6 款开放；模型服务会更新，推理预算和提示词也会改变结果。更稳妥的表述是：在 Moonshot AI 发布的 PerceptionBench 设置下，团队所评的 16 款模型均未过 60%。
分项也不能直接替代业务验收。定位题得分高，不等于模型能稳定处理长视频中的目标跟踪；OCR 高，不等于它能读懂低清票据并正确执行财务规则；幻觉分项较高，也不等于模型在开放世界图片里已经学会可靠拒答。原子能力是诊断探针，离端到端任务仍有一层组合误差。
复现门槛：脚本开放后还差三步
仓库已经给出评测脚本、环境变量、并发和裁判配置。模型只要提供 OpenAI 兼容接口，就能运行 eval/eval.py；逐题结果与按类别准确率会落到本地文件。这让第三方至少可以检查同一数据、同一裁判下的可重复性。
完整复现还需要补三步。其一，锁定每个模型的精确版本、服务日期、温度和推理预算。“最高可用推理预算”对不同厂商不是完全相同的资源约束。其二，使用人工或第二裁判复核边界答案，观察 GPT-oss-120B 是否偏好某种表达。其三，在不调参的前提下先复测原榜，再用独立图像集检查十类能力的排序能否迁移。
若团队直接根据公开集做微调，分数上涨也不等于感知能力普遍增强。最有说服力的后续实验应保留未公开的同分布测试集，再增加来源不同、拍摄条件不同、题型不同的外部分布集，同时报告总分与十类能力的变化。否则 PerceptionBench 也会迅速从诊断工具变成新的刷榜目标。
许可核对：代码开放不等于数据可任意商用
GitHub API 将仓库许可证识别为 Apache-2.0，master 分支顶层 LICENSE 也是标准 Apache License 2.0 全文。这可以支持“仓库以 Apache-2.0 开放”的描述。
但 Hugging Face 数据卡的 frontmatter 标记为 CC BY-NC 4.0。两处信号不能揉成一句“代码和数据全部 Apache-2.0”。更谨慎的解释是，代码仓库顶层采用 Apache-2.0，而数据集分发页声明非商业署名许可；至于 GitHub 仓库内数据文件、图像素材和论文分别适用哪一项，公开页面没有给出足够细的文件级说明。企业若要把数据用于商业训练、评测服务或再分发，应先向项目方确认范围。
这一差异也影响“开源”的写法。评测代码可以在 Apache-2.0 下修改和分发，不代表数据卡上的非商业限制自动消失。报道层面应把“开源评测仓库”与“数据许可允许何种使用”拆开陈述。
PerceptionBench 把多模态模型的失败从“整题答错”推进到“最早在哪个视觉环节断掉”。当模型总分只差一两个百分点时，分项能力可能相差十几个点；产品选型因此不该只看一个综合名次，而应先画出自身任务依赖的感知能力图谱。
这套方法目前更像一台由厂商造出的诊断仪，还不是行业公认的刻度尺。题目与分类都来自发布团队，内部 1.7 万余题池没有完全开放，16 款模型结果也未被第三方复现。榜单可以用来提出假设，不能单独用来证明某个模型拥有更强的通用视觉理解。
最值得跟进的是分项能否预测真实事故。如果 OCR、定位或感知相关幻觉的低分能稳定对应票据读取、界面操作、机器人视觉中的失败，PerceptionBench 会成为训练数据补洞和上线验收之间的桥梁；如果分项只在这 3000 道题上稳定，它的价值就会停留在研究诊断。
许可口径则是项目当前最容易被忽略的工程问题。代码仓库的 Apache-2.0 与数据卡的 CC BY-NC 4.0 同时存在，说明“可复现”与“可商用”仍是两件事。第三方在重跑分数之前，应先明确自己下载和再分发的对象受哪份许可约束。
后续观测：复现、迁移与许可
独立复测是判断榜单成色的第一道门。复测应锁定 master 分支提交、公开精确模型版本与调用日期，保留逐题输出，并把人工与裁判分歧样本开放出来。只要总分或分项排序明显变化，就能定位差异来自服务版本、提示词、裁判还是数据。
方法透明度决定十类能力能否成为稳定坐标。项目若补齐 42 个源基准清单、失败归因流程、标注者一致率、近重复检测和能力级样本分布，外部研究者才有条件判断这些分类是可迁移结构，还是当前模型与题目的局部产物。
迁移效果需要在未见题和真实任务里验证。模型团队可以针对计数、深度、定位、OCR或幻觉分项补数据，但必须同时报告外部分布和端到端任务。某项能力的提升只有在真实业务中减少对应错误且不牺牲其他能力，才算形成工程闭环。
许可边界会直接影响第三方能否持续复测。GitHub 的 Apache-2.0 与 Hugging Face 的 CC BY-NC 4.0 应明确对应代码、JSONL、图像与论文中的哪些部分；企业接入评测流水线和社区制作衍生版本都依赖这一答案。