Appearance
多模态专题
版本：
v1.1最后更新：
2026-07-08适用对象：需要从纯文本 LLM 走向图像、音频、视频和实时交互系统的产品、研发、平台和交付同学
多模态不是“模型会看图”这么简单，而是：
- 模型可以理解多种输入形式
- 模型可以生成多种输出形式
- 系统必须围绕不同模态设计完全不同的数据流、延迟、评测和交互方式
根据 2026-07-08 可访问的 OpenAI Image generation、Audio and speech、Video generation with Sora，Google Gemini Image understanding、Video understanding、Live API，以及 Anthropic Vision 官方资料，可以先建立一个非常关键的共识：
多模态系统的难点通常不在“模型能不能看懂”，而在“不同模态怎样被预处理、拼装、路由、评测和持续运营”。
这篇文档适合作为 AI Wiki 里从纯文本 LLM 走向图像、音频、视频和实时交互系统的总入口。
1. 什么是多模态
多模态通常指模型能够处理以下一种或多种信息：
- 文本
- 图像
- 音频
- 视频
- PDF 与图文混排文档
- 结构化工具结果
1.1 从模型视角看，多模态是“输入与输出形态变多了”
例如：
- 图像 + 文本问答
- 语音输入 + 文本输出
- 实时语音输入 + 语音回复
- 图像输入 + 图像编辑
- 视频输入 + 视频摘要
1.2 从工程视角看，多模态是“系统边界变复杂了”
真正要解决的核心问题通常是：
- 如何把不同模态的信息变成模型可消费的上下文
- 如何在质量、延迟和成本之间做权衡
- 如何设计符合用户预期的输入输出体验
- 如何让不同模态间的中间产物可追踪、可评测、可回滚
一句话理解：
多模态不是一个模型特性，而是一整条跨模态数据链路。
2. 多模态系统常见场景
2.1 理解类
常见场景包括：
- 图片问答
- OCR 与文档理解
- 视觉质检
- 语音转文本
- 视频摘要
- PDF 与图表解读
2.2 生成类
常见场景包括：
- 图像生成
- 图像编辑
- 文本转语音
- 配音与播报
- 视频生成
- 素材扩展与延展
2.3 交互类
常见场景包括：
- 语音助手
- 实时客服
- 视觉助手
- 屏幕理解与操作代理
- 低延迟语音/视频交互
2.4 检索与运营类
很多团队会忽略这一类，但它在企业里非常重要：
- 语音检索
- 图像或视频内容检索
- 多模态知识库
- 多模态数据标注与回放
3. 多模态系统的基本架构
一个典型多模态系统通常会包含以下模块：
text
User Input
-> Modality Preprocess
-> Context Assembly
-> Model / Tool Routing
-> Generation or Action
-> Post-process
-> UI / API Response其中最关键的不是“模型本身”，而是这几个工程层：
- 预处理层：压缩、切片、抽帧、降噪、格式转换
- 路由层：判断走文本模型、视觉模型、语音模型还是工具链
- 上下文层：控制输入长度和证据质量
- 后处理层：字幕、摘要、结构化结果、缓存、审核
3.1 多模态系统比纯文本系统多出的复杂度
主要来自：
- 文件与流输入
- 更重的中间产物
- 更高的 token / 媒体成本
- 更长的处理链
- 更难的故障归因
3.2 多模态工作流常常不是“一次请求”
例如一个视频摘要请求，底层可能会经历：
- 上传文件
- 抽帧
- 音频转写
- OCR
- 汇总
- 问答
所以工程上更接近一个 mini pipeline，而不是普通 chat request。
4. 多模态要先分“离线媒体”还是“实时媒体”
这一步非常重要，因为它直接决定架构。
4.1 离线媒体
适合：
- 图片理解
- 视频分析
- 会议录音转写
- 长文档 OCR
- 视频生成批任务
特点：
- 输入边界清晰
- 可以异步
- 更适合重试、回放与审计
4.2 实时媒体
适合：
- 实时语音助手
- 视觉对话
- 语音翻译
- 连续流式交互
特点：
- 输入是持续流
- 延迟直接影响体验
- 状态管理比模型能力更容易把体验做坏
4.3 为什么这一步不能混着想
因为同样是语音或视频任务，离线和实时的工程解法差别很大：
- 请求模型不同
- 延迟预算不同
- 上下文管理不同
- 回退策略不同
5. 图像模态要关注什么
OpenAI 当前 Image generation 文档明确区分了：
- 单次生成 / 编辑的 Image API
- 适合多轮编辑与多步流程的 Responses API
Anthropic Vision 文档也强调了：
- 图像理解的成本、输入限制和基于坐标的工作流边界
从工程角度看，图像系统最容易遇到的挑战包括：
- 分辨率过高导致成本和延迟上升
- 单张图信息不够，需要多图对比
- OCR、布局理解、表格理解其实是不同任务
- 图片分析结果需要转成结构化输出，方便下游系统使用
5.1 图像理解和图像生成是两类系统
图像理解更偏：
- 识别
- 提取
- 对比
- 归因
图像生成更偏：
- 风格
- 细节控制
- 角色一致性
- 品牌一致性
5.2 图像系统的工程重点往往不在“看懂”
而在：
- 如何上传与存储
- 如何压缩与裁切
- 如何留证与回放
- 如何做结果结构化
6. 音频模态要关注什么
OpenAI 当前 Audio and speech 文档把音频场景清晰拆成：
- audio input
- audio output
- transcript
- realtime session
Google Gemini Live API 也强调：
- 低延迟连续音视频流式交互是独立架构问题
音频场景与文本场景的最大不同是：
- 输入是连续流，不是静态文本
- 延迟要求更高
- 噪声、口音、设备环境会显著影响效果
典型任务包括：
- 语音转文本
- 说话人分离或角色识别
- 实时转写
- 文本转语音
- 语音对话
6.1 离线音频和实时语音是两条不同工程线
离线更偏：
- 批量处理
- 重试
- 审计
实时更偏：
- VAD / turn detection
- 中断处理
- 首包延迟
- 会话状态
6.2 语音系统的失败往往不是“模型答错”
而是：
- 断句差
- 延迟高
- 打断处理差
- 术语识别差
- 情绪与角色控制不稳
7. 视频模态要关注什么
Google Gemini 当前 Video understanding 文档明确强调：
- 视频理解要同时处理音频流和视觉流
OpenAI Video generation with Sora 文档则把视频生成拆成：
- 新建生成
- 扩展
- 编辑
- 批量渲染
所以视频系统的复杂度通常来自两头：
- 视频理解要解决长时序理解
- 视频生成要解决镜头、运动和一致性
7.1 视频理解本质上往往不是“直接看完整段”
而是：
- 抽帧
- 按镜头切分
- 结合音频转写
- 再做跨时间段总结
7.2 视频生成本质上也不是“单次出成片”
更常见的生产方式包括：
- 先出素材
- 再扩展
- 再局部编辑
- 再批量渲染不同版本
8. 多模态不只是模型能力，还包括产品决策
很多产品失败，不是模型做不到，而是交互决策错误。
8.1 什么时候不该直接上多模态
例如：
- 用户其实只需要文本结果
- 图片或语音只是锦上添花
- 成本和延迟预算不足
8.2 什么时候多模态是核心能力
例如：
- 视觉检查
- 语音助手
- 视频运营
- 课堂 / 会议回放
8.3 模态越多，交互越要收敛
因为用户通常不关心“你后面调了几个模型”，更关心：
- 输入方式是否自然
- 反馈是否及时
- 结果是否可信
9. 多模态评测怎么做
多模态系统最大的坑之一是：
- 沿用纯文本评测心智
9.1 理解类指标
适合看：
- 准确率
- 召回率
- 引用正确率
- 关键信息漏检率
9.2 生成类指标
适合看：
- 一致性
- 风格稳定性
- 可用率
- 编辑可控性
9.3 交互类指标
适合看：
- 首响应延迟
- 打断恢复成功率
- 任务完成率
- 用户中途放弃率
9.4 运营类指标
企业里更该补的还有：
- 成本
- 重试率
- 异步任务完成率
- 人工复核率
10. 多模态系统的常见坑
10.1 过早追求全模态一体化
结果往往是：
- 复杂度暴增
- 诊断难度上升
10.2 不做预处理，直接把原始媒体全塞给模型
后果通常是：
- 更贵
- 更慢
- 证据更脏
10.3 只测演示样例，不测真实环境
尤其在语音和视频里，真实环境噪声与设备差异会迅速暴露问题。
10.4 只看最终结果，不看中间产物
这样很难判断问题出在：
- 抽帧
- OCR
- 转写
- 汇总
- 生成
11. 一条更实用的多模态学习与落地路线
如果你准备从纯文本 LLM 走向多模态，通常更适合按下面顺序推进：
- 先理解离线图像与文档理解
- 再理解离线音频转写与 TTS
- 再进入视频理解与视频生成
- 最后再碰实时语音 / 视觉交互
因为实时系统对：
- 延迟
- 状态
- 中断
- 运营
要求都明显更高。