Skip to content

多模态专题索引

版本:v1.7

最后更新:2026-07-08

这组文档主要讨论:

  • 模型如何同时处理文本、图像、音频和视频等多种输入
  • 多模态能力怎么进入真实应用链路

它不是“给文本模型加一个文件上传按钮”的附录,而是从文本系统扩展到:

  • 视觉理解与文档解析
  • 语音交互与实时会话
  • 视频理解与视频生成
  • 多模态评测、成本与治理

的一条完整主线入口。


1. 这组内容在解决什么

多模态系统和纯文本系统最大的不同,在于它要同时处理:

  • 不同模态的输入格式
  • 不同模态之间的对齐关系
  • 不同模态带来的时延、成本和评测问题

2026-07-08 可访问的 OpenAI Images and visionFile inputsAudio and speechRealtime and audioVideo generation with SoraRealtime transcriptionRealtime translationManaging costs for Realtime,以及 Google Gemini Video understanding、Anthropic Vision 官方资料来看,多模态至少要同时回答五个问题:

  1. 图像、音频、视频和文件到底该怎么进入上下文,而不是只看“能不能上传”。
  2. 离线文件链路和实时流式链路到底该如何拆开。
  3. 图像理解、文档解析、视频理解、语音助手和媒体生成为什么不能用同一套工程心智。
  4. 多模态质量到底该在预处理、模型调用、任务完成和运营层分别怎么评。
  5. 成本、留存、审核和权限为什么必须在方案阶段就设计进去。

2. 推荐阅读顺序

2.1 想先建立多模态基本认知

  1. 01-多模态基础与应用
  2. 02-图像理解、文档解析与视觉工作流
  3. 03-实时语音、转写与语音助手架构

2.2 想重点做视觉理解、OCR 或文档系统

  1. 02-图像理解、文档解析与视觉工作流
  2. 视觉模型专题
  3. 平台工程

2.3 想重点做实时语音、转写或语音助手

  1. 03-实时语音、转写与语音助手架构
  2. 语音模型专题
  3. Realtime与语音工作流专题

2.4 想重点做视频理解、视频生成或长媒体链路

  1. 04-视频理解、生成与时间轴设计
  2. 视频模型专题
  3. 平台工程

2.5 想建立多模态上线、评测和治理视角

  1. 05-多模态评测、成本与治理
  2. 多模态评测案例专题
  3. 安全治理

3. 这一组现在包含什么

  1. 01-多模态基础与应用:负责总论,建立离线媒体、实时媒体、理解类、生成类和交互类的整体分界。
  2. 02-图像理解、文档解析与视觉工作流:负责讲图像输入、文件输入、PDF/表格/截图工作流、结构化输出和视觉系统评测。
  3. 03-实时语音、转写与语音助手架构:负责讲 request-based audio、realtime conversation、transcription、translation、VAD、打断和语音工具调用状态机。
  4. 04-视频理解、生成与时间轴设计:负责讲视频理解、视频生成、分镜、抽帧、时间轴组织和异步渲染链路。
  5. 05-多模态评测、成本与治理:负责讲评测分层、grader 设计、成本账本、降级与异步 lane、数据留存、安全审核、媒体谱系和多模态运营边界。

4. 多模态系统最值得先建立的几个共识

4.1 多模态不是“模态越多越高级”

很多系统真正需要的,可能只是:

  • 图像理解 + 文本回答
  • PDF 理解 + 结构化抽取
  • 音频转写 + 摘要

而不是一开始就把图像、语音、视频和实时流全混在一起。

4.2 文件链路和实时链路不是同一件事

OpenAI 当前把 File inputsAudio and speechRealtime and audioRealtime transcriptionRealtime translation 分成多份文档,本身就说明:

  • 上传文件分析
  • 单次语音处理
  • 实时持续会话

是三套不同的产品与工程边界。

4.3 多模态系统的难点通常不在“模型能不能看懂”

更常见的难点反而是:

  • 图像裁切和分辨率策略
  • PDF / 表格 / 截图如何预处理
  • 音频切分、VAD 与打断恢复
  • 视频抽帧和时间轴压缩
  • 多模态结果如何结构化、校验和回放

4.4 生成类和理解类不要混在一个治理框架里

理解类更关心:

  • 准确率
  • 召回
  • 字段完整性
  • 时间顺序正确性

