BonsonAI李沐：语音智能体很难，但机会才刚刚开始｜Vital Views

绿洲资本被投企业 BonsonAI 的创始人李沐博士， 在硅谷 101 举办的年度科技大会中，针对语音智能体*（Voice Agent）*落地应用，进行了一次精彩的演讲。

通过回顾两个实际的项目：如何在开放世界游戏中，让智能体同时扮演 "游戏设计师 + 游戏 NPC" 的双重角色，为玩家带来独一无二的体验；又是如何通过严苛的行业认证，让 AI 成为能卖出保险的智能电话销售员，深入剖析了语音智能体从技术挑战，到商业落地的关键经验和最佳实践。

以下是李沐博士的演讲内容，Enjoy

是的，今天我想谈谈语音智能体。

这是今年非常热门的话题，原因在于大家认为， 这项技术现在已经可以投入使用，已经到了 "落地" 的阶段。

所以今天我会分享两个我们过去基于语音智能体的项目，讲讲我们从中获得的一些经验和最佳实践，看看如何帮助客户真正用起来。

首先，什么是语音智能体？基本上，它就是一个 "带声音的智能体"，用户通过语音界面与智能体交互。我们希望这样能让人与大型语言模型之间的互动更加自然。

这里有两点：

第一是实时性， 这和视频生成不太一样。视频可以离线处理，但语音必须是实时的。响应时间必须在一秒以内，也就是所谓 "端到端延迟" 必须低于一秒。

第二点是，大多数情况下，人们不是在闲聊，闲聊型智能体 （比如陪伴机器人） 只是少数。**更多情况下，语音智能体是任务导向的。**比如做客服、做信息检索，或者销售产品。即便是"陪伴"，它也是一种任务，不只是随意聊天。它背后总有具体目标，比如讲一个故事、完成某件事。

这就是语音智能体的基本概念。在接下来的演讲中，我会通过两个例子，展示我们是如何构建它的、以及从中学到的经验。

这是第一个例子："我真的得赶紧找到离开这里的办法。" "好吧，看起来你直奔主题了。 不过， 至少能先多告诉我一点你自己的情况吗？ 比如……" "好，让我们看看（你的介绍）。" "好的。 我是玛丽安娜大学的大二学生，主修天体物理。"

这是我们大约两年半前开始制作的一款游戏。这是一个应用程序，这就是用户界面。游戏中的角色名叫Stella，玩家通过语音与她互动，帮助她完成任务。

可以说，整个故事情节都是由玩家的语音输入推动的。

这是一款开放世界游戏，上面那句话就是从游戏中截取的台词，这款游戏在两个月前上线。

大致的剧情是，Stella 坠落在一颗外星球上，飞船在这里坠毁，于是她请求玩家帮助她。"这个世界太奇怪了，这里有这么多的选项，我能体验到这么多的情绪。" 她会通过语音与玩家对话，让玩家帮助她逃生。整个游戏的世界观设定非常庞大，而这款只是整个系列中的第一部实验性作品。

那么，语音智能体在这里扮演什么角色呢？

它既是游戏设计师，也是演员。作为 "设计师"，它需要设计出逻辑合理、好玩的剧情。作为 "演员"，它要创作出符合人物设定的台词。

Stella 这个角色有完整的背景故事和性格资料，大约有二十页的设定文档。智能体必须根据这些设定来表演。

而从游戏设计的角度，当玩家与游戏互动时，剧情需要被引导。如果故事只是单线推进，那就不是 "智能体"，而只是普通的脚本。你要让剧情具备复杂的分支结构、图像结构，让玩家可以自由探索。

问题在于，你必须让游戏 "真的好玩"。就像写小说、写剧本一样，必须遵循叙事节奏、铺垫、高潮等原则，让故事有张力、有趣。

此外，玩家在开放世界中会不断试探边界，会 "调戏" AI。智能体必须始终保持在角色设定之内。例如，这个游戏是科幻题材，时间设定在两千年后，而你的对话是随机的。如果玩家问："你最近看了什么电影？" 模型不能回答如今的当代片，否则就成了 "一千年前的电影"。

但问题是，大多数语言模型的训练数据都是当下世界的内容。那么问题来了：你该如何把这些 "未来世界" 的设定迁移到模型里？

我分享一个早期的对话日志*（那时还是中文版本）*，展示一下挑战。场景是： Stella 找到一些食物，问玩家："我该吃哪一个？" 玩家回答："我帮你看看，我觉得你不能吃任何东西。"

于是 Stella 说："你需要找到肉吃。" 接着玩家去搜索怎么捕猎，但游戏设定是：你还没见到任何动物。于是 Stella 回答："我很想吃肉，但这里只有蔬菜。"玩家仍然拒绝帮忙。Stella 恳求："我真的需要你的帮助。"玩家仍然说 "不帮"。

