评测之殇：如何通往真正的多模态评测之路

0. 叠甲

先叠个甲。这篇是我最近跑实验、看行业时留下的杂记，主要是把之前的研究捋一遍，顺便整理自己还没想透的思考。我没打算给各种评测分个高下，更不是要宣布哪条路线赢了。文中引用的文章只是讨论起点，不给任何人背书；论文结论、第三方观察和我个人的推测，我也尽量区分开。欢迎大家随时补充新视角，一起讨论。

1. 引子：评测越来越卷，我们到底离什么更近了？

我们怎么知道自己走对了路？

现在的多模态评测热闹得很。题越出越难，榜单拉得越来越长。新模型一发，待跑清单排得满满当当：今天测学科知识、视觉数学，明天测长视频、桌面操作或交互规划，换着花样往上加码。这些尝试当然有价值，要是不跑，我们连很多失败都看不到。

但光有热闹，不等于我们真搞出了能促进领域进步的评测。模型多拿两分，到底是因为真看懂了、推理稳了，还是单纯摸透了裁判喜好，甚至偷偷把题背下来去 hacking？出来的分数能不能指导我们下一步改数据、调整训练目标，还是给更多推理预算？当用户真实踩坑时，榜单又能不能解释原因？

要是最后只剩一个排名，对研究来说远远不够。选型时看成绩单固然省事，改模型却需要能力定位、失败归因，以及“这次改动确实有效”的明确证据。我关心的不是哪家 benchmark 最好，而是怎么把评测从简单的报成绩，变成能指引模型进步的方向。特别是在多模态场景里，模型得先看图听音，再接着去调工具、做动作，最后才吐出回答。光看它最后给出的答案是对的，可不代表整条链路都没毛病。

2. 先立坐标系：时期横轴 × 阶段纵轴

过去一些研究，比如 Ma et al. 在 NeurIPS'25 上的 tutorial，已经很系统地剖析过评测里的核心问题，非常推荐一读。评测分数到底能不能当成 scaling 的 y 轴，本来就是最根本的问题：我们投入算力、数据和训练步数，究竟在推动什么增长？如今发布表越做越满，这个问题反而经常被放过。

我自己平时思考时，习惯先拿两把尺子：一把是评测形态演进的历史时期，另一把是模型开发的阶段性。这算不上什么行业标准分类，纯粹是能帮我把平时容易混在一起的讨论拆清楚。

横轴代表评测形态演进的“时期”：从最早的传统 metric，一路演进到专属 setting、动态 online 测试，再到现在大家热议的交互环境。它解决的是尺子怎么造、为什么要换。纵轴则是模型和系统生命周期的“阶段”：pretrain → mid-train → post-train → deploy / 产品评估 / 回归。它解决的是现在要做什么决策，评测需要守住什么底线。

评测的两轴：时期 × 阶段

横轴 → 时期评测形态如何演进（period / era）

纵轴 ↓ 阶段模型与系统的生命周期（stage / lifecycle）

点选一个交点，看它测什么、容易错在哪里；窄屏可横滑。

阶段 ↓ / 时期 →	传统 metric	任务 metric / setting	动态 / online	环境 / 交互
pretrain	表示 / 迁移	受控能力探针	新鲜持出样本	固定策略诊断
mid-train	专项增益 / 遗忘	领域 / 域外对照	时序 / 模板泛化	固定系统对照
post-train	基础能力回归	行为 / 判定	未见任务泛化	行动 / 最终状态
deploy	输入链路回归	产品失败回归	新流量 / 漂移	真实链路 / 回放

pretrain × 传统 metric

通常测什么用分类、检索或 caption 指标检查表示、跨模态关联与迁移。

容易踩的坑候选池、prompt 和验证分布会影响数字；局部指标不等于开放式能力。

同一个时期的尺子，完全可以挂在不同的开发阶段；同一个阶段，也能搭配好几种时期的评测手段。拿检索指标来说，放在 pretrain 阶段能看表征好不好，放到 post-train 又能检查底座有没有被训废；沙盒小环境也一样：调后训练策略时能用，上线前跑回归也能用。所以每种评测模式，不过是这套二维坐标里的一个 point，各有各的位置，谁也不天生更高一级。

尤其别把横轴的 online 和纵轴的 deploy 混为一谈。online 强调内容或过程会变，动态题库完全可以离线跑；deploy 强调系统已经在用，固定回归集照样能服务产品。这个 point 没说清，就容易拿基础探针苛求产品可靠性，或拿整个 agent 的偶发失败否定一次底座改动。

2.1 一个数字说明不了任何事情

这个标题听起来可能有点绝对。分数当然有用，但如果脱离了限制条件，一个孤立的数字根本回答不了我们真正关心的问题。

以前做分类任务边界很清晰，看 softmax 谁的概率高就选谁。早期的 VQA setting，也大多把看图说话压缩成有限选项里的判别。但现在的模型不一样了，既要吃文字图片，又要看视频听音频，还得边理因果边调工具把事情办了。能力一旦组合起来，缝隙里的问题就全露出来了。

就算模型认出了截图上的按钮，也不代表它知道当下该不该去点；视频里发生了什么它能讲对，可未必晓得去哪里抽证据，信息不够时可能也不会老实承认“不知道”。单项测试看起来都不错，凑到一起干活就频繁翻车，这其实一点都不矛盾。HELM 早就提醒过，评测里的“好”不只是一项准确率。多模态的输入和行动链路更长，拿局部偏科分数推整个系统可靠性，就更需要克制。

