小米AI

小米小爱团队负责人王刚：语音交互背后，有多少人工就有多少智能

原创  2018年04月13日 19:44:50

• 2632

整理 | Just，阿司匹林 
出品 | AI科技大本营（公众号ID：rgznai100）

【导语】近日，在英特尔与 O’Reilly 联合主办的中国人工智能大会上，小米的小爱团队负责人王刚分享了他们在语音交互技术上的进展以及面临的困境，其一是有些用户需求的处理方式仍然是“有多少人工就有多少智能”，其次对于用户行为反馈结果如何去做更好对话模型的理解问题，他希望引起学界和业界人士的重点关注。王刚希望，通过不断探索，最终能构建一个具有自主学习能力的对话系统。

以下为王刚演讲内容实录，AI科技大本营整理：

整个小爱同学的研发，应该是在 2016 年的年底开展的，在 2017 年的 3 月份，我们首次把小爱同学放在了电视中了，然后在 2017 年的 7 月份，（我们把）小爱同学放在了音箱上，然后在今年的 3 月份的 小米 MIX 2S 的发布会上，我们把小爱放到了手机里。

到目前为止，小爱同学已经在 10 多款生态链的设备里面存在了。

大概 2 年时间的研发，我觉得自己还是蛮幸运的，因为首先我们开始进入到电视这个领域，电视的场景比较单一，用户的主要需求就是搜片。除了搜片以外，其实它的一些场景，比如一些电视控制类的，都相对比较简单。

而音箱里面本身没有屏幕，所以用户主要需求是听音乐、内容类的，然后还有其它的一些娱乐类、控制类的转换，所以本身会使得这个音箱在这个（语音）领域比电视更近一步，它本身的复杂度也没有那么高。最后放在手机上就比较复杂了，这里面像音乐、视频、电台、人物等功能其实非常厉害。

因此，在各种多轮对话的场景下，怎样去把体验去做好，会面临到非常大的问题。

现在小爱同学所输出的多种设备当中，基本上可以分成三种标准形式：无屏、有屏以及触摸屏，不同的设备对小爱同学的要求不一样。

从本身的功能上来说，分出了 9 大类别，当然这不是非常严格的定义，它会不断去延伸，然后成交互形式，对应到不同任务场景下。



▌语音交互和搜索的区别

在做语音交互这么长时间之后，大家也能理解到为什么语音交互其实是跟搜索有非常大的区别。

第一，语音交互其实是完成更广泛的任务。在手机上我要给家人打一个电话，或者上一个闹钟，它本身要去完成的除了信息查询以外，还有设备控制，有内容消费、生活服务。它本身被认为是帮助用户去完成特定任务，并且不出错。而在这种情况下，搜索还是相对比较单一的。

第二，语音交互基本只有一次跟用户交流的机会。不像搜索有更丰富的展示，可以在多条结构里面进行选择。例如，语音交互对用户的话理解错了之后，用户基本上会感到很失望，就像大家经常说的是“你不懂我”，就觉得它比较傻。

第三，语音交互其实是很复杂的一个情况。首先它要考虑上下文，与用户上一轮说话方式是很相关的。比如说我想给一个同事发消息，然后它就问你要发什么消息，这时我说，“提醒我下午三点钟去开会”；或者我直接跟小爱同学说，“提醒我下午三点钟去开会”，这两件事都是提醒我开会，但一个是发消息的内容，一个是上闹钟，它跟上下文是相关的。

刚才说的是一个短期的上下文对话，它还可以再去延展，跟一个用户长期对话的上下文是相关的，智能助理在跟你不断的对话过程当中，它可以了解了比如说你家里有没有车牌，或者说你想问它限行的时候，它可以告诉你今天或者明天你会不会被限行，它可能去了解你家里有几口人，家里有没有宝宝，这样的话，可以越来越聪明地帮你完成一件事。

*第四，就是用户行为反馈*。语音交互比搜索难，搜索里面最重要的信号就是给用户的点击模型，当搜索第一天发明出来的时候，所有的搜索结果是工程师去进行的校调和排序，但只要有用户不断去用这个结果，第 1 条结果他不点开，他点了第 2 条，他一定是认为第 2 条结果肯定比第一条好，他点了第 2 条之后又点了第 3 条，那可能他对第 2 条的结果不是很满意，他觉得第 3 条可能更好。所以搜索里面通过大量的用户点击返回数据去调整搜索排序。

目前大家看到的是比较成熟的技术，用户点击反馈已经在搜索质量排序当中超过 60% 的重要性，但在语音交互这边，用户的反馈它是一种很隐式的，可能用户觉得你没听懂他，可能就会去换一种说法再问一下。

