大模型通识 / 大模型技术演进
9. 2024：模型能看、能听，交互从文字走向多模态
原文备份 · 第 10 / 26 篇 · 查看极客时间原知识库 ↗
本篇目录 · 8 节
来源：大模型技术演进
2024 年 5 月 13 日，OpenAI 发布 GPT-4o。它展示新模型的方式，不只是让观众看一张考试成绩表，而是让人听它说话，看它围绕画面参与交流。数学辅导、实时翻译、调整说话节奏，出现在同一组发布演示中。这让一个日常问题变得格外具体：如果与 AI 交流不必一直打字，体验会发生什么变化？GPT-4o 发布与演示
仅隔一天，Google 在 I/O 大会上介绍 Project Astra，展示基于 Gemini 的助手原型。它尝试把持续进入的画面与语音组织成事件，并在对话中利用这些背景。手机和眼镜成为 Google 展望这种助手的载体。这里展示的是研究原型，还不是已经向所有用户开放的完整产品。Google I/O 2024 公告
两场相邻的发布，把竞争的一个新方向摆到了公众面前。此前，用户通常先把问题组织好，再输入一个聊天框；现在，厂商开始展示另一种关系：人可以一边做事，一边让助手参与，画面和声音也可以成为问题的一部分。
它的吸引力很容易理解。描述一个软件界面，可能需要解释按钮的位置、窗口的层次和报错文字；展示截图，就能保留这些背景。讨论一幅手绘草图时，人往往会指着某个地方说“这里”，而不是先把整张图翻译成一段文字。多模态让应用有机会接住这种表达。
不过，这一年的历史不能被压缩成“5 月以后，AI 就能像人一样看世界了”。模型展示了什么、产品允许用户做什么、开发者能够调用什么，沿着不同的节奏推进。理解这几条线，才能看清当时的突破有多大，以及它究竟改变了哪些应用。
在 2024 年之前，图像和语音已经进入聊天产品
多模态不是 2024 年突然出现的新概念。“模态”可以先理解为信息的形式：文字、图像、声音，以及包含时间变化的视频。多模态模型能够处理其中不止一种形式，但具体能接收什么、输出什么，需要分别看。
2023 年 9 月 25 日，OpenAI 已宣布向 ChatGPT Plus 和 Enterprise 用户逐步开放图像与语音功能。用户可以上传图片提问，也可以在手机上进行语音对话。当时的语音方案使用 Whisper 把声音转成文字，再由后续模型生成回答并合成语音。ChatGPT 2023 年图像与语音公告
这已经改变了一部分体验。用户不用手抄照片中的文字，也不必总在键盘上输入完整问题。但一个产品既能上传照片、又能播放语音，并不说明这些信息都由同一个模型直接处理，更不说明它能够持续理解摄像头画面。
2023 年 12 月 6 日，Google 发布 Gemini 1.0，把原生多模态作为核心技术方向：在预训练阶段就结合不同类型的数据。首发时不同型号和产品入口仍有各自的开放安排，不能把模型家族的整体能力当作每个用户当日都能使用的功能。Gemini 1.0 原始公告
到 2024 年 3 月 4 日，Claude 3 的发布也明确强调照片、图表和技术示意图处理能力；Opus 与 Sonnet 当日已在产品和 API 中提供，Haiku 则随后开放。这条路线说明，多模态的价值并不全部来自会说话的助手，它也在进入阅读材料、分析图表这样的工作。Claude 3 发布公告
所以，2024 年的变化包含两个相互促进的方向：视觉和音频理解进入更多主流模型；围绕这些能力，产品开始追求更连续、更自然的交互。
从“识别图片”，到“围绕图片理解问题”
计算机识别图像、把语音转成文字，都有比大模型更长的历史。大模型带来的变化之一，是让识别结果可以与问题、背景和语言表达一起参与任务。
看一张折线图时，提取标题和坐标轴上的文字，只完成了工作的一部分。用户可能真正想问：“这两条线为什么会得出不同结论？”回答需要把图例、曲线、刻度和旁边的说明联系起来。只有文字清单，往往不足以保留这些关系。
OCR，即光学字符识别，主要帮助从图像中读取文字；视觉语言模型则尝试结合图像内容和语言要求完成任务。二者可以配合，不能仅凭产品能回答图片问题，就认定它内部一定使用或者一定没有使用 OCR。
一种常见的技术思路，是先把图像转换为模型能够使用的数值表示，再与语言模型连接，并训练它按照文字指令处理视觉信息。2023 年的 LLaVA 研究就是这一方向的代表：它连接视觉编码器与语言模型，并使用视觉指令数据训练。这是一个帮助理解机制的例子，不代表所有多模态模型都采用相同结构。Visual Instruction Tuning 论文
你不必现在学习网络结构，只需抓住两点。第一，模型不是在电脑里长出了一双人眼，而是在学习图像特征、语言和任务之间的关系。第二，一张图片进入输入，不代表每一个细节都被正确保留下来。缩放、裁剪、清晰度和模型能力，都可能影响最后的判断。
这与上一篇的长上下文问题相通。长窗口扩大了材料范围，多模态扩大了材料种类；两者都不能直接保证理解正确。
GPT-4o 的语音，改变的不只是输入按钮
可以把传统语音助手的一种常见链路画成这样：
用户说话 → 语音识别成文字 → 语言模型生成文字 → 语音合成 → 播放
这种分工有实际价值：中间文字便于保存和检查，各个组件也可以单独替换。但它会带来额外环节。如果语言模型只得到转写文本，某句话的重音、停顿和背景声音就可能没有进入它的判断。
比如，同样是“这个办法真不错”，语气可能表示赞同，也可能表示反讽。把它们都转写成相同的文字，信息就已经有所损失。这是说明信息差别的例子，不意味着任何新模型都能准确判断人的真实情绪。
GPT-4o 的技术说明强调，文本、视觉与音频在同一个模型中进行端到端训练。它提供了一条直接处理音频并生成语音的路线。官方报告的平均音频响应时间约为 320 毫秒；这是厂商报告的指标，不能当作任何网络、设备和请求下的实际等待保证。GPT-4o 系统卡
更短的响应间隔之所以重要，是因为交流方式会随等待时间改变。等一份文档摘要时，多等几秒未必打断工作；正在练习口语时，每句话后面都停顿很久，双方就很难保持对话节奏。
自然交流还要求系统能处理打断。假设助手正在解释第一种解法，用户插话说想看另一种。好用的系统需要停止过时的输出，接住新要求，再继续回答。如果它只把整段录音识别得很准，却坚持播放完原先的长答案，用户依然会觉得自己在操作一个播放器。
因此，“实时”在这里主要描述持续输入、较低延迟和及时反馈的交互方式。它不意味着零延迟，也不意味着模型知道互联网上刚发生的新闻。后者仍然需要搜索或其他最新信息来源。
发布会上的体验，怎样分批走到用户手里
GPT-4o 在 2024 年 5 月首发时，公开提供的是文本和图像输入、文本输出；开发者当时也主要把它作为文本与视觉模型接入。新的语音能力另行推进，并非所有演示功能同时上线。GPT-4o 当时的开放说明
与此同时，OpenAI 开始把 GPT-4o 及相关工具逐步带给免费用户，并保留使用额度限制。这个变化降低了体验门槛：讨论照片、上传资料，不再只面向原来的付费人群。免费产品额度与开发者 API 计费仍然是两回事。2024 年免费用户开放公告
Google 的路线也需要分开看。2024 年 8 月 13 日，Gemini Live 开始向 Android 手机上的 Gemini Advanced 订阅用户推出，首批为英语语音体验，支持打断和暂停后继续。这是一个真实的产品开放节点，却不能把 5 月 Astra 原型展示的全部视觉能力一并算进来。Gemini Live 首发公告
到 12 月 12 日，ChatGPT 的更新记录才写明：高级语音中的实时视频、屏幕共享和图像上传开始在手机端分批推出，当时仍有套餐、地区和用量限制。ChatGPT 2024 年 12 月更新记录
这些时间差不是无关紧要的脚注。它们决定了一个开发者在当时究竟能做什么，也解释了为什么有人看完发布会后，打开应用却找不到同样的入口。发布展示让人看见方向，产品开放才把方向变成可使用的体验。
Gemini、Qwen 等路线，让多模态不只是一场语音演示
上一篇介绍 Gemini 1.5 时，重点是它能够容纳更多材料。到了多模态任务，长上下文还有另一种意义：材料可以是一段包含图像、声音和时间顺序的视频。
Google 在 2024 年 5 月的开发者更新中，回顾了此前加入的原生音频理解，并推出强调速度和效率的 Gemini 1.5 Flash，面向响应时间更重要的任务；当时 1.5 Pro 与 Flash 仍以预览形式提供。Gemini 开发者更新
这对应着不同的应用需要。离线分析一段课程录像，可以先上传材料，再等待整理结果；在对话中解释用户眼前的东西，则需要更快接收变化和回应。两者都涉及视频，却不是同一种产品任务，不能用“支持视频”四个字概括它们的体验。
中国开发者也获得了可下载、可改造的视觉模型选择。2024 年 8 月 29 日，Qwen 团队发布 Qwen2-VL，公布图像、多图与视频理解能力，并以 Apache 2.0 许可开放 2B 和 7B 模型，当时为 72B 提供 API。这里记录首发安排，不将后来的开放状态倒推回来。Qwen2-VL 官方公告
它把第 7 篇的开放模型生态延伸到了视觉任务。开发者可以研究图片问答、文档理解或视频处理怎样进入自己的系统，而不只是使用一个现成聊天界面。不过，视觉模型权重并不包含完整的手机助手：采集图像、组织输入、保存材料和展示结果，仍然需要应用完成。
这也提醒我们，“多模态”是一组能力，不是一张全能通行证。一个模型能理解图片，不代表它能生成图片；能分析视频，不代表能生成电影；能进行语音对话，也不代表能操作电脑。后面的创作工具与任务型 Agent 篇，会分别讨论这些能力怎样进一步组合。
当实时语音成为 API，新的开发问题出现了
2024 年 10 月 1 日，OpenAI 面向付费开发者推出 Realtime API 公测。它提供持续连接、音频流输入输出和打断处理，并支持函数调用。首期重点是语音，视觉和视频仍列在后续计划中。Realtime API 原始公告
这个节点的重要性，在于开发者可以围绕自己的任务构建语音体验。例如，一个学习助手可以在对话中查找已保存的笔记，再讲解某个概念。语音负责交流，函数调用负责连接应用中的能力，资料检索负责提供背景；前面几篇讨论的路线在这里相遇。
但调用模型只是整条链路的一部分。麦克风是否收到了清晰声音、扬声器的声音是否被再次录入、网络中断后怎样恢复，都会影响体验。首发公告提及与 LiveKit、Agora、Twilio 等生态伙伴合作，覆盖音频组件与电话接入。这说明实时 AI 应用开始与既有通信技术结合。当时的生态接入说明
对开发者来说，一个新的设计单位出现了：持续一段时间的会话。 文字应用往往围绕一次提交和一次回答组织；实时应用还要管理用户何时开始说、何时暂时停顿，以及什么时刻应该中止原来的回答。
例如，助手提出“我可以把这条记到复习计划里”，用户随即说“先别保存，我还没想好”。这个过程需要应用区分提议与确认，再决定是否执行保存。声音更自然，并没有消除第 4 篇中模型判断与程序执行之间的分工。
成本也变得直观。Realtime API 首发公告把音频价格近似换算为：输入每分钟 0.06 美元，输出每分钟 0.24 美元。这是当时的音频计费量级，不是今天的报价，也不是每分钟通话的固定总价。首发价格说明
按这个历史近似值做一道简化算术题：若一次交流包含五分钟计费音频输入和五分钟音频输出，两项合计约为 1.50 美元。这个示例不包括文字、历史上下文重处理或其他服务费用，也不等于实际账单。它说明，低延迟体验与低成本服务需要分别评估。
对于只需要整理一段录音的任务，实时对话未必是必要选择。先转写、再归纳，可能更便于检查和保存；需要口语练习、即时追问时，连续交互才更有价值。模型能力扩大了选择范围，开发者仍要根据任务决定投入在哪里。
一个个人项目，会因此多出什么可能性
继续使用前几篇的个人复习助手。下面是用于理解设计的假设项目，不是对某款产品的实测。
过去，它主要接收文字笔记。现在，你可以拍下一张手绘的请求流程图，再口述：“我不明白，为什么这一步要等服务器返回？”问题里的“这一步”，可以通过圈选或明确指向图上的某个区域来补足。
这时，图像贡献的是结构，语音贡献的是问题，历史笔记提供的是你的学习背景。把三者组合起来，助手才有机会给出符合当前疑问的解释，而不是泛泛讲一遍网络通信。
一个合理的交互，可以先让助手确认它读到了什么：图上有哪些节点，箭头指向哪里，哪一处字迹看不清。用户纠正后，再进入概念解释。这样做的价值是把“看错图”和“理解错概念”分开，避免它在错误的观察上继续推理。
如果助手把一条反向箭头识别错了，后面的解释即使语言流畅，也可能全错。修复方法可能只是重拍、裁出局部，或者让用户补一句文字；不一定需要换一个更复杂的 Agent 框架。
保存学习记录时，也可以同时保留原图、用户修正和文字总结。以后通过 RAG 找到这条记录，助手才能回到原始依据。多模态输入并没有让知识库和长上下文失去价值，而是让它们需要管理更多类型的信息。
同样的设计思路可以迁移到其他个人项目：围绕截图解释软件操作、结合照片整理收藏、根据录音复盘一次练习。共同变化是，用户不必先独自完成全部信息转换，才能向 AI 求助。
更像自然交流，也更需要看清证据在哪里
多模态应用的错误，未必表现为完全离题。它可能正确识别了图表主题，却读错一个刻度；听懂了大部分句子，却漏掉一个“不”；看到了视频前后两个画面，却把先后关系解释反了。
因此，可以用三个问题判断一个回答：原始输入里是否真的有这条信息？模型是否读对了？结论是否超出了输入能够支持的范围？这与上一篇区分“装得下、找得到、推理得对”是一致的。
尤其是涉及连续画面时，要区分展示给用户的完整视频与系统实际处理的内容。应用可能选取部分帧、降低分辨率或分段处理；具体方式取决于模型和实现。不能因为界面显示“已上传”，就默认每一个瞬间都被同样细致地分析。
声音还会改变用户对回答的感受。一句自然、肯定、富有情绪的解释，容易让人忽视它是否有依据。GPT-4o 的系统卡专门讨论了拟人化与信任问题，指出高度拟真的声音可能加深用户对模型的误判。系统卡中的交互影响讨论
在复习助手里，可以把这种认识变成很具体的设计：说话时同步显示关键文字，解释图表时标出所依据的区域，不清楚时允许重拍和纠正。用户需要的不只是听起来顺畅，还包括能够追问“你是根据哪里得出这个结论的”。
麦克风和摄像头也让输入范围更直观。应用应让用户知道何时正在采集、怎样停止，以及哪些内容会被保存。它们是这一类交互本身需要的控制，与更换一个模型名称无关。
2024 年的意义就在这些变化的交汇处：模型能处理的信息形式增加，交流节奏开始接近连续对话，能力又通过产品、API 和开放模型进入更多开发者手中。用户与 AI 之间，开始出现比“输入一句话，返回一段文字”更丰富的关系。
接下来，我们把视线转向一个同样受到这种变化影响的场景：写代码。程序员面对的背景不仅是当前光标附近的几行文字，还有整个项目、报错与运行结果。下一篇将回到 2023—2024 年，看看 GitHub Copilot、Cursor、Windsurf 等工具怎样从代码补全走向更深入的项目协作。
本文属于第 0 部分“大模型发展史”；全系列观察截止日期为 2026 年 10 月 3 日。文中按历史阶段描述能力与开放范围，发布演示不等于作者实测。复习助手与成本算例为教学构造，不是产品测试或当前采购报价。
下一篇：10｜2023—2024：从补全代码到理解项目，AI 编辑器改变编程方式
返回：第 0 部分大纲