最近 Inkling 2 Small 的案例挺有意思。Thinking Machines 在博客里强调，他们不再单纯依赖单步单元测试的 reward，而是在部分任务中引入 agentic RL grader 看模型如何处理问题；早期 checkpoint 还会用 Fledge-Alpha 在 OpenCode 上跑真实 coding。这其实也是在承认：单条代码通过测试，和整个 agent 在真实场景里好不好用，完全是两码事。

另一面，Vals 的观察，以及 The Decoder 的转述，把视线放到过程：他们在 13 个 benchmark、2,655 条运行记录里，发现 50 条出现相关脏话，共 316 次，而且大部分集中在两条记录。这些内部推理通常不是用户直接看到的回答，不能据此说模型对用户没礼貌，也不能把它拟人化成“情绪失控”。96% 的失败记录没有脏话，它甚至不是可靠的失败预警。

我更在意的是：分数可不会主动告诉你，背后有没有长时间死循环、重复尝试、中途放弃，或者靠昂贵的重试才把答案凑出来。碰到特别折腾的任务，换成真人去做也想骂两句；词语本身不是能力判决，更不是要黑 Inkling。两个模型同样拿 60 分，一个顺畅一次过，另一个靠海量重试硬凑出来，给用户的体验完全是两码事。分数跟真实体验、过程质量经常脱节，这才是这个例子值得拿出来聊的地方。

同一个分数，不同过程

假设同一组 100 个任务、相同权限与预算上限，每完成一项记 1 分。两者最终都完成 60 项；点选模型看过程，窄屏可横滑。

假设模型 A60 分稳定一次过假设模型 B60 分海量重试 / 空转

假设模型 A · 稳定一次过

1. 读取证据
2. 执行操作
3. 核验状态
4. 完成任务

过程差异完成的 60 项都在首次尝试中成功，行动有据、及时核验；未完成的任务仍要记录。这里仅示意一次成功轨迹。

分数之外还要查检查重复运行是否稳定、失败时能否合理停止或求证；一次过也不意味着其余 40 项没有问题。

2.2 分布在变，旧尺子不会自动跟着变

真实用户可不会照着 benchmark 目录来提问。照片可能拍歪了，录屏也可能糊成一片；说话时中英文夹着，冷不丁还冒出行业词。产品一换设备、用户群或工作流，翻车位置说不定整套换掉。同样叫“读文档”，扫描件、手机随手拍和屏幕截图，难的地方根本不一样。

像 ImageNetV2、ImageNet-C 和 WILDS 这些经典工作，其实早就把话说清了：在旧数据集上拿了高分，可不代表换个新环境也能稳赢。重采样测试、图像腐蚀测试还有分布漂移，测的本来就是不同的硬伤，硬凑出一个‘综合鲁棒性得分’把差异抹平，没啥实际意义。

评测当然要与时俱进，但不是每月换个榜单名就算完事。你得讲明白采样的人群、测试条件和任务到底变了啥，之前的对比结论还能不能算数。拿旧分数去回答旧问题，一点都不尴尬；真正尴尬的是分布早就变了，大家还把过去的结论原封不动地往上套。真实场景里的各种噪声，靠换个榜单包装是解决不了的，得把这些变化实打实地放进采样、对照和失败归因里。噪声也不是越多越好，那些跟实际用户压根没关系的干扰，除了把测量搞乱，没有任何意义。

2.3 榜单开始参与商业循环了

研究指标进入发布会、采购和市场认知之后，优化压力就会沿着分数走。这不需要假设人人作弊：只要数字影响资源，大家就会研究怎么把它做高。真正在提升底层能力，还是针对这场考试专门做应试适配，放在成绩单上看可能完全没区别，可外界往往会把两件事都当成模型全面变强了。

我平时依然会关注 AA / Artificial Analysis 这类公开比较平台。它们把模型能力、价格、速度放到一起，降低了对比成本。但越有影响力，越应该关心测试方法、覆盖度和更新说明，而不是只盯第几名。如果评测给的推理预算变了、调用的工具权限改了，或者分数的权重变了，名次上下浮动，根本算不到模型底座头上。

我完全理解轨迹（trajectory）属于闭源资产，公开可能碰到隐私、商业秘密或评测安全边界，不是说所有原始 log 都必须放出来。但依旧希望大家尽量关注过程：大家平时经常踩什么坑、失败到底该归到哪一类、裁判模型在什么地方容易摇摆，或者评测规则修过之后结论有没有翻车。给脱敏例子、过程统计、独立复核，也比只给一个结果更能建立信任。榜单负责比较，不能顺手把解释责任全部省掉。

3. 沿横轴：四个时期，从算分、出题到搭环境

这里划分的四个‘时期’倒不是什么绝对的时间线，更多是我自己梳理技术演进时划分的视角。看图问答（VQA）早在现在的多模态大模型火起来之前就有了，动态题库不是今天才有的新鲜事，沙盒环境评测也没打算把传统方法彻底淘汰。核心在于我们到底想从评测里要什么答案，而不是每出一个新方法，就得把旧尺子全扔了。

沿横轴看：四个时期的评测重心

从算分、设计任务，到持续采样与交互环境。点选时期查看代表工作与局限；窄屏可横滑。

时期 01传统 metric时期 02任务 metric / setting时期 03动态 / online时期 04环境 / 交互

传统 metric

在明确的任务和答案空间里，用既定指标测一个局部能力。

代表工作ImageNet / ILSVRC · COCO Captions · CLIP

局限准确率、Recall@K、caption 分数各有边界；候选池和 prompt 一变，数字就未必可比，更不能直接外推为系统可靠性。

← 上一时期1 / 4下一时期 →

3.1 时期一：借用传统 metric，先测定义好的任务

