桔妹导读：基于网约车司机的职业特性，帮助与指引司机在各类复杂的场景下更安全、便捷地完成工作，并尽可能疏导与减轻他们因长时间处于封闭环境下的心理压力，一直是滴滴发力的一个方向。但现有的一些途径，如规则展示、人工客服等，可能存在着司机被动接收信息成本较高、因客服处理速率引发其他情况等弊端。因此，我们在将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的另一种表现形式：

3. 

细节设计

▍3.1 灰度控制域

一个完备的灰度开关设计，不仅可以在必要时对功能进行开关量操作，更可以使同一功能在不同场景下实现差异化使用。针对以下智能语音助手的场景差异化需求：

• 总体使用开关控制

• 分场景使用开关控制

• 分场景可使用功能控制

• 适配对应场景特点配置基础参数

灰度控制的部分参数与分组形式，如图3.1。

图3.1 智能语音助手灰度控制域示意图

其中，引导播报的优先级规则为：

优先级规则1

• 播报优先级共分为5级，1级最低，5级最高；

• 若正在播放低优先级播报时，到来高优先级播报，则始终打断低优先级播报，同时，低优先级引导播报后的预定交互将被取消；

• 若正在播放高优先级播报时，到来低优先级播报，则判定低优先级播报等级，若低优先级播报等级为：2、4级，则在高优先级播报播放完成时，排队播放低优先级播报；1、3级，直接丢弃低优先级播报，同时，低优先级引导播报后的预定交互也被丢弃；

• 若正在播放播报时，到来同优先级播报，则判定到来播报等级，若到来播报等级为：2、4、5级，则在当前播报播放完成时，排队播放到来播报；1、3级，直接打断当前播报，同时，当前引导播报后的预定交互也被丢弃。

以此设计方案配置的灰度控制域，可以很好地满足智能语音助手“交互场景多样”的特点要求，为其灵活控制功能及A/B测试配备了充要前提。

▍3.2 音源切换控制器（Android版本特有）

与初期语音交互功能不同，智能语音助手可覆盖的最大范围是车主端全使用周期，基于这个特点，载入智能语音助手时必须要考虑两个问题：

【问题3.2.1】

• 行程录音冲突问题

  行程录音作为保障滴滴行程安全的中坚手段，于车主端内处于一个需要最优先保证其正常运行的优先级高度。在Android系统中，同一时间内，只允许有一个录音进程占用其收音通道。而智能语音助手在行程中、行程后延时录音阶段，都极可能会与行程录音产生抢占收音通道的问题，因此为了保障行程录音的功能正常运行，既需要特别处理好此冲突，同时还应该使智能语音助手在这些场景中能顺畅接收到司机的语音数据。

【问题3.2.2】

• 与既有语音功能的收音冲突
  

  在保证行程录音功能正常运行的基础上，智能语音助手由于覆盖全流程，势必会与已上线的其他语音功能使用与时机上产生交集。因此，此处还需要处理好不同语音交互功能与智能语音助手的使用优先级，确保在同一时间内，只会有优先级较高的语音交互功能可以接收、响应司机的语音数据，或令两个同优先级的语音交互功能可以同时收音。

为了解决以上两个问题，为智能语音助手设计了其伴生系统——音源切换控制器。

音源切换控制器的雏形，是早期语音交互功能的一个根据行程录音状态切换收音源的逻辑。该逻辑可以根据当前行程录音存在与否，切换两种接收音源方式：

a. 当行程录音关闭时，由语音识别SDK直接开启收音通道，接收司机语音数据

b. 当行程录音开启时，将行程录音的分片数据复制一份，把复制品通过语音识别SDK的接收接口，传送司机语音数据到语音识别SDK

这个逻辑虽然解决了大部分情况下与行程录音的冲突，但该方式在智能语音助手中使用时的弊端比较明显：

【问题3.2.3】

