贴近司机，感知生活：智能语音助手在滴滴车主端的设计与实践

桔妹导读：基于网约车司机的职业特性，帮助与指引司机在各类复杂的场景下更安全、便捷地完成工作，并尽可能疏导与减轻他们因长时间处于封闭环境下的心理压力，一直是滴滴发力的一个方向。但现有的一些途径，如规则展示、人工客服等，可能存在着司机被动接收信息成本较高、因客服处理速率引发其他情况等弊端。因此，我们在将AI能力与车主端功能结合的过程中做了各类尝试，最终创造了一个可以完善解决这些问题的司机助手：小滴。

1. 

功能概述

▍1.1 功能背景

一直以来，滴滴始终致力于让出行更美好，而基于Technology for Traffic的使命任务，也在不断探索AI产品技术能力在滴滴场景下的价值。

其中，AI语音交互能力在滴滴内部多方的探讨下，从2019年9月开始，在滴滴车主端（后文简称“车主端”）以语音无责取消连环派单的场景作为切入场景进行探索。其后历经数次版本更新，在车主端发布了若干AI语音交互功能，详细时间表如下：

表1.1 车主端语音交互功能已上线功能表

而智能语音助手是在经历了之前语音交互功能迭代和获得相应的技术积累后，诞生的一套比较完善的语音交互体系，其整合覆盖了已独立存在的各AI语音交互功能，并使各能力之间联系起来，更加快捷和有效率地服务司机。

▍1.2 功能定位

滴滴车主端智能语音助手，其定位是一个基于用户特征及行为预测，满足不同场景诉求的拟人化智能语音助手，TA作为司机与平台、司机与司机、司机与乘客间的连接角色，在司机工作中的不同场景下，从平台角度提供给司机的帮助与指引，是司机一对一个性化的平台代言人。

▍1.2.1 智能语音助手的功能方向

辅助工作

在实际工作中，出于司机本身的工作性质并从安全角度考虑，频繁地手动操作车主端容易对司机与乘客造成较高的安全隐患。对此，智能语音助手可以在这类场景中，辅助司机使用语音方式完成相关操作，有效降低安全风险。

同时，车主端部分功能的入口较深，司机要到达比较复杂，而通过智能语音助手，可帮助司机直接使用这些操作繁琐而对其又较常用的功能，降低车主端的使用难度，提升上手度。另外，当司机命中某些辅助策略时，后端可通过语音助手直接触达司机，询问其是否需要使用相应功能，解决一些司机可能需要但无法表述或不知道如何使用的问题。

情感关怀

长时间的工作很容易对司机心理造成较大压力，而对乘客或客服倾诉又容易引发其他问题（如乘客投诉、占用客服资源等），语音助手则可以为司机承担一个情绪宣泄出口的角色，司机可与其进行日常闲聊、对话，获取每日资讯、天气情况等，以疏导一些轻度的心理问题。

主动或因策略而被动触达的引导帮助，可以在司机遇到问题不知所措的情况下很好的将其解决，避免因此导致IPO进线，甚至更严重问题的发生。

▍1.2.2 智能语音助手的涉及场景与相应功能

非订单场景

①语音唤起；②出收车；③司机听单问题告知与后续操作推荐（听单诊断与听单指引）；④开启自驾导航；⑤联系客服；⑥天气、奖励、到账、疲劳等提醒；⑦放松活动推荐——闲聊、游戏、广播、助手养成等。

订单场景

①语音唤起；②订单状态提醒；③司乘语音沟通，包含语音识别与消息发送；④安全与特殊情况报备；⑤联系客服等。

▍1.2.3 智能语音助手的独有特色

拟人定制化

支持名称、声音、性格、司机称呼、播报内容的定制。

司机全使用周期陪伴性

司机从新手到退出全使用周期的形象与功能陪伴。

唤醒方式多样

支持主动播报与司机唤醒两种方式，使用更多方向发现司机问题并给出建议。

2. 

总体设计

▍2.1 旧有语音交互架构

▍2.1.1 交互架构图

图2.1 旧版语音交互架构图

▍2.1.2 设计思想与特点

在智能语音助手开发前，车主端语音交互功能大体以图2.1的方式构建，主要依据是：

• 需要司机语音交互的语句比较固定
  从识别速度考虑，使用离线识别库代价较小，效率较高（后期个别功能的识别要求已有宽泛化趋势，因此AI离线识别库开始部分转变为AI API）。

• 独立需求实现的功能比较专一简单
  因交互结果要实现的目标是固定的，故可预置固定的命中关键词，之后为其配置后续需要进行的操作即可。

• 可交互和使用时间较短
  这些功能往往只在特定时间内需要与司机进行交互，用完即销，不容易和其他交互功能以及行程录音产生载入和使用冲突，因此仅需在初始化时判断当前收音通道再进行设置即可。

• 没有特定的形象展示形式
  分散的语音交互往往是因为一些前置组件的展示而发生，理论上，这些组件在不依赖语音交互的情况下也可以独立使用，两者并不具备互相绑定的关系，因此实际上，这些交互功能没有自己的组件展示能力。

▍2.2 智能语音助手交互架构

▍2.2.1 交互架构图

图2.2 智能语音助手交互架构图

▍2.2.2 设计思想与依据

表2.1 智能语音助手架构需要解决的问题与思路

▍2.2.3 人类仿生学角度的智能语音助手架构

实际上，智能语音助手的设计架构可以完全类比到人类的神经系统。

将图2.2中：

• Voice Input、被动推送Push等看做“感受器”（接收外来信号的器官，如眼睛、耳朵）

• 音源切换控制器看做“中枢神经”（保证信号正确传输，在多种感知到来时选择最重要的部分）

• SDK Encapsulation看做“语言中枢”（将信号概括为基本语义）

• 业务API看做“大脑”（负责解释语义并对其作出相关的反应指令）

• Presenter看做“神经中枢”（将语义封装传递给大脑；之后从大脑接受指令，解析后再传出到相应器官）

• View、Client可做动作（语音播报、页面跳转等）看做“效应器”（接收反应信号的相应器官，如嘴巴、双手）

• 灰度控制域（Apollo控制域）看做“规则”（限定神经系统处理的外在要求）

因此，图2.2的智能语音助手交互架构图，从人类仿生学角度可以理解为如图2.3的另一种表现形式：