早期多模态任务的边界相对明确：像在 ImageNet 上做分类、在 COCO 上跑检测与 caption，或者拿 Recall@K 测图文检索。因为分类类别、候选池和参考答案都是事先定好的，跑起来既省钱又能稳定复现，出了错也很容易定位。

但连这些数字也不是天然可比。在 Recall@K 里，候选池大小、划分、以图搜文还是以文搜图方向一变，难度就变了；caption 与参考描述更接近，也不等于所有事实都对。协议省略之后，小数点会制造一种并不存在的精确感。

CLIP 把大规模图文预训练和 zero-shot transfer 推到重要节点，但成绩仍取决于类别文本和 prompt。它确实证明了通用的图文表征很管用，但离证明模型懂开放式看图聊天还差得远，更谈不上能帮你去点鼠标、操纵电脑了。

这些测试今天仍值得保留，作 pretrain 探针，或上线后的输入链路回归锚点。我并不是说“传统 metric 过时了”，而是局部任务成绩不该包装成整个多模态智能。越是便宜稳定的指标，越适合高频诊断；前提是承认它测到哪里为止。

3.2 时期二：为任务单独创造 metric 和 setting

从 VQA 演进到 visual instruction tuning，模型输出不再只是标签或排序，原来的尺子不够用了。VQAv2 抑制纯语言先验，也承认人类答案共识；GQA 追组合关系；TextVQA 考察读图中文字。它们说明“看图问答”内部有不同瓶颈，不是多加一万道题就全解决了。

后面的 MME、MMBench、MMMU 和 MathVista 这些基准，把大家关心的能力范围拉得更宽了。但选题分布、答案形式和汇总算法，仍然决定总分看见什么。学科知识没学会，和图中坐标读错，最后都可能表现为一道题没答对，下一轮该改的东西却完全不同。

开放式输出引入 model judge，比如 LLaVA-Bench。流畅但事实错怎么扣分，长答案会不会占便宜，裁判偏好会不会偏向某类模型，都属于方法的一部分。规则打分也不天然更好：等价答案漏判、答案抽取出错，同样会污染结论。裁判可不是免费获得客观真值。

lm-eval 和 lmms-eval 让协议更容易复用，但进入同一个框架，不等于测到同一种东西。我自己在本地跑评测时常有一种感觉：跑着跑着像在 debug，而不是在积累硬结论。环境依赖、图像处理、解码参数、stop token、推理框架实现，稍微变一下，分数可能就上下摆动。

当时很多 decoding / inference 探索当然有价值，但先得分清测的是底座改动，还是接口终于对齐了。复现差两分，不能立刻解释成能力差两分。记录环境、固定配置、检查样本级差异，必要时重复运行；只有先把执行误差压到可接受范围，结果才有资格支持下一轮训练判断。

3.3 时期三：固定题库 → 动态 / online

公开题库反复用，训练数据又难完整审计，静态评测就同时面对污染与固定复杂度饱和。VLB 用视觉、语言变换生成新样本，再用 judge 检查一致性，说明内容不必永远冻住。但变换后还在不在测原能力，图片和答案是否正确，都需要额外验证。

LiveBench、LiveCodeBench 的新鲜数据、程序可验证判定、时间记录也值得借鉴。不过它们不能直接替代多模态里的图像来源、视频标注和感知捷径问题。换一批新题、把旧题重组、拉高难度，或者搞自适应出题，逻辑完全不一样。试卷本身变难拿到的 80 分，和题目新鲜但难度持平的 80 分，含义可不能混在一起看。

我更想强调的是：能力评测应该从一套说得清楚的分布里采样，保证整体趋势可信，而不是执着于所有模型永远做一模一样的死题。固定题有复现与回归价值；但如果把这种便利当成长期不更新测量的理由，说白了也是偷懒。进入深水区，总该往前走一点。

“趋势一致”也不是随便生成几道题，看起来差不多就行。采样规则、任务占比以及难度阶梯得保持稳定，样本量也要给够，最好靠多次采样来估算波动范围。差距小于采样误差，就别硬排座次。动态不是取消静态锚点，而是从发布一次题库，转向持续维护测量过程：锚点解释历史，新采样检查泛化，两边都要有。

3.4 时期四：从输入输出走向可交互环境

WebArena、VisualWebArena、OSWorld 的关键不只是给模型看截图，而是观察—行动—再观察，并把目标落成环境状态。“嘴上说保存”与文件真的保存，是两种证据。模型选对按钮，仍可能没等页面加载完，或把东西存进错误目录。

视频也类似：只问结尾答案，测不到证据搜集过程。允许回看片段以后，还该记录它查了哪里、漏了什么、用了多少预算。不是所有过程都能从内部推理文字推断，工具调用、输入输出与实际状态，往往更值得检查。

在我看来，环境做得很小但足够严谨，远比搭建一个宏大却漏洞百出的模拟世界更有意义。初始状态、权限、预算必须明确，完成后尽量按状态判定。但环境不是通向现实的自动传送门：模拟器漏洞会被模型记住，工具 API 会左右表现，沙盒报错还可能被误算成模型不行。更别说测出的成功率，到了真实用户手里未必管用。而且部署成本不低，容器、依赖、并发、重置加裁判机制，哪样都省不了。很多‘可复现’任务，换台机器跑可能分分钟崩掉。

最近关于 MiMo-V2.6 与 DeepSWE 的讨论，很适合提醒我们别把问题压成一个阴谋。MiMo 报告主动讨论 reward hacking、solution leakage，以及环境清理、隔离和轨迹审计。Vals 的审计 又指出，部分公开训练环境删除后续分支，却仍保留不可达 Git 对象，参考修复可能继续可读，并给出模型利用泄漏的案例。这是在问信息边界有没有真正封住，不只是 prompt 有没有写“禁止作弊”。

