AI 是怎么「看懂」图片的？

一张图片发给 AI，它是怎么"看懂"的？这篇文章从技术原理出发，带你彻底搞清楚。

🎯 从一个场景开始

你把一张报错截图发给 ChatGPT，它立刻给出了解决方案。你把一张菜单照片发给 Claude，它帮你翻译了所有菜名。

这件事看起来很自然，但仔细想想——LLM 的本质是处理文字 token，它是怎么"看"图片的？

---

🧠 OCR：最早的「图片识字」

在多模态 LLM 出现之前，计算机"读取"图片中文字的方式叫做 OCR（光学字符识别，Optical Character Recognition）。

OCR 的工作原理大致是：

图片
  ↓
检测文字区域（找到哪些像素是字）
  ↓
逐字符识别（这个形状是"A"，那个是"B"）
  ↓
输出文字字符串

代表工具有 Tesseract（谷歌开源）、PaddleOCR（百度）。

OCR 的本质局限：它只能"抄字"，不理解内容。

OCR 就像一个"抄写员"——能把图片上的字忠实地抄下来，但他不知道自己在抄什么。

---

🧠 多模态 LLM：真正「看懂」图片

现代多模态 LLM（如 GPT-4V、Gemini、Claude 3）不只是认字，而是真正理解图片的语义。

核心思路：把图片也变成 token

LLM 本质上只懂 token（一段文字切成的小单元，经过向量化变成数字）。多模态的关键是把图片也变成 token，让 LLM 能和文字一起处理。

文字："一只猫坐在沙发上"
  ↓ Tokenizer
["一只", "猫", "坐在", "沙发上"]  →  向量序列  →  LLM

图片：🖼️
  ↓ Vision Encoder
[patch_1, patch_2, ..., patch_n]  →  向量序列  →  LLM（同样的处理！）

Vision Encoder：图片的「翻译官」

Vision Encoder 的工作分三步：

第一步：切 Patch（图片切片）

把图片切成 N×N 的小块（通常 16×16 像素一块），每块叫一个 patch。一张 512×512 的图会被切成 32×32 = 1024 个 patch。

┌────────────────────────┐
│  🖼️ 原始图片             │
│                        │
│  ┌──┬──┬──┬──┬──┐      │
│  │p1│p2│p3│p4│p5│      │
│  ├──┼──┼──┼──┼──┤      │
│  │p6│p7│p8│p9│..│      │
│  └──┴──┴──┴──┴──┘      │
│   每个格子 = 1 个 patch  │
└────────────────────────┘

第二步：Patch → 向量（ViT 编码）

每个 patch 经过 ViT（Vision Transformer）编码，变成一个高维向量。这一步学到的是"这块区域长什么样"的特征表示。

第三步：投影对齐（关键！）

图片向量和文字向量的"语义空间"不同，需要一个**投影层（MLP）**做映射，把图片向量对齐到 LLM 的 embedding 空间。

图片向量空间  ──投影层──→  LLM embedding 空间
 (1024维)                    (4096维，与文字相同)

对齐之后，"一只猫的图片" 和 "一只猫" 这段文字，在向量空间里就靠近了。LLM 处理起来就像读文字一样自然。

为什么能「懂」？关键在训练数据

技术架构只是基础，真正让 AI 看懂图片的是海量的图文配对训练数据：

• CLIP 预训练：用十亿级（图片, 文字描述）配对数据，让图片向量和对应文字向量在空间上靠近
• 指令微调：用（图片, 问题, 答案）三元组数据，教模型回答关于图片的问题

---

📊 图片占多少上下文？

图片变成 token 后，会和文字一起占用上下文窗口。

多轮对话：图片每轮都要重传

很多人以为多轮对话存的是"token 数字"，其实 history 存的是原始 JSON，图片存的是 URL 或 base64 字符串：

[
  {
    "role": "user",
    "content": [
      { "type": "image_url", "image_url": { "url": "https://cdn.example.com/img.png" } },
      { "type": "text", "text": "这张图里有什么？" }
    ]
  },
  { "role": "assistant", "content": "图片里有一只橙色的猫。" },
  { "role": "user", "content": "它看起来多大？" }
]

每次 API 请求都把完整 messages 传过去，服务器重新把图片编码成 token 再处理。所以图片 token 费用每轮都叠加：

第 1 轮：图片 1500 tokens + 文字 20   = 1520 tokens
第 2 轮：图片 1500 tokens + 文字 70   = 1570 tokens  ← 图片又来了
第 3 轮：图片 1500 tokens + 文字 130  = 1630 tokens  ← 还在

Prompt Caching 可以缓解这个问题——Claude 和 GPT 都支持把图片标记为缓存，服务器复用计算结果，缓存命中只收 10-25% 的费用。但图片数据还是每次都在 JSON 里传，上下文窗口里图片依然占着位置。

---

🏛️ 主流产品的实现方式

原生多模态（现在的主流）

直接把图片 token 和文字 token 一起塞给支持 Vision 的模型，一次搞定。

用户发图片
    ↓
前端：图片 → base64 或 CDN URL
    ↓
API：{ content: [{ type: "image_url", url: "..." }, { type: "text", text: "这是什么？" }] }
    ↓
模型直接理解图片 + 回答

代表：ChatGPT（GPT-4o）、Claude.ai、Gemini 网页端，用的都是这套方案。

中间层转文字（文档系统常见）

先用一个 LLM 把图片/文件描述成文字，再把文字喂给主 LLM。

图片/PDF/Excel
    ↓
专用解析服务（用 Claude/OpenAI 描述图片，或用规则提取文档文字）
    ↓
返回文字描述
    ↓
文字注入主 LLM 上下文

这种方案的优势是兼容性强：不管是图片、PDF、Excel 还是 PPT，统一转成文字，主模型不用管格式。缺点是多了一次 LLM 调用，而且图片语义有一定损耗。

---

🔍 两种方案怎么选？

---

📝 总结

一张图片从上传到 AI 理解，经历的过程：

你上传图片
    ↓
Vision Encoder 把图片切成 patch，编码成向量
    ↓
投影层把图片向量对齐到 LLM 的语义空间
    ↓
图片 token + 文字 token 一起进入 LLM
    ↓
模型基于训练中学到的图文关联，理解图片含义
    ↓
生成回答

OCR 只是"认字"，多模态 LLM 是真正的"读懂"。两者不是竞争关系，OCR 便宜快，适合批量抠文字；多模态 LLM 贵但全能，适合需要理解语义的场景。

随着 GPT-4o、Gemini 2.5 价格持续下降，原生多模态正在成为处理图片的默认选择。