视觉原语还是文本坐标？多模态模型路线对比

一、对比背景

最近，某开源系列发布了其首个实验性多模态模型，社区讨论的焦点并不是参数规模，而是它延续了“视觉原语（Visual Primitives）”这条技术路线：在其公开的分词器配置中，注册了一组成对出现的特殊token，分别对应“方框（box）”“点（point）”“多边形（polygon）”，以及用于指代表达的“引用（ref）”标记。这意味着模型在生成文本时，可以原生输出结构化的几何标注，而不是用自然语言去“转述”位置。

对应用开发者而言，这背后是一个很实际的选型问题：构建图像理解、视觉定位、文档解析类应用时，应选择“模型原生输出几何结构”的视觉原语路线，还是沿用“模型输出自然语言或纯文本坐标”的传统路线？两条路线在架构改造、集成成本、下游解析、数据构造上差异明显，方向选错的返工成本很高。本文即围绕这一对比展开。

二、对象定义

方案A：视觉原语路线（以该实验模型为代表）

核心做法是在模型词表中扩展特殊token，用成对的“开/闭”标记包裹几何元素，形如 <box>…</box>、<point>…</point>、<polygon>…</polygon>；同时提供 <ref>…</ref> 式的引用标记，显式表达对某个对象或区域的指代。以该模型为例，其分词器配置中这组token被标记为特殊词元（special），拥有独立的token id，不参与普通文本的大小写归一化等处理，也不会被常规分词逻辑拆碎。于是模型输出流天然带有结构边界，例如：“图中左侧的红色车辆位于 <box>坐标</box> 区域内”。

方案B：传统文本表达路线

模型不改动词表，视觉定位结果以两种形式输出：一是纯自然语言描述（“画面左上角有一辆红色轿车”）；二是把坐标当作普通文本token生成（如”[120, 45, 300, 210]”这类字符串）。结构信息完全依赖文本约定，模型自身不提供显式结构边界。

三、相同点分析

两条路线并非对立的技术体系，基础层面高度共享：

1. 目标一致：都为了让多模态模型“看懂图”并能定位、指代图像中的对象，服务图像问答、目标定位、区域描述与文档理解等任务。
2. 架构底座一致：主流做法都是“视觉编码器 + 投影层 + 自回归语言模型”，图像被编码为token序列后与文本拼接、统一解码。视觉原语路线改变的是“输出词表与目标格式”，不改变总体架构。
3. 训练范式相近：都依赖图文配对的监督微调数据，都需要模型学会将视觉区域与语言指代对齐。
4. 都需要应用层后处理：无论哪条路线，把模型输出变成业务可用的结构化数据，都需要一层解析与校验逻辑，差别只在复杂度。

四、核心差异分析

1. 几何表达能力：仅框 vs 框+点+多边形

传统文本路线受“人读得舒服”的格式约束，通常只稳定输出矩形框坐标；多边形轮廓、密集点集这类长序列结构放进自由文本，容易被截断、格式漂移，或被模型“偷懒”省略。视觉原语路线把多边形作为一等公民：成对的开闭token给了模型明确的“开始/结束”信号，任意边数的轮廓在生成上有约束、在解析上有保证。点原语则适合关键点、中心点等定位粒度。对文档版面、票据、图表这类不规则区域密集的场景，多边形能力常是“可用”到“好用”的分界线。

2. 输出可解析性与稳定性

特殊token提供确定性结构边界，解析器可做成简单状态机：

def parse_stream(tokens):
    results, stack = [], []
    for tok in tokens:
        if tok.is_open_primitive():        # 如 <box> / <polygon>
            stack.append(Primitive(tok.kind))
        elif tok.is_close_primitive():     # 如 </box> / </polygon>
            node = stack.pop()
            node.coords = parse_coords(node.buffer)
            results.append(validate(node))  # 坐标校验与越界裁剪
        elif stack:
            stack[-1].buffer.append(tok)
        else:
            emit_text(tok)
    return results

文本路线的解析则依赖正则匹配或二次抽取，格式稍有漂移（多一个空格、坐标顺序变化、模型加了“大概在”这类修饰）即告失败，防御成本随任务复杂度上升。

3. 词表与推理链路改造深度

视觉原语路线需要：扩展词表并固定特殊token id；对话模板正确处理这些token；解码时明确保留或剥离它们；若做推理加速，还需确认静态词表、缓存等优化组件对新增token的兼容。任何一环处理不当，特殊token被当作普通文本重新分词，结构即被破坏。文本路线几乎零词表改造，接入现有推理与服务框架的摩擦小得多。

4. 训练数据构造与标注成本

视觉原语路线要发挥威力，训练数据必须包含大量“图文交错 + 几何原语标注”样本：目标框、多边形轮廓、点及引用式指代表达，标注成本与门槛高于普通图文描述数据。文本路线对数据格式更宽容，普通caption与问答数据即可起步，坐标类数据可渐进补充。

