一张打印出来的设备图纸被拍成照片，角落有手写箭头和两行潦草备注。编辑把图片传给模型，问“这个位置改了什么”。它准确复述了备注文字，却把箭头指向的零件说错。这个小小的错位，比“识别失败”更值得琢磨：文字读对了，空间关系没跟上。
多模态模型常被描述成“能看、能听、能读”。真正进入工作流后，事情没这么整齐。图像里的信息是并行的，文字是线性的，声音带时间轴，表格又有行列结构。把它们放进同一个模型，不等于它们在同一套语义里对齐。上面那张图纸，模型要同时理解“箭头”“零件”“备注”三者的指代关系，任何一环松动，答案就会跑偏。
“看见”与“读懂”之间
早期做法常把不同编码器拼在一起，再接一个语言模型。工程上可行，却容易留下缝隙：视觉特征到了文本空间，细粒度关系可能被压扁。一个按钮在界面截图里的位置、一个零件在装配图中的相邻关系，很难只靠一句描述还原。于是，多模态模型需要的不只是“识别出有什么”，还要“说清楚在哪里、和谁有关”。这要求训练数据里包含指代、空间、时序等关系，也要求推理阶段能把这些关系稳定地输出。
另一个容易被低估的问题是输入顺序。用户先发图再补一句话，和先写问题再发图，模型收到的上下文并不相同。实际使用中，人们往往边拍边问，图片模糊、语音夹杂背景声、文字里有错别字。模型如果只会处理干净样本，到了现场就会显得“聪明但不好用”。
评测要回到具体任务
讨论多模态模型时，容易拿一套通用题去衡量全部能力。可真实任务往往很窄：从巡检照片里找出标签脱落，从会议白板里整理待办，从客服对话里定位用户发来的截图。每个任务的关键错误不一样，有的怕漏，有的怕错配，有的怕把推测写成结论。评测若只看得分，很难暴露这些差异。
我更倾向于把评测拆成几层：识别是否完整，关系是否说对，引用能否回到原图或原话，遇到不确定时是否明确说“不知道”。前两层关乎能力，后两层关乎可信。尤其在企业场景里，答案能不能被复核，往往比答案看起来是否流畅更重要。模型给出结论时附带截图坐标、原文片段或时间点，人工检查的成本会低很多。
边界与接口
多模态模型不会自动理解业务规则。一张图里哪些变化需要上报，一段录音里哪句话算承诺，仍要由人来定义。把模型放进流程时，接口设计比演示效果更值得花时间：输入是否允许分次上传，输出是否保留来源，失败时能否退回人工，敏感内容是否在进入模型前处理。这些决定它能不能从“演示可用”走到“日常可用”。
回到那张图纸。更合理的用法，也许不是让模型直接给结论，而是让它先标出它看到的箭头、文字和零件，再由工程师确认指代关系。它的价值，可能就在这种来回核对里慢慢显现：把分散的信息摆到一起，人负责判断哪些关系成立。技术往前走，边界也要跟着画清楚。