语音交互三范式
语音为什么值得作为独立的交互形态？
- 速度: 正常说话的速度约为打字的四倍;
- 不占资源: 说话不占用双手与视线，适合把 Agent 放进持续工作、随时可能被打断的输入输出回路;
- 两个方向: 用户对 Agent 说话，与 Agent 代替用户对外部世界说话（如代打电话）;
- 分工: 语音模型决定“能回答什么”，交互架构决定“能否听清、及时回应、自然换手，并在通话中完成确认和工具调用”;
级联、端到端 Omni、全双工三者的取舍是什么？
| 范式 | 核心结构 | 主要优势 | 主要限制 |
|---|---|---|---|
| 级联（Cascading） | VAD → ASR → LLM → TTS | 模块清晰、易替换、易调试 | 延迟累积，副语言信息在接口处丢失 |
| 端到端 Omni | 原生音频输入输出，按轮次交互 | 延迟较低，能保留语气、情绪和环境声 | 仍依赖轮次，训练和调试成本较高 |
| 全双工 | 原生音频输入输出，持续听、说和决策 | 支持重叠说话、自然打断和连续流 | 模型训练、控制和评估都更复杂 |
- 三分法来源: OpenAI 在 GPT-Live 介绍中概括的语音系统三种交互范式;
- 性质: 三者不是简单的新旧替代，而是不同延迟、成本与可观测性约束下的取舍;
- 演进主线: 如何摆脱“轮流说话”和 VAD 对发言权的猜测——级联与 Omni 仍要划分轮次，只有全双工把“该谁说话”变成模型的持续决策;
级联流水线由哪些模块构成，瓶颈在哪？
| 模块 | 作用 | 典型瓶颈 |
|---|---|---|
| VAD | 判断用户是否说完 | 静音阈值带来等待和误切分 |
| ASR | 音频转文字 | 识别延迟与上下文丢失 |
| LLM | 理解、思考、生成 | 首 token 延迟，开启 reasoning 后等待更长 |
| TTS | 文字转语音 | 首包合成和播放缓冲 |
- 延迟性质: 简短、不开 reasoning 的回复中，四段等待串行累积，真实数值取决于输入长度、模型、硬件、网络与负载;
- 生产放大: 服务排队会进一步放大空载延迟，属于容量规划问题;
- 流式改造: 减少串行等待的具体做法见 流式语音感知;
- 商业现状: 绝大多数商业语音助手仍基于这条串行流水线，模块化让每个组件可独立优化;
端到端 Omni 与全双工在架构上差别有多大？
- Omni 的收益: 同一个模型直接听音频、生成回复并输出语音，能理解声音中的停顿，也能传递唱歌、特殊语调等副语言信息;
- Omni 的残留约束: 仍假设轮流说话，通常靠 VAD 划分发言权，用户报数字时的中途停顿仍可能被误判为说完;
- 全双工的先声: Kyutai 的 Moshi（2024）并行建模用户与模型的音频流，使重叠说话与打断成为模型的自然行为;
- 交互模型（Interaction Model）: Thinking Machines Lab 的提法——交互性内建在模型中，不靠 VAD 等外部 harness 拼装；微轮次机制以短音频块持续推进，静音、重叠与打断都作为连续上下文保留;
- 委派模式: 交互模型可把完整对话委派给后台推理模型，自己继续维持话头，后台结果返回后前台在合适时机接入;
- 生产规模: OpenAI 的 GPT-Live 让模型持续处理输入并生成输出，能等待用户、附和、被打断，也能处理实时翻译;