从“连接”到“交互”——阿里巴巴智能对话交互实践及范式思考

导读：传统互联网时代体现出来的更多的是“连接”，现如今，随着智能设备的增加，人和设备逐渐走向“交互”，那么，交互时代，人机之间如何有效通过自然语言实现智能对话交互已经成为开发者面对的直接问题，本文阿里巴巴iDST 自然语言理解和人机对话负责人孙健将带来他们在这个领域的探索和实践分享。

互联网正在从“连接时代”走向“交互时代”

纵观传统互联网时代，如果用一个词来总结和概括的话，“连接”这词再合适不过了，传统互联网时代主要建立了三种连接：第一，人和信息的连接；第二，人和人的连接；第三，人与商品服务的连接。第一种连接成就了Google和百度这样的互联网巨头；人和人的连接成就了Facebook和腾讯这样的互联网公司，人和商品服务的连接，成就了Amazon、阿里巴巴、京东这样的巨头。从这个意义上看，传统互联网最典型的特征就是连接。

过去3-4年，我们可以看到，互联网其实发生很大变化，交互的设备已经从PC和智能手机延伸到更广泛的智能设备。智能设备的快速发展正在改变着人类和设备的交互方式。不难看出，无论是智能设备的发展和普及，还是用户的接受度都在快速增长，都促使人和设备之间交互方式的巨大改变，我们已经进入“交互时代“。

正在发生的变化

那么，交互时代，人和设备究竟如何通过自然语言对话展开对话交互的呢？首先，对话交互的特点，我认为主要有以下四点：

• 第一，人和智能设备的交互一定是自然语言。因为对于人来说，自然语言是最自然的方式，也是门槛最低的方式。

• 第二，人和设备的对话交互应该是双向的。

• 第三，人和设备的对话交互是多轮的。为了完成一个任务，比如定机票，这里会涉及多轮交互。

• 第四，上下文的理解。这是对话交互和传统的搜索引擎最大的不同之处，传统搜索是关键词，前后的关键词是没有任何关系的。对话交互实际上是要考虑到上下文，在当前的上下文理解这句话什么意思。

从连接到对话交互，一个本质的改变是什么？举个例子，比如淘宝网首页，抛开内容，其本质就是链接和按钮。对于用户来说，无论是点击链接还是按钮，他的行为完全是由产品经理定义好的和是完全确定的，所以它是一种受控、受限的行为，这种方式并不能确保好的用户体验。

而对话交互，用户可以说任何内容，天文、地理，包罗万象。我认为这背后的本质改变就是从“确定性”转变为“不确定性”。实际上，后面无论是算法还是交互设计，基本上都想办法提高语言理解的确定性或者是降低交互设计的不确定性。

阿里巴巴在智能对话交互方向上的进展和实践

下面介绍下阿里巴巴在智能对话交互方向的进展和实践。先看对话交互逻辑的概况，传统的对话交互大概会分以下几个模块，从云识别把语言转成文字，语言理解是把用户说的文字转化成一种结构化的表示，对话管理是根据刚才那些结果来决定采取什么样的合作。在语言设置这一块就是根据action生成一句话，通过一种比较自然的方式把它读出来。

对话系统架构简图

我认为现在人机交互和传统的人机交互一个主要不同点就在于数据和服务。随着互联网的发展，数据和服务越来越丰富，那人机交互的目的是什么？归根到底还是想获取互联网的信息和各种各样的服务。

语言理解简单来说就是把用户说的话，转换为一种结构化的语义表示，从方法上会分成两个模块：意图的判定和属性的抽取。

比如用户说：“我要买一张下周去上海的飞机票，国航的“。第一个模块就要返回理解，用户的意图是要买飞机票，第二，使用抽取模块，要把这些关键的信息出处理出来，出发时间、目的地、航空公司，从而得到一个比较完整的结构化的表示。 

自然语言理解

那么，人机对话中的语言理解面临哪些挑战呢？我总结为四类：

• 第一，表达的多样性。同样一个意图，不同的用户有不同的表达方式。那对于机器来说，虽然表达方式不一样，但是意图是一样的，机器要能够理解这件事情。

• 第二，语言的歧义性。比如说，“我要去拉萨“，它是一首歌的名字。当用户说：“我要去拉萨”的时候，他也可能是听歌，也可能是买一张去拉萨的机票，也可能是买火车票，或者旅游。第三，语言理解的混乱性，因为用户说话过程当中，比较自然随意，语言理解要能够捕获住或者理解用户的意图。第四，上下文的理解。这是人机对话交互一个非常大的不同，它的理解要基于上下文。

在语言理解这一块，我们把用户语言的意图理解抽象为一个分类问题，之后，就有一套相对标准的方法解决，比如CNN神经网络、SVM分类器等等。阿里巴巴现在就是采用CNN神经网络方法，并在词的表示层面做了针对性的改进。机器要理解用户的话的意思，背后一定要依赖于大量的知识。比如说，“大王叫我来巡山”是一首歌的名字，“爱探险的朵拉”是一个视频，互联网上百万量级这样开放领域的实体知识，并且每天都会有新的歌曲/视频出现，如果没有这样大量的知识，机器是很难真的理解用户的意图的。那么，在词的语义表示这块，除了word embedding，还引入了基于知识的语义表示向量。

