语音助手——DM——分发和排序_dm分发和排序

        这一章我们来讲一下语音助手中的DM（对话管理），之前讲过，DM的主要功能为多轮会话以及技能的分发和排序，这里先来讲一下技能的分发和排序。

为什么要做分发和排序：

        为什么要做技能的分发和排序呢，这和语义的识别有关，很多同学可能会这么认为：“用户的会话都是有意图的，所以一句话就应该有一个确定的语义，只要场景分类和意图识别做的好，不应该涉及到技能的分发和排序”。这么想其实也没错，但是有一点需要注意，这个条件成立的前提有四个：

1、用户所说的话被ASR准确翻译过来，没有误收音或者误识别。比如：

        用户想表述的query：“定一个7点的闹钟叫我起床”。

        但是由于ASR收音中断，导致话术被截断：“定一个7点”， 或者由于ASR误收音导致多收了一些环境音：“定一个7点的闹钟别吵安静点叫我起床”，或者由于ASR误识别导致得到的query出现错字：“定一个7点的脑中叫我起床”。 对于这些问题，利用query纠错可以在一定程度上解决问题，但是并不能解决全部的问题，所以错误的话术就会影响到语义的理解，导致无法准确识别语义。

2、助手能够准确知道用户说这句话时所处的状态，包括设备的状态，上文历史的状态，甚至心理的状态。比如：

        用户表述的query为：“播放无名之辈”

        这个话术，如果没有任何上文信息或者设备状态信息，很难判断用户是想播放音乐还是播放视频，因为“无名之辈”同时存在同名的音乐和视频。如果用户上文说：“播放音乐”，此时再说：“播放无名之辈”，则大概率是想听歌，如果用户当前处于视频APP界面下，此时说：“播放无名之辈”，则大概率是想看电影。那么如果说确实没有上文信息或者设备状态信息，那么这句话该怎么执行呢？这里就可以结合知识图谱热度信息，进行结果的排序。

        再比如，用户表述的query为：“成都”。

        “成都”，既是一个城市，也是一个歌名，那么要出什么结果呢？大家可以思考下。

3、用户一句话可能存在多个语义：

        比如用户表述的query为：“我想去北京，帮我买一张机票，顺便查一下那里的天气”

        一般我们设计的BOT，其职能都是相对独立的，比如闹钟BOT只负责闹钟相关的技能，天气BOT只负责天气查询相关的技能，出行BOT只负责出行相关的技能。当然，有些相似的技能我们可以将其放到一个BOT中执行，但是仍会保证技能的独立性。可以想象，如果将上面用户的query识别为一个技能，同时执行买机票和查天气，那么各种不同的技能组合是非常非常多的，所以技能的独立性很重要。所谓技能的独立性，就是一个技能负责执行一个动作。

        那么问题就来了，如果将一个具有多个意图的技能，准确的分发给对应的BOT，然后将各个BOT的结果，进行组合然后返回给用户，使其能够按照用户的预期去执行呢？这也是DM需要做的事情。所以说，所谓的排序，并不一定是指排序后只给出一个结果，也可以是将不同的结果按照执行优先级排序，让客户端去顺序执行。

4、第四点是一个比较现实的问题，那就是往往分类模型和意图、槽位模型等等的准确率和召回率都是有限的，并不能做到百分百。

        一个语音助手，可以有40+场景，每个场景又有3-10个不等的意图，每个意图又有5-10个不等的槽位，所以这对于模型的架构设计和效果都是很大的挑战。为了能够尽量召回所有可能的结果，分类模型就会有多标签模型和单标签模型，一般来说，场景分类模型都是多标签的，所以对于一句话就可能召回到不同的场景中。比如：“我想去北京”，场景分类模型会同时给出：导航、打车、旅游这几个标签。

如何进行分发和排序：

        基于上面的原因，DM的分发和排序就显得尤为重要，DM的分发要能够保证把这句query分发给所有可能能够执行的BOT中，各个BOT自己进行处理，得到各个BOT反馈的结果后，DM的排序又要能够准确的将最终符合用户预期的结果返回给用户。下面的例子展示了DM分发和排序的主要过程：

 

        上图中虚线部分分别为：Context（包含了历史上下文，设备上下文），QU（QU层的结果），BOT（系统支持的各个子BOT），实线部分分别为：分发（根据Context和QU的内容，决定分发激活哪些BOT），排序（拿到各个BOT的结果后，再次根据Context和QU进行排序）。

举个例子，当用户输入query：“我想去北京”

1. 经过QU模块拿到query的基础语义分析结果，比如文本分类结果、NER结果，语义角色标注结果等等
2. 同时经过Context模块拿到历史信息和设备信息，比如当前用户正处于哪个APP界面下，是否正在听歌，闹钟是否正在响，上一轮对话说的是什么等等。
3. 然后进入分发模块，分发模块中会综合所有信息，决定分发给哪些BOT，例如：文本分类中包含travel，则分发给travel_BOT，用户正在播放音乐，并且这句话较短，符合单实体的特征，则分发给music_BOT，等等。在这个例子中，共分发了4个BOT，同时说明了分发原因。
4. 各个BOT收到请求后，内部进行信息处理，给出各自的结果，比如这里的Map_BOT给出了action=navigation，认为可以帮助用户执行导航，Travel_BOT给出了search_train，认为可以帮助用户购买火车票，Taxi_BOT给出take_taxi，认为可以帮助用户打车，Music_BOT给出play_muisc，因为搜索到了这首歌。同时各个BOT会给出各自结果的置信度，关于各个BOT是如何给出结果的，以及置信度如何确定的，后面我们会在讲BOT内部设计时讲到。
5. 有结果的BOT，会进入Rank模块进行排序，这里会综合Context信息、QU信息、用户画像、产品策略、BOT置信度等等特征进行综合排序，比如这个例子中，排序后最终结果为navigation，其依据可以是，Musci_BOT和Taxi_BOT分数较低，而分数相同的Map_BOT和Travel_BOT，则根据用户使用习惯、产品策略等进行排序。当然，也可以将所有可以得到的特征，放到XGboost中进行排序，但是这一般用于问答型的助手中，而在指令型的助手中，使用策略和规则来排序更常见。

一点想法：

        上面讲到，分发的依据可以有很多，对于DM的分发来说，其标准可以为：“只要认为有可能，我就会分给你”，当然在这个标准下，我们还是希望能够分发的越准越好，不然压力就会给到排序模块。

        随着语音助手覆盖的垂类和技能越来越多，各个BOT内部的机制也随着产品需求变的越来越复杂，甚至会有专有的深度学习模型来进行处理，这就导致各个BOT内部的识别机制并不是统一的，那么就会暴露一个问题：“如果仅仅依靠各个BOT返回的分数进行排序，那么各个BOT的分数是否可信呢？如果某个BOT耍流氓（或者由于其内部的模型特性导致给出的分数过高），将所有返回结果的置信度都设置为1，那么DM就要百分百都出它的结果吗？”。这就要求各个BOT能够尽量按照统一的标准来设计，当然这对于架构的要求就会比较高。另外一点，就是DM要有自己的排序标准，依据其能够获得的所有信息进行排序。 当然，这又是一条很长的路。。。