另一类问题方向相反。Ian Barber 的博客 转述对 DeepSWE 的审计：agent 新增测试与隐藏测试同名，可能让本来合理的修复因编译冲突而失败。前者可能高估能力，后者可能低估能力；训练环境缺口、评测误判、模型主动投机，不能混成一摊，更不能据此硬说所有涨分都是假的。

Standard Normal 的报告 则用带攻击提示的其他模型检查公开环境的 grader 绕过问题。它证明的是特定条件下漏洞可利用，不等于证明 MiMo 正常运行时必然采用同样行为。做红队、测日常行为、追溯训练影响，各需要不同证据。

资源充足的团队也更有能力反复探测环境与评分机制，企业级使用并不会自动免疫 hacking。交互环境把更多真实约束放进来了，也把更多攻击面放进来了。总的来说，我仍觉得更 online、更实时交互的 benchmark 更符合预期，但前提是把判定、权限和过程一起维护，不是把“静态题库”换成“昂贵且可利用的模拟器”。

3.4（分支）时期四：面向真实任务场景

还有一条更直接的路线：少做抽象投影，拿真实问题本身当 benchmark。Qiuyang Mang、Wenhao Chai（柴文浩）等人的 FrontierCS 与 FrontierCS 2，是值得认真看的例子，项目在 frontier-cs.org。

FrontierCS 的开放式 CS 问题，不是要求吐出一个标准答案，而是实现程序、客观衡量解的质量。“最优解未知”也不等于所有题都没人解决过，它们有专家参考解。FrontierCS 2 更进一步：取论文和作者发布的仓库，删掉论文贡献对应的代码，让 agent 在研究环境里补回或改进，与 human reference 比较。开发反馈与最终持出判定分开，评测也包含 Codex harness 等 agent 接入方式。

这里比普通问答更有力量的地方，是模型得在原生问题里完成研究与工程，而不是答一道关于研究的题。任务横跨不同 CS 领域，结果可能是更快的实现、更好的系统指标，而不只是一句正确解释。但这仍不是自动证明“模型已经会所有科研”，CS、RSI 以及其他学科研究任务需要各自的验证条件，不能只换题目外壳。

代价也很明显：搭代码仓库、还原论文贡献、校验专家参考答案，加上维护硬件与测评脚本，成本高得吓人。题目一旦过于特化，模型究竟是因为懂了通用知识、工程能力扎实，还是刚好撞上了某个小技巧，很难分得清，也不好总结通用规律。高总分甚至可能掩盖某一工作负载上的退化。

我认可直接啃原生问题的道理，但我自己觉得更实用的做法是取个折中：保留少量有代表性的真实任务作为外部检验，再从失败里抽出可复用、可控的诊断任务。FrontierSmith 尝试规模化构造开放式训练环境，也提醒我们，这条路线终究绕不开“真实结构如何保留、成本如何摊薄”。不是非得在纯抽象题和原封不动的世界之间二选一。

4. 沿纵轴：从 pretrain 到投入使用，评测要回答不同问题

沿纵轴看：四阶段评测阶梯

点选阶段，拆开要改变或守住什么、评测问题、loss 信号、补充方法与常见坑。

01pretrain02mid-train03post-train04deploy

pretrain

要改变或守住什么基础表示、知识与跨模态关联。

要回答什么基础表示、知识与跨模态关联有没有建立，能否迁移？

eval loss 能看什么在固定验证分布与目标下，观察预测或对齐目标的优化进展。

还要补什么 method分类、检索、受控问答与迁移测试；重要路线选择可补小规模后续训练对照。

常见坑loss 相近不保证后续 agent 表现相近；预处理、prompt 或适配器变化也会遮住底座差异。

纵轴关注模型与系统生命周期。OPD 等讨论，把预训练与 mid-training 后的行为微调拆开，比只问最后涨几分更有启发。不过各团队对 mid-train 定义不一，同一种 SFT 也可能放在不同阶段。我这里不统一术语，只拆开每一步要改变或守住什么、eval loss 能看什么、eval method 还要查什么。

同一套方法可以跨阶段复用，前提是接口和比较条件说清；也不是简单题只准测 pretrain，复杂环境只准测 post-train。横轴决定测量形态，纵轴决定结果该支持哪种决策。

4.1 pretrain：基础有没有长出来

在预训练阶段，大家最在意的是基础表征稳不稳定、跨模态关联有没有建立起来。看验证集 loss 能判断训练推进得顺不顺利，再挂上分类、检索或者简单的受控问答，测试能力能不能迁移出去。图像预处理、prompt 格式与模型适配要尽量一致，否则接口差异会盖住底座改动。小环境也能做诊断，但固定接口与策略后，才有机会把失败归因到底座能力。

Mistral Large 4 报告里的架构消融尤其值得注意。为降低 KV-cache 成本，他们探索 SWA、CLA 等设计，早期评测损失不大；继续训练、做 mid-train 和 SFT 后，在 SWE-bench 上却拉开差距。报告指出，相当的 loss 完全可能对应很不一样的后续 agent 表现，知识评测也没暴露同样的瓶颈。

这不是“loss 越低，agent 越差”，而是即使底座 loss 差不多、知识选择题得分相当，后续做复杂任务时的迁移潜力也可能千差万别。golden metric 可能只是对过去某些能力有效，对未来更复杂的继续训练不一定适配。延长训练可能缓解部分差距，也说明结论依赖预算和路径，不能把一次消融写成所有高效架构的死刑。

