一张拍歪了的报销单，人扫一眼就能把金额和日期对上。换成模型，它可能把「1」认成「7」，然后在后面几步推理里一路错下去。这类差错常被归到「识别不准」头上，但往深里看，问题往往不在识别，而在视觉和语言之间的衔接环节。
把视觉编码器和语言模型接起来，中间环节容易丢信息
常见的做法是让视觉编码器先看，再把结果交给语言模型说。中间那层投影看着简单，实际可供传递的信息很有限：图像里的位置、线条、字号、表格框线，都要被压进一组向量里。
压缩必然有取舍。粗粒度的「这是一张表格」很容易保留，细粒度的「第三行第二列」就未必。多模态模型真正难的地方，不是把图变成向量，而是让文字里的「上一行」「合计」「这里」落到图上的具体位置。指代对不上，后面说得再流畅也没有实际意义。
用户看到答案，看不到它看了哪儿
文本问答出问题时，还能顺着上下文找线索。多模态的输出是一句话，中间它盯着图的哪个区域，外面基本看不见。模型说「表头写的是含税价」，它到底看了表头，还是从别处猜的，无从判断。
这让调试变得别扭。工程师改提示词、换分辨率、调预处理，改动之后效果变了，却说不清是哪一环起了作用。可解释性在这里不是学术趣味，而是排查问题的必需品。
评估这件事，比训练更让人头疼
纯文本任务有相对明确的答案，多模态任务的「对」常常取决于上下文。同一张图，问「这是什么」和问「这里有没有风险提示」，合格标准完全不同。用一套固定题库打分，容易诱使模型去猜题目格式，而不是真的看图。
所以判断一个多模态模型能不能用，我更愿意看它在自己业务里的脏数据上错在哪儿：是漏了手写批注，是把相似的表头搞混，还是根本没定位到关键区域。干净测试集上的表现，参考价值有限。
它省事的地方，其实很具体
不是所有活儿都值得上多模态。信息本来就在文字里的，用文本模型就够了，多一路图像输入只是多一份不确定性。真正合适的是那些信息本来就以图像形式存在的场景：截图、扫描件、带标注的照片、界面操作回放。
- 截图里的按钮状态和报错文案，文字和位置要一起看；
- 扫描件里的表格结构，框线本身就是信息；
- 照片里的物体关系，「左边那个」「后面那个」要靠空间位置说话。
这些任务的共同点是：单看文字说不清，单看图也说不清。
边界还是要说清楚
模型对图像的「理解」和人的理解不是一回事。它在文字渲染、精细计数、复杂空间关系上仍然吃力，遇到密集排版更容易出岔子。做产品时留个兜底更稳妥：让它标出不确定的字段，关键数值交给规则再校验一遍，别把整条链路压在一次前向计算上。
多模态模型这几年的进步是真的，但它更像一个能同时处理两种材料的助手，而不是一双不会看错的眼睛。指望它一次到位，多半会在某张拍歪的表格上暴露问题。