朋友给我看过一段演示：手机对着配电箱拍一张照，屏幕上的多模态模型几秒钟就念出表盘读数、圈出松动的接线端子，还顺手生成了一条工单描述。现场有人鼓掌。坐在后排的运维主管没鼓掌，他问了一句：如果读数是 3.8，实际是 8.3，这条工单谁来核？
这个问题不太好回答，但它恰好点出了这类模型从演示走向业务时，最容易被跳过的一段路。
它做的其实是“对齐”
把图像、文本、语音塞进同一个模型，听起来像是让机器同时长了眼睛和耳朵。更准确的说法是：训练过程把不同模态的表示拉近到同一个语义空间，让“这张图”和“这句话”能互相指认。它学到的是一种对应关系，而不是对世界的理解。所以它能说出图里有一台设备、有一处锈迹，却不知道这台设备停机一天意味着什么——那部分知识在业务里，不在参数里。
三处容易低估的成本
- 输入不稳定。实验室里的照片光线均匀、主体居中；现场的照片有反光、有遮挡、有半个身子入镜的路人。像素层面的微小变化会让输出飘，而工程上真正要处理的正是这种飘。
- 评测不好写。分类任务可以算准确率，开放式描述不行。一段读起来通顺的话可能漏掉关键信息，也可能补出一个不存在的细节。要判定对错，得先把业务能接受的错误边界写清楚，这活儿通常比调模型更费时间。
- 链路变长。一次识别背后是图像预处理、编码、推理、后处理，每一步都加时延和成本。视觉输入的开销不低，高频调用时账单会比预期厚。
也许该换个位置放它
我越来越倾向于认为，多模态模型在大多数业务里的合适位置，不是替人下结论，而是把非结构化的材料整理成可核对的结构。巡检照片变成带时间地点的条目，纸质单据变成字段，会议录音变成待办。这些工作原本由人来做，重复、耗时、容易漏；交给模型之后，人从“录入”退到“复核”，风险结构变了，但没有消失。
一旦涉及高风险判断——比如是否停机、是否放行——单独让模型给结论就是不合适的。更稳妥的做法是让它给出候选和依据，人保留否决权，同时把每次调用的输入输出留档，出了事能倒查。日志这件事常被当成运维细节，其实是责任划分的基础。
先问自己一个问题
如果明天就要上线，你打算用什么标准判断它“够用了”？这个标准如果写不出来，多半不是模型的问题，而是业务本身还没想清楚要它干什么。