所以 pretrain 可以保留高频、便宜的 loss，但重要路线选择最好插入小规模后续训练试验。今天省下的服务成本，若以明天无法迁移为代价，只看底座曲线根本看不出来。

4.2 mid-train：专项进去了，旧能力还在吗？

注入领域知识、扩展长上下文或加入视频后，要问的不是总分涨没涨，而是专项增益在哪、能否迁移、会不会挤掉旧能力。把新分布的吸收与旧能力的保留分开呈现，才是诚实做法，别让综合总分把两者抵消。

Qwen3 report 提醒我们数据重心与上下文条件会变化；当然阶段命名不能简单照搬。而 MAI-Thinking-1 报告更明确：mid-training 主要是从原 pretrain 语料里过滤、重加权，不引入新数据源，再扩展上下文。这说明专项训练不一定靠新数据，旧知识以不同配比重新进入训练也是重要形式。

MAI 报告还尝试按记忆风险限制重复曝光：如果 loss 改善更多来自近乎确定的 token，就需要小心它是在学通用结构，还是反复熟悉材料。依我看，光盯专项验证集的 loss 远远不够，更得看在全新的来源、不同的上下文组合以及更长输入下的真实表现。况且，模型能一口气读更长的文本，和它能在海量长文里精准找到关键证据，完全是两码事。

具体做法仍然朴素：域内、域外持出与固定回归锚点一起看，同一 checkpoint、同一行为接口做对照。换动态题时拆开新鲜度和难度变化；跑领域工作流时固定工具和规划。要不然新塞进来的知识、题目难度的起伏还有工程系统的改动全揉在最终成功率里，等出了问题，你压根分不清到底该继续洗数据，还是去改行为策略。

这些报告多从语言和推理模型展开，我借的是阶段诊断思路，不是把其中结论直接当成多模态实验证据。加视频之后，还得额外测帧采样、时间关系与跨模态证据有没有真的用上。

4.3 post-train：会做之外，还要看怎么做

在后训练阶段，指令、偏好、推理和工具训练，改的是能力如何被激活和调用：比如遇到难题什么时候展开推理，拿不准的时候何时拒答或主动向用户求证，甚至工具报错之后怎么恢复调用。光知道答案不够，单靠 RL 里的 reward 信号也不够。表面相同的成功率背后，乱试工具与基于证据行动，风险差很多。

Qwen3 的四阶段 post-training 很有参考价值：long-CoT cold start、reasoning RL、thinking mode fusion、general RL，不是一个“后训练”总开关。报告单独用 ThinkFollow 检查思考模式切换，用 CounterFactQA 检查反事实问题下的幻觉，用 LengthCtrl 检查长度要求。它们测的是如何调用能力，数学答案正确率不会自动替我们回答。

Qwen3 报告也没把每个阶段都讲成全线暴涨。模式融合与 general RL 改善通用行为的同时，部分高难推理掉了分，团队接受了这种权衡。我的 takeaway 是：后训练是在重新分配内部能力，一个干巴巴的总分不该把代价藏起来。

MAI-Thinking-1 也明确区分：pre/mid 给预测能力与知识，RL climb 再训练推理、工具交互、推理预算和安全行为。它把 STEM、agentic、helpfulness / safety 等目标分别展开，再整合进模型。会推理、会安全地行动、不会过度拒答，都需要各自的证据，不能用“RL reward 上去了”包办。

多模态尤其要查轨迹：看模型遇到不确定的图片时会不会主动提问求证，工具返回的结果跟预期不符时懂不懂及时调整思路，或者在视频证据不足时是不是在胡编乱造。预算、工具、重试次数不同，结果会差很多。任务判定、工具轨迹和人工抽查要配合，传统感知指标也应保留，检查行为训练有没有损伤底座。关注过程，不意味着把内部 CoT 当真实机制说明书，而是尽量检查能验证的行动与后果。

4.4 deploy：评的是正在被使用的系统

权重没变，图像 resize、RAG 库、API 或用户群一调，产品表现也可能跟着晃。上线评估不是给 checkpoint 临时补几道考题，而是在测「底座 + 服务 + 工具 + 真实用户」整套系统。

线上监控用来抓新踩的坑，离线回放用来复现刚踩过的失败，受控 A/B 实验用来对比新老版本，固定回归集则用来死守底线、防止旧 bug 卷土重来。这几样工具各司其职，可不能混成一摊。离线回放适合看同一输入上的行为漂移，在线实验更贴近真实体验；但在线实验得控制用户画像和时间窗口，别把大盘流量波动当成模型变强。

真实流量有授权与隐私边界，不是模型见过就能直接塞进公开测试。去敏也要检查是否删掉了决定答案的关键结构。除了看一眼平均成功率，那些致命的严重错误、单次调用的耗时与算力成本，还有模型知不知道合理提问、能不能从错误里恢复，往往才是决定要不要推上生产环境的关键。

修好的失败做成回归集很有价值，但只说明旧问题没回来，不能替代新持出样本。基础设施超时不该全算模型错误，无限重试也不能用来藏失败。如果 agent 花十倍成本才达到同样成功率，产品团队完全有理由做不同选择；这不是“不够学术”，而是这个阶段本来就在回答另一种问题。

4.5 eval loss ≠ eval method ≠ 真实能力；更新尺子要留对照

验证 loss 有用，但依赖验证分布、训练目标和权重。换目标后曲线未必可比。eval method 则包含采样、输入处理、交互、裁判和汇总，回答的是某种能力主张有没有证据，不是训练目标有没有下降。真实能力又比这两者宽，我们只能在明确条件下逐步接近它。