刚才提到了，用户说的话实际上是比较随意和自然的，那怎么样让这个模型有比较好的鲁棒性来解决口语的随意性问题呢？我们主要针对用户标注的数据，通过算法自动加一些噪音，加噪之后(当然前提是不改变语义)，基于这样的数据再training模型，这样处理之后模型就会有比较好的鲁棒性了。 

第二个模块是属性抽取，在这一块，我们把它抽象为一个序列标注问题。这个问题，神经网络也有比较成型的方法，我们现在也是用这种双向LSTM，在上面有一层CRF解码器，取得了不错的效果，但是这背后更大的功夫来自于对数据的分析和加工。

基于深度学习的属性提取

以上所述的人机对话语言理解最大的特色就是基于上下文的理解，什么是上下文？我们看一个例子，用户说：“北京天气怎么样？”，回答说，北京的天气今天温度34度。接着用户说“上海呢？”，在这里用户的潜台词是指上海的天气，所以要能够理解用户说的话需要根据上文意思来分析。针对这样的场景，我们再对问题做了一个抽象，在上下文的情况下，这句话和上文有关还是无关，把它抽象为二分的分类问题，做了抽象和简化以后，这个问题就有相对成型的解决方法了。

刚才介绍的是语言理解，下面我介绍下对话引擎。

对话引擎就是根据语言理解的这种结构化的语意表示以及对照到上下文，来决定采取什么样的动作。这个动作我们把它分成几类。

第一，用于语言生成的动作。第二，服务动作。第三，指导客户端做操作的动作。

再看一个简单的对话例子。用户说：“我要去杭州，帮我订一张火车票”，这个时候机器首先要理解用户的意图是买火车票，之后就要查知识库，要买火车票依赖于时间和目的地，但是现在用户只说目的地没说时间，所以它就要发起一个询问时间的动作，机器问了时间之后，用户回答说“明天上午”。这个时候机器要理解用户说的明天上午正好是在回答刚才用户问的问题，这样匹配了之后，基本上这个机器就把这个最关键的信息都收集回来了：时间和目的地，之后，机器就可以发起另外一个请求服务指令，然后把火车票的list给出来。这个时候用户接着说：“我要第二个”。机器还要理解用户说的第二个，就是指的要打开第二个链接，之后用户说“我要购买”，这个时候机器要发起一个指令去支付。

综上，对话交互，我会把它分成两个阶段：

第一阶段，通过多轮对话交互，把用户的需求表达完整，因为用户信息很多，不可能一次表达完整，所以要通过对话搜集完整。第一阶段得到结构化的信息，出发地、目的地、时间，有了这些信息之后，第二阶段，请求服务。接着用还要去做选择、确定、支付、购买等等后面的动作。

传统的人机对话，包括现在市面上常见的人机对话，一般都是只在做第一阶段的对话，第二阶段的对话做得不多。

在对话交互这块，阿里巴巴还是做了一些有特色的东西：

• 第一，我们设计了一套面向Task Flow的对话描述语言。刚才说了，对话其实是分两个阶段的。传统的对话只是解决了第一阶段，我们设计的语言能够把整个对话任务流完整地表达出来，这个任务流就是类似于我们程序设计的流程图。对话描述语言带来的好处是它能够让对话引擎和业务逻辑实现分离，分离之后业务方可以开发脚本语言，不需要修改背后的引擎。

• 第二，由于有了Task Flow的机制，我们在对话引擎方带来的收益是能够实现对话的中断和返回机制。在人机对话当中有两类中断，一类是用户主动选择到另外一个意图，更多是由于机器没有理解用户话的意思，导致这个意图跳走了。由于我们维护了对话完整的任务流，知道当前这个对话处在一个什么状态，是在中间状态还是成功结束了，如果在中间状态，我们有机会让它回来，刚才讲过的话不需要从头讲，可以接着对话。

• 第三，我们设计了对话面向开发者的方案，称之为Open Dialog，背后有一个语言理解引擎和一个对话引擎。理解引擎是基于规则办法，能够比较好的解决冷启动的问题，开发者只需要写语言理解的Grammar、基于对话描述语言开发一个对话过程，并且还有对数据的处理操作。这样，一个基本的人机对话就可以完成了。

对话引擎之后，我们再看下我们的问答引擎和聊天引擎：

问答引擎：其实人和机器对话过程中，不仅仅是有task的对话还有问答和聊天，我们在问答引擎这块，目前还是着力于基于知识图谱的问答，因为基于知识图谱的问答能够比较精准地回答用户的问题。 

问答引擎

聊天引擎：我们设计了两类聊天引擎。

