语音助手在货拉拉出行业务的落地实践

今年3月28日，小米SU7发布会上，演示了搭载AI大模型，配合小爱同学语音助手，提供全新智驾体验，令我印象深刻。它支持模糊指令识别、五音区语音交互，实现手机、Pad与车机的无缝连接。作为同样依赖车进行业务运营的货拉拉而言，这是一个非常合适的土壤。我们首先在出行业务中对语音助手的落地进行了尝试。

为什么要做语音助手

语音助手是指通过语音识别技术（ASR）将驾驶员或其他乘员的语音指令转化为可理解的指令，然后通过语音合成技术（TTS）将系统的反馈信息以语音形式传达给对应人员，同时执行对应的动作。它有以下几个明显的优势：

1. 提升驾驶安全性： 驾驶员可以通过语音指令完成操作，无需分散注意力去触摸屏幕或按钮，减少驾驶风险；
2. 提供便捷的操作方式： 语音交互能够提供更自然、更直观的人机交互方式，让驾驶员更轻松地控制车辆功能和获取信息；
3. 支持多任务处理： 通过语音交互，驾驶员可以同时进行驾驶和操作，无需停下来或转移注意力；
4. 个性化体验： 语音交互可以根据驾驶员的习惯和偏好进行个性化设置，提供更加贴合用户需求的服务和建议。

如何做一款相对有用的语音助手

制作一款相对有用的语音助手涉及到多个技术领域，包括但不限于语音识别、自然语言处理（NLP）、语音合成（TTS）以及一定的业务逻辑处理能力。

1. 确定功能和目标群体

• 功能范围：明确你的语音助手需要完成哪些任务，例如控制App进行跳转，自动查询听单检测结果、查询附近热力图信息、推荐附近热区、入账播报、会员推荐等等。
• 目标用户：了解你的目标用户和他们的需求，这将帮助你设计更加符合用户预期的交互和功能。

2. 选择技术栈

• 语音识别（ASR） ：将用户的语音输入转换为文本。
• 自然语言处理（NLP） ：理解和解析用户意图。通过司机语音识别将结果进行处理，理解司机意图。
• 业务逻辑处理：根据解析出的意图执行相应的操作。这可能涉及到调用第三方API、执行内部逻辑等。
• 语音合成（TTS） ：将文本转换回语音反馈给用户。

3. 设计对话流程

• 单/多轮对话能力：设计支持多轮对话的机制或者单轮对话机制，以便在处理复杂请求时能与用户进行有效的交互。
• 意图和实体识别：明确每个用户请求中的意图（要做什么）和实体（具体信息），以提供准确的服务。
• 错误处理和反馈：设计错误处理机制和用户反馈流程，以优化用户体验。

4. 实施和测试

• 快速原型制作：构建一个最小可行性产品（MVP）来验证你的想法。
• 用户测试：通过用户测试收集反馈，了解哪些功能受欢迎，哪些地方需要改进。
• 迭代和优化：根据用户反馈和使用数据不断迭代和优化你的语音助手。

5. 确保隐私和安全性

• 用户数据保护：确保用户数据的安全，遵守相关法律法规。
• 透明度：向用户清晰地解释你的语音助手如何使用他们的数据以及数据使用的目的。

6. 集成第三方服务

• API集成：为了扩展功能，可能需要集成天气、新闻、日历等第三方服务的API。

7. 持续学习和适应

• 机器学习：使用机器学习技术来分析用户行为和反馈，不断优化语音助手的表现。
• 适应性：随着技术的进步和用户需求的变化，持续更新和改进你的语音助手。

怎么做语音助手技术框架的搭建

1. 语音唤醒

1.1. 方案选型

语音唤醒目前有很多免费的开源可商用项目可以使用，选择的依据包含是否免费、包体积、是否可离线使用、识别准确度、CPU占用，耗电量等诸多因素。在其之上选择支持自定义唤醒词、SDK体积小的，支持在移动端部署的即可。这里列举几个质量相对很好的开源项目： 百度语音唤醒/FunASR/Sherpa-onnx/Teachable Machine等，篇幅所限，就不一一展开对比了。参考链接如下：

1. FunASR热词检测
2. 百度语音唤醒
3. SherpaOnnx语音唤醒词
4. 基于Teachable Machine实现语音指令

1.2. 免唤醒

在此基础上，我们扩展了一些线上使用频次比较高的语音指令，也就是免唤醒指令，用户直接说 “返回上级”即可退出当前界面返回上级界面，避免手动操作返回。避免了从 “你好小拉”唤醒之后再进行事件触发。

1.3. 语音唤醒率提升与识别率提升

其次，为了提高语音唤醒率。通过让司机录制特定唤醒词的语音，利用现有模型识别出这些语音中的文字，然后将这些识别出的文字作为唤醒关键词，以此来适配不同地域、方言和发音的差异，从而提高语音唤醒的准确性和适用性。主打以错对错。

举个例子

