[智能座舱]小鹏G9语音新功能介绍与分析

自从2020年小鹏P7上市后，其搭载的全场景语音交互系统就成为车载语音交互产品的标杆。小鹏G9发布也带来了语音系统的升级。因为目前市面上还没办法体验到最新的系统，本文根据B站的体验视频，对小鹏G9上的三个语音功能进行介绍和分析。

功能介绍

G9上关于语音产品升级重点强调了3个新功能，分别是：多人对话，全时对话，极速对话。这三个功能目前还都是测试版，用户需要等待G9的OTA升级才能体验到。下面将对这三个功能进行简单介绍。

图1 G9语音功能升级

极速对话

1. 第一个是唤醒速度快，也就是说完“你好小P”后可以秒响应，被称为极速唤醒。但是视频中有信息提到极速唤醒的延迟是700ms，从数字看这个指标不好，当前稍微好一点的车载语音产品基本都能达到这个要求。11月17号关于小鹏语音的官方推文中从语音结束到界面动画小于300ms，希望之后能实车体验确认一下。

2. 第二个是指语音指令响应速度快，是指从用户说完话之后到小P开始执行指令的时间。从视频的对比中可以发现，当前的极速版本把语控响应延迟从原来的1.5s缩减到0.9s左右。对于车载语音产品，0.9s是一个比较优的数字。当前的车载语音产品一般就是1.5s左右，好一点的可以做到1.2s。

3. 除此之外每个视频中都强调了多意图指令理解的能力，不过这个是P7的已有功能。体验比较好的一点是目前针对多意图指令的TTS回复也是综合答复，不是逐条播报每个指令执行情况。

全时对话

1. 打开全时对话开关后，小P会进行持续收音，任何时候都不需要唤醒（不用喊你好小P），就可直接说出指令并执行。目前只支持部分指令，猜测主要是车控类的指令。在全时对话的过程中，对于不支持的指令车机不会响应，但是用户可以5s内补充说一个“小p”，这样小p就可以把刚才不支持的指令识别出来并执行。通过这个产品设计很巧妙的解决了全时对话只支持部分领域引入的体验割裂问题，并且只需要说“小p”而不是“你好小p”。个人认为这是此次G9最出彩的功能更新。就像你让人帮忙做事情，如果他没动，可以在喊一下他的名字，把“你好小p”缩短为“小p”两个字也更加自然。

2. 在视频展示中，可以看到G9上联合oneshot的交互方式，将“你好小p”的四字唤醒词缩减为“小p”两个字，实现了唤醒词字数减倍的巨大进步。当前两个字的唤醒词技术非常不成熟，单独使用会引入大量的误报，将其和指令连在一起以oneshot的形式推出两个字唤醒词，很好的缓解了这个问题。两个字的唤醒词相比于四个字更加自然使用也更加方便，一定程度上可以缓解唤醒词给用户带来的尴尬。百度智能健身镜上也应用了该设计，据说苹果也将采用该设计将“hi siri”缩短为“siri”。

3. 打开全时对话开关后，默认只支持主驾的全时对话。此处小P的眼睛动画有变动，可以看出产品设计细节，用户体验比较好。

多人对话

1. 同时打开多人对话和全时对话后，四个位置都可以使用全时对话功能，并且四个位置的用户可以交替说或者同时说，不会相互干扰，满足多人对话需求。

2. G9上实现了跨音区多轮对话，不同的音区使用同一个多轮状态进行维护，主驾说完“打开座椅加热”，副驾只需要说“我也要”就可以打开副驾的座椅加热。主要是针对音区绑定相关功能点进行的多轮对话继承优化。

3. 四个位置asr的结果分别在四个角的位置显示并且会在屏幕上会展示回复内容，并且会锁定音区回复（有时不会进行TTS回复）。在视频中强调了此处一些产品细节的设计。

图2 四路全时对话屏幕展示

功能分析

极速对话

简单来讲，语音交互技术的永恒追求可以浓缩为两个字：快和准。快且准的语音交互技术是打造出真正让用户满意的语音交互产品的必要条件。极速对话的目标就是实现语音交互的“快”。

图3 语音交互数据流图

图3展示了从用户说话到车机执行并给出的答复的一个简化流程。黄色部分的录音模块是负责数据采集，蓝色部分是对采集到的语音数据进行处理来理解用户的意图，紫色部分是根据理解的指令回答用户，橙色部分是车机执行。一般意义上讲，用户感受到语音速度快就是从录音到指令执行的这段时间，这其中涉及到硬件、算法等多个模块。事实上一个完整的语音交互产品内部的模块以及交互逻辑要远比此处展示的复杂的多。对于如何优化语音交互速度，可以从以下三个方面进行分析：交互链路，算法，系统与硬件。