• 由于行程录音的开启需要一定的时间，因此在智能语音助手在载入时，接收到的录音状态可能并不是正确的值

  
  如：由于行程录音未完全开启，语音助手载入时获得的状态是行程录音关闭，此时智能语音助手将直接占用收音通道，之后当行程录音开启时，将发现录音通道已被占用，因此弹出收音冲突的提示，并导致全程行程录音不可用。

【问题3.2.4】

• 即使同时有多个语音交互任务运行，但语音识别SDK接收语音数据时，其底层仅支持接收一份录音分片复制体，若重复传递，将导致数据重叠，导致识别率降低

  
  如：当前“语音报备”功能和智能语音助手功能如都在行程中页面全程开启，若两个识别任务在初始化时都各自复制一份行程录音分片，那么语音识别SDK将会收到两份语音数据，使得两个功能在识别语音时成功率都大幅下降。

因此音源切换控制器在切换逻辑的基础上，围绕几个弊端的解决，进行了大幅变更和优化。

总体上，音源切换控制器的工作状态分为3个阶段：

▍3.2.1 载入阶段

音源切换控制器在载入阶段的工作流程如图3.2所示：

图3.2 音源切换控制器——载入阶段流程图

在该阶段主要解决的问题是【问题3.2.3】， 旧有的判断逻辑是根据当前的录音状态来判断，而在载入阶段，则是以当前应处于的录音状态判断，即使行程录音因开启时间过晚有延迟现象，智能语音助手也不会出现提前抢占收音通道的问题。

其中，录音标记在此阶段的默认值为false，但当以下两种情况发生时，此值会有变化：

a. 重新载入时，即当重新开启收音时，将根据音源切换控制器在本次交互任务中，标记收听阶段的赋值决定

b. 有【问题3.2.4】的情况发生时，该字段的值将由音源切换控制器在已载入的交互任务中，标记收听阶段的赋值决定

▍3.2.2 标记收听阶段

本阶段的主要能力，是在收听行程录音状态的同时，更改录音标记的值和及时重启收音（即重新进入载入阶段）。

音源控制器在标记收听阶段的工作流程如图3.3所示：

图3.3 音源切换控制器——标记收听阶段流程图

在该阶段主要解决的问题是【问题3.2.1】，音源切换控制器在这个阶段会全程对录音状态进行收听，当检测到行程录音状态发生变化时，则重新载入一次智能语音助手。其中，行程录音变为开始的这种状态变化，不仅会重新载入智能语音助手，还会同时让音源控制器进入轮询阶段（轮询阶段是一个独立的阶段）。

• 设置预备状态的意义

  录音的回调器在实际操作过程中，可能存在回调顺序错置的问题，即在onPerformStart()后插入回调了一次onStop()，这是一次无效的回调流程，且会干扰正常的回调顺序：

  onPerformStart()→onStop()【异常调用】→onStart()→onStop()这将会导致行程录音真正开启时，收音通道可能已被智能语音助手因被调用过onStop()而占用，仍然造成【问题3.2.1】。

  此次异常回调应该被舍弃，因此，此处设定除非由onStart()解锁预备状态，否则将之后回调的onStop()视为无效。

• 对进入行程中页面动作的收听可以考虑这样的情况，智能语音助手由一个没有行程录音的页面，忽然转换到会开启行程录音的页面，【问题3.2.3】要解决的是行程录音载入过慢的情况，但若是行程录音载入过快，以致于前一个页面还没有来得及释放收音通道，这将仍然造成【问题3.2.1】。因此，需要对进入行程中页面前的动作做出准确的预判，当该前置动作发生时，立刻停止各非行程中页面中智能语音助手的收音，为行程录音让出收音通道。

• 延迟动作的意义
  在智能语音助手中，延迟动作体现在两个方面：

• • 载入时间延迟

  • 音源控制器的onStop()回调停止动作延迟执行

