Enivia OpenAI 昨天发布了 GPT-Live 的响应式 AI 语音系统构建文章。
GPT-Live 之所以如此好用，是因为 OpenAI 从客户端到模型，重建了语音堆栈结构，新架构能保持音频持续流动。
从「回合制」到「无限流动」
对于 Voice AI 来说，知道何时开口说话比听懂更难。
我们人类进行对话时，可以在不到 1 秒的时间内毫不费力地进行听说切换，但语音 AI 系统却很难跟上这种节奏。
早期的语音架构继承了 LLM（大语言模型）「回合制」的特性，每段对话都以离散的音频 blob 格式表示，而非文本。所以过去 AI 系统处理对话时，语音到文本、LLM 和文本到语音各自串行运行，大大增加了延迟，并且会导致忽略语气、节奏等关键信息。
再后来，speec-to-speech（语音转语音）模型通过直接处理音频改进了这种方法，通过对模型进行训练使其能够直接理解和生成语音，从而保留转录过程中可能丢失的细节，并更快做出反应，但系统仍依赖「回合检测」机制。
GPT-Live 这次彻底移除「回合」机制，让语音模型直接控制对话。音频会在模型中不断流入、流出，而更深层次的推理和工具调用则以异步方式进行。
使用更快的协议启动会话
与大语言模型不同的是，在我们点击会话按钮的那一刻，语音模型的响应就开始了。所以 GPT-Live 必须在对话开始前建立媒体通路，并开始通过模型传输音频。
实时语音模型通常会使用 WebRTC（网页即时通信）协议，它是一个支持浏览器和移动应用进行点对点（P2P）实时音视频及数据传输的开源技术标准。但是，启动一个普通的 WebRTC 会话需要惊人数量的协议握手和网络交互。
所以，OpenAI 基于 WebRTC 开发了简化的往返协议（WARP），它将媒体和数据的启动从 6 次网络交互减少到 1 次。OpenAI 将这个协议设计为一组开放规范，并与 WebRTC 的社区合作者合作，共同维护。
真实使用场景的变化
过去使用语音 AI 时，我经常会临时补充信息，或者在听到一半时改变问题。传统语音系统通常很难自然地处理这种情况，因为机制决定它必须等到一轮对话结束。
在 GPT-Live 的交互模式下，我可以在它回答时直接插话，它会听到新的内容，并根据当前对话调整回应。我的停顿、说话速度和语气，也可以成为模型理解语境的一部分。
另外，当我询问天气、搜索资料或要求 AI 执行某项任务时，在过去，这类操作可能会让对话暂停，等待系统完成处理。
GPT-Live 将语音交互和复杂任务分成了不同的处理路径后，语音可以持续传输，搜索、工具调用和复杂推理则在后台运行，不至于让整段通话陷入沉默。
现在就去用 ChatGPT 聊聊吧。
