Agent 如何处理「图像+文本「的混合输入
1️⃣ 考察意图
面试官想看你能否设计一个多模态输入处理方案。刁钻点在于：混合输入不仅涉及格式解析（图像 URL vs Base64），还涉及"何时编码图像"和"如何在 LLM 上下文中组织多模态 token"的工程决策。答好了能展示你的系统设计能力。
2️⃣ 标准答
多模态 Agent 处理混合输入分三步：
1. 输入解析与格式统一
- 输入来源：用户可能通过多种方式提供图像——URL、本地文件上传、Base64、剪贴板粘贴
- 统一处理：所有来源统一转为图像张量。URL → HTTP 下载；Base64 → 解码；文件 → 读取
- 安全检查：图像大小限制（如 <10MB）、格式验证（JPEG/PNG/WebP）、内容安全检测（CLIP 相似度过滤不当内容）
- 多图处理：用户可能一次输入多张图（如"比较这两张图"），需要按输入顺序编号管理
2. 视觉编码与 Token 组织
- 编码时机：图像在送入 LLM 前需要通过 ViT 编码。策略：(1) 即时编码——用户上传后立即编码并缓存；(2) 延迟编码——等到 LLM 需要时才编码。即时编码适合多轮对话（缓存复用），延迟编码适合单轮交互（节省内存）
- Token 组织：视觉 token 和文本 token 的拼接顺序影响效果。主流方案：前缀拼接：
[IMG_1...IMG_256][TEXT: "描述这张图"]——图像在前，文本在后。LLaVA 默认方案 - 交错拼接：
[TEXT: "这是"][IMG_1...IMG_256][TEXT: "和这是"][IMG_257...IMG_512][TEXT: "的对比"]——图文交错，支持多图推理。Qwen-VL 方案 - 特殊标记：用
<image>标记在文本中标记图像位置，[TEXT: "这是 <image> 中的物体"]→ 编码时替换<image>为视觉 token
3. 上下文管理与优化
- Token 预算：LLM 上下文有限（如 4K-32K token），视觉 token 占用大量空间。256 个视觉 token 占 4K 上下文的 6%。多图场景需要压缩
- 压缩策略：(1) Token pooling——将相邻的 4 个视觉 token 合并为 1 个（256→64），精度降 1-2%；(2) 动态选择——根据文本指令只编码图像的 relevant region（如"左上角的文字"只编码左上角 patch）
- KV Cache 管理：多轮对话中视觉 token 的 KV cache 需要管理——如果对话转向纯文本话题，释放视觉 cache 释放内存
3️⃣ 答题模板（30 秒电梯版）
"混合输入处理分三步。第一步输入解析——URL/Base64/文件统一转张量，安全检查（大小+格式+内容），多图按顺序编号。第二步视觉编码——ViT 编码图像为 token，组织方式有前缀拼接（LLaVA）或交错拼接（Qwen-VL）。第三步上下文管理——256 视觉 token 占 4K 上下文的 6%，多图需要 pooling 压缩，多轮对话需要 KV cache 管理。核心挑战是 token 预算管理。"
4️⃣ 高频追问 & 应对
追问 1：交错拼接和前缀拼接有什么效果差异？
交错拼接在多图推理任务上效果更好——如"比较图1和图2的差异"，交错拼接让 LLM 在生成"图1"时 attend 到图1的 token，生成"图2"时 attend 到图2的 token，注意力更精准。前缀拼接把所有图像 token 放在前面，LLM 需要自己"记住"哪些 token 属于哪张图，容易混淆。实验：Qwen-VL 的交错拼接在多图 VQA 上比前缀拼接高 5-8%。但交错拼接的 token 序列更长（文本和视觉交替），计算效率略低。
追问 2：用户上传 4K 分辨率的高清图，ViT 只能处理 224×224，信息损失怎么办？
三种方案：(1) 分块处理——将 4K 图像切分为多个 224×224 的子图，分别编码后拼接。缺点：token 数爆炸（4K → 36 个子图 → 7056 token）；(2) 动态分辨率——Qwen-VL 方案，ViT 支持变长 patch，4K 图直接编码产生 ~4000 token，再 pooling 压缩到 256；(3) 混合方案——低分辨率全局图（224×224，理解整体布局）+ 高分辨率子图（224×224 裁剪关键区域，理解细节）。实际中 GPT-4V 用混合方案——先看全局，再"放大"看细节。
追问 3：Agent 需要处理实时视频流（如摄像头），怎么处理？
实时视频流的核心挑战是"无限长度"——视频持续输入，不可能把所有帧都编码。方案：(1) 关键帧提取——用场景变化检测（如帧间 SSIM 差异 >阈值）提取关键帧，只编码关键帧。通常 30fps 视频提取后约 1-2fps；(2) 滑动窗口——只保留最近 N 秒的关键帧（如最近 30 秒的 30-60 帧），旧帧丢弃；(3) 视觉摘要——对每个关键帧生成文本描述（"画面中有一个人在走路"），只保留文本描述和最近几帧的视觉 token。Agent 在需要时可以"回看"历史帧的文本描述。
5️⃣ 避坑 · 常见错误答法
- ❌ "图像直接拼接在文本后面就行" → ✅ "拼接顺序影响效果。多图场景交错拼接比前缀拼接好 5-8%。单图场景差异小但交错更自然（用户说'这是'时图像在文本中间）。"
- ❌ "高清图直接 resize 到 224 就行" → ✅ "resize 到 224 会丢失细节（如小文字）。需要分块处理或动态分辨率。GPT-4V 用混合方案——全局低分辨率+局部高分辨率。"
- ❌ "所有图像都在输入时编码" → ✅ "即时编码适合多轮对话（缓存复用），但占内存。延迟编码适合单轮交互。多图场景可以只编码用户当前关注的图，其他图延迟编码。"
6️⃣ 简历呼应
- 如果你有 VLM 系统设计经验：从"多模态输入 pipeline"切入，描述你设计的输入解析+编码+缓存方案，给出性能数据（如多图处理延迟 <500ms）
- 如果你只做过 NLP 输入处理：用"多语言输入处理"迁移——多语言需要 tokenizer 适配，多模态需要 ViT 编码器适配，核心挑战都是"异构输入统一化"
- 如果你是校招无项目：实现一个支持多图交错输入的 VLM 推理 pipeline，对比前缀拼接和交错拼接在多图 VQA 上的效果
- "LLaVA: Visual Instruction Tuning" (Liu et al., 2023)
- "Qwen-VL: A Versatile Vision-Language Model" (Bai et al., 2023)
- "Flamingo: a Visual Language Model for Few-Shot Learning" (Alayrac et al., 2022)