AI Day 10: 多模态模型：Vision-Language架构 — 让AI"看懂"图片和视频

日期：2026-04-11 阶段：第一阶段 — AI/LLM技术深潜 (Day 1-15) 标签：Multimodal Vision-Language Model ViT CLIP LLaVA GPT-4o Gemini Video Understanding OCR

---

学习路径树

AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15)
│   ├── Day 1:  Transformer架构与LLM基础 ✅
│   ├── Day 2:  模型量化与本地部署 ✅
│   ├── Day 3:  训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│   ├── Day 4:  Prompt Engineering与上下文学习(ICL)原理 ✅
│   ├── Day 5:  RAG架构：检索增强生成全链路 ✅
│   ├── Day 6:  向量数据库与Embedding模型 ✅
│   ├── Day 7:  Fine-tuning实战：LoRA / QLoRA / Adapter ✅
│   ├── Day 8:  推理优化：vLLM / TensorRT-LLM / SGLang ✅
│   ├── Day 9:  长上下文技术：RoPE扩展 / Ring Attention ✅
│   ├── Day 10: 多模态模型：Vision-Language架构 ← 你在这里
│   ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking
│   ├── Day 12: Agent框架：ReAct / Tool Use / Planning
│   ├── Day 13: MCP协议与Tool生态
│   ├── Day 14: 模型评估：Benchmark / Arena / 安全评估
│   └── Day 15: 阶段复习与架构总结
│
├── 第二阶段：工程实践 (Day 16-30)
│   ├── Day 16-20: LLM应用架构设计（微服务/网关/缓存/监控）
│   ├── Day 21-25: 生产级RAG系统（Chunking/Rerank/评估/迭代）
│   └── Day 26-30: Agent系统工程化（状态管理/错误恢复/成本控制）
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│   ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│   ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│   └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
    ├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
    ├── Day 47-49: 产品/架构面试模拟
    └── Day 50: 总结与作品集

---

核心概念

一句话定义

多模态模型 (Multimodal Model / Vision-Language Model, VLM) 是在大语言模型基础上接入视觉编码器，使AI能够同时理解文本、图像乃至视频的统一架构，核心公式为 VLM = Vision Encoder + Projection + LLM Decoder。

金融类比

纯文本LLM = 只看报表数字的分析师
  → 你给他一份年报的纯文字版本
  → 他能读懂"营收增长15%"、"负债率下降3%"
  → 但他看不到趋势图、看不到产品照片、看不到工厂实拍
  → 他完全靠数字做判断，遗漏了大量"非结构化"信息

Vision-Language Model = 同时看报表 + 现场照片 + 监控录像的审计师
  → 财务报表上说"库存充足" → 他同时看仓库照片(货架空了?)
  → 损益表说"门店扩张中" → 他同时看门店实拍(装修到什么程度?)
  → 年报中有复杂图表 → 他能直接读懂柱状图/饼图/折线图
  → 甚至能看供应链监控视频 → 判断物流是否正常运转

关键insight:
  金融世界70%的信息藏在"非纯文本"中:
    → 合同上的印章/签名
    → 财报中的图表/趋势线
    → 抵押物的实拍照片
    → 网点的监控录像
    → 票据上的手写字迹
  VLM让AI从"只读文字的实习生"升级为"全方位审查的高级审计师"

为什么PM/架构师需要理解这个

---

知识点1: 多模态架构演进

从CLIP到Gemini: 让AI学会"看"

阶段0: 专用视觉模型时代 (2012-2020)
  CNN (ResNet/EfficientNet) → 只做分类/检测
  图像和语言是两个完全割裂的世界
  金融OCR系统: 专用模型 → 识别数字 → 规则匹配 → 极不灵活

阶段1: CLIP对齐时代 (2021)
  OpenAI CLIP: 4亿图文对训练 → 图像和文本在同一向量空间
  突破: 图片可以用自然语言搜索
  局限: 只能做匹配/分类，不能"对话"
  金融应用: 图片搜索相似商品、合同类型自动分类

阶段2: 指令跟随VLM (2023)
  LLaVA: CLIP视觉编码器 + Vicuna LLM → 第一个能对话的开源VLM
  架构: 图片 → CLIP编码 → Linear Projection → 作为"视觉Token"送入LLM
  突破: 能回答关于图片的任意问题
  局限: 单图、低分辨率(336x336)、幻觉严重

阶段3: 原生多模态 (2024-2025)
  GPT-4V/4o: 图文混合原生训练(非后接)
  Gemini 1.5/2.5: 图/文/音/视频统一架构，原生多模态
  Claude 3/4 Vision: 强图表理解，低幻觉
  突破: 多图、高分辨率、视频、交错图文理解
  金融应用: 复杂表格提取、多页合同审阅、图表趋势分析

阶段4: 2025-2026前沿
  原生多模态预训练(图/文/音/视频/代码统一)
  Any-to-Any生成(不只理解，还能生成图片/音频)
  实时视频流理解(Gemini Live、GPT-4o实时)
  金融应用: 视频会议自动纪要、实时监控异常检测