那剧情就卡死了，故事无法推进。所以我们加了一个规则：**如果玩家三次拒绝，就强制剧情推进，让系统自动选择一个选项。**结果 Stella会 "饿死"。她说："我快死了。" 玩家回应："那就死吧。" 这显然不是一个 "好玩家"， 但模型必须保持礼貌、符合人设。

挑战在于：这是一个开放世界的游戏，但你的回答要符合逻辑。 设定发生在一两千年后，很多细节并未在剧本中定义。游戏设计师不可能为每种情况都写脚本。

模型必须自己"想"，什么在未来世界是合理的，同时又要让互动有趣。这才是游戏，不是聊天机器人。这些就是我们面对的核心挑战。

我们是这样做的：这个项目两年前启动，当时有 GPT-4，但成本非常高。我们做了计算，如果使用 GPT-4， 会带来巨额亏损。

当时最好的开源模型是 Llama 2，但性能还不够强。于是我们自己预训练了一个 300 亿参数的模型，用了大约 5 万亿 tokens。这些训练数据主要来自小说与角色扮演游戏文本。

结果在通用任务上大致与 Llama 2 相当，但在角色扮演上表现更好。我们的经验是，预训练要花几个月时间，即使稍微超越 Llama 2，也很快被 Llama-2-70b 反超。

因此，如果在预训练上花太久，进展并不划算。这是我们学到的教训。也说明那可能是个错误的决策。

我们做的另一件事是，因为 GPU 当时太贵，所以我们花了不少精力自己搭建了数据中心，这样成本能大幅降低。

之后我们转向后训练*（post-training）*，这是关键所在。我们的剧情工作流非常复杂。这里展示的只是一个简化示例，真实的更复杂。

我们请了 20 位标注员，必须先训练他们成为 "优秀的游戏编剧"，因为他们要判断智能体的回应是否合理、是否符合人物设定，并据此打分和排序。

经过一个季度的训练与标注，我们的模型在这个游戏场景中已经超过 GPT-4 表现。但问题是，那只是一个游戏，是整个开放世界里很小的一部分。如果你想做多个游戏呢？

我们进入了第二阶段，希望扩展到更多游戏和角色，目标是減少对提示词工程师*（prompt engineer）*的依赖。因为提示词工程很复杂，不同版本的 GPT-4 对 prompt 都非常敏感。

我们希望让游戏设计师来编写提示词，但这并不可持续。一年半前，我们想到要先预训练一个奖励模型*（reward model）*，让它自动判断哪种回应好、哪种不好，而不是依赖人工打分。

于是我们先训练这个奖励模型，让它在游戏语境中能识别优劣，再据此对主模型进行训练。

我们学到的一个重要经验是，即使是游戏这种听起来很简单领域，也涉及大量遵循指令*（instruction following）*的问题。要合理，模型必须保持足够的通用性。即便是域内模型，也要在通用任务上表现良好。

如果最好的闭源模型*（比如 OpenAI）*的 API 得分是 90，但在你的应用中，通用能力测试得分必须是 85。如果低于这个分数，那么你在具体场景的表现就会出现 "天花板效应"，难以突破。因此，首先要保证模型在通用任务上的性能稳定。

接下来针对具体任务，我们建立了 "域内评测" 体系*（in-domain evaluation）*，包含大量人物设定与场景设定，用于验证模型是否在特定情境下遵守规则、输出合理、语气合适。

一旦有了这种评测基准，你就可以据此微调模型，使其在该领域超越其他模型。这是一个通用规律：你必须关心 in-domain*（域内）*表现。

关键是，同时保证通用任务性能不下降，设计出一个真正高质量的 in-domain 评测任务，这样才能可量化地看到模型改进。

我们得到的总体教训是，**智能的本质仍然来自大规模预训练。**项目完成后回头看，所有重大性能提升来源于基于海量数据做出的预训练。

这让我们反思，放弃预训练或许不是个好主意，也许我们应该再多花一个季度继续预训练。这就是我们从中得到的教训。

不过即便如此，模型仍然有限制，在复杂场景下对话超过 50 轮后，质量明显下降，智能水平变得不稳定。

此外，当前的模型在复杂世界观、多角色环境下依然困难重重。无论是语音模型还是视频生成模型，目前普遍只能同时处理两到三个角色。即使在纯文本场景中，若涉及四个角色或四个平行设定，也极具挑战。

还有一点，在演示中，你看到我们的最新系统仍是 "逐轮对话" 模式。所以，这些项目都主要集中在大语言模型本身。

