把一张现场照片交给系统，问一句「这台设备哪里不对劲」，是不少人对多模态模型的第一想象。想象很顺：它能看图，也能说话，那让它把看到的说出来、再判断一下，似乎就成立了。真做起来，卡住的地方往往不在「能不能说」，而在「说的那句话能不能拿去用」。
看得见，和看得出，是两件事
模型处理图像时，通常先把图片切成小块，每块编码成一个向量，再和文字一起排进同一条序列。这一步就决定了它「看得见」什么：切得太碎，算力吃不消；切得太粗，螺丝上的裂纹、仪表盘上的一格刻度就没了。文字描述可以概括「画面中有一台设备」，但现场判断依赖的偏偏是那些被压掉的细节。
于是常见的尴尬是：模型给出的描述没有错，却也没有用。它说「管道表面有污渍」，而你要的是「这处污渍是不是渗漏的开始」。前者是识别，后者要结合材质、位置、随时间的变化，甚至这台设备上一次检修留下的记录，而这些信息多半不在图里。多模态模型能补上的一部分，是把图像与文字放在同一个语境里对照，但它补不上图外的那部分。
评估方式的错位
单张图片问答的准确率，和把它放进一条工单流程里的表现，并不是一回事。前者考的是「说得对不对」，后者考的是「在什么条件下会错、错了之后谁来兜」。线上出错的方式也更隐蔽：模型不会报错，它会用同样流利的语气给出一个偏了的答案。不熟悉这块业务的工程师，很难第一眼看出问题出在哪一环。
这也是为什么，把多模态模型接入实际流程之前，值得先想清楚失败的样子，而不是只想着成功的演示。
有些场景，本就不该用它
有明确规则可判的，用规则更省：固定机位的读数、颜色阈值、尺寸测量，几行判断就够，还稳定。传感器能给出数值的，优先传感器。多模态模型擅长的，是那些「人看一眼能说出大概、却讲不清判断依据」的模糊任务，比如核对一张现场照片是否拍全了需要的部位，或者把口语化的描述整理成结构化字段。
工程上的取舍
真正决定好不好用的，往往不是模型本身，而是围绕它做的收窄：
- 收窄输入：固定拍摄角度、固定光线、给出拍摄内容清单，比指望模型「适应各种情况」现实得多。
- 收窄输出：让它填字段，而不是写段落。字段能被校验，段落只能靠人读。
- 留回退路径：要求模型标出不确定的地方，比如哪些区域看不清、哪些信息缺失。
还有一种倾向值得警惕：把多模态模型当成一双什么都能看的通用眼睛。它更像一个读图能力不错、却没去过现场的实习生，能帮你把看到的说清楚，判断还得自己下。