理论上，按照以上逻辑，可以保证智能语音助手与行程录音不会形成收音通道冲突。但在某些机型上由于系统本身会出现卡顿，可能会造成两次行程录音快速切换时（连续接单的情况下，上一次行程录音停止后将很快开启下一个订单的行程录音），录音回调不及时，导致智能语音助手在载入时使用了错误的录音标记，从而最终造成抢占录音通道的【问题3.2.1】，因此，适当的延迟载入以及接收到onStop()回调后延迟执行停止动作，虽然会造成极短的时间内语音助手收音不可用，但从需要最优先保证行程录音正常运行的原则出发，牺牲较小的代价可以更多地降低此类状况的发生，是切实可行的方案。

▍3.2.3 轮询阶段

轮询阶段是相对独立于前两个阶段的一个步骤，只要标记收听阶段通知其开始，不需要顾及当前是否重新了进入载入阶段，仍可正常运行，直至不满足轮询条件为止时自动结束。

音源控制器在轮询阶段的工作流程如图3.4所示：

图3.4 音源切换控制器——轮询阶段流程图

在该阶段主要解决的问题是【问题3.2.2】和【问题3.2.4】，轮询阶段又可分为两个先后顺序的轮询：录音分片创建轮询和录音分片数据传输轮询。

3.2.3.1 录音分片创建轮询

本阶段轮询有两个功能：

a. 初始化创建该交互任务（收音任务）对应的行程录音的录音分片复制体，若创建复制体失败，重新创建，直至创建成功，同时开启与行程录音的数据通道

b. 当该任务在下一个轮询中已获得传输权，若因行程录音SDK复制出现错误，导致连续N次复制体中的语音数据为空，则重新运行该轮询，并清空累计次数，直至获得新的可用的录音分片复制体

无论以上哪种情况，在本轮轮询结束时，将获得一个有效可用，并和本次交互任务绑定的、可随时复制数据的录音分片复制体。

3.2.3.2 录音分片数据传输轮询

本阶段轮询具有以下功能：

• 当不同的交互任务（收音任务）同时开始收音时，该轮询确保只有先进入的任务可以获得传输权。而未获得传输权的任务，将持续在此轮询阶段等待，直至其他任务释放传输权，再抢夺传输权复制和传输录音数据

传输通道锁保证了同一时间只会有一个交互任务的绑定录音分片复制体可以复制行程录音数据并将其传输到语音识别SDK中，同时对复制体内数据的有效性判断可以确保始终传递给语音识别SDK的数据是可用的，保障智能语音助手在与行程录音共存的情况下，司机语音数据的稳定传输。

当交互任务结束时，会将与其绑定的分片的状态置为不可用，在轮询过程中若检测到分片不可用时，即会结束本次轮询，同时在结束轮询时，会检查本任务是否持有传输权，若持有将释放，以供其他仍在运行的交互任务抢夺。

以此可见，轮询阶段保证了同一时间内，仅会有一个交互任务的有效录音分片复制体传输到语音识别SDK，可彻底解决【问题3.2.2】与【问题3.2.4】中的录音数据重复传输问题。

▍3.2.4 收音阶段播报干扰问题的解决（两端共有问题）

在智能语音助手上线后，通过对大数据和实际效果的分析，还发现了新的问题：

【问题3.2.5】

• 收音阶段，很容易接收到其他播报的播放而干扰收音，导致提高了此次收音的无效概率

在车主端中，虽然所有的播报都会遵循【优先级规则1】来执行排队、打断或舍弃的动作，但是“收音”这个过程并不属于“播报”的范畴，若出现以下情况，收音阶段就会将播报播放的声音带入语音识别SDK中，干扰识别结果：

a. 播放引导播报时，恰好有应排队在引导播报后的优先级的播报到达，此时引导播报结束后（收音阶段）就会立刻开始播放此播报

b. 已开始收音时，恰好有任意优先级的播报到达，会在收到播报的时刻立刻开始播放此播报

车主端播报众多，出现以上两种情况的概率很大。据统计，有近30%的收音会被此问题干扰，使得此次收音最终无效，司机需要重新开启交互（而若此次交互是被动触达，则可能导致无机会再次开始此交互）。因此该问题亟待解决。