1、交互链路

交互链路优化是指在交互逻辑设计时缩短数据的传输路径或者优化数据的传输速度，使得的反馈结果更快的流向用户。可能的方案包括：

• 使用离线方案，优化离在线融合的逻辑。

• 采用流式处理，减少各个算法模块的绝对等待时间。

• 算法模块的并行处理，找出实现数据传递的最短路径。

• 算法模块合并，缩短数据传递的链路。

2、算法

语音交互技术的链条中包含了很多模块，试想如果每个算法模块都有几十毫秒的延迟，可能累积起来大几百毫秒就没了。因此要提升语音交互速度，各个算法模块的优化打磨是必不可少的。对于做产品落地的算法工程师而言，每个人面临的终极问题就是：怎么精简算法可以在不降低算法性能、不增加算力（CPU/NPU）占用的条件下尽可能的提升速度。成为一个带着镣铐在刀尖上翻腾的舞者，这可能是对做产品的算法工程师的最高要求。算法模块的优化不仅与产品体验息息相关，而且精简的算法可以直接降低硬件的成本。在语音技术链条中，对语音交互速度有直观影响的几个模块有：

• 信号处理：包含aec、分离、降噪三个核心算模块，此外还会有音区定位、人声隔离等。

• VAD：VAD算法本身的延迟一般比较小，核心在后处理策略方面会造成比较大的延迟，这个和产品设计有关，需要在延迟小和其他体验方面做tradeoff。

• ASR：引入延迟的部分包括模型打分需要累积的数据、对未来信息的依赖、CTC等算法的尖峰后移、剪枝搜索策略等。

3、系统和硬件

硬件是基础，系统是支撑。一个流畅的底层系统是优秀的软件产品的必要条件。语音交互系统不仅依赖硬件和系统，其本身也要对车身硬件或者系统进行控制。如果车机系统本身就容易卡顿，语音交互算法优化的再好也没有用。影响到语音交互体验的硬件和系统包括：

• 录音硬件和录音驱动

• 语音相关进程的优先级以系统资源分配策略

• 控制车身硬件的响应速度

• 车机系统的响应速度

G9的极速对话功能将语控延迟从1.5s降低到了0.9s左右。能做到如此大的提升，各个体验视频中强调的两点原因是：

• 将云端语音方案替换成离在线融合的方案，去掉云端方案中数据上传和下载的流程，从而缩短交互时间。

• 支持流式理解，ASR和NLU可以并行处理，缩短NLU的等待时间。

但是现在都是5G时代了，网络延迟真的会这么大吗？抱着怀疑的态度，笔者根据体验视频做了详细的分析，从语音结束到第一个字上屏、语音结束到全部识别结果上屏、识别结果到车机开始响应这三个关键时间段的数据统计来看，得到了如下结论：

• 极速对话中，识别结果提前了0.15s但是首字上屏结果却变慢了此处的提升大概率和离线的asr算法方案有关，网络延迟在里边占的比重比较小。

• 极速对话的巨大提升大概率来源于vad后处理策略改进和流式理解的离线NLU算法的改进。

因为网上的体验视频会有后期处理，可能与真实体验会有差异。因此之后会根据实车体验再做一次分析校正。对速度优化感兴趣的同学可以跳转的附录查看分析过程。

全时对话

全时对话是一种颠覆性的交互方式，打破了自iphone 4s 推出siri以来语音交互系统必带唤醒词的传统。根据语音交互逻辑的发展，可以从两个方向推导出全时对话的演化方式，其本质都是为了提升交互效率，让人机语音交互更自然更便捷，更符合人与人的对话逻辑。

图4 全时对话演进图

众所周知，唤醒词相当于语音系统的开关，打开则开始录音，关闭则停止录音。全时对话中去掉了唤醒词，语音识别系统就要做到一直进行收音。在失去开关的控制后，意味着语音交互系统的隐私性、安全性等会受到更多的关注。为了做好全时对话功能，必须做好以下几个方面：

1、采用离线语音方案

离线语音方案具有以下优势：

• 数据全部在本地处理，保护用户隐私。此处的数据不仅仅是包含生物特征的语音数据，语音识别出的文本内容中也包含了大量的用户隐私。

• 数据不需要上传云端，节省流量费用。

• 所有工作在本地完成，节省云端服务的成本。

G9上精心打磨的离线语音方案为实现全时对话功能提供了可行性。

2、做好人声分离和隔离

人声分离的目标是把目标人和其他人声分离开，人声隔离的目标是剔除非目标人声，只把目标人声送入语音识别引擎进行识别。G9上采用的是分布式四麦克风的硬件配置，从硬件上降低了人声分离和人声隔离的难度。但是算法上依然要努力做好这两方面，尤其是要做好目标位置不说话其他位置说话时的漏音问题。