司机通过语音识别 “去热力图” 因为地域口音等影响识别为 “去那里图”。

那么在这个语音唤醒后，通过匹配 “去那里图”,作为触发语音指令，解决个体差异也能识别语音指令的问题。

其次可以将识别的语音指令文字作为特定个体的语音唤醒词，提高语音唤醒率。

可行性分析如下：

1.3.1. 优点

1. 适应性强：通过个性化录制唤醒词语音，可以有效适配不同的地域、方言和个人发音特征，提高识别的准确率。
2. 用户体验提升：司机可以自定义唤醒词，这种个性化设置能够增强用户体验。

1.3.2. 缺点

1. 实现复杂度：需要开发一套流程和界面让司机录制语音，并确保录制的语音质量符合要求，这增加了实现的复杂度。
2. 用户参与度：这种方法需要司机主动参与录制语音，可能会受到司机参与度的限制，影响普及率。

这里其实可以参考苹果/华为的语音指令进行UI交互设计

综上所述，通过录制特定唤醒词的语音并将识别出的文字作为唤醒关键词的方法，在技术上是可行的，且会大幅提升系统的适应性和用户体验。

2.语音识别

2.1. 语音识别模型选择

在语音识别这块，通过考虑语音识别这块不适合部署在远端进行识别再返回，耗时长，服务器价格太贵，支持路数有限等因素决定必须寻找端侧模型进行识别。我们先后调研了很多开源框架，包含Wenet/FunASR/Sherpa-ncnn/Sherpa-onnx/华为语音识别/讯飞语音识别/百度语音识别/Whisper/DeepSpeech等开源框架，通过集成测试，依据是否免费、包体积、CPU占用，耗电量等诸多因素，排除了十几款模型，最终选择了华为语音识别与Sherpa-ncnn作为ABTest来测试其在Andorid设备上语音识别准确度。框架比对内容很多，这里不再赘述。

对各个开源框架集成测试感兴趣的戳这里：

www.yuque.com/zuoyi-hhn9b…

iOS经过一系列测试，发现苹果技术生态做的太好。支持噪音过滤、热词、语音分类、文本分类等能力，同时支持端侧模型训练与部署，这些我们后边会一一举例。

2.2. 语音识别的前置优化

车上的语音内容信息多种多样，不同说话人声、歌曲声、有声小说声、导航播报声、发动机噪音声等，那么为了进一步提高语音识别的准确性，我们就必须先排除其他声源的干扰。如果我们可以将这些非人声的音源排除干净，那么送入语音识别系统，识别出的人声转文字就越准确。得益于目前苹果生态的支持，声音分类不再是一个难题，可以通过机器学习解决。

Android端可以参考如下链接：

www.yuque.com/zuoyi-hhn9b…

www.yuque.com/zuoyi-hhn9b…

2.2.1. 可行性分析

1. 语音特征差异性：人声与机器生成的导航或app播报声在声音特征上存在差异，如语调、语速、背景噪声特征等。这些差异可以被用来区分人声和非人声。
2. 机器学习模型的发展：当前深度学习和机器学习技术的发展已经允许我们构建高精度的语音分类模型，这些模型能够基于声音的特征进行有效分类。
3. 实时处理能力：随着计算能力的提升，即使是复杂的深度学习模型也能在接近实时的环境下运行，满足实时语音识别的需求。

2.2.2. 具体实现方法

1. 数据收集与标注：

   1. 收集大量的人声、导航播报声、车内背景音和app播报声的样本数据。
   2. 对这些样本进行准确的标注，区分不同类型的声音。

2. 特征提取：

   1. 对所有语音样本进行预处理，提取关键特征，如MFCC、频谱特征、节奏和语调等。

3. 分类模型的选择与训练：

   1. 使用深度学习模型，如卷积神经网络（CNN）或循环神经网络（RNN），特别是长短期记忆网络（LSTM）和Transformer模型，因为它们在处理序列数据（如语音）时表现优异。
   2. 使用标注好的数据集训练分类模型，使其能够区分人声、导航声和app播报声。
   3.   比如iOS CoreML中自带了几种语音特征提取器，感兴趣戳如下链接：   www.yuque.com/zuoyi-hhn9b…

4. 实时分类与过滤：

   1. 在语音识别流程前引入一个实时语音分类步骤，所有捕获的语音数据首先通过分类模型进行处理。
   2. 根据分类结果，仅将分类为人声的数据送入后续的语音识别流程，而将导航声和app播报声过滤掉。

5. 模型优化与测试：

   1. 对分类模型进行持续的测试和优化，以提高其准确性和效率。
   2. 特别注意模型在不同环境下的表现，如不同的背景噪声条件、说话人的变化等。

6. 系统集成与部署：

   1. 将训练好的分类模型集成到语音识别系统中。
   2. 确保系统的整体性能满足实际应用的需求，包括识别准确度和处理速度。