针对该问题，讨论提出了三种解决方案：

【解决方案1】

• 由语音识别SDK内部自行统一识别车主端自身发出的播报（普通合成播报或语音文件播报），并对该播报进行降低音量处理

【解决方案2】

• 由播报任务/收音任务一方收听另一方的运行状态，根据另一个任务的优先级，决定是否执行本任务

【解决方案3】

• 在引导播报后，立刻播放一段防干扰音频，使得在防干扰音频报期间不会有其他非高优播报播放而产生干扰

由于语音播报SDK与语音识别SDK是同一体系内的产品，因此【解决方案1】可以更方便地、根本地解决【问题3.2.5】，但是目前的降低音量算法不甚完善：只能对普通合成播报生效，无法对可能是任意音色的语音文件播报处理，且能有效降低的音量有限。另外，此方法要求在解析语音数据时再增加一个过滤过程，会增加更多的时间和空间消耗，整体语音识别时性能占用更大。

【解决方案2】实现比较复杂，且容易遗漏场景；互相收听比较耗费资源，同时较难实现收音后继续播放排队条件的其他播报。

相对比，【解决方案3】几乎不对性能有额外要求，并且可以在有效过滤普通合成播报和语音文件播报的前提下，更加灵活地控制什么样的播报可以在收音阶段中播放，是一种实现方式简单又能达成更高效率的方案。

图3.5 收音阶段AI SDK集的工作流程图

在使用【解决方案3】后，实际收音阶段中AI的两个SDK工作流程如图3.5：

从图3.5中可以看到，当引导音播报结束后，开始播放一段较长时间的防干扰音频播报，并同时开始语音识别SDK的收音阶段。

从语音识别SDK的方面看，有几个行为会结束收音阶段：

【中止收音规则】

1. 没有语音输入达到最长无声收音时间，取消此次收音

2. 有语音输入、未达最长收音时间且被判断为语音输入停止时，之后进入语音数据的解析阶段

3. 因【「防干扰音频」中止播放规则】4（见下）打断空白音频时，取消此次收音（不进入语音数据的解析阶段）

4. 有语音输入且连续输入达到最长收音时间而强制停止时，之后进入语音数据的解析阶段

而从语音播报SDK的方面看，当开始播放空白音频播报时，有几个行为会结束此播报的播放：

【「防干扰音频」中止播放规则】

1. 因【中止收音规则】1取消收音收音时

2. 因【中止收音规则】2和4停止收音时

3. 达到空白音频的结束时间时

4. 被高优型（符合【优先级规则1】打断空白音频播报的播报优先级）播报打断时

空白音频播报结束前，符合【优先级规则1】中丢弃条件的其他播报将被丢弃；空白音频播报结束后，符合【优先级规则1】中排队条件的其他播报将依次继续播放。

综上，对【中止收音规则】和【「防干扰音频」中止播放规则】的实际实施，可完整地实现对【解决方案3】的既定思路并完成对【问题3.2.5】的解决目标。

通过音源切换控制器，为智能语音助手的使用提供了夯实的基础，满足了其“全使用周期陪伴，涵盖既有语音交互功能”的特点要求。

▍3.3 语义解析中枢

语义解析中枢是与语义解析API、智能语音助手直接连接的“神经中枢系统”，他将司机表达的基本语言信号（语义意图等）传输到大脑（语义解析API），再将大脑判断出的行为经过合理解析，用可接收的信号传递回身体（智能语音助手）。

因此，在描述中枢工作原理前，需要先定义好传输到大脑信号的基本单位——语义解析元。

▍3.3.1 语义解析元

语义解析元，是输入向（司机→语义解析API）的最小单位，每一次司机语义的表达，都需要以该格式才能传输到语义解析API，其基本结构如图3.6：

图3.6 输入向的传输最小单位——语义解析元

以下就语义解析元中包含的5种信息进行具体解释：