5. 指代表达的显式性

成对引用标记让“指代”成为显式结构：模型可先输出对象描述，再在多轮对话中回指，追问“它右边的那个是什么”时，指代链路清晰、机器可追踪。文本路线的指代靠语言上下文隐式解析，多轮场景下歧义与漂移概率更高。

6. 工具链与生态兼容性

特殊token相当于一套“私有序列化协议”：若输出需要再喂给另一个不认识这些token的模型或组件，要么先做转换，要么忍受token被拆分或判为未知。文本输出则天然全局可读。跨系统流转频繁的链路要重点评估这一点。

7. 版本与接口稳定性

该模型明确为实验性版本，意味着token设计、坐标约定、模板格式都可能在后续版本调整，将解析逻辑硬编码在生产链路上风险较高。传统文本路线经过更多代际沉淀，接口约定相对成熟。

五、对比速查表

维度	视觉原语路线	传统文本表达路线
几何表达	框/点/多边形，粗到细全覆盖	以框与自然语言为主，多边形能力弱
输出结构	特殊token显式分界，确定性高	依赖文本约定，易格式漂移
解析成本	状态机式解析，成本较低	正则/二次抽取，防御成本高
词表改造	需扩展并固定token id	基本无需
指代表达	显式引用标记，多轮可追踪	隐式，依赖上下文
数据要求	需几何原语标注，成本较高	caption/QA数据即可起步
生态兼容	私有协议，跨系统需转换	全局可读，兼容性好
稳定性	实验版本，约定可能变更	约定相对成熟

六、典型场景怎么选

1. 文档/票据/图表解析（版面区域不规则、需精确定位）：优先视觉原语路线，多边形对倾斜文本行、异形表格区域的价值明显。
2. 视觉Agent/UI自动化（下游是程序、需要机器可读坐标）：优先视觉原语路线，解析确定性与指代链路直接决定任务成功率。
3. 看图问答、内容审核辅助、图像描述（下游是人）：文本路线足够，接入成本更低。
4. 输出需跨系统/跨模型流转的Pipeline：文本路线更省心；若用视觉原语，务必加一层结构化转文本的适配。
5. 快速原型验证阶段：先用文本路线跑通业务闭环，验证价值后再评估迁移。

七、选型建议（条件化）

• 看下游消费者：下游是代码、Agent、数据库时，视觉原语的结构化收益最大；下游是人的阅读界面时，文本路线更直接。
• 看几何粒度需求：只需“框住目标”，两条路线差距有限；需要轮廓、关键点、密集区域时，多边形与点原语是实质差异点。
• 看团队改造能力：能长期维护自定义分词器、解析器与评测集的团队，视觉原语路线门槛可控；工程资源紧张时，文本路线更稳妥。
• 看版本成熟度：实验版本适合预研与对照验证，不建议未做抽象隔离就将生产关键路径单点绑定。
• 部署层面：自建推理集群与云上托管各有机会成本；若选择云上部署，可评估百度智能云等平台在GPU算力、容器化推理服务、日志与监控告警等通用能力上的支持，把团队精力集中在解析与应用层建设。

八、迁移与使用注意事项

若决定采用或迁移到视觉原语路线，建议按清单逐项确认：

1. token id对齐：模型版本升级或更换实例时，逐一核对特殊token id是否变化，词表相关的静态优化与缓存需重建。
2. 坐标系约定：确认坐标是归一化（0-1）还是像素值、框顺序是xyxy还是xywh、多边形点序是否有方向要求；不同模型间这些约定并不统一。
3. 防御式解析：即使有结构边界，模型仍可能生成未闭合标记、越界坐标或异常数值，解析层必须做校验、裁剪与兜底。
4. 模板适配：特殊token在对话模板中的位置、是否被剥离，直接影响下游展示与多轮上下文拼接。
5. 评测先行：用自有业务数据做小规模定位准确率与解析成功率评测，再决定是否全面切换，不要只看公开样例。
6. 输出安全：坐标型输出同样可能指向图像中的敏感区域，内容审核策略需覆盖结构化输出。
7. 兼容层设计：在业务与模型之间保留一层输出抽象（统一坐标结构、统一错误码），为未来切换路线或版本升级留出余地。

九、总结

回到最初的问题：这次开源实验模型值得关注的地方，不只是又多了一个多模态模型，而是它把“视觉原语”这条接口设计思路再次推到台前——让模型用原生的几何token“说话”，而不是用自然语言转述几何。两条路线没有绝对优劣：视觉原语用更高的接入与数据成本，换取结构化、可解析、细粒度的定位能力；文本路线用更弱的几何表达，换取极低的接入门槛与广泛的生态兼容。选型的落点在于三个问题：下游是机器还是人、需要框还是轮廓、团队能否承担词表与解析层的长期维护。把这三个问题想清楚，答案自然浮现。