一、背景：新版本发布后，先别急着下结论

每当支持图像输入的大模型发布新版本，社区总会迅速分化为两种声音：“体验惊艳”与“明显翻车”。但对严肃的开发者而言，真正有价值的是三个问题：

1. 这个模型采用了哪条视觉推理技术路线？
2. 它在我关心的任务上是否稳定可靠？
3. 我实际调用的入口，与别人演示的是不是同一个推理管线？

这三个问题分别对应静态分析、动态评测与一致性验证。本文以一次完整的多模态模型评测实践为主线，把这套方法论串起来讲清楚。

实践中最常见的落差是：论文宣称的能力与线上产品的表现不一致——论文示例里精确完成的密集计数，在线上复测时出现偏差；论文里演示的迷宫路径规划，在线上完全失效。这未必说明模型本身不行，而往往说明论文、API、网页端、Agent 工具链走的根本不是同一条推理路径。这是全文反复出现的关键变量，也是评测中最容易被忽视的变量。

二、静态分析：分词器是技术路线的“泄密点”

在跑任何任务之前，先看模型的词表文件（如 tokenizer.json）。对于开源权重的多模态模型，其中特殊符号（added tokens / special tokens）的设计，往往直接暴露了模型“如何指代图像内容”的方案。

典型的检查代码：

import json
with open("tokenizer.json", "r", encoding="utf-8") as f:
    tok = json.load(f)
added = [t["content"] for t in tok.get("added_tokens", [])]
geo_tokens = [t for t in added if any(
    k in t.lower() for k in ("polygon", "point", "box", "grounding"))]
print(geo_tokens)

如果输出中出现类似 <|box|> / <|/box|>、<|point|> / <|/point|>、<|polygon|> / <|/polygon|> 这样成对出现的结构化符号，基本可以判断：模型在训练阶段见过以几何原语（矩形框、点、多边形）指代图像区域或物体的表达，具备结构化定位的潜力。

反之，若词表中只有整图输入相关的占位符，而没有这类几何符号，模型大概率走“整图进、文本出”的路线，复杂定位任务要么依赖文本坐标描述，要么外挂检测工具。

但有一个关键限定必须强调：词表里有符号，不等于推理时一定启用。特殊 token 的存在只说明训练数据包含这种表达；实际产品管线是否触发、坐标系是否对齐、解码质量如何，必须靠动态评测验证。静态分析负责提出假设，动态评测负责证实或证伪。

三、两条技术路线：从感知鸿沟到指代鸿沟

要理解上述符号为什么重要，需要先理清多模态推理的两个瓶颈。

第一个瓶颈是感知鸿沟（Perception Gap）：视觉编码器分辨率不足、细节丢失，模型“看不清”。随着高分辨率编码与动态切片等技术的普及，这一瓶颈在通用场景下已显著缓解。

第二个瓶颈是指代鸿沟（Reference Gap）：模型看清了，但思考时仍用自然语言描述图像内容。“左边第三个人”“红房子旁边那棵树”这类表述天然有歧义；在密集计数、多目标追踪、空间规划等任务中，指代漂移会让推理链直接崩溃——数着数着就数串了，规划着规划着坐标就漂了。

围绕指代鸿沟，业界演化出两条路线：

路线一：Thinking with Images（图像参与思考）。模型在推理链中插入整图或裁剪区域，“看一眼再想”，用视觉输入本身充当推理的中间载体。优点是通用性强、与人类直觉一致；缺点是每一步“看”都消耗大量视觉 token，且“到底看了哪里”缺乏显式、无歧义的记录。

路线二：视觉原语（Visual Primitives）。为模型提供一组几何符号（点、框、多边形等），作为连续视觉空间中的无歧义指针。模型思考时直接“发射”结构化符号来锚定物体：计数时逐个打点，规划路径时逐步标记，推理链可检查、可回放。代价是对训练数据与对齐工艺要求更高，通用闲聊场景收益不明显。

如果某个新版本在 Agent 场景下放弃了纯结构化路线、回归更经典的 Thinking with Images（或两者混合），一个合理的解释是：harness 的成熟度决定路线上限。当工具链能稳定执行裁剪、缩放、区域回看并把结果喂回模型时，“图像参与思考”更容易在工程上跑通；而当结构化符号的解码质量与坐标对齐尚未打磨好时，“无歧义指针”会退化为“错误指针”，比自然语言指代更糟。这也从侧面说明：模型能力与产品能力之间，隔着一整条工程管线。