生成类更关心:

  • 风格一致性
  • 输出稳定性
  • 可编辑性
  • 审核与交付率

4.5 多模态越强,数据和留存问题越要前置

图像、录音、视频和文档比纯文本更容易碰到:

  • 隐私边界
  • 文件权限
  • 长期留存
  • 安全审核
  • 成本失控

所以更适合和 安全治理 以及 评测运营与案例 一起看。

4.6 实时多模态会话本质上也是“会话状态系统”

OpenAI 当前 Realtime conversationsConversation state 的官方资料都在强调:

  • 实时会话不是单次请求
  • session 里的响应默认会进入默认会话状态
  • 你可以控制哪些会话项参与某次响应生成,或者并发生成多个响应

这对工程设计的启发很重要,因为多模态实时系统除了“能不能听懂 / 看懂”,还要同时处理:

  • 当前这一轮输入属于哪一次 turn
  • 哪些历史音频、图像、工具结果应该继续保留在上下文里
  • 哪些中间态只是转写增量,不应该被误当成最终回答

换句话说,很多实时多模态问题并不是模型本身不行,而是:

  • session 状态边界没设计清楚

4.7 VAD、打断恢复和成本控制是同一个控制面

OpenAI 当前 Voice activity detectionManaging costs for Realtime 的资料说明了一个很实用的工程事实:

  • VAD 不只是体验问题
  • 它也会影响 turn 切分、空音频过滤和实时成本

如果团队只把 VAD 理解成“什么时候开始说话 / 什么时候停下来”,就很容易漏掉:

  • 空白音频是否被当成输入
  • 打断后上一轮生成如何收尾
  • 一次会话里无效 turn 是不是在持续烧钱

所以在实时语音和实时多模态系统里,VAD 参数、打断策略、补说策略和成本预算,最好一起设计而不是分散到不同团队。

4.8 客户端直连和服务端控制通常要同时存在

OpenAI 当前 Realtime API with WebRTCRealtime API with WebSocketRealtime API with SIPWebhooks and server-side controls 的资料给了一个很清楚的分界:

  • 浏览器 / 移动端直连 WebRTC 很适合承接低延迟音视频交互
  • WebSocket 更适合服务端媒体流水线
  • SIP 更适合电话和呼叫中心接入
  • 工具调用、业务规则和私有逻辑通常更适合留在应用服务端

这意味着很多实时多模态系统并不是:

  • 要么全前端
  • 要么全后端

而更像:

  • 媒体链路尽量低延迟直连
  • 业务控制、工具调用、审计和策略在服务端统一收口

5. 企业里最常见的九个多模态路线判断

5.1 图像理解、文档解析和图像生成是不是一回事

不是一回事。

OpenAI 当前 Images and visionImage generation 已经把“看图”和“出图 / 编辑图”拆成两条能力线。前者更偏识别、抽取、定位和问答;后者更偏风格、细节、一致性和编辑可控性。

5.2 语音转写、语音问答和语音助手是不是一回事

也不是一回事。

OpenAI 当前把 Speech to textRealtime transcriptionRealtime and audioVoice agentsRealtime translation 分开写,本身就说明:

  • 转写系统
  • 实时语音问答
  • 持续语音助手
  • 语音翻译

是不同的运行模型。

5.3 视频理解和视频生成是不是一回事

不是一回事。

Google Gemini 把 Video understanding 单列,OpenAI 把 Video generation with Sora 单列,本身就说明视频系统至少有两条完全不同的主线:

  • 看懂视频
  • 生成 / 编辑视频

5.4 多模态任务应该一次请求做完,还是拆成 mini pipeline

很多企业任务更适合拆。

例如发票系统、会议系统、视频复盘系统,往往都不是“单条 prompt 一把梭”,而是上传、解析、抽取、汇总、审校、落库的多步链路。

5.5 先上实时能力,还是先把离线能力做稳

更稳的路径通常是:

  1. 先把离线图片 / 文档 / 音频链路做稳。
  2. 再决定是否需要实时对话或连续媒体流。

因为实时系统对延迟、状态、打断、回放和异常恢复的要求明显更高。

5.6 PDF、Office 文档和表格是不是同一种文件输入

不是一回事。