核心架构: VLM = Vision Encoder + Projection + LLM

                    ┌──────────────────────────────────────────┐
                    │         Vision-Language Model             │
                    │                                          │
   图片输入          │   ┌───────────┐   ┌───────────┐          │
   ┌─────┐         │   │  Vision   │   │Projection │          │
   │     │ ───────►│   │  Encoder  │──►│  Module   │──┐       │
   │ 🖼️  │         │   │ (ViT/CLIP)│   │           │  │       │
   └─────┘         │   └───────────┘   └───────────┘  │       │
                    │                                  ▼       │
                    │                        ┌──────────────┐  │
                    │                        │              │  │
   文本输入          │                        │  LLM Decoder │──► 输出文本
   "描述这张图"  ──►│   Text Tokenizer ──────►│  (LLaMA等)   │  │
                    │                        │              │  │
                    │                        └──────────────┘  │
                    └──────────────────────────────────────────┘

三大组件:
  1. Vision Encoder: 把图片变成"视觉Token"(向量序列)
     → 常用ViT-L/14, SigLIP-400M, DINOv2
     → 输出: N个视觉Token，每个与文本Token同维度

  2. Projection Module: 对齐视觉空间到语言空间
     → Linear Projection: 简单线性层(LLaVA方案)
     → Cross-Attention: Q-Former/Perceiver(BLIP-2方案)
     → MLP Adapter: 多层MLP(LLaVA-1.5+)
     → C-Abstractor: 卷积抽象器(Honeybee方案)

  3. LLM Decoder: 统一处理视觉Token+文本Token → 生成回答
     → 视觉Token和文本Token混合排列送入LLM
     → LLM不区分"来自图片"还是"来自文字"

两种核心融合方式

方式1: Linear Projection (LLaVA系列)
  ┌─────────┐     ┌──────────┐     ┌─────────┐
  │  ViT    │────►│ MLP 2层  │────►│  LLM    │
  │ 576 tok │     │ 对齐维度  │     │         │
  └─────────┘     └──────────┘     └─────────┘

  优点: 简单高效，训练成本低，效果好
  缺点: 视觉Token数量固定(取决于ViT输出)
  代表: LLaVA-1.5, LLaVA-NeXT, LLaVA-OneVision

  训练策略(两阶段):
    Stage 1: 冻结ViT+LLM，只训练Projection → 学习对齐
    Stage 2: 解冻LLM，训练Projection+LLM → 学习指令跟随

方式2: Cross-Attention / Q-Former (BLIP-2系列)
  ┌─────────┐     ┌───────────────────────┐     ┌─────────┐
  │  ViT    │────►│  Q-Former / Perceiver │────►│  LLM    │
  │ 576 tok │     │  32个可学习Query       │     │         │
  └─────────┘     │  交叉注意力压缩信息     │     └─────────┘
                  └───────────────────────┘

  优点: 可控Token压缩(576→32)，LLM负担轻
  缺点: Q-Former训练复杂，可能丢失细粒度信息
  代表: BLIP-2, InstructBLIP, MiniGPT-4

2025趋势: Linear Projection胜出
  → 简单架构+大数据+强ViT = 更好效果
  → Q-Former虽能压缩Token但丢信息
  → 主流VLM(Qwen2-VL/InternVL/LLaVA-OV)都用MLP Projection
  → 压缩需求转向Dynamic Resolution和Token Merging

---

知识点2: Vision Encoder深度

ViT (Vision Transformer) 原理

核心思想: 把图片当作"文本序列"来处理

传统CNN: 卷积核滑动扫描 → 局部特征 → 逐层扩大感受野
ViT:     图片切成Patch → 每个Patch当成一个"Token" → 送入Transformer

步骤:
  1. 图片切Patch
     224x224图片，Patch大小14x14
     → (224/14)^2 = 256个Patch
     → 加1个[CLS] Token = 257个Token

  2. Patch Embedding
     每个14x14x3的Patch → 展平为588维向量 → 线性投影到D维(如1024)
     → 得到257个D维向量

  3. 加Position Embedding
     → 让模型知道每个Patch的空间位置
     → 可学习的位置编码(非RoPE)

  4. 标准Transformer编码
     → 多层Self-Attention + FFN
     → 输出257个D维向量
     → [CLS]向量用于分类，全部向量用于VLM

金融类比:
  把一张银行账单(图片)切成16x16个小方格
  每个方格 = 一个"信息碎片"
  Transformer的Self-Attention让每个碎片都能"看到"其他所有碎片
  → "户名"碎片能关联到"金额"碎片 → 理解整张账单

主流Vision Encoder对比

┌─────────────┬────────────┬──────────────┬────────────┬──────────────────┐
│   编码器     │   参数量    │   训练方式    │    特点     │    使用模型       │
├─────────────┼────────────┼──────────────┼────────────┼──────────────────┤
│ CLIP ViT-L  │   304M     │ 图文对比学习  │ 语义理解强  │ LLaVA-1.5        │
│ SigLIP-400M │   400M     │ Sigmoid对比  │ 比CLIP更稳  │ PaliGemma,       │
│             │            │  (非softmax)  │ 细粒度更好  │ LLaVA-OV         │
│ DINOv2      │   304M     │ 自监督(无文本)│ 空间/纹理强 │ 部分研究模型      │
│ InternViT   │   6B(!)    │ 图文对比     │ 超大ViT    │ InternVL 2/2.5   │
│ 自研Encoder  │   未公开    │ 端到端训练    │ 深度融合    │ GPT-4o, Gemini   │
└─────────────┴────────────┴──────────────┴────────────┴──────────────────┘

