随手拍的一张收据照片，光线偏暗，边角折了一折，字迹被手指挡住一半。人看一眼会先判断“这张大概能读，但金额那行得凑近看”，然后把照片转正、调亮，猜一下被挡住的字。把同样的图丢给一个多模态模型，回答往往走向两个极端：要么把每个字符都“读”出来，包括根本不存在的；要么干脆回一句“图片模糊，无法识别”。
这不是模型笨，而是“看见”这件事在它那里和在人那里并不是一回事。
它拿到的不是图，是一串被压扁的东西
图像进入模型之前会被切成小块，每块变成一组数字，再经过编码器压成向量。文本也一样，被切成词元，走另一条路。多模态模型要做的关键一步，是让这两条路最后能落在同一个表示空间里——说白了，就是让“猫”这个词的位置，和一张猫图算出来的位置离得不太远。这一步通常靠配对数据训练，图文对的数量和质量，直接决定了这种“靠近”是否可靠。
麻烦在于，这种靠近是统计意义上的，不是理解意义上的。模型知道“收据”这个词常常和“金额”“日期”“商户”一起出现，于是它会顺着这个概率去补全被手指挡住的部分，补得还很流畅。人也会补全，但人会停下来标记“这里不确定”。模型不会，除非你在提示里明确要求它把不确定的地方指出来。
把不同模态拼在一起，代价藏在细节里
工程上常见的做法是冻结视觉编码器，只训练一个投影层，把视觉向量映射到语言模型能接受的空间。这样省算力，也容易复用现成的语言能力。代价是视觉侧的分辨率、细粒度信息在压缩时就已经丢了。一张 A4 收据缩到几百个视觉 token，小字基本没救。所以很多“识别不准”并不是推理出了错，而是信息在进门时就被削掉了。
另一个容易被忽略的点是顺序和位置。文本有天然的先后，图像没有。模型处理图块时，位置编码怎么给、给多细，会影响它能不能把“左上角的抬头”和“右下角的盖章”关联起来。这类问题在文档、表格、界面截图场景里尤其明显。
能用和好用之间，隔着任务设计
我倾向于把它看成一种“容错较高的粗加工工具”，而不是“精确的读数器”。它擅长的事有共同特征：容错空间大、结果可以被人快速核验、不需要逐字对齐。比如给一批商品图打上大致类目标签，把界面截图转成一段可读的操作说明，从会议白板照片里整理出几条待办。
反过来，凡是要求逐字符准确、要求给出可追溯依据的场景，单靠它就不稳妥。更实际的做法是把任务拆开：先用传统视觉方法做版面检测、把区域切出来，再让模型去理解每个区域里的语义；或者让它输出结构化字段，同时要求附上它依据的图块位置，人抽查时能对得上。
- 把“定位”和“理解”分开：定位交给确定性方法，语义交给模型。
- 让它说出“哪里不确定”，而不是只给一个漂亮答案。
- 分辨率别省，尤其是文档类图像，压缩比想象中更伤细节。
真正的边界在于它不知道自己在猜
多模态模型的输出总是通顺的，这既是它的价值，也是它的陷阱。一段流畅的描述会让人默认背后有对应的观察，而实际上可能只是语言先验在起作用。判断一张图里有没有某个物体，和描述这张图讲了什么，是两种难度完全不同的任务，前者对视觉证据的要求高得多。
所以落地时我更关心两件事：这个环节出错，会不会被下游立刻发现；以及有没有一条成本很低的人工复核路径。两者都成立，模型的能力才谈得上兑现。否则再漂亮的演示，也只是把不确定性往后推了一层。