多模态视觉推理演进：从语言描述到结构化原语

一、从两个“鸿沟”说起：模型到底错在哪

讨论多模态模型的视觉能力时，业界过去几年把注意力集中在“感知鸿沟”（Perception Gap）上：输入图像在进入模型前会被缩放、切块、压缩，细节信息在预处理阶段就有损耗；再加上视觉编码器的分辨率与感受野限制，模型确实可能“看不清”小目标、密集区域和细粒度纹理。对应的工程手段也很成熟——提高输入分辨率、切片推理、多尺度特征等。

但近期的研究与大量实践暴露出另一个更隐蔽的问题：即使模型“看清了”，它在回答时仍然要用自然语言去“说”图像里有什么。自然语言是线性、歧义的符号系统，而视觉空间是连续、二维甚至三维的结构。当任务要求“数出图里一共有多少人”“框出左起第三名球员”时，模型需要在内部把连续的视觉布局翻译成离散的语言描述，再基于这份“二手描述”做推理。这个转译环节一旦失真，下游逻辑就会崩溃——计数会重复或遗漏，定位会偏移，路径规划会自相矛盾。这就是所谓的“指代鸿沟”（Reference Gap）。

两个鸿沟的区分在工程上非常有价值：如果误差主要来自感知鸿沟，优化方向是数据与预处理；如果来自指代鸿沟，优化方向则是输出表示与推理范式。很多团队反复加数据、调分辨率却收效甚微，正是因为问题出在后者。

二、两条技术路线：视觉原语与图像思考

2.1 视觉原语：把“指针”还给视觉空间

针对指代鸿沟，业界提出过一类很有代表性的思路：让模型用结构化的“视觉原语”（Visual Primitives）来指代图像中的对象，而不是用自然语言描述。常见的原语有三类：

• 方框（box）：轴对齐矩形，用两个角点坐标表示，适合目标定位与区域引用；
• 点（point）：单一坐标，适合密集计数场景下“一个对象一个指针”的简洁表达；
• 多边形（polygon）：顶点序列，适合轮廓级别的精细分割与形状描述。

这些原语本质上是连续视觉空间中的“无歧义指针”：坐标就是坐标，不存在“左边第三个人”这类指代歧义。模型可以先输出一组点完成计数，再基于这些指针做进一步推理——语言只负责高层语义，空间关系全部交给结构化表示。

2.2 图像思考：把感知变成工具调用

另一条路线通常被称为“图像思考”（Thinking with Images）：模型在推理过程中不满足于一次性“看完”整张图，而是把图像当作可以反复操作的对象——裁剪感兴趣区域、放大局部、在图上标注中间结果，然后基于操作后的新观察继续推理。它把“感知”从一次前向传播，变成了一个多轮的 agent 循环，每轮都是“观察—思考—操作—再观察”。

这条路线与 agent 工具生态天然契合：裁剪、缩放、画框都是普通函数调用，模型只需要学会“何时调用、如何传参”。可解释性也好——每一步裁剪都留下了显式的推理痕迹，便于回溯与调试。

2.3 路线取舍：没有银弹，只有权衡

• 视觉原语路线输出结构稳定、后处理简单，一次前向即可完成密集预测；但强依赖训练阶段的标注数据（框、点、多边形都要有监督信号），对训练分布外的布局泛化有限。
• 图像思考路线灵活、可解释、能复用现成工具链；但推理链路长、延迟与成本高，且“何时停止裁剪”本身是个难题——策略不当反而引入新的遗漏。

实践中还有一个值得玩味的现象：一些团队会从原语路线转向图像思考路线。这通常不是学术偏好，而是工程考量——agent 化的产品形态要求模型能力与工具调用框架深度耦合，走工具路线可以最大化复用已有的 harness、解析器与护栏逻辑，代价是放弃端到端结构化输出的部分稳定性。选型时应结合业务形态（批量离线处理 vs 交互式 agent）判断，而不是简单认定哪条“更先进”。

三、落地细节一：tokenizer 中的特殊 token 设计

判断一个多模态模型是否原生支持结构化定位，最直接的证据之一是查看它的 tokenizer 配置：是否注册了成对出现的特殊 token。典型的设计模式如下：

{
  "added_tokens": [
    { "content": "<|box|>",      "special": true },
    { "content": "<|/box|>",     "special": true },
    { "content": "<|point|>",    "special": true },
    { "content": "<|/point|>",   "special": true },
    { "content": "<|polygon|>",  "special": true },
    { "content": "<|/polygon|>", "special": true }
  ]
}

这里有几个值得注意的工程细节：

1. 成对的开启/闭合标签。闭合标签不只是语法糖，它为下游解析器提供了明确的边界信号，便于用正则或状态机可靠抽取坐标段落，同时防止坐标数字泄漏进普通文本流。
2. 坐标序列化格式。业界常见做法是将坐标归一化为固定范围的整数（例如 0～1000），好处是与输入分辨率解耦——同一模型可处理任意尺寸图像，输出坐标按比例映射回去即可，也避免了浮点数在文本流中长度不可控的问题。
3. 特殊 token 必须在词表中“保留”，不被普通分词逻辑切开。如果 <|box|> 被拆成若干普通子词，整个结构化协议就形同虚设。自建模型时这是常见的隐蔽 bug。