怎么样让用户反馈进入到这个模型中，帮助小爱同学去变得更聪明？实际上，目前世界上还没有看到工业界和学术界与之相关的研究成果出来。

小爱同学可以认为它是一个语音助理，一个技术集成者，不存在一种通用技术，可以去解决所有问题。所以说针对每一个领域，它所解决问题的方法，所面对的困难都是不一样的。

我主要讲三大方面，就是小爱同学整体构建时所采用的技术：第一，语音技术；第二，自然语言理解；第三，用户行为反馈。

▌语音技术

首先，就整个架构来说，在任何一个终端上，用户跟小爱同学说的话先是前端的一些信号数据，主要是声学技术，进去之后就是变成了一个纯用户的声音，通过语音识别转换成文字，然后通过语义理解，去了解用户真的想要什么，然后去服务的线上分发，最后进行语音合成，告诉用户希望什么样的结果。

具体展开而言的话，语音技术的难点，其实还挺复杂的。首先是前端包括唤醒技术、回声消除和声源定位，大家用了小爱同学，可以发现其实它在这方面其实还是有许多问题的。

第一，小爱同学唤醒还是比较容易，但经常会发生误唤醒，可能还没有说“小爱同学”，它就唤醒了，甚至你说什么小白同学、小赖同学，也可能会唤醒。

所以唤醒技术本身就很复杂，小爱同学现在已经训练有接近 1 年时间了，但做得还不是很好，其实用户还想要更多的唤醒词来去叫醒它。

当一个唤醒词我们花了 1 年的时间训练，怎么样把一个唤醒词的技术更加通用化、能让用户自定义自己的唤醒词就好了。例如我的小孩叫丹丹，我们可以直接跟音箱说，“丹丹你好”，用户有这样的需求，但我们的技术现在没有做到。

第二，语音识别。语音识别有噪音环境，声音混杂，不同的人有不同的方言，我们集成了国内所有语音技术的提供商，但现在没有任何一家有特别好的用户体验。

第三，语音合成。两年前，语音合成在整个中国一年产出的人才不超过 20 个，所以现在做语音合成的人才，在语音交互的场景里炙手可热。

语音合成里面有非常多的问题，一个是合成实体词。比如用户自己说，这个“618”要促销了，就是我们自己知道“618”什么意思，但机器看不到“618”，它不知道你说的是 6、1、8 还是 618（六百一十八），它看到的字是一样的，但是它念出来——如果说六百一十八要促销——大家就会觉得很奇异，因为它背后有很多的知识。

那么，通过知识怎么样去融合进来，做语音合成，这又很复杂，包括中英文混杂，用户情感怎么样处理，这点上其实小冰做得比较好，它的合成声音带着情感，这个技术其实目前看也是最好的。

语音识别的话，其实我们后面已经有 11 家技术供应商，来给我们提供语音识别的效果。在不同设备上，不同场景下哪一家语音识别怎么样，我们都有评测。

然后，我们也进行了一个融合策略，一个用户的语音发给多家技术提供商，有些结果譬如说有中英混杂的，可能是这家识别的好，对方言来讲，可能是讯飞识别的好，而对某些设备的厂商，它可能是另外一家提供的好。所以我们的融合策略，在不同的设备下，可以显著提升一个共同的好结果。

▌自然语言理解

自然语言理解这件事情其实还是挺难的，因为第一要素就是首先要有一个清晰的产品定位。比如，用户直接跟音箱说雷军，和跟手机说雷军，可能它的意思就是不一样了。

在手机上，我们输入雷军直接就是人物介绍，但在音箱上直接说雷军，比如小爱同学，就直接蹦“ Are you OK ”了。因为我们认为音箱是一个无屏设备，所以它说雷军的时候，就直接放雷军的歌，可能用户感觉很好。

首先要有一个清晰的产品定义。

自然语言理解的背后我们认为这个 query 应该给什么样的用户结果，使得这个产品给用户的体验最好。

当用户将一个 query 发给小爱同学的时候，它有 4 种应答方式：

1.我们有一个叫内置垂域，比如查天气、定闹钟都是小爱同学内部自己的团队来去定义的。

2.我们会把这个能力开放给设备开发者，包括我们自己的设备，譬如在手机上说打开手电筒，就是设备所独有的，它不是一种通用能力。譬如说一个电视，连接 HDMIE，我们相信小爱同学自己是做不了的，所以我们就把这个能力开放出来，交给设备开发者，由他们自己去定义。

3.开放平台。大家对这个行业了解一下就应该知道，它本身是一个操作系统，它上面可以有无数多的 APP，很多的开发者愿意在小爱同学上面去开发 APP，譬如像开发菜谱，开发成语接龙、开发冒险世界这种语音交互类的这种游戏，在亚马逊的内容已经有接近 3-4 万了，在小爱同学上面现在有 100-200 种。