第一是基于

对话交互平台的开发策略

刚才语言理解引擎、对话引擎、聊天引擎再加上语音识别合成，形成了完整的一套系统和平台，我们称之为自然交互平台。在这套平台上，一端是连接着各种各样的设备，另外一端是连接了各种各样的服务，这样用户和设备的交互就能够用比较自然的方式进行下去了。

值得一提的是，这样的自然交互平台在阿里巴巴已经有比较多的应用了。比如说在互联网汽车对话交互，我们和合作伙伴设计开发了汽车前装和汽车后装场景的对话交互。在功能上，比如说像地图、导航、路况，还有围绕着娱乐类的音乐、有声读物。

在汽车场景下的对话交互，还和其他场景有非常多的不同。因为产品方希望当这个车在郊区网络不好的时候，最需要导航的时候，你要能够工作，所以我们的语音识别还有语言理解、对话引擎，就是在没有网络的情况下，要在端上能够完全工作，这里面的挑战也非常大。

现在正在把这样的对话交互平台开放出来，让合作伙伴去开发自己场景的对话交互，所以我们正在开发面向开发者的平台，这个平台背后有端上的解决方案和云上的解决方案，端上包括声音的采集、VAD、端上无网情况下完整的对话方案，服务端的能力会更加强大了。

在合作伙伴这块有两类：一类是面向设备的，比如说汽车、电视、音箱、机器人、智能玩具。另外一类就是类似于行业应用，比如说智能客服这样的一个场景。

考察一个对话交互平台的能力，其实第一需要看它背后沉淀和积累的技术，我们在这方面花了三年的时间去沉淀了一些公共场景的对话交互能力。比如像娱乐、出行、理财、美食，有了这样的能力之后，当一个新的业务方接入的时候，就不需要再去开发了，直接调用就好。用户只需要开发业务场景中特定的一些场景就可以，大大加快业务方开发对话交互的速度。

第二个能力就是提供足够强的定制能力，这种能力我们在语言理解，用户可以定制自己的时点、对话逻辑、聊天引擎、问答引擎，可以把自己积累的数据上传上来，以及对语音识别的词语定制，包括TTS声音的定制等等。

智能对话交互生态的范式思考

过去3-4年，在人机对话领域，应该说，我们还是取得了长足的进步，这样的进步来自于以声音学习为代表的算法突破。这个算法的突破带来语音识别大的改进。同时，另一方面，我们认为当前的对话交互和真正的用户期望还是有明显距离的，对话交互能覆盖的领域比较受限的，大家如果是用智能云交互的产品，你发现翻来覆去就是那几类，音乐、地图、导航、讲笑话等等，其次，有的服务能力还不够好，所以对于未来，我们是走自主研发路线还是平台路线呢？

• 第一类，自主研发。很多的创业公司或者是团队基本上都是自主研发的，像苹果公司它基本上就是自主研发的模式。

• 第二类，平台模式。典型代表就是亚马逊的Alexa，这个平台的好处是它能够发动开发者的力量快速地去扩展领域。

两者各有利弊，所以如何把这两者结合在一起，有没有第三种模式。如果有，第三种模式应该具有哪些特点呢？我总结了下，大概有以下几个特点： 
第一，由于自然语言理解的门槛比较高的，门槛高指的是对于开发者来说，它比开发一个APP难多了，从无到有开发出来不难，但要做到效果好是非常难的。所以，语言理解引擎要自研。第二，对话逻辑要平台化。对于对话交互，因为它和业务比较紧，每个业务方有自己特殊的逻辑，通过平台化比较合适，让平台上的开发者针对各自场景的需求和交互过程来开发对话。第三，需要建立一套评测体系，只有符合这个评测体系的，才能引入平台当中。第四，需要商业化的机制，能够让开发者有动力去开发更多的以及体验更好的交互能力。

如果这几点能够做到，我们称之为第三种范式，这个平台能够相对快速地，并且开发的能力体验是有效果保证的。这样它开放给用户的时候，无论是对B用户还是C用户，可以有更多的价值。

总结

最后，总结下我们对于研发对话交互机器人的几点思考和体会：

• 第一，坚持用户体验为先。这个话说起来很容易，但是我也知道，很多团队不是以用户为先的，是以投资者为先的。

• 第二，降低产品和交互设计的不确定性。如上所说，对话交互最大的问题是不确定性，在产品的交互上，我们要想办法把这种不确定性尽量降得低一点。

• 第三，打造语言理解的鲁棒性和领域扩展性。语言的理解能力尽量做到鲁棒性，才能够比较好的可扩展。

• 第四，打造让机器持续学习能力。对话交互我认为非常重要的一点就是怎么样能够让机器持续不断地学习。

• 第五，打造数据闭环。要能够快速地达到数字闭环，当然这个闭环当中要把数据的效能充分调动起来，结合更多数据的服务。

作者简介：孙健，博士，阿里巴巴iDST 自然语言理解和人机对话负责人，资深专家。