1. 请求来源向语义解析API传输数据的来源有3种：语音识别SDK（文字和语言解析中枢）、被动推送Push（其它感官）、解析接口自身（大脑本身），在语义解析API解析每次意图请求时，需要事先判断清楚本次请求是由何种媒介触发，由此作出最基本的可回应圈定范围：不同来源可做出的反应可选项并不相同。因此，请求来源的设置保证了“大脑对信号的最大解析范围”。

2. 语义意图语义意图可以说是语义解析元中最不可或缺的内容，当语音识别SDK将司机所说的话语初步解析为一个语义单位（语义意图字符串）后，语义解析元即将其封装好，传输到语义解析API由其来作出具体应有的回应。因此，语义意图的设置保证了“大脑对信号的最基本解释能力”。

3. 触发场景智能语音助手载入的页面位置不同，其来源也将不同。不同来源的语音助手可使用的功能范围不同，根据灰度控制域的配置已在车主端本地做此限制，但若是在某个场景发出符合该场景的功能请求，但在另一个场景时才收到了此请求对应的回应，则需要对此次回应做出过滤操作。因此，触发场景的设置保证了“大脑传输回的数据只在可接收信号的身体位置接收处理”。

4. 流程标识从请求来源来看，解析元传输有一种是来自于解析接口自身（大脑本身）的，智能语音助手之所以可以作出多轮互相关联的与司机的交互，流程标识是必不可少的元素。流程标识为一轮对话中的多次提问/回答标注了同一Tag，确保此轮对话的连续性，并可在某次提问/回答中依流程标识的特点，增加/减少司机可表达的语义范围（即“联想能力”）。因此，流程标识的设置保证了“大脑对交互的连续保持能力与联想能力”。

5. 扩展槽位司机表达的语义，有些情况下只通过语义意图，往往很难穷举出所有可能的实际表达含义。如“我要报备”（REPORT）意图，在不同语境下，要表达的报备目的并不相同，可能是“醉酒报备”（REPORT-DRUNK），也可能是“取消订单报备”（REPORT-CANCEL_ORDER）；再如，“你真棒”（REWARD）意图，在积极语境下，表达的是“夸奖”（REWARD-PRAISE）的意思，而在消极语境下，反而表达的是“贬损”（REWARD-DISPRAISE）。扩展槽位可将同一大类意图下进一步详细的信息，写入到该字段中，避免无限扩展意图本身的范围，可以更精细地确定司机的语义。因此，扩展槽位的设置保证了“大脑对言外之意与补充信息的理解”。

语义解析元中的5种信息互相补充，是语义解析API解析所需信息的集合。

另外，在每次请求语义解析API时，若触发场景为行程中页面，除语义解析元外一般还会额外传递一个“当前订单号”的信息。此处传递该字段，是为了帮助语义解析API判断当前订单场景，并更快速地做出对同一交互请求在不同订单下的不同回应。

语义解析中枢的其中之一功能，即是将各处零散的信息整合成语义解析元，其后进行的阶段就是语义解析中枢的核心逻辑。

▍3.3.2 语义解析中枢的核心逻辑

图3.7 智能语音助手语义解析中枢

图3.7是智能语音助手语义解析中枢的整体运行流程，中枢整体可分为3个区域：外围区域、解析元构建工厂区域、解析中枢核心区域。

3.3.2.1 外围区域

外围区域主要封装一些基础数据结构，并设置若干对接语音识别SDK、语义解析API和智能语音助手的接口方法，可概括为是数据的传输通道。

3.3.2.2 解析元构建工厂区域

解析元构建工厂区域的主要功能，是将从各个来源触发的语音交互请求，封装成语义解析元，以供核心区域请求语义解析API时使用。

3.3.2.3 解析中枢核心区域

核心区域的解析流程，大体可以分为两个步骤：请求步骤和回应解析步骤。