通过上述步骤，可以实现一个能够有效过滤掉导航和app播报声，仅对人声进行识别的系统。需要注意的是，这个过程可能需要持续的数据收集和模型训练迭代，以适应不同的声音特征和场景变化。

下边是我们最初训练的模型，可以看到语音识别分类还是很准确的，在此基础上仅将人声送入语音识别系统，比事后拿到一整段语音再分类剔除噪音，再进行语音识别的效果更好。数据集的收集花了很长时间，都是公开的车内数据集。感谢开源社区的贡献。

2.2.3. 语音识别分类效果展示

2.3. 语音识别结果脏数据过滤优化

在语音识别结果出来后，我们需要将语音识别结果进行NLP语意的理解，当然最开始使用的是最简单的正则匹配，根据用户授权同意语音识别并参与改进计划的识别结果数据集，手动筛选司机语音指令大致匹配的数据。然后根据这些标签罗列，将识别文本进行机器学习训练。后续如果有资源，会接入Bert作为语意理解后端服务，通过接口智能识别即可。前期的数据标注是比较耗时的。

这里为什么不用大模型，其实主要是国内模型还是不够智能的原因，另外数据隐私也限制了不能进行第三方大模型接口的调用。目前已经可以使用公司内部部署的大模型，隐私问题不再是问题了.

测试结果1	测试结果2

相比之下还是ChatGPT给出的分类标签最准确。

2.3.1. 数据收集打标签

鉴于篇幅所限，这里仅仅列举了一些，一个常用指令在线上可能有二三十中表现形式。

热力图	返回大厅	刷新订单	指令	小拉充电	更新定位	关闭助手	打电话	小拉加油	出车	截图	收车
打开热里图	放回到厅	没有订单	看看指令学习	没有电了充电	更新当前位置	小拉休息	联系客人	打开小辣椒有	我要出车	说截图	去收车
打开这里头	抢占大厅	没单啊	指令看看	最近充电桩	刷新定位	关闭助手	打给乘客	打开加油一面	立即出车
打开这里住	抢单打听	来个单子	查查纸令学习	打开小拉充电业	刷新定位	关闭助手关闭	打电话	去加油	打开出车
打开这里图	抢单	来个大单	查查查看指令	打开小拉充电页	刷新定位	关闭语音	打电话给乘客	进入加油站	去出车
打开这里头	打开订单大厅	有没有订单	打开指令学习	充电	发现定位	关闭因助手	我要打电话	最近的加油	躯出车
去热力图	回踏厅	寻找订单	开指令学习	寻找充电桩	刷新地位	你休息	帮我联系一下乘客	小辣加油	开始接单
打开热力炉	打回到厅	抓新订单	打开手册	去充电	刷新定位	关闭语音	联系客户	，加油	租车
热闹区	为大厅	刷新订单	咋干指令学习	充电桩	更新定位	退出语音唤醒	打电话给	打开加油一面
热里图	回大厅	怎么有单呢	去语音助手	小拉充电	重新定位	闭嘴	打电话给乘客
热力的图	打开抢单大厅	我要接大单	你会干嘛	附近充点/店/的	更新当前位置	请退下
打开热历图	小拉小拉去抢单大厅	为什么没有订单	语音指令	附近最近充电桩	更亲当前位置
打开热点图	去抢单大厅		查看指定学习	没有电了充电
打开热立图	大厅抢单大厅	刷新页面	打开学习指令	最近充电桩
打开热需图	返回大厅	帮我找一单	打开指定学习	想拿充电
打开日历图	返回抢单大厅	怎么没有单呢	查看指令学习
打开日历图页	图打开大厅	怎么没有单字呢	查看指令
打开日里头	返回大厅	怎么没有蛋呢	调侃指令学习
打开乐图	听反围大厅	怎么没的单子	查查纸令学习
那地图	到首页	帮我找几个单	指令看看

2.3.2. 数据训练分类

图中展示的就是训练的数据以及训练达到的准确率与召回率。

2.3.3. 数据分类结果展示

这样在前期还没开始语音分类处理时，我们先手动过滤导航播报，自研TTS语音播报被识别的数据，剩余的基本就是用户说话声音数据了。

由此，我们完成了最核心的语音指令与语音识别功能，为语音助手扩展功能的落地打下了基础。

语音助手实现效果展示

总结

就如乔布斯所言：一个好的想法与一个好的产品之间，需要大量的精细工艺去打磨。随着这个好的想法的发展，它会不断变化和成长。它不会像最初设想的那样简单，因为在深入了解其微妙之处时，你会学到更多的东西。你还会发现，你必须要做出许多的权衡。

通过语音助手项目的上线，我们也从其中学习了大量语音相关的知识，语音技术飞速的突破也就是这几年的事情，大量的开源语音项目也为语音技术的应用奠定了基础，感谢开源社区。最后我们团队建立了一个语音技术专项博客，链接如下：www.yuque.com/zuoyi-hhn9b…。

作者： 出行架构组-姚亚杰