关键区分:
  CLIP系: 图文对齐好 → 理解"图片说了什么"
  DINOv2:  空间感知好 → 理解"东西在哪里"
  SigLIP:  CLIP改进版 → Sigmoid损失更稳定，2024-2025成为新默认
  InternViT: 6B参数巨型ViT → InternVL的核心竞争力

图像分辨率与Token数关系

这是架构师最关心的问题: 分辨率 → Token数 → 成本 + 延迟

基本公式:
  Token数 ≈ (图片宽/Patch大小) × (图片高/Patch大小)

示例 (Patch=14):
  224×224   → 16×16   = 256 tokens    (低分辨率，老模型)
  336×336   → 24×24   = 576 tokens    (LLaVA-1.5默认)
  448×448   → 32×32   = 1024 tokens
  672×672   → 48×48   = 2304 tokens
  1344×1344 → 96×96   = 9216 tokens   (高清模式)

成本影响:
  假设API价格 $0.01/1K tokens:
  处理一张336x336图 ≈ 576 tokens ≈ $0.006
  处理一张1344x1344图 ≈ 9216 tokens ≈ $0.09  (15倍!)
  批量处理1000张发票:
    低分辨率: $6        高分辨率: $90
  → 分辨率选择直接影响产品成本模型

GPT-4o的Token计算:
  low模式: 固定85 tokens(不论图片大小)
  high模式: 先缩放到2048×2048内，再切512×512 tiles
  每个tile = 170 tokens + 基础85 tokens
  例: 1024×1024 → 4个tiles = 4×170 + 85 = 765 tokens

动态分辨率处理 (2024-2025关键创新)

问题: 图片千差万别(文档竖版/风景横版/微信截图)，固定分辨率不合理

旧方法: 统一Resize到336×336
  → 高分辨率图细节丢失
  → 文档中的小字体变模糊 → OCR失败
  → 长条图片严重变形

新方法: Dynamic Resolution (动态分辨率)

方案1: Tile切分 (GPT-4o / Qwen2-VL)
  1. 保持原始宽高比
  2. 将图片划分为多个固定大小的子图(tiles)
  3. 每个tile独立编码 → 所有tile的Token拼接
  4. 加一个缩略图(全局信息)

  例: 一张2000×500的银行流水图
    → 切成4个500×500 tiles + 1个缩略图
    → 每个tile=576 tokens → 总计 ≈ 5×576 = 2880 tokens
    → 小字也能看清!

方案2: NaViT/Packing (Gemini方案)
  1. 不强制正方形，直接处理任意分辨率
  2. 多张不同大小的图Packing到同一批次
  3. 用Masked Attention隔离不同图片
  4. 训练和推理效率更高

方案3: Any-Resolution (LLaVA-NeXT/OneVision)
  1. 预定义一组分辨率模板: {672×672, 336×672, 672×336, ...}
  2. 选择最匹配原图宽高比的模板
  3. 切分+编码
  4. 兼顾效率和质量

实际影响:
  动态分辨率让VLM在文档/表格/票据场景准确率提升20-40%
  这是金融OCR场景从"不可用"到"可用"的关键转折点

---

知识点3: 2025-2026主流VLM全景对比

闭源模型

GPT-4o / GPT-4.5 (OpenAI, 2024-2025)
  架构: 原生多模态(图/文/音统一训练)
  特点: 实时音视频交互、最强指令跟随
  视觉能力: 强OCR、图表理解、创意描述
  弱点: 空间推理偶尔出错、幻觉问题、成本高
  Token: high模式 ~765 tokens/张 (1024x1024)
  金融场景: 通用文档理解、客户沟通

Claude Opus 4 / Sonnet 4 Vision (Anthropic, 2025)
  架构: 后训练视觉能力接入
  特点: 图表/表格理解极强，幻觉率最低
  视觉能力: 精准的数据提取、结构化输出
  弱点: 不支持音频、视频能力有限
  价格: Sonnet 4性价比最高的VLM之一
  金融场景: 财报分析、合规文档审查、表格提取(首选)

Gemini 2.5 Pro (Google, 2025)
  架构: 原生多模态(图/文/音/视频统一)
  特点: 100万Token上下文、原生视频理解
  视觉能力: 长视频理解、多图推理、文档OCR
  弱点: 部分语言任务不如GPT-4o
  独特优势: 视频直接作为输入(无需抽帧)
  金融场景: 视频会议纪要、大批量文档处理、多文档比对

开源模型

Qwen2-VL / QVQ (阿里, 2024-2025)
  架构: Qwen2 LLM + 自研Vision Encoder + Dynamic Resolution
  参数: 2B / 7B / 72B
  特点: 中文最强、动态分辨率、视频理解
  QVQ: 视觉推理模型(类似o1的"思考"能力用于图片)
  金融场景: 中文票据/合同处理首选