举个假设：高分辨率文档进训练后，loss 降了，TextVQA 升了，桌面 GUI 操作没动。这可能是文本识别变强了但规划没进步，也可能是部署截图预处理把细节丢了。只看 loss 下降就宣布产品更可靠，或只看 GUI 没动就说训练白做，都是跳过了中间证据。

我想要一条可追踪的链：代理目标改了什么 → 受控测试验证了什么 → 实际使用还在哪些条件失败。每个箭头都要有对照，而不是凭感觉自动成立。

尺子更新时，保留稳定锚点、版本与采样记录，必要时同一组模型在两版上都跑，区分模型进步、题目变难、协议变化。锚点也不能成为永久公开的优化靶子，可以用隔离的持出变体检验趋势。更新测量与保住可比性有张力，但这不该成为拒绝更新的理由；至少让读者知道哪些数字能连起来，哪些应该断开看。

5. 我们做评测，归根到底想要两件事

诊断、比较、选型、回归，用途可以列很多。往回追，说白了核心就两件：防 hacking；以及在小而严格的环境里，更好模拟真实能力评估。一个保证分数不被捷径架空，一个保证测的事情值得关心。

5.1 让分数对应能力，不对应考试捷径

分数怎么偏了：七种机制，分别查

点选一种机制：看它怎么歪曲分数、关键证据，以及应对检查。按钮随宽度换行，详情放在下方；机制不同，不能混成一句“防 hacking”。

01只看题面也能答02看了图，也走捷径03题目或答案见过了04验证集越用越熟05位置、篇幅、风格讨喜06生成—裁判偏好闭环07环境钻空子，还是误判

只看题面也能答

机制问题措辞、答案频率或单一模态就够猜中，不必用上任务声称需要的视觉证据。这和见过原题不是一回事。

分数错在哪把语言先验或文本信息的贡献，算成了看图与跨模态能力。

证据线索

• VQAv2 — 用平衡图像—问题对压低语言捷径的收益。
• GQA — 用场景图与组合问题追问对象及关系。

怎么查做无图、单模态与平衡成对对照；先确认问题真的需要被移除的证据，不能仅凭无图答对就判污染。

数据污染、泄漏、刷榜、奖励投机，经常被塞进同一个筐里讨论，但底层机制大相径庭。训练集里掺入标准答案，与模型利用题面文本偏差，需要不同审计；沙盒里读到隐藏代码，与裁判偏爱篇幅长、格式漂亮的回答，也不是同一种漏洞。虽然最后都会把评价虚高，但治理不能指望一句“做过去重了”就完事。

多模态测试中，哪怕模型“不给图片也能回答正确”，虽然值得警惕，也不能单凭这一点判定作弊：这可能是因为见过原题，但也可能是题目本身只需要通用常识或文本信息。相比之下，更有说服力的是引入反事实对照实验：比如干脆把图片拿掉、把图里的核心主体换掉、重新洗一把选项顺序，或者改改图像里的逻辑关联，看看模型的回答是不是真的跟着关键视觉证据在变。

还有一类更隐蔽：图也看了，却只靠“问题和某个物体共现”蒙对。VQA-CE 专门挖这种琐碎规则，再拿反例去压——主集看起来不错，反例一换可能塌得厉害。这跟“训练集里混进标准答案”不是同一种病。

改题后仍有效是前提。图片改坏、指代变含糊，分数下降不能解释成“抓住捷径了”。出题者也得承担质量责任。环境侧则要检查隐藏答案是否可访问、判定是否可篡改，而不是只要求模型道德自律。

裁判这一侧也别省事。Zheng et al. 把位置偏差、冗长偏好写得很清楚；AlpacaEval-LC 和 LMSYS style-control 则提醒：长度本身就能搅乱胜率，控制长度前后的结果得分开读。Preference Leakage 更狠一点——生成合成数据的模型和裁判若同族，相关学生会被系统性抬分，比单纯“写得长”还难察觉。新题不一定能打断这条闭环。

前沿报告其实已经在拆开测。Qwen3 的 LengthCtrl 之类探针，测的是能不能按长度要求写，不是答案对不对；Mistral Large 4 又提醒，底座 loss 差不多，后面 agentic 迁移仍可能差一截。一个代理指标，经常够不着你真正关心的下一站能力。

还有一种不那么戏剧性的适配：反复用同一验证集选 prompt、采样和模型版本，它会逐渐成为优化的一部分。Dwork et al. 讨论的 holdout 重用问题就在这里。“没拿测试集反向传播”，不等于测试结果一直独立。

防 hacking 是设计工作：把训练与测试的边界划清、限制验证集被探测的频次、引入更多测试变体，换独立裁判族，守住环境隔离，同时把审计日志存留好。合理学习与披露过的任务适配可以接受，冒充独立持出的高分则要警惕。最重要的不是给谁贴标签，而是这个成绩究竟支持泛化，还是只支持在这一套考试条件下做得好。

5.2 让小世界保留真实任务里重要的约束

设想这样一个小任务：让模型读取几张报销单照片中的金额，交叉核对并填入财务表格，遇到字迹模糊无法辨认时，主动向用户提问求证，而不是凭空瞎猜一个数字继续提交。任务虽然不大，却把看图识别、数字核算、工具操作，以及遇到拿不准的情况怎么处理，一股脑全串在了一起。它能轻松暴露传统单项问答测不出来的深层问题。

这种测试场景的“严格”体现在何处？整个交互过程的轨迹能完整记录，最终落地的数据能靠脚本自动校验，底层真正的答案模型压根接触不到；操作的权限和资源预算从一开始就交代得明明白白，任务结束后直接依据表格持久化状态做断言判定，每一次失败都有迹可循。

