多模态AI从视觉Token到商业系统完整原理
多模态 AI 让模型同时处理文本、图片、音频、视频和文档布局。它不是“把图片直接塞进语言模型”：每种模态都要经过解码、规范化、采样或切块，再由专用编码器转换成向量，通过 Projector 或原生多模态结构映射到语言模型可以融合的表示，最后才参与 Attention 和生成。
多模态能力扩大了输入范围，也扩大了成本和风险：一张高分辨率扫描件可能变成大量视觉 Token；图片文字太小会在缩放后消失；视频漏抽关键帧就无法回答；文件元数据和画面可能含个人隐私；模型描述得很流畅也可能读错金额、单位和空间关系。
学习目标
完成本页后，你应该能够：
- 区分纯文本、OCR、ASR、计算机视觉和多模态大模型。
- 解释图片解码、缩放、Patch、视觉编码、Projector和视觉Token链路。
- 计算固定Patch方案的理论Patch数量并理解实际Provider计费可能不同。
- 解释文字为什么会因分辨率、缩放和压缩而识别失败。
- 为截图、扫描件、表格、图表、音频和视频选择不同处理方案。
- 设计 OCR/版面模型/多模态模型的混合架构。
- 解释音频采样、ASR、说话人分离和视频抽帧的边界。
- 设计多模态RAG离线入库、检索、引用和权限。
- 处理上传安全、隐私、Prompt Injection、成本和异步任务。
- 建立按任务和模态分层的评估集。
- 排查图片读错、图表算错、视频漏事件、超时和成本升高。
- 写出图片预算估算和受控上传接口Demo。
一、先区分相关技术
| 能力 | 输入输出 | 擅长 | 不擅长/边界 |
|---|---|---|---|
| OCR | 图片→文字和坐标 | 稳定文字检测与识别 | 复杂语义推理、业务结论 |
| ASR | 音频→转写文本和时间戳 | 语音识别 | 业务总结和事实核验 |
| 目标检测 | 图片→类别和框 | 固定目标定位 | 开放式问答 |
| 版面分析 | 文档→段落、表格、阅读顺序 | 文档结构 | 通用自然语言推理 |
| 多模态大模型 | 图片/音频/文本→文本或结构 | 开放式理解、问答和解释 | 精确计数、确定性坐标、强事实保证 |
商业系统通常组合，而不是互相替代：OCR 提供可校验文字和坐标，规则校验金额，版面解析还原表格，多模态模型理解上下文并生成解释。
二、图片到回答的完整链路
flowchart TD
A["用户上传图片和问题"] --> B["鉴权、配额和文件流限速"]
B --> C["Magic Number、格式、大小和病毒检查"]
C --> D["安全解码、方向纠正和颜色转换"]
D --> E["缩放、裁剪、切Tile或保持高分辨率"]
E --> F["图片划分Patch或视觉区域"]
F --> G["视觉Encoder生成特征"]
G --> H["Projector映射到语言模型维度"]
H --> I["形成视觉Token/Embedding"]
I --> J["与文本Token和位置关系融合"]
J --> K["多层Attention与自回归生成"]
K --> L["结构、引用、事实和安全校验"]
L --> M["返回结果并记录版本、Token和耗时"]每一层都可能失败。模型回答“看不清”可能不是模型参数能力不足，而是上传图片被后端压缩、EXIF方向错误、文字在统一缩放后只剩几个像素，或多图顺序错乱。
三、图片如何变成Patch和视觉Token
3.1 固定Patch直觉
以 Vision Transformer 思路为例，若模型输入图像大小为 H×W，Patch边长为 P，且能整除：
Patch数量 = (H / P) × (W / P)例如 224×224 图片、Patch 16×16：
14 × 14 = 196个Patch每个Patch展开并线性映射为向量，再加位置表示送入视觉Encoder。可能还有全局/分类Token；模型和Provider也可能对视觉特征降采样、重采样或使用动态分辨率，因此“Patch数”不自动等于最终计费视觉Token数。
flowchart TD
A["输入图片"] --> B["切成固定Patch或动态Tile"]
B --> C["每个Patch映射为向量"]
C --> D["加入二维位置关系"]
D --> E["视觉Transformer/Encoder"]
E --> F["视觉特征序列"]3.2 为什么需要位置
只知道图片包含“红灯”和“车辆”不够，还要知道灯在上方、车辆在停止线前。二维位置、相对位置或模型特定机制帮助表达空间布局。多模态模型仍可能在左右、前后、精确坐标和计数上出错，关键场景应结合检测模型或规则。
3.3 动态分辨率和切Tile
高分辨率图片统一缩到很小会丢文字。常见方向：
- 按长宽比缩放并Pad。
- 将高分辨率图片切成多个Tile，同时保留全局缩略图。
- 根据内容动态选择区域。
- 先用OCR/检测定位关键区域，再裁剪送模型。
Tile越多，细节可能越清楚，但视觉Token、延迟、显存和费用增长。切块还会破坏跨Tile关系，需要保留页码、坐标和顺序。
四、视觉Encoder、Projector和语言模型怎样连接
4.1 视觉Encoder
负责把像素变成高层视觉特征。浅层可能表达边缘和纹理，深层组合成对象、文字区域和语义关系。它输出的维度和分布通常与语言模型Token Embedding不同。
4.2 Projector
Projector把视觉特征映射到语言模型隐藏维度，可以是线性层、MLP、Query/Resampler等结构。它不是简单“改一下数组长度”，而是训练跨模态对齐，使视觉表示能被语言模型利用。
4.3 跨模态对齐
训练通常需要图片—文本描述、问答、指令等数据，让模型学会视觉区域与语言概念的关联。若训练数据偏向自然照片，模型对医疗影像、工程图和密集表格未必可靠。
4.4 融合方式
不同模型可能：
- 把视觉表示作为一段特殊Token插入语言序列。
- 用Cross-Attention让文本查询视觉特征。
- 使用更原生的统一多模态架构。
不要用某一个开源架构推断所有云模型内部实现。工程上要关注其公开输入限制、Token/费用规则、能力评估和可观测元数据。
五、文本和视觉Token怎样共同生成
[System规则]
[图片1视觉表示]
[图片1来源与页码]
[图片2视觉表示]
[用户问题]
[模型输出]模型通过Attention让文本问题读取视觉信息，再逐Token生成答案。输入顺序会影响“这张图”“上一页”等指代；多图请求必须提供稳定图片ID、页码或标签，不能只依赖数组位置。
视觉内容也会占上下文和预算。文本历史很长、图片很多时，可生成空间变少，Prefill变慢。不同Provider对低/高细节模式、缩放和计费规则不同，最终以真实Usage和文档为准。
六、可运行Demo：Patch和预算估算
下面只做教学估算，不声称等于任何Provider账单：
from dataclasses import dataclass
from math import ceil
@dataclass(frozen=True)
class ImageInput:
width: int
height: int
image_id: str
def estimate_patches(image: ImageInput, patch_size: int = 16) -> int:
if image.width <= 0 or image.height <= 0 or patch_size <= 0:
raise ValueError("图片尺寸和patch_size必须为正数")
return ceil(image.width / patch_size) * ceil(image.height / patch_size)
def estimate_request(
images: list[ImageInput],
text_tokens: int,
max_output_tokens: int,
context_limit: int,
patch_size: int = 16,
compression_ratio: float = 4.0,
) -> dict:
raw_patches = sum(estimate_patches(image, patch_size) for image in images)
# 仅模拟视觉编码器/Resampler把多个patch压缩为较少视觉表示。
visual_tokens = ceil(raw_patches / compression_ratio)
required = text_tokens + visual_tokens + max_output_tokens
return {
"image_count": len(images),
"raw_patch_estimate": raw_patches,
"visual_token_teaching_estimate": visual_tokens,
"required_context": required,
"remaining_context": context_limit - required,
"allowed": required <= context_limit,
"warning": "真实视觉Token和计费由目标模型与Provider决定",
}
if __name__ == "__main__":
images = [
ImageInput(1024, 768, "screenshot-1"),
ImageInput(1600, 1200, "invoice-2"),
]
print(estimate_request(
images=images,
text_tokens=2_000,
max_output_tokens=1_000,
context_limit=32_768,
))使用它比较图片数量、分辨率和Patch大小的增长趋势即可；不要用 compression_ratio=4 计算真实费用。
七、图像预处理为什么决定上限
7.1 安全解码
文件扩展名和Content-Type可伪造，应检查Magic Number并使用安全解码库。限制：
上传字节数
解码后像素数
宽高
帧数
页数
压缩比
处理时间
并发小文件也可能解码成巨大像素，形成解压炸弹和内存攻击。
7.2 方向和颜色
手机照片可能依赖EXIF Orientation；忽略会横置或倒置。CMYK、灰度、带Alpha、特殊色彩空间应规范转换，并保留原文件摘要和变换记录用于审计。
7.3 缩放和压缩
JPEG重复压缩产生块状伪影，过度缩放让小字消失。对密集文档应按页和区域处理，而不是把A3扫描件缩成单张224像素图。
7.4 裁剪
裁剪能降低成本和噪声，但可能删除图例、单位、页眉或异常区域。保留原图坐标和裁剪框，回答引用才能回到原图。
八、OCR与多模态模型怎样组合
flowchart TD
A["扫描件/票据"] --> B["版面检测和方向纠正"]
B --> C["OCR文字、坐标和置信度"]
B --> D["关键区域图片"]
C --> E["规则校验日期、金额和编号"]
D --> F["多模态模型理解上下文"]
E --> G["结构化候选"]
F --> G
G --> H["Schema和跨字段业务校验"]
H --> I{"低置信或冲突"}
I -->|"是"| J["人工复核"]
I -->|"否"| K["保存结果、坐标和证据"]OCR优势是字符、坐标、置信度和可重复后处理；多模态模型优势是理解布局和语义。发票金额、银行卡、药品剂量等关键字段不能只依赖自然语言回答，应使用Schema、校验和人工门槛。
九、表格和图表为什么容易错
9.1 表格
问题包括合并单元格、跨页表头、阅读顺序、空白含义和单位。建议同时保存：
原页图片
单元格坐标
HTML/结构化表格
OCR文字
页码和表标题9.2 图表
模型可能看错：
- X/Y轴。
- 对数轴。
- 单位与倍率。
- 图例颜色。
- 双轴图。
- 截断坐标轴。
- 堆叠值和总值。
精确计算应先提取底层数据或使用图表解析，再由程序计算；模型负责解释趋势。要求回答引用具体轴、单位和数值，证据不足就拒绝精确结论。
十、截图和界面诊断
截图排障完整流程：
保留完整截图和时间
→ OCR提取错误码、URL和版本
→ 识别应用/浏览器/操作系统区域
→ 对敏感用户名、Token和患者信息脱敏
→ 结合日志、请求ID和实际配置
→ 模型生成候选原因
→ 运维人员用系统证据验证只看截图无法知道服务端真实堆栈、网络链路和数据库状态。模型建议是排查方向，不是根因证明。
十一、音频链路
11.1 ASR加LLM
flowchart TD
A["音频上传/实时流"] --> B["格式、采样率、声道和时长校验"]
B --> C["降噪、VAD和切片"]
C --> D["ASR转写与时间戳"]
D --> E["说话人分离和角色映射"]
E --> F["术语纠正与PII脱敏"]
F --> G["LLM摘要、质检或抽取"]
G --> H["引用时间段和人工复核"]VAD用于检测语音区间，减少静音；Diarization区分说话人，但“Speaker 1”不自动等于客服，需要业务映射。ASR错字会传递给LLM，尤其姓名、药名、金额和编号。
11.2 原生音频模型
有些模型直接编码音频特征或音频Token，能利用语气、停顿等信息。但仍需评估采样、时长、实时延迟、音频保留和隐私，不代表ASR文本链路永远不需要。
十二、视频链路
视频包含画面序列、音频和时间：
flowchart TD
A["视频"] --> B["读取容器、编码和时长"]
B --> C["镜头切分/固定间隔/事件抽帧"]
B --> D["提取音频"]
C --> E["关键帧和时间戳"]
D --> F["ASR和说话人"]
E --> G["按时间窗口融合"]
F --> G
G --> H["片段级理解"]
H --> I["全局汇总、引用和评估"]固定每10秒抽一帧可能漏掉只持续1秒的事件；高频抽帧则成本巨大且画面重复。应按场景组合镜头变化、目标检测、规则触发和自适应采样。
视频摘要不能只评估文字流畅，还要评估事件召回、时间定位、顺序和关键异常漏检。
十三、多模态RAG
13.1 离线入库
flowchart TD
A["PDF、图片、音视频"] --> B["病毒、格式和权限检查"]
B --> C["页/帧/时间段解析"]
C --> D["OCR、ASR、版面和对象检测"]
D --> E["生成文字、结构和视觉描述"]
E --> F["保存稳定assetId和区域坐标"]
F --> G["文本/图像/多模态Embedding"]
G --> H["向量库与结构化元数据"]
H --> I["原始资产受控存储"]13.2 在线查询
认证用户问题
→ 权限Filter
→ 文本/图像查询向量
→ 召回页、区域或时间段
→ Rerank
→ 获取受权原图/片段
→ 多模态模型回答
→ 引用assetId、页码、坐标或时间段权限必须在检索前生效。只在生成后删除敏感文字，向量检索和模型已经接触越权内容。
十四、受控上传接口Demo
下面展示接口边界。真实解码必须使用经过安全配置的图片库和对象存储，不应只依赖Content-Type：
from fastapi import FastAPI, File, Form, HTTPException, UploadFile
app = FastAPI()
MAX_BYTES = 8 * 1024 * 1024
ALLOWED_MAGIC = {
b"\x89PNG\r\n\x1a\n": "image/png",
b"\xff\xd8\xff": "image/jpeg",
}
def detect_type(content: bytes) -> str | None:
for magic, media_type in ALLOWED_MAGIC.items():
if content.startswith(magic):
return media_type
return None
def call_multimodal_service(content: bytes, media_type: str, question: str) -> dict:
# 真实实现应放在独立Service，设置超时、配额、版本、审计和结果校验。
return {"answer": "教学占位结果", "modelVersion": "replace-me"}
@app.post("/api/multimodal/images:analyze")
async def analyze_image(
question: str = Form(..., min_length=1, max_length=2000),
file: UploadFile = File(...),
):
content = await file.read(MAX_BYTES + 1)
if len(content) > MAX_BYTES:
raise HTTPException(413, "文件超过8MB")
detected = detect_type(content)
if detected is None:
raise HTTPException(415, "只接受真实PNG或JPEG")
if file.content_type and file.content_type != detected:
raise HTTPException(400, "声明类型与文件内容不一致")
result = call_multimodal_service(content, detected, question)
return {
"code": "SUCCESS",
"data": result,
}生产还需：登录和租户权限、流式读取、像素/宽高限制、解压炸弹保护、病毒扫描、对象存储、生命周期、并发限额、异步任务、内容安全和日志脱敏。
十五、成本和容量
总成本 = 上传与对象存储
+ 图片/音频/视频解码
+ OCR/ASR/检测
+ Embedding与索引
+ 多模态模型输入输出
+ 重试和失败任务
+ 人工复核
+ 数据保留与传输容量指标：文件大小、像素、页数、音视频时长、抽帧数、视觉Token、输入输出Token、排队、TTFT、总耗时、失败率和每任务成本。只限制HTTP文件大小不能控制解码后资源。
十六、商业场景
16.1 医疗票据和文档结构化
OCR提取文字和坐标，版面模型识别表格，多模态模型处理语义，规则验证金额、日期和编码，低置信字段人工复核。患者数据必须按租户、角色和用途隔离。
16.2 采集报错截图助手
截图OCR提取错误码，工具用requestId查日志，RAG查询当前Runbook，模型生成带证据的排查步骤。不能仅凭截图自动重启或修改生产配置。
16.3 商品质检
检测模型负责固定缺陷定位，多模态模型解释异常和生成工单；高风险判定保留原图、框坐标、模型版本和人工复核。
16.4 客服通话质检
ASR、说话人分离、规则词命中和LLM摘要组合；必须处理录音授权、保留期、员工权限和误转写申诉。
十七、评估体系
| 任务 | 指标 |
|---|---|
| OCR | 字符/词错误率、关键字段准确率 |
| 文档抽取 | 字段F1、Schema、跨字段规则 |
| 图像问答 | 事实正确、证据区域、拒答 |
| 图表 | 数值、单位、趋势、引用 |
| 音频 | WER、说话人错误、时间戳 |
| 视频 | 事件召回、时间定位、顺序 |
| 安全 | PII泄露、越权、注入成功率 |
| 性能 | 排队、TTFT、总耗时、成本 |
评估集要按清晰度、分辨率、旋转、语言、表格密度、噪声、口音、时长和设备分层。只测清晰正面图片无法代表真实上传。
十八、生产Runbook
18.1 小字总是读错
保存原始像素、后端变换记录和实际发送尺寸；检查是否过度缩放、压缩、切Tile或低细节模式。用OCR坐标和裁剪区域对照，不要只换Prompt。
18.2 图片旋转或颜色异常
检查EXIF Orientation、色彩空间、Alpha和解码库版本。记录规范化前后摘要/尺寸并生成受控缩略图取证。
18.3 图表结论错误
核对轴、单位、图例和原始数据；要求输出引用数值。若需精确计算，转为结构化数据由代码计算，而不是反复让模型“再看仔细”。
18.4 视频漏掉关键事件
检查抽帧策略和事件持续时间，确认关键时段是否有帧进入模型。调整镜头/事件触发采样，并用带时间标注评估集验证。
18.5 任务突然变慢或变贵
拆上传、解码、OCR/ASR、排队、模型Prefill/Decode；比较像素、页数、帧数、视觉Token和输出长度分布。常见是客户端上传更高分辨率或抽帧配置改变。
18.6 出现敏感信息泄露
立即停止传播，定位来自原文件、OCR、工具、RAG、模型输出还是日志；审计assetId、租户、权限、模型和缓存，清理副本并按安全流程处置。修改Prompt不能修复检索前权限缺失。
十九、常见误区
多模态模型等于OCR
错误。OCR更适合稳定文字和坐标，多模态模型擅长语义，但关键字符仍可能错。
文件小就安全
错误。压缩文件可能解码为巨大像素或大量帧。
分辨率越高越好
错误。细节提高伴随Token、延迟和费用增长，超过模型处理策略后未必继续受益。
模型能描述图表就能精确计算
错误。视觉识别、单位和数值都可能错，精确计算应使用结构化数据和代码。
视频均匀抽帧一定覆盖事件
错误。短事件可能位于两个采样点之间。
多模态回答带引用就一定真实
错误。引用必须由应用绑定真实assetId、页码、坐标或时间段，不能让模型自由编造。
二十、面试标准回答
图片怎样进入多模态大模型
图片先安全解码、纠正方向、缩放或切Tile，再划分Patch或视觉区域；视觉Encoder将像素变成特征，Projector映射到语言模型隐藏维度，形成可与文本Token融合的视觉表示；模型通过Attention读取视觉和问题，再逐Token生成答案。不同模型的动态分辨率和视觉Token规则不同。
OCR和多模态模型怎么配合
OCR负责稳定提取文字、坐标和置信度，版面分析还原表格结构；多模态模型结合图像布局和问题理解语义。商业票据通常用OCR/版面提供可校验证据，多模态生成解释，再用Schema、金额日期规则和人工门槛验收。
为什么高分辨率图片成本高
图片通常被切成Patch、Tile或视觉Token。分辨率和图片数量增加会产生更多视觉表示，占用上下文、Prefill计算、显存和费用。实际Token由目标模型和Provider策略决定，不能只按文件字节估算。
视频为什么要抽帧
视频帧数巨大，全部处理成本过高，所以会按时间、镜头变化或事件触发抽帧，并提取音频做ASR。抽帧太稀会漏短事件，太密会重复和变贵，需要用带时间标注的业务评估集选择策略。
二十一、学习验收
不看答案完成：
- 画出图片到视觉Token再到文本回答的链路。
- 计算224/16和1024/16的理论Patch数量。
- 解释为什么Patch数不一定等于Provider计费Token。
- 运行预算Demo并比较分辨率和图片数。
- 设计图片Magic Number、像素、宽高和解压炸弹限制。
- 为发票设计OCR、版面、多模态、规则和人工流程。
- 为图表回答设计单位和数值引用校验。
- 设计ASR、说话人、摘要和时间戳链路。
- 比较固定、镜头和事件抽帧。
- 设计多模态RAG的assetId、页码、坐标和权限元数据。
- 为每种模态设计质量、安全、性能指标。
- 分别排查小字错误、视频漏事件和成本突增。