4.小爱的训练计划。这个我们看到大家用的最多的，第一个就是逗小孩或者逗家人，比如世界上最美的是谁啊？直接把你老婆的名字念出来，世界上谁聪明啊？把自己小孩念出来……针对自定义的去说出自己希望说的话，也就是把高度定制化的能力交给用户。

用户可以自己训练小爱，小爱刚开始运作起来也是挺傻的，但你如果有耐心去训练它，让它能够跟你作伴，这其实是整个小爱同学的一个产品。

其次，就是垂域的深度优化。

垂域理解就是每一个垂域用的算法、方法都是不一样的，譬如说北京明天天气怎么样？北京明天晴转多云。单说这句话其实是一个天气类的，但你直接前头加入一下“翻译”两个字，它就变成了一个翻译类的。



下一个例子就是韩磊《南山南》，本身韩磊没唱过《南山南》，所以就把它纠错成张磊。为什么我们知道韩磊没有唱过《南山南》呢？因为它本身是带有知识库的，所以要做好这个领域的话，首先不光要知道相应的词表，必须得需要相应的知识，知道用户想找音乐，然后到知识库里去判断它到底是歌手还是歌名，看看有没有这个歌手和歌名，然后找到相应的歌给用户。

最后一个是用户闲聊的需求，例如用户问“天猫精灵怎么样”，这种 query 是很难回答的，我们也不知道怎么回答，我们这一块其实就是通过有多少人工就有多少智能的方式。把这种 query 能运营好，但我们也希望尽可能通过算法能让这个人工的方式更智能，所以后面可以稍微期待一下。

语义的垂域理解，这块还是挺复杂的，每一个垂域自己的知识库和领域都是很复杂的。要理解这种用户的复杂查询的话，一定要对后台的知识库，甚至是用户有深度的理解，所以针对视频这一块，非常简单列了一下，我们有 25 个相应的知识字段去构建知识库，只有这样的话，才能把用户复杂的查询构建好。



总的来说，小爱同学它是一个非常复杂的系统，要去融合无数的技术，技术是我们外部的合作伙伴给我们的，有些功能是我们自己内部研发的，但自己内部研发也不是一种通用的解决办法，而是针对不同类的问题来找解决办法。

我们把一些具有代表性的东西拿出来列一列，词网格其实是我们一个比较基础的自然语言理解模块，这个里面在我们的分词和词道用的非常多。

平时用户说打开卧室的灯，但是由于口音问题，或者是距离的问题，就是 AI 在识别的时候，它经常会“打开卧室壁灯”，或者“大开卧室的灯”，识别出不同可能性出来。这是语音识别的结果给 NLP 的输入，基于这个输入，我们通过词网格的方式，去寻找一种最优路径，去构建出它最优的可能性。



另一个例子是，我想看功夫电影和我想看周星弛的电影《功夫》，就功夫这个词在第一个 query 里面，它其实想表达一类电影，我想看周星弛的功夫电影，它就是找这种有功夫类的电影，然后我想看周星弛的电影《功夫》，那我就是想找名字叫《功夫》的电影，这个就要根据它前面串的和后面串的一个这种相似度，在历史的统计数据里面去找到最有可能匹配的路径，这个就是词网格。

上下文无关文法，这是一位斯坦福教授提出来的，这个在很多那个垂直领域其实是很有关系的。刚刚我们看到的词网格的模型，它本身是基于一种有限状态思维逻辑，但是上下文无关文法是有下推的思维逻辑，它会无限的去扩展，构建出现在的模型出来。譬如，亲戚计算器，不知道大家知不知道小爱这个功能：爸爸的爸爸的爸爸叫什么？小爱同学会回答：你可以喊他高祖父。我们要解决这类问题，一定要选择相应方法。

知识库的搜索就刚才说的那个韩磊唱了《南山南》的歌。我们首先要去判断这个领域去搜索知识库，然后找到相应特征，发现它可能在现有特征里，比如在歌名和歌手不满足的情况下，怎么去进行相应的匹配，从而找到一个最优的结果。



问答对匹配，比如说天猫精灵怎么样？就是说用户以后说天猫精灵好不好这样类似的说法，我们都希望能匹配到。虽然我们是有多少人工就有多少智能，但也希望在人工一定的投入下有最大的智能。

所以其实就是这种模糊匹配的技术，我们还是投入了蛮大经历去做，就是用户的 query 是这样的，那我们匹配的 query 比如小豆包漂亮吗？小豆包长的漂亮吗？我们希望它们是一个意思。这样的话，当有多少人工有多少智能的时候，可能快速的去做泛化。

