多模态：图片怎么被读懂 | 大模型 | 做产品

多模态：图片怎么被读懂

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

你会遇到的现象

• 发一张整屏截图让它找按钮，它把界面描述得头头是道，按钮位置说错了

• 发一张表格图，大标题读得准，表格里的小字全读串了

• 换个模型，同一张图一个读得出、一个读不出，你不知道差在哪

图是怎么进去的

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

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

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

于是它有这些边界

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

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

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

它看到的细节上限，在缩放那一步就已经定死了

整屏截图直接发

缩放

小字糊成一片，后面再怎么问都补不回来

裁出你关心的那一块

原尺寸

小字就能读了——所有技巧里最有效的一条

图片是给它看结构和布局的，不是给它读字的 图里的数字、字段名、报错内容，能贴文字就贴文字。要它定位元素，靠的应该是页面的 DOM 或元素清单。 对精度有硬要求就别用通用模型：读发票、认车牌、扫条码，专门的 OCR 又准又便宜。

它做得好的是看整体、看关系、看语义——这张图在讲什么、布局有没有问题、两版设计差在哪。凡是需要「基于像素的判断」的，都该换个做法。

怎么给它图

• **裁剪，不要缩放。**你关心哪一块就把哪一块裁出来单独发。整屏截图会被压得看不清细节，而裁出来的局部按原尺寸进去，小字就能读了。这一条是所有技巧里最有效的。

• **关键信息用文字补一遍。**图里的数字、字段名、报错内容，能贴文字就贴文字。图片是给它看结构和布局的，不是给它读字的。

• **一次一张，别铺一堆。**多张图会互相干扰，而且每张都在吃上下文。要对比两张，明确说清楚哪张是 A、哪张是 B，再问具体的差异点。

• 问具体的问题。「这张图有什么问题」得到的是一堆泛泛而谈。「这张图里的主按钮和次按钮，视觉权重是不是反了」才能得到有用的回答。

• **算上图片的成本。**一张图通常折算成几百到上千个 token，高分辨率模式下更多。做多图场景之前先估一遍账，别等上线才发现贵。

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

接着看

大模型的运作原理 图片接进序列之后，接下来发生的还是同一件事：猜下一个 token。

Token 与计费单位 图片也要折算成 token 计费。先搞清楚这个单位怎么算。

参考锚点 给它图最有价值的用法：拿一张参考图当目标，让它照着做。