我们对用于语音智能体的 GPT-Live-1 API 的初步印象
两天前，OpenAI 将其全新的全双工语音模型 GPT-Live-1 发布到 API。我们在生产环境中构建和运营 AI 电话智能体，因此为它接入了一个真实电话号码，然后给它打了电话。很多次。
我们使用一位保险客户提供的约 13,000 个词元的温热线索资格审核脚本对它进行了测试，其中包含必须逐字朗读的台词、严格的复述规则以及分支追问。在漫长的一天里，我们进行了十几通真实电话、约 25 次模拟访谈，以及一批非结构化测试。
以下是我们的第一印象，附有文字记录和音频。更深入的分析文章很快会发布。
文字记录来自我们的测试通话，由 GPT-Live 转写。我们修改了姓名和可识别身份的措辞，删减了部分对话，并合并了被拆分的片段。时间戳以通话开始后的秒数计，均来自原始记录。
自然度非同寻常
GPT-Live-1 是我们接入电话线路的语音智能体中，对话听起来最自然的一款。它确实向前迈出了一大步。
它在同一条连续音频流中同时聆听和说话，无需分开的转写与语音合成阶段。大多数对话机制都能正常运作。来电者停止说话后，中位数约 1.3 秒就能听到它的第一段音频；不计电话链路时约为 0.7 秒。我们没有添加语音活动检测或轮次交接逻辑。它能自然地处理打断，发出自然的应答声（“嗯哼”），并以明快、近似真人的节奏说话。
当我们提供目标而非要照读的台词时，它会根据对话调整问题，也能从容接受纠正：
无论是纠正、打断，还是来电者在通话中途改变答案，它都从未失去从容。如果自然度就是全部工作，这篇文章到这里就该结束了。遗憾的是，事情并不止于此。
它无法可靠地遵循指令
对于脚本化电话中至关重要的行为，GPT-Live-1 无法可靠地遵循指令。
不止一次，它把明确的“是”当成“否”来回应，重新询问问题，或像来电者已经拒绝那样继续往下推进。
最稳定的失败模式是过于字面地执行指令。我们的提示词写道：如果来电者表示档案中的住房状态不正确，就询问他们是自有住房、租房，还是与父母同住。一位来电者说“不是，我现在自有住房”，这其实已经回答了问题。模型却还是把选项逐一念了出来：
早期出现的一些怪异表现是我们的提示词造成的，但这种字面化倾向在我们尝试过的每个提示词版本中都存在。任何我们没有明确写出的回答，它都会机械处理，而不是做出合理判断。
它有时还会在压力下把思考过程说出来：
数字和字母数字组合存在风险
拼写、地址、出生日期和身份证件号码都必须准确无误。GPT-Live-1 的语音在这些方面问题最多。
我们听到它在字母数字字符串中漏读和替换字符。下面它读取了一个虚构的理赔编号；除了裁剪静音部分外，音频片段未经任何处理。在英语中，它的转录文本是正确的，但音频多读了一个“Y”：
俄语中的情况更糟：“Q”在音频和转录文本中都变成了“X”。
日期也出现了同样的问题。来电者用数字报出了出生日期，模型后来却将其读成了一个数值：
它偶尔还会说出本应属于来电者的一句台词：
其他语言中的口音
我们会在产品支持的 47 种语言中测试新的语音模型。GPT-Live-1 的俄语很流利，但带着浓重的美式口音（而我们在生产环境中运行的 TTS 语音通常听起来像母语者）：
我们还测试了卢干达语。第一次通话时，它回答成了斯瓦希里语。第二次，它说的是卢干达语，其自然程度超出了我们对通用模型的预期，但同样带着浓重的美式口音。我们尚未测试每一种语言，但预计这种口音模式很可能具有普遍性。对于仅支持英语的智能体，这并不重要；但对于其他语言的使用场景而言，这是一个相当重要的限制。
值得了解的一些 API 限制
根据我们本周的发现，以下几项 API 限制会影响真实智能体的使用：
- 会话开始后，指令不可更改，且上限为 16,384 个 token。
- 输出音频的流式传输永远不会停止——静音也会被流式传输——因此，对于需要分割轮次的使用场景，不能将“音频停止”作为轮次结束信号。
- 它只能通过新的
v1/live/sessions端点访问；我们检查时，Azure 上尚未提供该功能。
目前的看法
生产环境中的电话智能体必须听起来自然，并且能够始终如一地遵循脚本。GPT-Live-1 在前者方面非常出色，但在后者方面存在一些严重问题。随着时间推移，我们会进行更多测试，并持续分享我们的发现。