3、做好误报控制

误报控制是全时对话中最难的也是最关键的部分，直接决定了全时对话功能的用户体验。做语音的同学应该都知道语音唤醒也有误报，每个语音唤醒从业者要解的80%的badcase可能都是误报的优化。全时对话的误报和语音唤醒的误报本质上都是不该被响应的语音被车机系统错误的响应了。但是全时对话的误报又和唤醒的误报有明显的不同。

首先，误报对用户的影响不同。唤醒词仅是一个开关，发生误报的时候无非就是小P应答了一声并且转头看看你。但是全时对话中每一句话都是有实际动作的语控指令。试想你下雨天开着车正在和老婆打电话说路上堵车了晚点到家，这时候天窗莫名其妙的打开了。此时的你会不会口吐芬芳，如果你知道是全时对话作祟肯定会立马关了不会在打开了，如果你不知道是全时对话误报了，第一次可能莫名其妙，第二次估计就会开到4S店要求检修了。

其次，误报发生的频率和控制的难度不同。唤醒词是确定的4个字，目标相对确定，但是依然非常难把误报控制做好，只有一个确定的词都这么难做，更何况全时对话中的数百个功能点，数千种说法。这种误报其实在现在的延迟聆听中也会存在，只不过因为延迟聆听一般只有几十秒，误报的可能性在时间维度上被大大的压缩。

全时对话的误报可以分为两类。第一类是因为算法识别错误导致得指令误识别，比如asr把无关的语音识别成了有效指令，或者nlu把无关的文本解析成有效指令。解决该类的最好的方法就是无限提升算法性能，还有就是通过一些策略对这些错误指令进行检测屏蔽。第二类问题是人机对话和人人对话的区分。比如你在和朋友聊天的过程中提到的某一句话本身就属于一条可以触发车机动作的指令，但实际上你是在和朋友聊天而不是向车机下达指令。该类问题估计是全时对话中最难解决的问题。

4、避免用户体验的割裂感

从安全设计以及当前技术的成熟度出发，很长一段时间内全时对话支持的功能点只是全部语音功能点的子集，这会造成用户的学习成本上升，因为用户是不知道哪些功能支持哪些功能不支持的，会造成用户体验的割裂感。笔者认为小鹏G9对这个问题的处理非常好，小鹏的产品和工程师们使用后置唤醒的方式很优雅的解决了这个问题。个人猜测后置的“小p”应该是使用asr实现的而不是做了一个专门的两字的唤醒系统。

目前了解到除了G9以外还有两款车支持全时对话。第一款是吉利的星越L，在系统里被设置为极客模式，打开后可以使用全时对话。但是这款的车的体验非常糟，基本上属于无法使用状态，因为一旦打开后，随便说一些话就会触发语音功能。第二款是奇瑞瑞虎8 pro，在系统中默认上线了全时对话功能，在该车宣传中称为全时免唤醒功能。该方案是由地平线提供，是业界第一款的基于全离线方案打造的全时对话系统，也是目前市面上体验最好的。希望早日体验到G9的全时对话功能，也希望G9能够后来居上，进一步推动全时对话功能的发展。

多人对话

G9中的多人对话功能主要有两点：一个是不同位置的人可以同时使用语音，相互独立互不干扰；第二个不同位置的人的对话可以相互继承。从技术上讲，多人对话相对于极速对话和全时对话会简单一些。

1、多人并行使用功能

要实现多人并行使用功能需要做好两点。第一点是强大的信号处理功能，特别是人声分离和人声隔离的能力，目前基于分布式四麦的前端信号方案相对比较成熟，有比较好的解决方案，但是也存在一些困难场景需要继续突破。第二点是算力大，能够支撑4路语音交互系统的并发，核心是4路asr和4路nlu的并发。

2、多人多轮对话功能

该功能的核心是做好多音区内多轮状态的继承，属于对话管理的范畴，业内也有比较好的解决方案。

总结

根据体验视频，笔者总结了G9上两种交互逻辑。（只是个人猜想）

图5 以“你好小P”发起的语音交互内部算法模块逻辑示意图

图6  全时对话语音交互内部算法模块逻辑示意图

小鹏P7的上市将车载语音助手推向了一个新的高度，成为众多车厂对标追逐的对象。希望G9能够将车载语音推向一个新的高度，给用户带来更多的便利，也给众多的语音从业者创造更多的机会和发展空间。最后希望能早日体验到G9的全部功能。

附录：延迟分析

在体验视频中，笔者选取了一个“打开车窗”的例子，通过分析录像视屏的方式，对比语音和视频中文字上屏状态以及指令执行状态，整理分析出了各个关键事件的时间点。

图2-1 关闭极速对话，各个关键时间的时间点

