单图≠多图：多图理解时 VLM 为什么更容易“胡说”，以及一个两阶段解法

背景

这一讨论起源于作者在近期一个关于电池缺陷检测和自动分拣的课程设计中遇到的实际工程问题。由于电池样本极少（不足十根），且缺陷主要体现为外皮缺失，传统的图像分类或 YOLO 等目标检测模型难以通过常规训练达到理想效果。尽管课程推荐方案涉及边缘检测和 OpenCV，但作者出于对 OpenCV 类型系统（typing）的不熟悉，转而采用了一种混合方案：利用 YOLO 定位电池坐标及朝向，随后使用视觉语言模型（VLM）来判断电池是否存在缺陷及缺陷类型。

在初期测试中，作者通过网页端上传包含不同光照条件的电池图像（包括完好参考图及缺陷图），发现 ChatGPT 和 Gemini 等模型在识别检测中达到了惊人的 100% 准确率，且多次回复的一致性极高。即便一次性上传六七张图像，表现依然稳定。这使作者误以为该方案已足够成熟，甚至计划通过本地部署 Ollama 上的 VLM 来降低延迟并增加“工作量”。

然而，当作者转向 API 直调测试时，情况发生了剧烈反转。无论是准确率还是回复的一致性都大幅下降，准确率仅维持在 50% 左右，且模型经常前后矛盾。值得注意的是，当仅发送单张图像时，API 与网页端的表现差距并不显著。这种“单图正常，多图崩坏”的现象促使作者深入探究 VLM 在多图理解机制上的差异，并试图从工程角度寻找补救措施。

核心内容

网页端与 API 调用的巨大差异

作者在测试中发现，使用相同模型（如 gemini-flash-2.5、chatgpt-5.1-chat 等）通过 API 调用得到的结果，与网页端体验存在显著差距。特别是当图像数量超过四张时，一致性开始明显下降。作者推测，网页端之所以表现更好，可能得益于以下工程优化：

1. 预处理机制：网页端可能实施了逐图预摘要、重排序（rerank）或选择性投喂策略。
2. 更强的约束：网页端可能拥有更强大的系统提示词（System Prompt）和格式约束，例如强制输出 JSON 或要求逐图作答。
3. 参数差异：API 侧的 temperature、max_output、tool choice 及并发顺序等参数设置可能影响了模型的一致性。

相比之下，API 直调往往将图像直接以 Base64 编码形式嵌入 OpenAIMessage 结构中，缺乏上述中间层的优化，导致模型在处理长上下文时遭遇“迷失在中间”（Lost in the Middle）效应，即长上下文检索困难和位置偏置问题被放大。

VLM 多图理解的技术瓶颈

现有的多模态基准测试（如 MIBench、MMIU、MIRB）一致表明，模型从单图过渡到多图时，会出现显著的性能下滑，尤其是在关系理解和多跳推理方面。其核心瓶颈在于视觉 Token 过多导致的工程与算法双重挑战：

1. Token 计量与处理机制：

   • Tile-based（分块机制）：适用于 gpt-4o、gpt-4.1 等模型。detail="low" 时固定收取 85 tokens；detail="high" 时，图像先等比缩放至最长边 ≤2048、短边=768，然后按 512×512 的 Tile 数量计费。例如，一张 1024×1024 的图片在 high 模式下会被缩放并切分为 4 个 Tile，总图像 Token 为 85 + 170*4 = 765。
   • Patch-based（补丁机制）：适用于 gpt-4.1-mini 等模型。按 32×32 的 Patch 覆盖图像计数，若超过 1536 个 Patch 则等比缩小。例如，1024×1024 的图片会产生 1024 个 Patch，最终 Token 约为 ceil(1024 * 1.62) = 1659。
   • 视觉 Token 的拼接：虽然 OpenAI 未公开具体细节，但开源 VLM 方案显示，视觉 Token 与文本 Prompt Token 的拼接方式直接影响推理效果。

2. 注意力机制的局限性：

   • 拼接派（Concatenation）：将视觉 Token 与文本 Token 直接拼接输入 Transformer。这种方式简单端到端，但视觉 Token 会大量占用上下文窗口，导致“注意力摊薄”（Attention Dilution）。在多图场景下，这种摊薄是不均匀的，部分图像可能被模型选择性忽略。
   • 交叉注意力（Cross-Attention）：将视觉信息作为外部 Memory，文本按需查询。这种方式在工程上更易控制“视觉信息预算”，适合长序列，但增加了模块复杂度，且存在“查询不确定性”，难以保证模型真正“看到”了所有图像。

实际落地中的三大不确定性

在实际应用中，多图任务面临三个维度的不确定性，进一步加剧了模型的理解难度：

1. 数量不确定：用户可能一次性输入大量图像，导致单次推理中分配给每张图像的注意力急剧减少，甚至出现部分图像完全未被“注意”到的情况。
2. 关系不确定：图像之间可能存在复杂的耦合关系（如角色比对、场景关联）。若图像数量多且类别杂，模型难以一次性匹配所有相似角色或理解两两之间的细微差别，除非工作流中插入额外的提取步骤。
3. 任务需求不确定：用户的指令往往隐含在上下文或特定语境中（如角色扮演中的隐喻），而非显式陈述。模型倾向于将注意力权重分配给最近的显式指令（如“描述一下”），而忽略上下文中的隐含谜题或指代，导致回复偏离用户真实意图。

两阶段解法

针对上述难点，作者提出了一种无需修改模型推理架构、可直接套用于应用层的两阶段解法：

1. 第一阶段：逐图独立分析

   • 将图像分析与文本分析分离。
   • 使用一个独立的 Vision Model 对每张图像进行单独分析。
   • 关键设置：此阶段不传入用户当前的具体提示词（User Prompt），而是使用固定的系统提示词和抽取指令。
   • 输出目标：生成结构化的 JSON 数据，提取场景、关键物品、可见文本及 UI 提示等客观信息。例如：

     {
     	"scene": "VS Code 全屏显示代码与终端",
     	"key_items": [
     		{"type": "app", "label": "VS Code", "detail": "深色主题, 全屏窗口"},
     		{"type": "ui", "label": "文件树", "detail": "左侧资源管理器展开多个目录"}
     	],
     	"visible_text": ["run_tool_loop", "ToolTrace", "vision__screen_shot"]
     }
     

2. 第二阶段：基于结构化信息的综合推理

   • 将第一阶段生成的结构化 JSON 信息作为上下文，结合用户的真实意图和提示词，送入 LLM 进行最终的综合判断。
   • 这种方法通过预处理压缩了视觉信息的冗余，明确了图像间的关系，并隔离了视觉 Token 对文本注意力的干扰，从而显著提升了多图理解的一致性和准确性。

关键要点

• API 与网页端表现差异巨大：API 直调多图时，由于缺乏网页端的预摘要、重排序及强格式约束，极易出现“胡说”和一致性下降，主要受限于长上下文中的“迷失在中间”效应。
• 多图性能显著低于单图：MIBench 等基准测试证实，VLM 从单图到多图存在显著性能下滑，核心瓶颈在于视觉 Token 过多导致的注意力摊薄和位置偏置。
• Token 计量影响成本与性能：不同模型家族（如 Tile-based vs Patch-based）对图像的 Token 计算方式不同，直接影响上下文