InternVL 2.5 (上海AI Lab, 2025)
  架构: InternViT-6B + InternLM2 + Dynamic Resolution
  参数: 1B / 2B / 8B / 26B / 78B
  特点: 超大ViT(6B)，细粒度视觉理解，开源最强之一
  亮点: 接近GPT-4o水平的开源VLM
  金融场景: 需要高精度视觉理解的私有化部署

LLaVA-OneVision (LLaVA团队, 2024)
  架构: SigLIP + Qwen2 LLM + AnyRes
  参数: 0.5B / 7B / 72B
  特点: 学术界标杆，架构简洁，复现性好
  意义: 证明简单架构(MLP Projection)就够了
  金融场景: 研究/原型验证

Pixtral Large (Mistral, 2025)
  架构: 自研Vision Encoder + Mistral LLM
  参数: 124B (MoE)
  特点: 欧洲开源代表，多语言支持好
  金融场景: 欧洲合规场景、多语言文档

综合对比表

┌──────────────────┬────────┬──────────┬──────────┬─────────┬──────────┬──────┐
│     模型          │ 参数量  │ OCR/文档 │ 图表理解  │ 视频    │ 中文能力  │ 部署  │
├──────────────────┼────────┼──────────┼──────────┼─────────┼──────────┼──────┤
│ GPT-4o           │ 未知   │ ★★★★☆   │ ★★★★☆   │ ★★★★☆  │ ★★★★☆   │ API  │
│ Claude Opus 4    │ 未知   │ ★★★★★   │ ★★★★★   │ ★★★☆☆  │ ★★★★☆   │ API  │
│ Gemini 2.5 Pro   │ 未知   │ ★★★★☆   │ ★★★★☆   │ ★★★★★  │ ★★★★☆   │ API  │
│ Qwen2-VL-72B    │  72B   │ ★★★★★   │ ★★★★☆   │ ★★★★☆  │ ★★★★★   │ 本地  │
│ InternVL2.5-78B │  78B   │ ★★★★☆   │ ★★★★☆   │ ★★★☆☆  │ ★★★★★   │ 本地  │
│ LLaVA-OV-72B    │  72B   │ ★★★★☆   │ ★★★☆☆   │ ★★★☆☆  │ ★★★★☆   │ 本地  │
│ Pixtral Large   │ 124B   │ ★★★★☆   │ ★★★☆☆   │ ★★☆☆☆  │ ★★★☆☆   │ 本地  │
│ Qwen2-VL-7B     │   7B   │ ★★★★☆   │ ★★★☆☆   │ ★★★☆☆  │ ★★★★★   │ 本地  │
│ InternVL2.5-8B  │   8B   │ ★★★☆☆   │ ★★★☆☆   │ ★★☆☆☆  │ ★★★★☆   │ 本地  │
└──────────────────┴────────┴──────────┴──────────┴─────────┴──────────┴──────┘

选型决策树:
  需要视频理解 → Gemini 2.5 Pro
  需要精准表格/财报提取 → Claude Opus 4 / Sonnet 4
  需要中文票据/合同 → Qwen2-VL
  需要本地部署 + 高精度 → InternVL2.5 / Qwen2-VL
  需要低成本 + 够用就好 → Claude Sonnet 4 (API) 或 Qwen2-VL-7B (本地)
  需要学术研究/快速原型 → LLaVA-OneVision

开源vs闭源选型

闭源适合:
  ✓ 快速验证产品概念(PoC阶段)
  ✓ 不敏感的通用场景
  ✓ 需要最强能力(复杂推理+视觉)
  ✓ 团队无GPU资源
  成本: ~$0.01-0.05 / 张图片(API调用)

开源适合:
  ✓ 金融/医疗等数据敏感场景(数据不出域)
  ✓ 大批量处理(日处理>10万张)
  ✓ 需要Fine-tune适配特定领域
  ✓ 长期成本优化
  成本: GPU硬件摊薄后 ~$0.001-0.005 / 张图片

金融场景经验法则:
  PoC阶段: Claude Sonnet 4 API (最快出效果)
  生产阶段: Qwen2-VL-72B / InternVL2.5 私有化部署
  混合方案: 简单票据→本地7B模型，复杂文档→API兜底

---

知识点4: 视频理解

视频 = 帧序列 + 时间信息

视频理解的本质:
  视频 = 连续的图片帧(24-60fps) + 音频 + 时间顺序

挑战:
  1秒视频 = 24-30帧 × 每帧576+ tokens = 13,000-17,000 tokens!
  1分钟视频 = ~100万 tokens → 直接处理完整视频极其昂贵
  10分钟视频 = ~1000万 tokens → 超出所有模型上下文窗口

  → 必须做帧采样和压缩!

视频处理的四种方案

方案1: 均匀抽帧 (最简单)
  10分钟视频 → 每10秒抽1帧 → 60帧 → ~35K tokens
  优点: 简单、成本可控
  缺点: 可能错过关键瞬间(闪烁的异常、快速动作)
  适用: 监控视频、会议录像等变化缓慢的场景

