有多少人工就有多少智能

整个小爱同学的研发，应该是在 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 看起来就不像音乐了。

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

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------