但我们的体会是，如果想实现真正 "类人" 的交互，就必须对架构做出调整，不能完全沿用传统的三段式结构。这也成为我们下一个项目的方向。

"现在方便聊吗？""其实我正要出门。""没问题，John。我知道您很忙。如果您方便的话，我可以稍后再给您回电。""其实不用了，我公司已经有健康保险了。""那太好了。我很高兴您已有保障。不过，其实很多我接触到的人也都有雇主保险， 但他们并不知道还有一些方案能帮他们降低自付费用。"

好的，这个例子完全不同，这是卖保险。之前是游戏，现在是保险销售。

起初我以为卖保险会有很多创意空间，可以自由发挥。**但现实中，这个行业极其正式。**首先，你不能随便拨打任何人的电话，只能联系那些主动留下信息、表示对产品感兴趣的用户。

其次，整个保险行业监管非常严格。 让我解释一下具体问题，我们现在做的是 Al 电话销售员*（Al telemarketer）*，也就是说，语音智能体扮演的是 "电话推销员" 的角色。当前的案例是通过电话销售健康保险，且覆盖多个国家。

监管要求有两点：（第一）必须通过电话推销员认证考试，分数需 80 分以上才能上线。 （第二）还有业绩指标要求。

例如给你 1000 个客户，你给他们致电，且必须完成一定数量的成交。同时，客户投诉率必须低于上限。如果客户觉得体验差、信息不实，提出投诉，保险公司对此极其重视。

因此，这里你需要具备的能力包括：首先，要足够智能，能严格按照销售手册精准地回答问题。稍后我会展示 "精准回答" 是什么意思。

其次，要能调用工具，因为保险销售涉及大量内部工具的使用来查询与计算，需要组合不同方案。

此外，语音必须非常 "类人化"。当你打电话时，对方可能在外面、背景嘈杂、带口音，智能体必须能理解、应对这些情况，语音听起来自然，而非机械。

最后一点，端到端延迟。当我说完话，你的回答必须小于一秒，否则用户会觉得对面的人反应迟钝。

举个例子，如果用户问："牙科保险最高赔付多少？"智能体回答："最多可赔付 600 美元。"这是错的，完全错误。这个任务考核是失败的。

正确的精准答案是：常规治疗 400 美元，而 600 美元的赔付是前牙修复项目。这写在产品资料里。

所以，"如果你的牙齿出现任何问题" 这样回答是不准确的。"如果你的牙齿出现*（具体）问题，（赔付是多少）" 这样的回答才是准确的。如果智能体的回答是前一个（非具体项目）*，这个回答就失败了。

另一个更具挑战的点，与游戏类似。比如，当智能体尝试与客户预约谈保险时，有规则规定最多尝试 3 次。三次都不行，就必须结束或改期。

例如：第一次电话，客户说 "不"。第二次再试，仍然 "不"。第三次依然被拒，就必须停止。如果用户说 "嗯哼"，你可能会误以为他感兴趣，甚至可能会根据语气变化去调整话术，比如："那我可以再解释一下它对您个人有什么好处。" 但事实上，你需要判断那语气其实是不耐烦。结合上下文，你要意识到："我已经尝试了三次，该改期或挂断了。"

这就是有语音输入时的复杂性所在。你不仅要理解文字，还得识别情绪、节奏与上下文。

接下来一个关键问题是，我们如何做到实时语音交互。

我想展示一下我们现在使用的几种模型架构。

第一种是最先进的：端到端全双工*（end-to-end full-duplex）*。意思是，用户和模型之间只有一个统一的模型。用户直接说出语音波形输入，模型实时监听并生成回应。

在交互过程中，用户可以随时打断，模型也能自然地插入反馈词。如果用户说了比较长的句子，你接话说 "对"、"没错" 等。这是目前最自然的人机交互方式。

不过，这种系统目前尚未真正投入商用，现在只有一两个演示版本可以试用，但还不太可控。

在大多数实际应用中，例如 GPT-4o，使用的是端到端半双工*（half-duplex）。 也就是说，系统通过语音活动检测器（VAD）*判断用户是否在说话，把语音分成一个个片段输入模型，模型对上一段内容生成回应。所以这是半双工的机制。

另一种方案是二段式链式架构*（Chained 2-components）*。它同样是轮流说话的模式，但使用两个模型而非一个。第一个模型负责理解，接收音频、生成文本响应。第二个模型负责生成，将文本转换为语音输出。

最后一种是三段式链式架构*（Chained 3-components)。流程是自动语音识别（ASR），然后到大语言模型、生成回答，之后再到语言合成（TTS）*模型来生成语音。

