做产品 PMaker 首页
搜索
跟随系统
颜色主题
空格的键盘
图片是被切碎、编码,然后接进同一条序列的缩放图片先被缩放到模型能接受的尺寸细节上限在这一步就定死了,小字先糊切块切成 patch,每一块交给视觉编码器变成向量映射拼接向量映射成和文字 token 同空间,接进文字序列一起进模型继续生成模型不再区分文字和图片,照样一个接一个猜下一个 token文字理解的毛病,读图时一个不少对精度有硬要求,别用通用模型——专门的 OCR 又准又便宜

它不是「看」了一眼图,是把图切成一格一格、编成和文字同一种向量,再接到序列里。能看多细,取决于切了多少格。

多模态:图片怎么被读懂

多模态是后来加装的,不是天生的。加装的方式决定了它能看多细。

多模态是后来加装的,不是天生的。加装的方式决定了它能看多细。

多模态是加装上去的,不是天生的。加装的方式是把图切成小块、编成向量,接到文字序列后面。所有能力和所有毛病都由这个方式决定。

你会遇到的现象:

  • 发一张整屏截图让它找按钮,它把界面描述得头头是道,按钮位置说错了
  • 发一张表格图,大标题读得准,表格里的小字全读串了
  • 换个模型,同一张图一个读得出、一个读不出,你不知道差在哪

图是怎么进去的

流程是这样的:图片先被缩放到模型能接受的尺寸,然后切成一格一格的小块(patch),每一块交给一个视觉编码器,变成一串向量。这些向量再经过一层映射,变成和文字 token 同一个空间里的东西,接到文字序列里一起进模型。claude-vision

关键在最后一步:**接进去之后,模型不再区分哪些来自文字、哪些来自图片。**它照样是在那条序列上一个一个往下猜 token。你问它图里有什么,它是在「接话茬」,只不过接话的依据里多了几百个来自图片的向量。

这也就解释了几件事。第一,它读图和读字用的是同一套推理能力,所以文字理解上的毛病——会编、会记串、会顺着你说——读图时一个不少。第二,图片是要占上下文的,占的还不少。第三,它看到的细节上限,在缩放和切块那一步就已经定死了,后面再怎么问都补不回来。

于是它有这些边界

凡是需要像素级精度的事,它都做不好,而且机制上的原因很清楚:

做不好的事 机制上的原因
读清楚小字 图被缩放过,小字在 patch 里已经糊了
给出精确坐标 它只知道大致在第几块,不知道第几个像素
数清楚数量 数数本来就是弱项,切块之后更难对齐
判断细微的颜色和间距差异 压缩过程中这些差异最先被抹掉
看懂超长截图 要么被压得更狠,要么被切成很多块,两头不讨好
可靠地读手写体、复杂表格 语料里这类样本本来就少

前两行决定了一件事:**不要让它做「基于像素的判断」。**要它定位元素,靠的应该是你给的结构化信息(比如页面的 DOM 或元素清单),不是让它盯着截图看。

反过来,它做得好的也很清楚:**看整体、看关系、看语义。**这张图在讲什么、布局有没有明显问题、两版设计的差别在哪、图表反映的趋势是什么——这些不依赖像素级精度的任务,它相当可靠。

怎么给它图

  • **裁剪,不要缩放。**你关心哪一块就把哪一块裁出来单独发。整屏截图会被压得看不清细节,而裁出来的局部按原尺寸进去,小字就能读了。这一条是所有技巧里最有效的。
  • **关键信息用文字补一遍。**图里的数字、字段名、报错内容,能贴文字就贴文字。图片是给它看结构和布局的,不是给它读字的。
  • **一次一张,别铺一堆。**多张图会互相干扰,而且每张都在吃上下文。要对比两张,明确说清楚哪张是 A、哪张是 B,再问具体的差异点。
  • 问具体的问题。「这张图有什么问题」得到的是一堆泛泛而谈。「这张图里的主按钮和次按钮,视觉权重是不是反了」才能得到有用的回答。
  • **算上图片的成本。**一张图通常折算成几百到上千个 token,高分辨率模式下更多。做多图场景之前先估一遍账,别等上线才发现贵。openai-vision

最后一条判断给做产品的人:**如果你的功能对精度有硬要求,别把识图这一步交给通用模型。**读发票、认车牌、扫条码,这些有专门的 OCR 和检测模型,又准又便宜。通用多模态模型的位置是理解和串联,是在你把结构化信息取出来之后,帮你判断这些信息意味着什么。

参考资料

  1. Vision — Anthropic Docs
  2. Vision guide — OpenAI Docs