图2-2 打开极速对话，各个关键事件的时间点

根据识别结果上屏事件可粗略的把语音交互的延迟分为两个TD1和TD2两个部分，每部分的详细定义和说明可以参考表格。此外因为语音结果实时上屏也会影响到用户的感受，因此把语音结束到第一个字显示到屏幕上记为TD3。

名称	模块	说明	包含模块分析	关闭极速对话	打开极速对话（提升比例）
TD1	识别结果上屏延迟	从语音结束到屏幕上显示出完整指令文字的时间	1.录音延迟； 2.前端信号处理延迟； 3.vad算法延迟； 4. 数据网络传输延迟（云端方案）； 5. asr算法延迟。	0.608s （9.732s ~ 10.340s）	0.467s（23.2%） （21.0s ~ 21.467s）
TD2	从文本到指令执行的延迟	从屏幕上显示完整指令文字到车机开始执行的时间	1. vad策略延迟 ； 2.nlu算法延迟； 3.指令解译、硬件启动等系统延迟。	0.947s （10.340s ~ 11.287s）	0.407s（57.0%） （21.467s ~ 21.874s）
TD3	识别结果首字延迟	从语音结束到第一个指令文字上屏的时间	1.录音延迟； 2.前端信号处理延迟； 3.vad算法延迟（数据积累延迟）； 4.数据网络传输延迟（云端方案）； 5. asr算法延迟。	0.335s （9.732s~10.067s）	0.367s（-9.5%） （21.0s ~ 21.367s）

注：只是使用一条语音的参考意义一般，还需要一定的数据来证明有效性。

根据统计结果对极速对话中速度提升原因进行推测：

模块	极速对话中是否会有优化	说明
录音延迟	录音偏底层，打开极速对话前后应该没有变化
信号处理延迟	信号处理本身就是运行在端侧，估计没有变化
vad算法延迟	vad算法本身就是运行在端侧，估计没有变化	vad模型打分数据积累、对未来信息的依赖等
asr延迟	会有变化，TD1的提升大概率是和离线ASR算法方案有关。一方面是模型层面的优化，另一方面是本身搜索空间小，解码速度会快。	asr模型打分数据积累、对未来信息的依赖、解码延迟、ctc尖峰后移等
网络传输延迟	根据TD3的结果，感觉影响不大	云端方案中语音数据上传和识别结果下发
vad后处理策略延迟	影响比较大。	vad后处理一般会根据算法输出向后扩展一定时间，方式语控指令的提前截断
nlu算法延迟	针对“打开车窗”的指令，理论上不论云端还是端侧大概率的规则引擎实现，理论上二者在速度上的差异应该影响很小。结合流式语义理解会有提升
指令解译、硬件启动等系统延迟	不会有变化，硬件、系统层面不会有差异

传统的语音交互流程中为了保证语音识别不被提前截断（比如用户说话停顿、或者vad算法不鲁棒等）会在vad的算法输出后添加后处理策略，一般会在算法输出的基础上向后扩展一定的时间，这就会在很多场景下引入大量的延迟。如下图所示，虽然在t3时刻虽然拿到了完整的识别结果，但是由于vad段没有解码完成就不会送给nlu进行文本解析，直到t4时刻才会将asr结果给到nlu进行解析。引入流式语义理解后，asr的识别文本实时送给nlu进行解析，在t7时刻就可拿到nlu的解析结果，无论是继续等到t4时刻进行结果确认还是直接只用t7时刻的结果都会大幅度降低延迟。

其实有意思的一点是，不打开极速语音时，从t3到t6时刻竟然用了0.947s，假设系统的vad后处理向后扩展了0.6s，硬件执行消耗0.1s，那nlu部分居然消耗了0.247s，针对“打开车窗”的这条如此简单的指令感觉很不可思议。只能说提升巨大全靠上一代衬托。

图2-3  打开和关闭极速对话各个时间点展示

参考视频

1. https://www.bilibili.com/video/BV1v24y1o7sX/?spm_id_from=333.337.search-card.all.click&vd_source=395a011db2a23b5aac8f47f4a6882d99 （前7分钟，总结的比较系统到位）

2. https://www.bilibili.com/video/BV14e411M7fv/?spm_id_from=333.337.search-card.all.click&vd_source=395a011db2a23b5aac8f47f4a6882d99 （6分半以后）

3. https://www.bilibili.com/video/BV1NK411D7eb/?spm_id_from=333.337.search-card.all.click&vd_source=395a011db2a23b5aac8f47f4a6882d99 （细节比较多）

4. https://www.bilibili.com/video/BV1Qe4y1v7sK/?spm_id_from=333.337.search-card.all.click&vd_source=395a011db2a23b5aac8f47f4a6882d99