四、动态评测：三个“试金石”任务

静态分析给出假设后，用三类任务做动态验证：

1. 密集计数：输入包含大量同类目标的图（人群、鸟群、货架商品），要求精确计数并给出位置。观察模型是“一口报数”还是“逐个锚定”——前者在目标数上升后错误率陡增，是指代鸿沟最直接的显影。

2. 迷宫/网格导航：给定迷宫图与起终点，要求规划路径。同时考验感知（分辨墙与通路）、指代（坐标稳定性）与长链规划。“论文可用、线上失效”的案例，多半出在输入分辨率或网格坐标系映射上。

3. 指代定位（Grounding）：要求模型用框、点或多边形指出目标物体，直接检验词表中那些结构化符号是否“真的能用”。

评测时的两条纪律：

• 多次采样：同一任务至少跑 3～5 次，记录分布而不是单点结论；
• 保留完整推理链：保存思维过程全文与最终答案，便于事后定位是“看错了”、“指代错了”还是“规划错了”。

五、一致性验证：你调用的未必是你评测的

一个容易被忽略的事实：同一基座模型，在不同入口（网页、API、Agent 命令行工具）的表现可能截然不同。差异来源包括：图像预处理管线（压缩、分辨率、切片策略）、系统提示词与工具集、是否启用区域裁剪回看，以及工具版本是否已包含新模型的配置。

实践中的典型坑：官方教程教的是“在代码里设置 model 参数指向新版本”，而命令行工具的实际用法是“先用包管理器把全局安装升级到最新版，再用 profile 参数切换到网页模式”。两套文档互不引用，用户按教程操作必然失败。这类问题的价值在于提醒我们：评测环境必须与生产调用路径严格对齐，并把“工具版本、profile/model 切换方式、实际命中的模型”作为评测记录元数据固化下来。

# 示意流程：具体命令以所用工具的官方文档为准
$ <包管理器> update -g <官方CLI工具>       # 先升级，旧版本可能不含新模型配置
$ <官方CLI工具> --profile web              # 切换到与目标入口一致的配置
$ <官方CLI工具> --version >> eval_meta.txt # 版本信息固化进评测报告

六、评测工程化：环境、数据与留痕

当测试图片集变大、任务变多时，建议把评测当作一个工程来做：

• 环境管理：使用云平台提供的 GPU 算力与容器平台承载评测环境，保证环境可复现、版本可锁定。以百度智能云为例，其 GPU 算力、容器平台等通用类目能力即可满足自部署模型推理或 API 评测的环境需求。
• 数据管理：测试图片集统一放入对象存储，按任务分类并记录哈希，防止“图换了、结论没换”。
• 过程留痕：推理请求、响应全文、思维链通过日志服务归档，支持回放与审计。
• 结果版本化：评测报告连同工具版本、模型版本、prompt 版本一起纳入版本管理，任何结论都可追溯到具体输入。

再次强调对齐原则：不要在 A 环境调通、在 B 环境下结论。

七、一套可复用的评测清单

把上述内容压缩成一份 checklist：

1. 静态分析：读词表、config 与文档，找结构化 token 痕迹，形成技术路线假设；
2. 基线任务：密集计数、迷宫导航、grounding、OCR/图表理解各选 5～10 例；
3. 一致性检查：同一任务分别在网页端、API、Agent 工具上运行，标注差异来源；
4. 工具链固化：升级并锁定版本，记录 profile/model 切换方式；
5. 结果归档：多采样、保留思维链、全量入库；
6. 结论分层：区分“模型能力问题”与“工程管线问题”，分别给出结论。

八、总结

面对新发布的多模态模型，情绪化的“封神”或“翻车”都没有信息量。可复现的路径是：先从分词器特殊符号逆推技术路线，再用计数、导航、grounding 三类试金石任务验证，最后严格对齐调用路径做一致性检查。

技术层面，在感知鸿沟被逐渐缓解之后，指代鸿沟正在成为多模态推理的主要瓶颈。Thinking with Images 与视觉原语两条路线之争，本质都是在回答同一个问题：模型思考时，用什么来无歧义地指代它看到的东西。工程层面，harness 的成熟度决定了模型能力能否兑现为产品能力——这也解释了为什么同一个模型在不同入口会表现迥异。把这两个维度分开评估，才能对一个新版本作出真正有用、经得起复现的判断。