OpenAI 当前 File inputs 的官方资料明确区分了几类处理路径:

  • PDF:在具备 vision 能力的模型上,会同时提取文本和页面图像
  • 非 PDF 文档 / 文本文件:主要提取文本
  • 表格文件:会走 spreadsheet-specific augmentation

这意味着“文件上传”背后其实至少有三套不同的解析心智:

  • 文档视觉理解
  • 纯文本抽取
  • 结构化表格增强

如果把它们全当成同一类输入,后面在字段抽取、引用、页码定位和评测时很容易混乱。

5.7 实时语音是不是一定要全程由服务端中转

也不是。

OpenAI 当前同时提供 WebRTCWebSocketSIP 连接方式,本身就在说明:

  • 浏览器 / 移动端实时交互
  • 服务端媒体流水线
  • 电话与呼叫中心接入

天然是不同接入层。

更合理的问题通常不是“选哪一种唯一正确”,而是:

  • 哪一段最需要低延迟
  • 哪一段必须放在私网或服务端
  • 哪一段最需要和既有语音平台、电话系统或内部网关集成

5.8 VAD 只是一个体验调参项吗

不是。

从 OpenAI 当前 Voice activity detectionRealtime conversationsManaging costs for Realtime 资料看,VAD 同时影响:

  • turn detection
  • 打断恢复
  • 空音频是否进入计费路径
  • 用户感知的响应速度

所以 VAD 更像“对话运行策略”的一部分,而不是单独的音频参数表。

5.9 实时会话是不是只能处理音频

不是。

OpenAI 当前 Realtime conversations 官方资料明确提到,gpt-realtime-2gpt-realtime 也支持 image input。

这对产品设计的启发很大,因为很多实时场景真正需要的是:

  • 一边说话
  • 一边看屏幕截图、相机画面、票据或现场照片

也就是说,语音助手和视觉助手在实时链路里并不一定要彻底分开。


6. 常见误区

  • 把多模态理解成“让模型能上传文件”。
  • 把视觉理解、文档解析、图像生成、视频生成混成一套能力讨论。
  • 把实时转写系统误当成语音助手系统。
  • 只测演示样例,不测真实图片质量、真实噪声和真实视频时长。
  • 只看模型效果,不看预处理、结构化输出、异步队列和运营成本。
  • 把 PDF、Office 文档和表格都当成一类“文件输入”处理。
  • 把 WebRTC / WebSocket / SIP 当成可随意互换的接入层。
  • 只做前端媒体链路,不提前设计服务端工具控制、审计和留存边界。
  • 把 VAD 只当成交互体验开关,不把它纳入成本和 turn 策略治理。

7. 多模态系统里最容易漏掉的控制对象

7.1 原始媒体对象

至少要区分:

  • 原始图片、录音、视频、文档文件
  • 它们的来源、上传人、租户、时间和权限

否则后面很难回答:

  • 这次结论到底基于哪份媒体
  • 哪些内容可以继续缓存或回放

7.2 会话与 turn 对象

实时系统尤其要区分:

  • session
  • turn
  • transcript delta
  • final transcript
  • model response
  • interruption / resume event

没有这些对象边界,打断恢复、回放和线上归因很容易混成一团。

7.3 派生结果对象

多模态系统里经常会不断产生:

  • OCR 文本
  • 结构化字段
  • 摘要
  • 标签
  • 时间轴片段
  • 审核结果

这些派生结果最好不要只作为临时字符串飘在日志里,而要当成可以追溯、可评测、可回滚的资产来治理。

7.4 成本与留存对象

很多团队只看模型调用花费,却漏掉了:

  • 媒体存储
  • 预处理作业
  • 转码
  • 异步渲染
  • 长期留存与审计副本

多模态系统的成本常常不是只有推理费,所以对象层面就应该把这些资产分开。


8. 建议搭配阅读


9. 重点官方资源

以下资源在 2026-07-08 核查可访问:


10. 什么时候该跳到其他目录

  • 当你开始做单一模态的视觉、语音、视频能力时,跳到 多模态与语音
  • 当你开始治理异步任务、缓存、队列、状态和结构化输出时,跳到 平台工程
  • 当你开始做持续会话、工具调用和实时代理时,跳到 AI Agents专题
  • 当你开始建设多模态指标、失败回放和线上评测门禁时,跳到 评测运营与案例
  • 当你开始处理录音、图片、视频和文件权限、安全审核与数据留存时,跳到 安全治理