1. 请求步骤

   
   解析元构建工厂区域的出口有两个：一个是由于信息缺失或不符合校验条件，导致语义解析元封装失败，通过此出口后会将此次请求取消，并重置智能语音助手组件，使其恢复重新开始收音的状态；另一个是信息完整并通过校验后，产出完整的语义解析元，发起一次语义解析API的请求。

2. 回应解析步骤

   
   语义解析API请求后回应的结果，可以称之为直接结果集，即直接输出向（语义解析API→司机）的最小单位，表示本次请求后，语义解析API可立即对该次请求作出的同步回应。

如表3.1所示，在设计直接结果集数据结构时，预先设定了4种行为，对应了4个区块：

表3.1 直接结果集的行为性结构

直接结果集中的4种行为，在一次请求中并非只能执行其中一种，而是可以任意组合同时进行的，且具备可扩展性，这样可以保证交互结果的多样性，使语音助手可实现的功能大大加强，几乎涵盖了司机在车主端可以进行的所有活动。

另外，直接结果集中的场景与流程标识存储区块，则全程携带了多轮交互中构建语义解析元所必须的几种信息，确保这种情况下语义解析的连续性，是流程标识在多轮交互中的直观体现：

表3.2 直接结果集的非行为性结构

语义解析API请求后，除了会触发直接结果集外，有时由于API侧需要完成耗时操作后才能对该次请求作出回应，因此对此异步结果，还会通过被动Push推送到车主端，另外，一些平台的后台策略，也会主动直接通过该途径向司机发起Push（详见3.4.1.2节）。通过这种途径发起的语音交互，会统一重新进行一次语义解析API的请求，利用此请求的返回（主要是语音播报交互区块）获得详细的交互信息和方式，其后的流程与司机发起的语音交互流程基本一致，不同点也已在上文点出，在此不再赘述。

注意：对接收的语音数据，智能语音助手只会将其即时解析后处理为语义解析元用以执行指令，不会对其做持久化存储和作为其他方面的用途。

▍3.4 语义解析API（业务API）

语义解析API可以比作智能语音助手的大脑，他将概括的语义解析元信息通过内部处理，输出为具体的行动数据（直接结果集等），本节对业务API侧的解析流程进行简单的介绍。

▍3.4.1 智能语音助手的两种触发及其交互方式

通过3.3.2节可知，触发车主端语音助手主要有两种方式：车主端主动触发和平台主动触发（从车主端角度上看是被动推送Push触发），以下分别描述两种触发方式的全链路交互简略流程。

3.4.1.1 车主端主动触发

图3.8 智能语音助手车主端主动触发全链路简略交互图

如图3.8，在司机主动触发过程中，语义解析API承担的角色为将车主端从AI API处获得的意图字符串，转化为可以在车主端行动的控制型字段，经由车主端解析后，以实际的各类表现响应给司机使其感知到。

3.4.1.2 平台主动触发

图3.9 智能语音助手平台主动触发全链路简略交互图

如图3.9，在平台主动触发过程中，语义解析API承担了三种角色：

• 接收第三方服务后，转化为意图字符串通过Push通道下发给车主端，本次过程中不处理解析实际动作

  ‍‍‍‍‍‍‍‍‍

• 确认车主端接收到消息后，调用接口实际处理解析本次被动触发应完成的首次交互，将交互方式通过返回结果通知到车主端，由车主端实际执行此次交互

• 将车主端从AI API处获得的意图字符串，转化为可以在车主端行动的控制型字段，经由车主端解析后，以实际的各类表现响应给司机使其感知到

▍3.4.2 语义解析API流程简述

如何将意图字符串转化为车主端可读取的控制型字段，是语义解析API的核心功能之一。

此流程可简单概括为：语义解析API将车主端传递到来的语义解析元字符串拆分后，先使用传入的触发场景创建场景信息，并使用流程标识获取流程信息；因在每一个流程标识对应的流程信息中，都维护了一个语义意图的Hit列表，故之后使用语义意图字符串与Hit列表进行匹配，匹配成功后，从4种行为数据库中分别写入行为数据，最后将车主端传入的触发场景重新携带，并把本次的流程标识与之一同封装成为直接结果集，最后下发给车主端。

