多模态 AI：模型开始理解真实世界

读完这篇，你能说清楚：为什么多模态比"两个模型拼一起"难得多、一张图是怎么被变成模型能读懂的"词"、以及当你想让 AI 基于截图去点按钮时，真正该担心的延迟、成本与对齐问题。

一、为什么多模态难：从单模态到统一表示

早期的视觉模型（比如只做分类的 CNN）和语言模型（只做文本生成）各自活在封闭的世界里：视觉模型输出"这是猫"的概率，语言模型输出"下一个字是什么"。它们能各自把数据压成向量（一串数字），但这两个向量空间彼此不连通——"猫"这个字和一张猫图在模型眼里毫无关系。

多模态的核心目标，是建立统一表示（unified representation）：让文字、图片、声音最终落在同一个可比较的语义空间里。这样模型才能回答"这张图里有没有猫"——也就是把图像区域和"猫"这个词对齐到相近的位置。难点不在"能看懂图"，而在"看懂之后还能用语言去推理、调用工具、做决策"，这要求跨模态的信息不能在编码过程中丢失或错位。

更深的一层难处是模态不对齐：一段 3 秒的视频包含的信息量，可能抵得上一千个字；而一个"红色按钮"在图里只占几个像素，却决定用户能不能下单。不同模态的信息密度、时序粒度、噪声模式都不同，强行塞进同一套处理流程，要么图被压得太狠丢了关键细节，要么文字被图带偏产生幻觉。

二、视觉编码器：ViT、CLIP 与 Q-Former 怎么把图变成"词"

要让大模型读图，第一步是把图像切成模型能消化的形式。主流做法是ViT（Vision Transformer）：把图片切成若干 16×16 的小块（patch），每块当作一个"视觉词元（visual token）"，像处理句子里的字一样用 Transformer 处理。一张 336×336 的图大约切成 576 个 token，这就是图像在大模型眼里的"字数"。

但 ViT 本身不知道"图"和"词"该怎么对应。真正把图文连起来的是CLIP：它用海量"图片+描述文字"对做对比学习——同一对图文向量拉近，不同对的推远。训练完后，CLIP 的图像编码器和文本编码器就共享同一个语义空间，于是"猫的照片"和"a cat"自然靠近。2023 年后的 SigLIP 把对比损失换成"图文是否匹配"的二分类 sigmoid 损失，在细粒度对齐上更稳。

第三种关键结构是Q-Former（BLIP-2 / InstructBLIP 用）：它是一组可学习的"查询向量"，专门负责从 ViT 输出里抽取与文本任务相关的信息，把几百个图像 token 压缩成几十个"瓶颈 token"再喂给语言模型。它的价值在于：既减少送入 LLM 的 token 数（省成本），又强迫模型只保留对回答有用的视觉内容。

# 用 CLIP 计算"图"与"文字"的语义相似度（transformers + torch）
from transformers import CLIPProcessor, CLIPModel
from PIL import Image

model = CLIPModel.from_pretrained("openai/clip-vit-base-patch32")
proc  = CLIPProcessor.from_pretrained("openai/clip-vit-base-patch32")

image = Image.open("screenshot.png")
texts = ["这是一个登录按钮", "这是一张风景照", "这是报错弹窗"]

inputs = proc(text=texts, images=image, return_tensors="pt", padding=True)
outputs = model(**inputs)
# image_embeds 与 text_embeds 已在 CLIP 的统一空间，直接点积即可比对
probs = outputs.logits_per_image.softmax(dim=1)
print(probs)  # 哪句描述最贴合这张图

三、VLM 架构与推理流程

把上面的零件拼起来，就是一个视觉语言模型（VLM）。典型流程是：图像经 ViT 编码成视觉 token，经 Q-Former（或投影层）对齐到 LLM 的词空间，和用户输入的文本 token 拼接后一起送进大语言模型，由 LLM 生成回答。LLaVA 用轻量投影层把 ViT 输出直接映射进 LLM；Qwen-VL、GLM-4V、DeepSeek-VL 则在更高分辨率、动态分辨率与 OCR 上做了增强。

工程上要分清两种"看图"：原生多模态模型（图在预训练阶段就进去了，理解更准，但贵）；外部视觉描述 + 纯文本 LLM（先用一个 caption 模型把图转成文字，再交给 LLM）。后者便宜、可控，但会丢失图里没被文字描述出来的细节——比如一个灰色的禁用按钮。

四、音频与视频：理解之外还有生成

音频通常先转成频谱图（spectrogram）——把声音随时间变化的频率画成一张图，于是就能复用视觉编码器去"读"声音；语音助手类系统则常走 ASR（语音转写）→ LLM → TTS（转语音）的管线，把"听、理解、说"拆成三段低延迟服务。

视频是"带时序的图像序列"。做法分两派：一是采样关键帧，把若干帧当多张图一起送（省算力但丢动作）；二是时序模型（如 VideoMAE、时间注意力）直接建模帧间运动，能识别"开门""摔倒"这类动作，但算力极高。

生成方向则是扩散模型（Diffusion）的天下：T2I（文生图，如 SDXL、Flux）从噪声逐步去噪出图；T2V（文生视频，如 Sora、可灵、即梦）在时间和空间两个维度同时去噪，难点在于"帧与帧之间物体不能突然消失"。理解模型（VLM）和生成模型（Diffusion）正在合流：先用 VLM 理解需求、做布局规划，再交给 Diffusion 出图，这正是 2025–2026 年设计类工具的主流做法。

五、应用设计变化：从"描述图"到"基于图做决策"

入门玩法常停在"描述这张图里有什么"。但真正产生价值的是第二步：让模型基于图去行动。区别在哪？

• 描述图："图里是一个红色购物车图标。"——输出一句人话，结束。
• 基于图做决策："图里红色购物车在右上角，用户目标是下单，所以下一步应当点击它。"——输出一个可被系统执行的动作（action），如坐标、工具调用或结构化字段。

所以从产品角度，多模态的落点往往是：把截图/文档/视频变成结构化输出（字段、坐标、标签、下一步动作），再接进你原有的业务逻辑。会议白板 → 待办清单；仪表盘截图 → 异常指标；商品图 → 类目与标题。模型负责"理解"，你负责"流程"。

# 让 VLM 输出结构化"下一步动作"，而非自然语言描述
import json, requests

payload = {
  "model": "qwen-vl-max",
  "messages": [{
    "role": "user",
    "content": [
      {"type": "image_url", "image_url": {"url": "https://.../screen.png"}},
      {"type": "text", "text": "这是结算页截图。请只返回 JSON："
        "{\"action\":\"click\"|\"type\"|\"none\", \"target\":描述, "
        "\"coords\":[x,y], \"reason\":一句话}。不要输出多余文字。"}
    ]
  }],
  "response_format": {"type": "json_object"}
}
r = requests.post("https://api.example.com/v1/chat/completions",
                  json=payload, headers={"Authorization": "Bearer KEY"})
action = json.loads(r.json()["choices"][0]["message"]["content"])
# 你的业务代码据此调用真实 UI 自动化 / 表单填充

六、延迟、成本与模态对齐的坑

把多模态接进生产，真正卡你的往往是下面几件事：

多模态的突破，是让文字、图像、音频与视频进入同一个语义空间，从而把"看懂"变成"能做事"。当模型能同时处理截图、录音和文档，真正的门槛就从"识别内容"转向"设计权限、延迟与脱敏"——能力越丰富，越要把隐私与边界前置。先想清楚模型看完图要产出什么结构化动作，再决定用哪种编码器、什么分辨率。