方案2: 关键帧提取 (场景检测)
  用场景切换检测算法 → 只提取画面变化明显的帧
  优点: 不遗漏重要变化
  缺点: 需要额外算法、实时性差
  适用: 电影分析、活动检测

方案3: 时间Token编码 (Gemini方案)
  将视频原生编码为token序列，保留时间信息
  Gemini 2.5 Pro: 1小时视频 ≈ ~1M tokens(在上下文窗口内!)
  优点: 保留时间动态、最强视频理解能力
  缺点: 只有Gemini支持
  适用: 需要时序推理的场景(动作分析、事件顺序)

方案4: 视频专用模型
  Video-LLaVA, Video-ChatGPT, PLLaVA
  在LLM之前加时间聚合模块(3D Conv或时间Attention)
  优点: 针对视频优化
  缺点: 开源模型能力仍有限
  适用: 学术研究、特定垂直场景

时间建模方法

纯空间理解 (把每帧当独立图片):
  "第3帧有一个人"、"第7帧有一辆车"
  但不知道: 人是在走向车、还是远离车

加入时间建模后:
  帧序列 → 时间Attention/3D编码 → 理解动态
  "一个人在0:05开始走向银行柜台，0:12到达柜台，0:15开始交谈"

时间建模技术:
  1. 帧级Position Embedding: 给每帧加时间戳位置编码
  2. Temporal Attention: 跨帧的注意力计算
  3. SlowFast: 两个路径——慢路径看全局(低帧率)、快路径看动作(高帧率)
  4. Video Token Merging: 相邻相似帧合并，减少冗余Token

长视频理解的核心挑战

Challenge 1: Token数量爆炸
  问题: 10分钟视频 ≈ 百万级tokens
  解决: 层次化处理——先粗粒度概述→发现重要片段→细粒度分析
  金融应用: 1小时视频会议 → 先提取议程→定位讨论投资决策的片段→详细转录

Challenge 2: 时间跨度推理
  问题: "视频开头的人物在结尾做了什么?" → 需要跨越全视频的推理
  解决: 记忆机制——维护"视频状态摘要"，不断更新
  金融应用: "整场路演中，CEO对Q3业绩的表述前后是否矛盾?"

Challenge 3: 多模态对齐
  问题: 画面+字幕+语音，三个信息源需要对齐
  解决: 时间戳对齐→统一Token序列
  金融应用: 视频会议中PPT画面+口头承诺的一致性检查

2025-2026现状:
  Gemini 2.5 Pro: 1小时视频理解已可用
  GPT-4o: 支持视频输入，约10分钟上限
  开源模型: 多数只支持1-2分钟短视频
  → 长视频理解仍是Gemini的独占优势

视频理解应用场景

金融领域:
  ├── 视频会议纪要: 投资委员会/董事会录像 → 自动提取决策要点
  ├── 路演分析: CEO演讲视频 → 提取关键财务承诺、情感分析
  ├── 合规监控: 营业网点录像 → 检测违规操作(如未验证身份)
  └── 远程尽调: 工厂/仓库视频 → 验证实际运营情况

零售领域:
  ├── 货架监控: 监控录像 → 缺货检测、陈列合规检查
  ├── 客流分析: 门店录像 → 热力图、停留时间、转化路径
  ├── 防损监控: 异常行为检测(盗窃/损坏)
  └── 广告效果: 店内屏幕前的注意力和反应分析

---

知识点5: 多模态应用场景深度

场景1: 文档OCR与表格提取

传统OCR vs VLM OCR:
  传统OCR (Tesseract/PaddleOCR):
    → 纯字符识别 → 不理解语义
    → "金额: ¥12,345.67" → 只知道是字符串
    → 复杂表格结构容易错乱

  VLM OCR (GPT-4o/Claude/Qwen2-VL):
    → 理解文档结构 + 语义
    → "金额: ¥12,345.67" → 知道这是一笔交易金额
    → 能输出结构化JSON: {"amount": 12345.67, "currency": "CNY"}
    → 复杂嵌套表格也能处理

金融文档处理流水线:
  传统方案: 扫描 → OCR → 规则解析 → 人工校对 → 入库
  VLM方案:  扫描 → VLM一步到位(识别+理解+结构化) → 人工抽检 → 入库
  效率提升: 处理时间缩短60-80%，人工校对量减少70%

实际精度 (2025):
  印刷体表格: 95-99% (已可替代人工)
  手写体: 85-92% (仍需人工兜底)
  复杂混排(图+表+文): 90-95% (Claude/Gemini最好)
  模糊/倾斜/污损: 70-85% (需要预处理)

场景2: 图表理解与数据提取

VLM能从图表中提取什么:
  柱状图 → 各柱的数值、比较关系、趋势
  折线图 → 趋势变化、拐点、峰谷值
  饼图   → 各扇区占比、类别标签
  散点图 → 分布模式、异常值、相关性
  K线图  → 开高低收、成交量、形态识别

金融图表场景:
  1. 财报中的图表 → 自动提取数据，与文本描述交叉验证
  2. 研报中的图表 → 直接问"这张图表说明什么趋势"
  3. Bloomberg截图 → 提取特定指标数值
  4. 交易所数据展示 → 截图即可获取结构化数据

