把一张便利店货架照片交给多模态模型，问它“哪一层放着无糖茶”，它可能先给出顺畅描述：瓶装饮料、价签、冷柜灯光，却把“无糖”对应到相邻一排。这个错误不大，却很有代表性：模型看见了，但未必把看见的东西和组织好的语言准确对齐。
看得见，不等于指得准
图像进入模型后，通常会被切成小块，转成向量，再与文本表示建立联系，再由语言部分生成回答。流程听起来完整，真正容易出问题的地方却在“指代”：用户说“左边那瓶”，模型要把方位、遮挡、标签和前后问句一起纳入。只要其中一项没接上，回答就会显得流畅但落点偏移。多模态模型的难点，往往不在能不能描述画面，而在能不能把一句话指向画面里的具体对象。
上下文不是装饰
同一张图，换一个问法，结果可能不同。问“图里有几瓶饮料”，和问“适合放进低糖专区的是哪几瓶”，需要的线索并不一样。后者不仅涉及识别，还涉及品类知识、陈列意图和对模糊标签的谨慎处理。企业如果把模型当成孤立的问答入口，容易得到看似完整、实际难以复核的答案；把商品库、陈列规则和追问记录作为上下文，模型才可能落在具体任务上。这并不意味着它能包办判断，它像一个需要边界约束的协作组件。
评估要盯住错误发生的位置
看演示时，人们常被回答的流畅度吸引；进入业务流程后，检查重点会转移到错误发生的位置。可以围绕几个位置做小范围验证：
- 图里的文字有没有被漏读，数字和单位是否前后一致；
- 方位、数量和对象指代是否稳定，追问后会不会换掉同一个对象；
- 回答是否补出了画面里没有的细节，语气是否把猜测说成了确定；
- 跨图比较时，模型能否说清依据，而不是只给结论。
这类检查能覆盖流畅回答看不到的部分。对多模态模型来说，边界不是抽象概念，而是一次次具体错误暴露出来的位置：漏读的价签、错配的方位、被忽略的追问。
把能力放回流程
一种做法是把任务拆小：先让模型生成可核对的结构化描述，再交给规则校验或人工抽检；需要精确到货架层数、标签文字时，不让一句生成式回答承担全部责任。图片、语音、文本放在同一个界面里，不等于它们已经自然协同；协同发生在任务设计、上下文供给和结果复核之间。多模态模型可以成为观察和表达的入口，但入口之后仍需要流程接住。