模型输出通常形如：

<|box|>312,145,498,367<|/box|>
<|point|>842,215<|/point|>
<|polygon|>100,80;240,65;310,190;120,220<|/polygon|>

解析侧只需要一个小的状态机：遇到开启标签进入采集态，遇到闭合标签把缓冲区交给坐标解析器，再做一次范围校验（坐标是否越界、多边形是否闭合）。

四、落地细节二：为什么论文指标与线上体验会对不上

密集计数和路径规划常被当作视觉推理的“试金石”，因为它们对指代歧义零容忍：计数要求每个对象被唯一指认（漏一个、重一个都算错），路径规划要求多步空间推理保持全局一致。在这类任务上，指代鸿沟的破坏力会被成倍放大。

实践中经常出现这种情况：论文或演示效果不错，自己接入后明显缩水。在怀疑“宣传夸大”之前，先排查几个更常见的工程原因：

• 输入预处理不一致：线上服务为控制成本做了更激进的缩放或压缩，密集小目标首当其冲；
• Prompt 模板差异：评测使用的指令模板、few-shot 示例与产品端不同，而定位类任务对指令措辞相当敏感；
• 解码参数差异：温度、采样策略会影响结构化输出的合法性，高温采样可能产出无法解析的坐标片段；
• 工具链版本落后：本地 CLI 或 SDK 版本陈旧，实际请求的推理模式与论文描述并不一致；
• 评测口径不一致：论文用的是受控测试集，线上是分布外真实数据。

由此得出第一条实践准则：评测必须与部署对齐。建议自建一套“黄金评测集”，覆盖计数、单目标定位、多目标定位、轮廓级分割等任务，用与线上一致的预处理、prompt 和解码参数跑分，并把指标漂移纳入监控告警。云上做这件事并不复杂：用对象存储管理图像资产与标注文件，用模型服务托管被测模型，用日志服务收集结构化输出，再配一个定时任务对比指标曲线即可。

五、落地细节三：Agent 工具链与配置管理

视觉 agent 的体验很大程度取决于 harness（工具链外壳）的质量，而 harness 恰恰是文档最容易缺位的地方。一个典型场景：官方推送了新的视觉模型，却没说明命令行工具需要先升级才能识别新配置，用户按直觉操作会得到莫名其妙的报错。正确的姿势往往类似：

# 1. 先把命令行工具升级到最新版本
pkg update -g <agent-cli>
# 2. 切换到与网页端同源的配置档
<agent-cli> --profile web

这里的教训值得所有提供模型服务的团队吸取：

1. 配置变更要写进发布说明。模型名、profile、端点这类“接线信息”的任何变化，都应在官方渠道显式交代，而不是依赖用户自行猜测。
2. 面向第三方开发者的接入文档要与工具版本绑定。明确写出最低版本要求和升级命令，否则第三方拿到的是一份无法复现的文档。
3. 配置即代码。把模型名、profile、采样参数放进受版本管理的配置文件，而不是散落在终端历史里，团队协作时尤其重要。

对使用者一方的建议是：遇到“演示效果与实际不符”时，先检查工具链版本与配置档，再怀疑模型能力本身——这是成本最低的排查顺序。

六、企业落地建议：选型、评测与数据闭环

把前面的分析收敛成可执行清单：

• 能力评估维度：定位精度（IoU、命中率）、结构化输出稳定性（可解析率）、工具调用兼容性（能否接入现有 agent 框架）、推理成本（长链路图像思考的延迟与费用）。
• 场景匹配：批量离线的密集预测优先考虑结构化输出路线；交互式、需要多轮排查的场景优先考虑图像思考路线。
• 评测闭环：自建黄金集 + 与线上一致的推理配置 + 指标监控告警。
• 数据闭环：把线上坏例（计数错误、框偏移）回流到标注队列，作为下一轮微调或 few-shot 库的素材。

以百度智能云为例，上述流水线所需的通用能力都有对应的产品类目支撑：对象存储承载图像与标注资产，模型服务承载推理与版本管理，容器平台或函数计算承载定时评测任务，日志服务与监控告警承载指标漂移的发现。企业无需自建整套 MLOps 设施，重点应放在评测集建设与坏例闭环这两个真正构成壁垒的环节上。

七、总结

多模态视觉推理的瓶颈正在从“感知鸿沟”转向“指代鸿沟”。视觉原语用结构化 token 把空间指代从自然语言中解放出来，图像思考则把感知升级为多轮工具调用——两者是同一问题的不同解法，取舍取决于产品形态与工程约束。对工程团队而言，比追问“哪条路线更强”更有价值的是：读懂 tokenizer 里的协议设计、保证评测与部署对齐、把工具链配置当作一等公民来管理。做到这三点，无论底层模型如何迭代，视觉推理链路都能保持可评估、可复现、可演进。