Claude Vision在图表任务上的独特优势:
  → 极低幻觉率: 不瞎编看不清的数字
  → 结构化输出: 擅长输出JSON/表格格式
  → 推理能力: 不只是OCR，能计算"同比增长X%"
  → 2025 Claude Opus 4 在ChartQA benchmark上达到SOTA

场景3: 零售货架识别

货架识别任务:
  输入: 货架照片
  输出: 商品种类、品牌、位置、陈列面积占比、价签信息

传统方案: 专用目标检测模型(YOLO) + 分类模型 + OCR
VLM方案:  一个VLM搞定识别+理解+报告

VLM优势:
  → 零样本泛化: 新品上架不需要重新标注训练
  → 理解陈列规则: "可口可乐应在第二层，实际在第四层"
  → 自然语言交互: "这个货架上百事和可口可乐的陈列面积比是多少?"
  → 跨场景复用: 同一模型处理不同门店/不同货架布局

局限:
  → 精确计数不可靠(15个还是17个分不清)
  → 被遮挡/堆叠的商品识别困难
  → 细粒度SKU区分(同品牌不同口味)仍需专用模型
  → 生产环境: VLM初筛 + 专用模型精确检测 = 混合方案

场景4: 金融票据处理

常见金融票据:
  增值税发票 → 金额/税号/开票日期/购买方/销售方
  银行回单   → 付款人/收款人/金额/摘要
  海关报关单 → 品名/数量/价值/原产国
  保险单     → 被保险人/保额/保期/条款

VLM处理流程:
  1. 分类: 识别票据类型(发票/回单/合同)
  2. 提取: 关键字段结构化抽取
  3. 校验: 交叉验证(金额大小写一致性、日期逻辑)
  4. 输出: JSON/数据库写入

Prompt示例:
  "请分析这张增值税专用发票，提取以下字段并以JSON格式返回:
   发票代码、发票号码、开票日期、购买方名称、购买方税号、
   销售方名称、金额(不含税)、税率、税额、价税合计。
   如果某字段无法识别，标记为null。"

实际部署考量:
  → 串行vs并行: 大批量票据需要并行处理架构
  → 置信度机制: 低置信度字段自动转人工
  → 兜底策略: VLM失败时降级到传统OCR
  → 审计日志: 保留原始图片+VLM输出，便于追溯

场景5: 医疗影像 (了解)

X光/CT/MRI → VLM辅助诊断
  → 不是替代医生，而是"AI第二意见"
  → 2025: FDA已批准多个AI辅助诊断产品
  → VLM在此领域主要用于报告生成，非诊断本身
  → 精准诊断仍需专用医学影像模型(如MedSAM)

场景6: 自动驾驶 (了解)

VLM在自动驾驶中的角色:
  → 场景理解: "前方有施工路障，需要变道"
  → 语言交互: "为什么在这里停车?" → "前方行人正在过马路"
  → 不做实时控制(延迟太高)，做高层理解和规划
  → Tesla FSD / Waymo等用专用模型，VLM做辅助

---

知识点6: 本地多模态部署

硬件需求与模型选择

8GB显存 (RTX 4060/3070):
  → Qwen2-VL-2B (FP16, ~4GB显存)
  → InternVL2.5-2B (FP16, ~4GB显存)
  → LLaVA-OneVision-0.5B (FP16, ~1GB显存)
  → Qwen2-VL-7B (4-bit量化, ~5-6GB显存)  ← 推荐
  → MiniCPM-V 2.6 (8B, 4-bit, ~6GB显存)

16GB显存 (RTX 4080/4070Ti):
  → Qwen2-VL-7B (FP16, ~14GB)  ← 最佳性价比
  → InternVL2.5-8B (FP16, ~16GB)
  → LLaVA-OneVision-7B (FP16, ~14GB)

24GB显存 (RTX 4090/3090):
  → 上述所有7-8B模型轻松运行
  → InternVL2.5-26B (4-bit量化, ~16GB)

48GB+显存 (A6000/双卡):
  → Qwen2-VL-72B (4-bit量化, ~40GB)
  → InternVL2.5-78B (4-bit量化, ~45GB)

Ollama多模态支持

# Ollama是本地VLM最简单的部署方式 (2025年已原生支持多模态)

# 安装模型
ollama pull llava:7b              # LLaVA 7B
ollama pull llava:13b             # LLaVA 13B
ollama pull minicpm-v:8b          # MiniCPM-V (中文友好)
ollama pull llama3.2-vision:11b   # Llama 3.2 Vision

# 命令行使用
ollama run llava:7b "Describe this image" --image ./invoice.jpg

# Python API调用
import ollama

response = ollama.chat(
    model='llava:7b',
    messages=[{
        'role': 'user',
        'content': '请分析这张发票，提取金额和日期',
        'images': ['./invoice.jpg']
    }]
)
print(response['message']['content'])

# 注意: Ollama多模态模型选择有限，精度不如原生框架
# 复杂场景建议用vLLM或Transformers直接部署