不必把全世界搬进来，保留用户在意的结构就行：关键信息可能缺失、每一步操作都会带来实际后果、环境状态会随之改变，出了错还要能自己挽回。小环境若删掉这些约束，再精致也只是另一个答题器；全保留所有噪声，又可能贵到无法诊断。

成功率之外，耗时、成本、严重错误、询问与恢复都值得看，但不必马上压成加权总分。财务录入中少一次严重错误，可能比节省几秒重要；其他场景权重不同。权重是价值选择，要看得见。一个模型没有完成任务，但准确发现缺失证据，与编出金额后“成功提交”，也不该被当作同一种失败。

6. 道阻且长：动态了，也不等于免疫了

6.1 动态降低一种风险，也引入新测量成本

VLB 与 Live* 很有价值，但解决具体问题，不是发“不会被污染”的免检证。刚生成不等于对模型完全新鲜：来源可能熟悉，模板可能重复，答案也可能经别的渠道流通。靠无关干扰变难，更不等于测得有意义。

Chen et al. 把静态到动态放进 contamination 讨论，提醒我们污染是来源、访问与内容生命周期共同决定的风险。生成—裁判闭环也可能很一致，却不对现实更有效。Preference Leakage 把这点说死了：生成器和裁判一沾亲带故，分数就能被悄悄抬高。如果出题、判题都偏好一种表述，被测模型熟悉那套风格，漂亮 scaling 曲线就未必还能支持原来的能力主张。

MAI 报告的 MRCR 消融也是提醒：少量针对性样本能显著抬高特定任务成绩，报告方却没有证据认为这种训练带来更一般的改进。这不是证明 MRCR 无价值，而是在问，涨分到底迁移了什么。

混训与 hacking 空间值得正视，但官方训练划分、披露的任务适配、未披露使用测试内容必须区分。声称泛化就给匹配的持出证据，声称特化就把范围说清。动态降低记原题的机会，却不会自动解决来源重叠、裁判偏差和反复调参；维护成本只是从题库制作转移到了持续测量。

6.2 水印、指纹与 AA：风险类比，不是具体指控

捷径未必是背答案。措辞、格式、元数据、水印或指纹式线索，都可能暴露评测来源；系统理论上可以识别“现在在考试”并切换策略。线索也可能只是偶然特征，不必假设有人刻意植入。

Kirchenbauer et al. 与 Sadasivan et al. 研究文本水印和检测边界，不能证明某个多模态榜单已被刷。从能识别来源，到能有效抬分，还隔着策略、访问条件和实验证据。

提 AA 时，我只谨慎地问：独特线索会不会辅助针对性优化？这篇不做具体刷榜指控。可讨论的是语义相同、表面格式不同的变体测试，以及来源隔离和访问审计。防污染、防捷径、防环境漏洞，最终要回到具体威胁模型：谁看见了什么，能改什么，判定信任什么。一句“我们是动态评测”，回答不了这些问题。

7. 到了长尾，我们还要不要什么都测？

7.1 覆盖更多，不一定更知道会在哪失败

常见任务不错之后，剩下的是那些小众语言、极其模糊的扫描件、时间跨度复杂的视频，或者是垂直工作流里偶发性的诡异失败。平均分上升，用户却可能一直撞同一类坑。平均值进步与局部体验没变，可以同时成立。

MMMU 与 MMT-Bench 说明能力不是单块铁板，但类别平均分不等于真实失败分布。不同的学科权重不同，用户碰到的频率不一样，出了错造成的后果更是天差地别。低频高后果错误可能比常见题多对几道更重要，也不能所有低频任务都无限投入。这个判断不能只靠评测者兴趣，更要看谁实际受影响、失败造成什么后果。

7.2 聚焦与面面俱到，都有不舒服的代价

聚焦可验证、高杠杆、难刷的核心，可能比画满雷达图更有价值。但谁定义核心？如果总是熟悉开发者工作流的人决定，其他语言、设备和普通用户就可能长期在边界之外。少测可以是诚实控范围，也可以是藏起难看的失败。

面面俱到则维护成本高，每类只有几道题，很容易制造“已经测过”的幻觉。一类三道题全对，不值得外推成覆盖了一个行业；类别再多，裁判不可靠，也只是把不确定性铺得更宽。

必须同时问：重不重要，以及能不能可靠地测。重要但暂时测不了，不该从需求清单消失；易测但无关，不该占满预算。指标成熟程度不应替代需求优先级。聚焦还应预先公开取舍、报告遗漏，不能看到自己模型分数不好，再临时宣布那部分不重要。这也是“关注过程”的一部分：评测者如何选择任务，本身需要解释。

7.3 可讨论折中：稳定核心、长尾探针、真实回归

我自己目前更认同一种三层的折中思路，而不是把所有东西绞进一个冠军总分。这三层也能放回前面的二维坐标系里：

第一层是稳定核心：挑可验证、有迁移价值的基础能力，固定协议、留历史锚点，服务长期比较和版本回归。稳定不是永不更新，而是每次升级都能说清楚改了什么。

第二层是长尾探针：持续引入新输入形态、新干扰和新用户群，用来发现未知失败，不一定适合长期公开排行。探针踩到新问题后，先评估影响范围和自动判定成本，再决定要不要提炼进核心层。

第三层是真实失败回归集：在授权与隐私合规前提下，把线上重大失败脱敏复现，专门回答“这个缺陷修好了没有”。它不必冒充通用能力测试，但要把可执行的证据反馈给 mid-train、post-train 或部署侧。

三层折中：比较、发现、验证修复

点选一层，看目的、公开榜适用性与训练反馈；三层分工，不合成一个冠军总分。窄屏可横滑。