但是，可以看到这里面红的这块是错误的，我想听《好想你》，然后直接匹配成一个叫“我好想你”这个 query 了。就本来是听音乐的意图，它直接匹配成了我好想你这样的闲聊了，虽然听起来好像没有差太远。

“不说再见”，是我不想跟你再见，和“不说了，再见”，其实语意完全不一样了。

字的差别非常小，而且它可能就是一些语气助词，但它的语意会完全转，所以我们希望在语意不变的情况下，去做（直接匹配），但有些情况下，是语意转的情况下，我们要及时发现。

最后，就是全局的统一策略。

我们就发现中控全局判别这件事越做越复杂。譬如，北京天气怎么样？翻译“北京天气怎么样”？对于天气而言的话，它就发现它前面多了两个词，它也不认识翻译，因为对于每一个垂域来讲，它都是局部的信息，很难去知道全局性的，它前面多了个翻译，自己的转换就不管了。

所以每个转换都是深度去理解自己的信息，但是它发现前头多了两个字的时候，它并不可能把世界上所有的知识，放在每一个垂域去做判断，所以就是尽量先理解自己的知识，然后上传给一个中控模块，然后通过全局信息去做最后的决策。

当全局决策发生的时候，我们发现每一个领域的局部信息最后要尽可能的交给中控，中控不光要维护所有的特征，而且它要维护全局的热度信息、用户行为信息等，从而更好的帮助全局判断。

譬如播放《超级飞侠》，在我们的音箱里面有 2 种选择，一种是给小孩直接放《超级飞侠》的歌，一种是找一个《超级飞侠》的故事。小孩说播放《超级飞侠》的时候，大部分的用户确实是喜欢听故事，但有些确实是想听歌。那我们怎么知道用户想听歌呢？当发现用户说播放《超级飞侠》，音箱紧接着给它放故事了之后，他会再去给它说播放《超级飞侠》的歌，他会就去纠正这句话。

通过这种方式就会发现之前的判断是有误的，也就是通过用户行为的完听率，去探索怎么样用用户行为来帮助 AI 更好的理解人话。

就像《超级飞侠》这个歌如果用户耐心的听完了，我们就认为他对这个歌的投票是满意的，但如果他听这个歌没有听完，我们就认为他对这个歌不满意，也就是我们定义的完听率。

通过完听率去判断用户是不是对这 query 满意，所以当播放《超级飞侠》这个歧义的问题，我们希望通过用户后期的行为数据，来判断、纠正我们怎么样去更好的理解这句话。

另外一个就是多轮的对话管理。譬如播放一首歌，然后用户说第 2 个，他其实想说第 2 首歌；我想说导航到附近麦当劳，它说为你找到以下附近的麦当劳，你想它说直接第 2 个麦当劳。所以我们希望在中控里面，有一种全局的、多轮对话管理来保证用户的持续对话。

▌用户行为反馈

最后是用户行为反馈，就是怎么样根据用户的结果去指导我们去做更好对话模型的理解。它在搜索里很有用，但在语音交互系统里，其实是一个非常值得去研究的问题。我特别希望不管是学术界还是工业界能高度关注的这个问题，因为这是一个崭新的领域。



现在用户对结果的满意和不满意，在搜索里面是非常直接的。我跳过这个结果，可能就表示对这个结果就不喜欢，但在语音对话里，就像我们正常的对话里，我可能跟你聊了两句话不投机，但我可能还是比如说嬉皮笑脸的就走了，你可能都不知道我到底对你的话投不投机。

或者假如我内向一点，也不是那种要攀仰别人的人，我跟你聊着就可能没有主动表达我对你的赞赏，这个时候用直接对话系统去表示对你的满意或不满意，其实是很隐讳的，这件事情一直是困扰我们的一个难题。



现在，我们在内容类的上面做了一点工作，就是通过首条完听率来判断它有没有把这首歌理解的对不对，我们也看到了一些数据，确实发现当我们判断出一些音乐意图，但是完听率又比较低的时候，这些 query 看起来就不像音乐了。

所以我们就通过不断的探索研究、构建具有自主学习能力的对话系统，这是我们的目标和理想，但现在看起来还是很难的。

展望未来 5-10 年，我相信语音交互在每个人的家里都会是成为你非常得力的助手，语音交互的接收终端，现在可能是我们的手机、音箱，未来你家里面一扇镜子、闹钟都可能成为终端，然后你随时需要吩咐它办什么事情，都可以去帮助你，提醒你做重要的事情。我们希望通过语音交互给每一位用户带来最好的体验。