vLLM部署Qwen2-VL (推荐生产方案)

# vLLM 2025已原生支持多模态模型推理

# 安装
pip install vllm>=0.6.0

# 启动Qwen2-VL-7B服务
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2-VL-7B-Instruct \
    --trust-remote-code \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.9 \
    --port 8000

# 调用方式(兼容OpenAI API格式)
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2-VL-7B-Instruct",
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "提取这张发票的关键信息"},
        {"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,..."}}
      ]
    }]
  }'

# 优势:
#   OpenAI兼容API → 应用层代码无需改动
#   高吞吐(PagedAttention) → 适合批量处理
#   支持动态分辨率 → Qwen2-VL的核心能力保留

Transformers直接推理 (最灵活)

# 适合调试、小批量、需要细粒度控制的场景

from transformers import Qwen2VLForConditionalGeneration, AutoProcessor
from qwen_vl_utils import process_vision_info
import torch

# 加载模型 (7B FP16需要约14GB显存)
model = Qwen2VLForConditionalGeneration.from_pretrained(
    "Qwen/Qwen2-VL-7B-Instruct",
    torch_dtype=torch.float16,  # 或 torch.bfloat16
    device_map="auto"           # 自动分配GPU/CPU
)
processor = AutoProcessor.from_pretrained("Qwen/Qwen2-VL-7B-Instruct")

# 构造消息 (支持本地图片/URL/Base64)
messages = [{
    "role": "user",
    "content": [
        {"type": "image", "image": "file:///path/to/invoice.jpg"},
        {"type": "text", "text": "请提取发票金额、开票日期、购买方，以JSON返回"}
    ]
}]

# 推理
text = processor.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
image_inputs, video_inputs = process_vision_info(messages)
inputs = processor(text=[text], images=image_inputs, videos=video_inputs,
                   padding=True, return_tensors="pt").to(model.device)

output_ids = model.generate(**inputs, max_new_tokens=512)
output = processor.batch_decode(output_ids, skip_special_tokens=True)
print(output[0])

# 4-bit量化版本 (8GB显存可用)
model = Qwen2VLForConditionalGeneration.from_pretrained(
    "Qwen/Qwen2-VL-7B-Instruct",
    load_in_4bit=True,
    device_map="auto"
)

部署选型决策

场景 → 推荐方案:

个人学习/Demo:
  → Ollama + llava:7b (5分钟搞定)

PoC验证:
  → Claude Sonnet 4 API (无需GPU，效果最好)

小团队生产 (日处理<1000张):
  → vLLM + Qwen2-VL-7B on 1xRTX 4090

中大规模生产 (日处理>10000张):
  → vLLM + Qwen2-VL-72B on 4xA100
  → 或 SGLang + InternVL2.5-78B

成本对比 (处理1万张发票/天):
  Claude Sonnet API: ~$50-100/天
  本地Qwen2-VL-7B (RTX 4090): ~$3/天 (电费+摊薄硬件)
  本地Qwen2-VL-72B (4xA100租): ~$30/天 (云GPU租赁)
  → 日处理量>5000张时，本地部署开始有成本优势

---

今日思考

思考1: VLM会消灭传统OCR行业吗?

我的判断: 不是消灭，而是重新定义

传统OCR (如ABBYY/合合信息) 的壁垒:
  → 20+年积累的字符识别精度
  → 特定版式的模板匹配(增值税发票有固定格式)
  → 极低延迟(10ms级别)
  → 离线/边缘部署成熟

VLM OCR 的优势:
  → 零模板: 新票据类型无需开发模板
  → 理解语义: 不只识别字符，还理解含义
  → 灵活输出: 任意格式的结构化数据

未来格局:
  标准化票据(发票/身份证) → 传统OCR仍有优势(快/准/便宜)
  非标文档(合同/研报/邮件) → VLM碾压传统方案
  复杂混合文档(图+表+文) → VLM是唯一可行方案

对金融行业的影响:
  → 文档数字化团队的职能从"开发模板"转向"设计Prompt+质检"
  → 非标文档处理成本下降90%
  → 催生新产品: "拍照即录入"、"扫描即分析"

思考2: 多模态是通往AGI的必经之路吗?

观点: 多模态不只是"锦上添花"，而是智能的基础要件

为什么文本LLM有天花板:
  → 人类70%的信息通过视觉获取
  → 很多概念无法纯文本表达("这个零件的形状"、"那栋楼的位置")
  → 空间推理、物理直觉需要视觉经验
  → "盲人摸象" vs "全方位观察" → 多模态让AI从前者升级到后者

2025-2026趋势:
  → 原生多模态成为标配(不再是"加上视觉模块")
  → Gemini/GPT-5: 图文音视频统一训练
  → 下一步: 触觉/嗅觉/空间(具身智能)
  → World Model: 不只是"看懂"，还要"理解物理世界如何运作"

PM视角:
  产品设计不要再把"文本交互"和"图片交互"当两个功能
  → 统一的多模态交互才是自然的用户体验
  → 用户不在乎你用了几个模型，他只想拍一张照片得到答案

思考3: 视频理解会改变哪些行业?