综上，各车主端传入字段与语义解析API字段关系与功能如图3.10所示：

图3.10 语义解析API字段关系功能整体分析

 

以各字段为基础，语义解析API使用工厂模式，通过封装和扩充演化为不同类别，实现不同意图不同处理方法的扩展。

语义解析中枢和语义解析API的设置，以及和两者与文字和语言解析中枢之间的衔接配合，总体上完成了对智能语音助手核心功能的设计与实现，满足了本产品所需的“司机表述语义多样”的特点要求。

▍3.5 智能语音助手展示组件 —— 小滴

智能语音助手与以往语音交互功能不同之处还在于，其需要拥有一个能与其核心互相通信并展示相关内容的专属信息载体组件，在该组件上，智能语音助手同时需要突出其一个独特的形象：小滴。

▍3.5.1 小滴的阶段状态划分

小滴的展示分为几个阶段，其详细功能与动态效果示例图如图3.11、图3.12和表3.3所示：

3.11 展示回应内容前效果  

3.12 展示回应内容时效果

表3.3 小滴的阶段状态划分及其功能与动态效果示例图

▍3.5.2 小滴的组成形式

a. 按钮形态

按钮形态下的小滴区分为：可语音交互状态（普通样式）和不可语音交互状态（佩戴耳机样式），如图3.13所示：

  图3.13 小滴的按钮形态

该形态比较简单，使用静态图片资源展示即可。另外，需要在向上滑动首页卡片列表时，对小滴按钮做渐变透明处理。

b. 信息展示形态

小滴的信息展示形态组成区域可划分为4个，如图3.14所示：  

图3.14 小滴的信息展示形态及区域划分

每个区域所需实现的效果与实现技术方案见表3.4：

表3.4 小滴信息展示形态的区域划分及需实现的效果与方案

对智能语音助手展示组件的设计，将“小滴”这个形象生动地展示在司机面前，结合其独有的播报形式（智能语音助手不使用普通合成播报的方式，而采用独特的音色合成来播放播报内容），满足了本产品所需的“有特定的形象，配合动画文字形式展示信息”特点要求，是智能语音助手的“嘴巴”和“脸面”。

4. 

结语

车主端智能语音助手目前处于内测阶段，仅对报名内测司机与部分城市司机开放功能。目前仍有尚多逻辑与能力不甚完善，也还有更多的功能与性能的改进空间，因此读者在阅读本文后若对智能语音助手有任何改进意见或建议，均望不吝赐教。

我们将不断优化，期待“小滴”可以早日与各位司机们见面，帮助他们更安全和高质量地工作，以达成“贴近司机，感知生活”的功能目标。

 

本文作者

▬

团队招聘

▬

终端技术团队拥有乘客端、司机端、终端平台等技术团队，致力于打造一流的业务入口连接用户和服务，搭建安全、可靠、用户信赖的移动出行体系，通过不断创造用户价值促进业务高速发展。写一行代码，添一分美好，圆一个梦想。终端技术需要你，用技术温暖人间万千人心。这是一群有梦想、积极上进，战斗力max的成长型团队。我们直面出行中的种种问题，站在解决问题的第一线，坚定地用技术改变着出行！在这里你将参与挑战的项目，你会遇到很多技术大牛、业内大咖、论坛斑竹、行业精英，也会邂逅来自五湖四海的简单、积极、乐观的年轻伙伴们，希望你能喜欢在一起的每一天，和我们"玩“在一起，乐在一块！

团队目前热招资深Android视频开发工程师、Android开发工程师、iOS开发工程师，欢迎有兴趣的小伙伴加入，可投递简历至 diditech@didiglobal.com，邮件请邮件主题请命名为「姓名-投递岗位-投递团队」。

扫码了解更多岗位

延伸阅读

▬

内容编辑 | Hokka

联系我们 | DiDiTech@didiglobal.com