层 01稳定核心层 02长尾探针层 03真实失败回归

稳定核心

目的挑可验证、有迁移价值的能力，固定协议与历史锚点，支持长期比较和版本回归。

适不适合公开榜较适合做明确范围的公开比较，前提是样本、判定和协议可信；稳定不等于永不更新，也不等于公开全部测试题。

怎么回馈训练定位基础短板与遗忘，比较 pretrain、mid-train、post-train 的收益和代价；升级核心时保留版本对照与隔离持出变体。

三层要联动：探针发现缺口，回归验证修复，反复出现的失败推动核心更新。但进入测试的问题又可能被学会，因此还得保留新的持出变体。修好一个样本，和修好一类问题，不是一个主张。

Datasheets 的思路可以借来公开构成、用途、未覆盖内容与限制。这只是待讨论框架：核心会不会越来越窄，探针谁维护，产品需求会不会被误当领域方向？我没有标准答案。至少应把资源取舍摆出来，不让一个总分替我们假装所有目标已经兼得。

8. 结语和展望

我不想给评测排最终座次。传统 metric、任务 benchmark、动态测试、交互环境各有分工；新不等于更真，难不等于更有用。真正的问题是，这把尺子在这个 point 上，能不能支持我们声称的改进。

我们预期大家可以思考的是：

• 分数对应什么能力主张，明确没覆盖什么？
• 用的是哪一时期的尺子，服务哪一生命周期阶段，结果该改变什么决策？
• 怎样区分正常学习、任务适配、污染、捷径与环境错误？
• 动态更新后如何保持可比，又不让锚点变成靶子？
• 小环境哪些结构必须保留，成功才对实际使用有解释力？
• 长尾预算谁来定，哪些人和哪些严重失败不能被平均掉？
• 发现失败以后，谁把证据送回训练、系统改进和回归？

最后一个问题最朴素，也最容易被跳过。如果评测只让发布表更完整，却不改变任何训练或使用决策，它到底推进了什么？

通往真正促进领域进步的多模态评测，可能需要更清楚的能力主张、更诚实的边界，以及把测量带回实际改进的路。不是再找一个数字替我们免除判断，而是让每一步判断更有证据。这篇先抛砖引玉，想听听大家的答案。

9. References

评测视角、商业榜单与过程观察

• Ma, Saxon, Yue，NeurIPS 2025：The Science of Benchmarking。
• Liang et al.：HELM。
• Artificial Analysis / AA：公开比较平台实例，不是本文刷榜指控的证据。
• Thinking Machines：Inkling 2 Small 发布帖。
• Connor Frank / Vals AI：Inkling 2 Small: An Inkling of Profanity；The Decoder：相关转述。

传统任务、表示与分布漂移

• Russakovsky et al.：ImageNet / ILSVRC。
• Lin et al.：COCO；Chen et al.：COCO Captions。
• Radford et al.：CLIP。
• Recht et al.：ImageNetV2；Hendrycks and Dietterich：ImageNet-C；Koh et al.：WILDS。

任务 benchmark、裁判与基础设施

• Goyal et al.：VQAv2；Hudson and Manning：GQA；Singh et al.：TextVQA。
• Fu et al.：MME；Liu et al.：MMBench。
• Yue et al.：MMMU；Lu et al.：MathVista；Ying et al.：MMT-Bench。
• Liu et al.：Visual Instruction Tuning / LLaVA-Bench。
• lm-evaluation-harness；Zhang et al.：LMMs-Eval。

动态评测、污染、适应与覆盖边界

• Yang et al.：VLB。
• White et al.：LiveBench；Jain et al.：LiveCodeBench。
• Simin Chen et al.，EMNLP 2025：Benchmarking Large Language Models Under Data Contamination: A Survey from Static to Dynamic Evaluation。
• Dwork et al.：Generalization in Adaptive Data Analysis and Holdout Reuse。
• Dancette et al.：VQA-CE。
• Zheng et al.：Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena。
• Dubois et al.：Length-Controlled AlpacaEval；LMSYS：Does style matter?。
• Li et al.：Preference Leakage。
• Kirchenbauer et al.：A Watermark for Large Language Models；Sadasivan et al.：Can AI-Generated Text be Reliably Detected?。
• Gebru et al.：Datasheets for Datasets。

交互环境、真实研究任务与漏洞讨论

• Zhou et al.：WebArena；Koh et al.：VisualWebArena；Xie et al.：OSWorld。
• Qiuyang Mang、Wenhao Chai et al.：FrontierCS / 代码；FrontierCS 2，arXiv:2610.29932 / 项目站。
• Qiuyang Mang、Wenhao Chai 与 FrontierSmith 团队：FrontierSmith。
• Xiaomi：MiMo-V2.6 Technical Report，尤其 reward hacking mitigation 与评测协议部分。
• Ian Barber：Environments and Benchmarks：对 DeepSWE 等环境与判定问题的讨论，含第三方审计转述。
• Oliver Chen、Anthony Ozerov / Vals AI：MiMo 训练环境答案泄漏审计。
• Standard Normal：MiMo2.6 Hacking Report：带攻击提示的环境漏洞测试，不能当成模型日常行为的无条件结论。

生命周期、迁移与训练技术报告

• Thinking Machines：On-Policy Distillation / OPD。
• Mistral AI：Mistral Large 4，尤其 §3.1 的架构与 agentic penalty 消融。
• Qwen Team：Qwen3 Technical Report，尤其 post-training 阶段与阶段间评测。
• Microsoft AI：MAI-Thinking-1，尤其 mid-training、RL climb 与附录评测；此处引用公开报告，不据此推定开放权重。