短期已在改变 (2025-2026):
  → 视频会议: 自动纪要+行动项提取(Fireflies, Otter.ai已在用)
  → 安防监控: 异常行为检测从规则匹配→语义理解
  → 教育: 视频课程自动索引、内容搜索
  → 电商: 直播商品自动识别和上架

中期将改变 (2027-2028):
  → 金融合规: 所有客户沟通视频自动审查
  → 零售运营: 门店监控→实时陈列/服务质量评分
  → 医疗: 手术录像自动分析和培训
  → 保险: 事故现场视频→自动定损

关键瓶颈:
  → 长视频处理成本仍然很高(1小时视频 ≈ $1-5 API费用)
  → 实时处理延迟(Gemini Live约1-2秒延迟)
  → 隐私和合规(视频包含人脸/敏感信息)
  → 准确率: 关键决策仍需人工确认

架构师建议:
  现在就开始设计支持多模态的数据管道
  → 视频存储 → 抽帧/转录 → VLM分析 → 结构化存储 → 检索
  → 不要等技术完全成熟才动手，基础设施先行

---

面试表达

30秒回答

"多模态VLM的核心架构是Vision Encoder + Projection + LLM三层结构。
Vision Encoder(通常是ViT或SigLIP)将图片编码为视觉Token，
Projection层(MLP或Cross-Attention)将视觉Token对齐到语言空间，
然后和文本Token一起送入LLM统一处理。

2025年，闭源模型中Gemini擅长视频、Claude擅长图表和文档精度、GPT-4o最全面；
开源模型中Qwen2-VL和InternVL2.5已接近闭源水平。
金融场景最大的价值在文档OCR和表格提取，VLM比传统OCR灵活10倍。"

深度回答模板

Q: "你会如何为银行设计一个多模态文档处理系统?"

A: "我会分三层设计:

  接入层: 统一多渠道输入
    手机拍照 → 图片预处理(旋转/裁剪/增强)
    扫描件 → PDF解析 → 按页转图片
    邮件附件 → 格式识别 → 图片提取

  处理层: 分级处理策略
    标准票据(发票/身份证) → 传统OCR(快+准+低成本)
    非标文档(合同/研报)  → VLM处理(Qwen2-VL本地部署)
    复杂/高价值文档      → 闭源API兜底(Claude Opus 4)
    每层都输出置信度分数 → 低置信度自动转人工

  输出层: 结构化+校验
    VLM输出JSON → Schema验证 → 业务规则校验
    例: 金额大小写一致性、日期合理性、税号校验位
    异常自动标记 → 人工审核队列

  关键架构决策:
    本地部署vs API → 敏感数据不出域，用本地Qwen2-VL
    同步vs异步 → 大批量用异步队列(Kafka+Worker)
    成本控制 → 分级路由，简单任务不浪费大模型算力
    可观测性 → 每笔处理记录耗时/Token数/置信度/人工改动率"

Q: "动态分辨率为什么重要?"
A: "因为金融文档形态千差万别——增值税发票是横版的、银行回单是竖版的、
    合同是A4纵向的。固定分辨率resize会丢失小字体细节，
    动态分辨率按原始宽高比切分tiles，保留每个区域的细节。
    这是VLM在文档场景从'玩具'变'可用'的关键技术转折点。
    实际测试中，动态分辨率让票据字段提取准确率从85%提升到95%以上。"

---

学习资源

必读论文

技术博客与教程

实操资源

---

明日预告

Day 11: Reasoning模型 — CoT / o1 / R1 / Extended Thinking

核心问题:
  LLM只是"直觉式回答" → 如何让AI"深度思考"?
  金融场景: 复杂风控决策、投资逻辑推演 → 需要推理而非记忆

预习: Chain-of-Thought → Self-Consistency → Tree-of-Thought
     → OpenAI o1/o3 → DeepSeek R1 → Claude Extended Thinking
     → 推理 Token 的成本问题 → 何时用推理模型

与今日关系:
  Day 10 多模态 → 让AI看懂更多类型的信息(图/视频)
  Day 11 推理   → 让AI在理解信息后进行深度推理和逻辑推演
  组合 = 能看懂复杂图表(Day 10) + 从中推导出投资结论(Day 11)

---

Day 10 总结: 多模态VLM的核心架构是 Vision Encoder(ViT/SigLIP编码图像为Token) + Projection(MLP/Cross-Attention对齐到语言空间) + LLM Decoder(统一处理视觉和文本Token)。2024-2025的关键突破是动态分辨率处理——让VLM在文档/票据场景从"不可用"变为"生产可用"。闭源模型中Gemini擅长视频、Claude擅长精准文档提取、GPT-4o最全面；开源模型Qwen2-VL和InternVL2.5已接近闭源水平，7B量级模型可在消费级GPU上运行。对PM/架构师而言，多模态不是"高级功能"，而是AI产品的基础能力——金融行业70%的信息藏在非纯文本中(图表/票据/监控)，VLM是打开这70%信息的钥匙。本地部署推荐Qwen2-VL-7B(4-bit量化仅需8GB显存)，生产环境用vLLM服务化，日处理量超过5000张时成本显著低于API方案。