端到端全双工的交互最像人，因为可以打断。而三段式虽然不像人那么自然，但可定制性最强。你可以更轻松地在智能体中增加新功能或新能力。

在实际的客户项目中，我们通常采用二段式链式架构。

例如我们用一个 13B 的理解模型来生成文本响应。如果用户问题复杂，我们会调用经过微调的更大模型来做为工具使用进行 "思考"，然后再交由 1B 的生成模型输出语音结果。

现在这些模型其实都基于同一个大语言模型*（LLM）*，只是使用不同的数据混合 做连续预训练或微调。

比如，理解模型需要大量不同质量的音频，包括低质量语音，因为它要在嘈杂、口音多变的环境中理解人类说话。同时，它还需要继续在文本 tokens 上预训练。

而生成模型则相反，需要更高质量、长时音频来提升自然度和语音流畅性。大语言模型本身则会在特定领域数据上进一步训练。

这种架构让定制化变得容易。因为理解与生成模块都是通用的，可以在多个场景中复用。进入具体行业时，只需微调该模型即可。

这样既能保持智能性，又能实现低延迟。这是语音智能体实现商业落地的关键。

这里有几个核心理念。

首先，语音智能体要能同时听、说、思考，它一边聆听用户、一边生成回应句子。在两者之间，还能异步调用大语言模型进行更深层的思考或信息检索，所有这些过程都是异步并行的。

此外，我们还关注 "上下文工程*（Context Engineering）*" 的概念，比提示词工程更进一步。因为在真实业务中，产品信息和其它操作手册等可能多达 10 万 tokens。系统必须能够动态拼接这些上下文，自动生成合适的 prompt 来驱动模型。

还有一个模块叫策略调度器*（Organizer）*。它负责识别用户类型，并自动切换策略，同时进行意图分析，例如判断 "嗯哼" 这类模糊反馈，或者实时追踪对话任务进度。

把这些模块结合起来，我们就能同时实现高智能与低延迟。

这个项目从今年年初开始。我们与一家财富 500 强保险公司合作。我们从 1 月份开始做，在 2 月开始使用 ChatGPT-4 时，测试得分 55。但你必须要到这根线——人类销售员的及格线是 80，必须达到这个标准才能上线。

我们经历了很多困难，但系统稳步改进。大约用了半年到三个季度，终于达到、甚至超过了人类表现。

我们在这里学到的经验是，**评估端到端语音智能体非常难，**因为必须通过真人通话测试。一旦涉及真人通话，就很难实现自动化评估。但如果没有这种测试，就无法真正衡量系统整体表现。

目前仍然存在持续的挑战，在实时场景中处理复杂的产品组合仍然非常困难，例如保险，有大量产品、价格组合。当客户说："太贵了，我想要便宜一点的方案" 时，系统必须实时挑选出合适的替代方案。

另一个问题是，**高安全要求导致成本更高。**在论坛讨论中有人提到，OpenAI 会不会成为主导AI的唯一巨头玩家？但在 toB 的领域，答案是否定的。以保险业为例，在不同国家部署时，数据不能出境，甚至不能离开公司内部的安全域。

因此，你要么租用 GPT 模型在自己账户下运行，要么必须自研。这就是为什么推进AI困难重重。也正因如此，我们投入了大量精力自建全套模型，而不是仅靠 prompt 工程去调 API。

我刚才展示了我们在过去两年中开发的两个语音智能体项目，我们得到的经验是：语音智能体任务是有高度可扩展性的。

即使游戏行业设定与保险行业设定有很大的差异，但从技术角度看，它们共享相同的模型架构与训练方法，不同的只是数据类型与评估方式。无论是预训练、后训练、数据标注流程，都需要花费大量人力，其本质都是一致的。游戏侧重 "有趣与互动"，电话销售侧重 "精准与规范"，但两者都对用户（语料）输入需要谨慎处理。

不过，我认为现在这些系统已经可以真正落地应用，但仍处于 "Day One*（初期）*" 阶段。比如在游戏中，目前还只是单角色、小世界规模。要扩展到多角色、庞大世界观，仍非常困难；在电话销售中，我们现在可以销售某家公司约 5 种健康保险组合，要售卖通用类型产品依然困难。

总体而言，这种语音销售员在价格区间 500-5000 美元的产品上效果最好。当然，用现有模型去销售全新产品仍需大量调优。**但应用场景正在快速扩展。**过去的客服系统只基于文本，现在都能加上语音界面，这意味着潜在应用巨大。

我认为语音智能体的商业落地才刚刚开始，未来几年将会非常令人兴奋。

最后，如果有兴趣和我们一起工作或者合作，欢迎联系我们。

（本篇内容由 Datawhale 团队编辑，点击阅读原文访问演讲视频）