好的,我们开始吧。如今我们要构建的大多数智能体都在后台工作,对吧?它们为我们编写代码、进行研究。你给它们一个任务,然后走开,回来时工作已完成。因此,没人会在意后台智能体多花10秒甚至10分钟,我们对此早已习以为常。但在过去的一年中的某个时刻,你可能接触过另一种智能体——实时智能体。
也许是药房续药,或者是航空公司的服务。前几天我打电话给一家汽车经销商时就和一个打过交道。在那通电话中发生了一些事情,你可能做了最像人的举动:你打断了那个AI。结果语音智能体崩溃了,感觉一点也不自然,不是吗?
如果你询问行业内的任何人如何修复这个问题,你可能会得到非常相似的答案:速度。更快的模型、更低的延迟,再削减100毫秒。但这是错误的答案。延迟确实是一个预算指标,我会告诉你具体的预算是多少。但这并非最终目标,真正的目标是让语音AI尽可能拟人化。
我们需要的是那种在说话时也能倾听的智能体,是那种能分辨出你是说完了一句话还是在思考中的智能体,也是那种当你改变主意时能顺势而为的智能体。仅靠速度无法实现这些目标。要实现这一点,关键在于你选择哪些模型以及如何配置你的管道流程。这是我们遇到的第一个问题:没人告诉你如何选择合适的模型。
排行榜帮不了你,供应商也肯定帮不上忙。那么,让我们谈谈如何解决这个问题。首先快速举手示意一下,在座有多少人曾经构建过语音智能体并将其部署给真实用户?好的。看来有些人有经验,知道部署实时智能体会面临哪些挑战。
再举一次手,在座有多少人使用过ChatGPT的高级语音模式与它交谈?是的,我们很多人都用过。OpenAI实际上选择了LiveKit来为这一功能提供动力。LiveKit是一个开源的实时框架和基础设施,旨在构建最拟人化的语音智能体。
这些智能体能够听、看并与另一端的人交谈,不仅限于语音,还包括视频、数据甚至物理AI。但由于语音具有挑战性,我们将重点讨论这一部分。我们要看的是语音智能体,它们基本上由三个协同工作的模型组成:一个是语音转文本(STT),一个是大型语言模型(LLM),另一个是文本转语音(TTS)。
这三个部分构成了系统的核心。不过我必须承认,实时模型也是存在的。这是一个较新的概念,虽然它们越来越好,但并不适合所有用例。仅仅存在实时模型这一事实就增加了我们确定语音管道最佳模型的复杂性。
现在,你有数百种模型、数十家供应商可供选择。再举一次手,有多少人仅仅因为看到某个模型在排行榜上名列前茅就选择了它?是的,大多数人都是这样做的。但这就是为什么这对实时智能体行不通的原因:排行榜评估的是单个组件,而你交付的是一个级联的管道流程。
假设你的来电者想预约3号星期二的时间,但语音转文本模型听成了30号。从那一刻起,无论你的语言模型有多智能都没用了,它会自信地预约错误的日期,并且错误会像瀑布一样向下传递。
底层的模型对此一无所知。排行榜上的分数来自安静房间里的纯净音频,但你的来电者可能是在免提通话、在交通中或后排有孩子的情况下打来的。这些排行榜从未见过你的用户,这种现象被称为“排行榜陷阱”。
分数衡量的是模型本身,但你交付的是一段对话。每个构建语音智能体的人都在问:最好的STT、LLM或TTS模型是什么?但真正的问题是:“我应该部署哪个技术栈?”这是两个完全不同的问题,而直到今天,只有前者有排行榜。我们稍后会详细讨论这一点。
假设你陷入了这个陷阱,根据排行榜选择了模型,然后开始测量指标。这是下一个问题:你可能在衡量错误的东西。你的TTS提供商报告的是首字节时间,这在仪表盘上看起来很好,但“字节”不等于声音。
我们测量过一些流行的提供商,它们在音频开头实际上发送了数百毫秒的静音。在最坏的情况下,在第一个音频到来之前,会有长达四分之三秒的纯静音。因此,“首音频时间”才是你的来电者实际听到的内容。
这是整个演讲的核心区别:测量的延迟与感知的延迟。仪表盘显示的内容与你用户听到的内容之间的差异。仪表盘说速度很快,但你的耳朵觉得慢。语言模型也是如此:首令牌时间是文本指标。
TTS不能仅凭一个令牌就开始说话,它需要整个句子。因此,这个数字对语音很重要,因为它需要完整的第一个句子,但模型在该指标上的排名却不同。流式传输令牌最快的模型不一定是首先完成句子的模型。
假设你完美地测量了所有这些,对话中还有另一个部分被基准测试完全忽略了:真实的智能体不仅仅是聊天。它需要执行操作,比如查询订单、检查可用性、预订房间等。工具调用会花费时间:2秒、10秒或40秒甚至更久。
没有任何模型选择能够掩盖超过40秒的延迟。想想人类接待员会怎么做:当预订系统加载时,他们不会僵住不动。他们会说:“稍等,我正在查询您的账户。”他们争取时间,并在继续工作的同时倾听。
这就是我们要寻找的拟人化行为。为什么智能体不能一边说话一边异步执行操作呢?它可以做到,这就是其形态,这也是你唯一会看到的代码。这是一个普通的工具调用,但只有一点不同:就是这一行代码。
它将麦克风交还给代理,同时让它在后台继续工作。这就是诀窍所在:对话和工具不再共享同一个线程。别只听我说,请亲自听听看。“感谢您致电橡树酒店,请问有什么可以帮您?”“我想预订一间客房。”“当然。您想订哪几天的房呢?”“10月10日至12日。”
“10月10日到12日?入住几位客人?”“两位。”“我们有双床大床房、特大号双人床房、标准间或套房。您更倾向于哪种?城景还是海景?”“海景。”“请问预订人姓名是?”“杰西·霍尔。”
“您的预订已确认,10月10日至12日入住海景特大号床房,总价582.40美元,将扣款尾号为1111的信用卡。请问确认下单吗?”“其实你知道吗?我需要把日期改为12月20日至24日。”
“12月20日到24日?这将使总价变为1,164.80美元。请问确认下单吗?”“是的。”“预订已生效。”
好的,由于时间关系我们加速了部分片段,但代理始终保持对话流畅。没有尴尬的停顿,通话者甚至中途插话,它依然继续回应。而且通话者在过程中改变了主意,代理也顺势调整了,对吧?这就是我们要寻找的拟人化行为。所以这再次证明并非某个模型表现良好,而是整个系统表现出色。
这是基础设施、框架和模型的协同工作,而没有任何单一组件或模型基准测试能体现这一点。此外,排行榜完全忽略了一个重要维度:知道何时该说话以及何时不该说话。人类主要通过语调在几百毫秒内协商发言权,而等待整个转录文本返回的流水线已经太迟了。
因此我们构建了一个基于音频本身的发言检测器,它监听语音的韵律、音调和语调。我们也公开了相关数据:在相同的延迟预算下,最佳替代方案会在9.9%的情况下打断用户,而我们的系统仅为4.5%,且评估工具是开源的。
您不必相信我,您可以用自己的数据运行测试并查看结果。让我们再深入一点:通话者最后一个音节与代理第一个可听声音之间的间隙。发言检测在转录文本到达前由音频触发,语言模型已在临时转录本上运行;如果最终词语匹配,则节省了半秒。
然后文本转语音(TTS)在第一个完整句子开始时启动,而不是最后一个词元。因此,人类停止等待的那一刻就是听到第一句可听声音的时候。您选择的每个模型都会体现在这个窗口中,而该窗口大小是固定的。
如果在端到端延迟上能保持在1.5秒以内,对话仍能维持,但已处于边缘。如果能接近600毫秒,感觉就会非常拟人化。所以问题从来不是“我能跑多快”,而是“我能在该窗口内放入多么拟人化的代理”。
回到延迟作为预算,但目标是拟人化。因此我们最初提出的问题“我该选哪些模型?”实际上是无法回答的。所以我们构建了那个我们希望存在的东西。以下是我们构建基准测试的方法:
我们要使用一个完整工作的代理,第一个就是您刚才听到的酒店前台。它处理真实预订,拥有真实的后端支持,并且是开源的,您可以查看代码库。我们让数百个模拟呼叫者与其交互。模拟器会插话、含糊不清或改变主意,就像真实通话者一样。
我们不凭感觉打分,而是根据我们为人类定义的方式评估结果:正确的预订是否落入数据库?通话者是否被打断?姓名和日期是否正确?是否有虚构的工具调用或泄露的个人数据?我们衡量所有这些方面是否符合人类等效行为。
这就是标准。仅看完成率是不够的,因为完成度是可以被操纵的:模型可以猜出完成路径。因此我们惩罚那些完成率无法看到的缺陷,比如问了不必要的问题,或做只需两步的事却走了十步。
然后我们替换技术栈:相同的代理、相同的情景,但使用不同的模型。每个模型看到的输入字节完全一致。但这创建的是针对我们代理示例的基准测试,有多少个代理就有多少种基准测试。
因此这个基准属于您:您可以使用完全相同的流程,让您的代理通过此基准测试并获得分数。这就是发现意外情况的方法:整个体系、方法论、评估集以及代理本身都是开源的。您可以将其指向您的代理,并让我们知道其表现如何。
关于LiveKit有一个重要事实:我们不制造语音识别(STT)、大语言模型(LLM)或文本转语音(TTS)模型。每个提供商都接入我们的技术栈,因此我们在这一竞赛中没有利益冲突(无马骑)。我们只是观察它们大量运行。
因此我们可以自信地选出赢家。您现在看到的是Gemini 4 31B模型在LiveKit推理上的预览,但这并非现成的Gemma 4 31B。它是专门为生产环境语音代理调优的,支持长提示、多工具和严格的延迟预算。它在语音评估中通过率达88%,并在约380毫秒内开始说话,比下一个模型快两倍以上。
这使其成为目前实际最快的高质量语音大语言模型。它将于明天在LiveKit推理中上线。我们的目标是在遵守延迟预算的前提下,实现最拟人化的代理。如果您只记住演讲中的一件事:语音代理不是堆叠了扬声器的聊天机器人,而是拟人化的基础设施。
它是一个实时系统,像人类一样感知和响应。一旦您这样看待它,每个决策都会变得清晰:预算、指标、模型以及测试标准。这里有一份清单,您可以拍照保存:首先设定延迟预算;其次测量感知延迟;将剩余的预算用于模型质量,而非无意义的速度。
任何超过一秒的操作都应异步进行,以确保对话永不中断;然后测试整个对话而非单个组件;最后要在生产环境中持续测试。这里是基准测试,请扫描二维码查看并针对您自己的代理运行它。请记住在某个……
在不久的将来,你将能够呼叫语音助手并进行对话,而它不会因此崩溃。它会像人类一样在该场景中自然应对。所以去构建这样的系统吧,谢谢。