0
9 位来自阿里巴巴 iDST 数据科学与技术实验室的顶级专家，为大家奉上精彩的“NLP 快速入门实战特训班”。你不信？登陆 www.mooc.ai 看看就知道。
雷锋网【AI科技评论按】：在AI领域，有一些问题被称为是AI-hard problems，所谓AI-hard，是指一旦这些问题得到了解决，AI或者strong AI也就实现了。自然语言理解和人机对话就是这些AI-hard problems之一。在阿里巴巴最神秘的iDST部门，有一群人从2014年年初开始就扎根在这个方向上进行探索和开拓，当时距离siri推出已经过了三个年头，一大波追逐siri而起的语音助手类产品正进入低潮和消亡期。这群人为什么在别人绝望的时候开始进入这个领域？他们看到了什么不一样的东西？他们对AI-hard有什么认识？三年过去了，他们在做什么？他们做出了什么？他们还要做什么？带着这些问题，雷锋网【AI科技评论按】对阿里巴巴 iDST 负责自然语言理解和人机对话的资深专家孙健博士进行了专访，带大家了解有关阿里巴巴 iDST在智能人机对话方向的探索、思考和进展。
孙健：我们是从2014年初开始尝试和探索人机对话这个方向。我们开始探索人机对话这个方向，是因为当时我们感知到了两个趋势和变化。
第一个趋势是智能设备开始快速发展。当时智能手机已经比较普及，其他智能设备发展也非常迅速，像智能眼镜、智能手表、智能电视、智能音箱、互联网汽车、机器人等产品层出不穷。这些智能设备硬件形态各异，使用场景也多种多样，传统的人机交互方式，像是键鼠或者触控，已经越来越不能满足用户的要求。比如走路的时候，一边走路一边发短信就比较痛苦；开车的时候，双手被占用，使用触控操作导航或收听音乐既不方便又很危险；跟机器人交互的时候，尤其是一些拟人形机器人，如果拖着一个键鼠或者需要触摸一块屏幕，都给用户很不自然的感觉。这样那样的问题，催生了人和机器之间迫切的自然对话交互需求。但是在2014年初的时候，人机对话交互还处于一个非常初级的阶段，体验非常不好。
第二个趋势就是互联网服务的日益丰富和下沉。从传统的偏信息和沟通的服务全面延展到购物、外卖、导航、打车等围绕人们生活方方面面的互联网服务。让用户在各种智能设备上突破传统交互方式获得各种各样的服务，成为一个重要的趋势。
基于以上两点，我们认为迫切需要打造一种能够让人和机器更自然更便捷的进行交互的手段，从而让用户在任何时间、任何地点便捷地获取到想要的信息和服务。
我们在启动这件事时，受到内部不小的challenge：被challenge的一个主要问题是当时淘宝搜索上语音搜索的量非常小，在语音搜索量很小的情况下为什么要搞语音人机对话；质疑者举的另一个例子是2014年初业界一些互联网公司搞的语音助手产品基本都死掉了，那我们为什么还要启动语音人机对话？但我们坚持我们的判断，因为我们感知到了不一样的趋势和变化，认为它会成为未来。
孙健：过去三年，我们其实经过了两个主要的阶段。第一个阶段是，我们iDST与YUNOS部门深度合作打造YUNOS移动操作系统上具备语音交互能力的智能助理产品。但在做的过程中，我们发现智能助理产品这个模式有问题。问题在哪里呢？
智能助理产品定位于期望成为用户的总入口，让它承接用户的任何需求，并且期望能够在该产品内完成用户的所有需求，尽量不让用户跳转到其它应用中。这就意味着要在这个产品内部实现所有的功能，比如说你要买火车票、购物、打车、外卖等等，即意味在一个智能助理产品内部实现12306、淘宝购物、滴滴打车、美团外卖等所有这些功能，这个工作量是非常庞大的，更可怕的是有限的资源根本不可能做到与这些app可比肩的使用体验。再者即使你实现了所有功能，那么它与其他APP是一个争夺流量入口的竞争关系，这也不可行。
所以，经过一年多的探索和思考，我们有一个判断是智能助理这样的产品不是一个app能够承载的，它应该是设备+操作系统+app生态三位一体的一个综合体。基于这样的一个判断，我们在 2015年底有一个战略上的选择：我们的定位不是打造智能助理产品，而是打造智能人机交互的平台，赋能给每个设备端、赋能给每个APP，从而让每个设备和app具备智能人机对话的能力。这样为每一个设备或者APP提供语音交互的能力，这样你与APP就不是竞争关系，而是协同关系。
孙健：我们是自然语言人机对话团队，做的工作包括自然语言理解、对话管理、智能问答、智能聊天等技术方向。
语言理解就是让机器理解人的语言。简单来说，可以分为两个子任务，第一个就是要判断用户所说话的意图，比如说是订餐，订出租车，还是买火车票？第二，在了解用户意图的基础上，还需要把用户话语里的关键信息提取出来。比如你要买火车票，就需要出发地、目的地和时间。
人和机器的对话交互，不是一句话就能完成的，这就需要一个对话管理模块来把对话过程管理起来。我们接着上面的例子来说，如果用户只说了出发地、目的地，没说时间，那机器就要问什么时间出发。这样通过多轮对话的方式，机器把完成用户需求所需要的信息给收集完整，然后再去请求一个具体的数据服务(比如：火车票服务)。获取到服务结果对于多数任务来说，只完成了一半，用户还要根据自己的喜好，来对结果进行各种筛选和过滤，比如翻页、查看详情、改变查询条件等等。这整个交互的过程都需要对话管理。
智能问答方面，人机对话是开放的，它不像APP，功能是事先设计好的，用户只能点那几个按钮。人机对话时，用户可以放开问，这个时候对机器的挑战很大。机器真的需要上知天文下知地理，才能够理解和回答用户的多种多样的问题。所以，在智能问答这一块，我们投入了一些资源在着力于互联网FAQ、互联网的百科知识、还有每天层出不穷的资讯信息的深入挖掘，从而能够较好回答用户的问题。这也是我们未来的重点方向。
聊天引擎方面，我们也做了一些工作，但考虑到它对用户的价值没有那么大，所以，我们在这个方向上也没有重点投入。
孙健：在智能人机对话这一块，我认为最大的挑战就是可扩展性。那扩展性有两个维度，第一，是领域的可扩展，第二个是设备的可扩展。
第一，先说领域的可扩展，比如说我们开发音乐领域的对话交互需要定义音乐领域的ontology、需要加工该领域的语义知识(歌曲名、歌手名、音乐风格、专辑等)、需要定义语言理解的pattern或训练语言理解的模型、开发对话交互过程、请求音乐领域的服务以及数据处理等等一系列过程，要能够达到产品发布要求，有大量的工作和细节需要打磨。但当我们要开发另一个新的领域比如地图领域的对话交互时，这些步骤和工作一样也不会少，这当中花费的时间几乎是线性增长的。因此，领域扩展的时间成本就很大。
第二，是设备的可扩展。比如我们开发了适用于智能电视的音乐领域的对话交互之后，能不能直接用到音箱上呢？答案是不行的。为什不行呢？是因为这两种不同类型的设备不一样，这可能导致人机对话交互的过程也不一样。比如说在智能电视上，由于电视屏幕大，产品的定义是：当用户要听刘德华的歌时，系统要展示出刘德华的歌曲列表，然后用户从中选择某一个，这是一种交互方式。但是在音箱上这种对话交互就不行，因为它没有屏幕，产品的定义是：当用户要听刘德华的歌时，系统就推荐该用户最喜欢听的刘德华的某一首歌就好了，不必让用户进行选择。所以，设备有没有屏幕、屏幕大小等因素，都决定了同一个领域的人机对话交互过程是不一样的。
基于以上两点，我们认识到人机对话交互是一个与业务、与领域、与设备类型等强相关的事情，每个业务的owner是开发其业务领域的最合适的团队，但同时人机对话交互的开发对业务方来说是一个高门槛的事情（相对于app开发），因此，我们的思路是把对话交互分成两层，一个是引擎层，一个是业务层。而由iDST提供自然交互平台，我们把引擎能力打造好，比如说语音理解的能力、对话的能力等，然后让业务团队基于这个平台去开发适合自己业务场景的对话。
人机对话中的语言理解面临哪些关键挑战？
孙健：我认为有以下几点：
第一点是用户口语表达的多样性和多义性。用户口语表达的多样性和多义性为语言增加了丰富的色彩，但是对于机器理解来说就增加了大量的难度。先说多样性，即可以用多种说法表达同一个意思，比如同样表示调大音量，可以说“调大音量”、“大点声”、“大一点声”、“放大音量”、“调高声音”，还可以说“声音太小”，甚至说“听不清”等等；再说多义性，即同一种说法可以表达多个意思，比如“我要去拉萨”，是想买机票？买火车票？查景点？查攻略？还是想听歌“我要去拉萨”。
第二点是语言的理解需要依赖于上下文。在对话中，只说一句的是特例，就像人和人说话，都是在一来一回的不停的说。人和机器的对话，这种上下文的建立、管理和使用就是一件很难的事情，比如：
Q: 那你嫁给我吧
A: 我妈说我还小不能嫁人
Q: 我问过你妈了他说同意你嫁给我
A: 为你找到以下结果…（即系统无法回答，转向了搜索结果）
第三点，通俗来讲叫容错性，专业一点叫鲁棒性。在智能人机对话中，由于各种原因导致的语音识别结果不理想的情况，会增加语言理解的难度，像是“玖月奇迹”可能会识别成“九月奇迹”，像是韩红有首歌叫“九儿”可能会识别为“九二”。还有人对于较长的实体词，一般很难准确记忆和表达，很多情况都是意译出来的，会存在多字、少字、错字等。举几个例子，比如“大王叫我来巡山”会说成“大王让我来巡山”，比如“爱探险的朵拉”或说成“爱冒险的朵拉”等等。
第四点是对常识的掌握和推理能力。人和人能进行流畅的对话，是因为我们共享了很多常识，并且能够推理。但是常识和推理对于今天的机器来说，是很困难的事情。比如”我饿了“是想找餐厅，”我肚子疼“是想找医院或买药
孙健：过去这一年我们的工作和成果主要有以下几个方面：
第一点， 我们的语言理解引擎从传统的机器学习方法，全面升级为深度学习方法并在效果指标上取得显著改进，对用户口语各种丰富表达的理解更具鲁棒性。在意图判定方面，我们在对比了多种深度学习模型之后，现在选择了CNN模型并做了很多改进；在slot-filling方面，随着数据量的增加和各种知识的融入，Bi-LSTM-CRF模型的优势越来越大。在上下文的理解上，我们建立了有效的模型来做处理。在鲁棒性方面，大量的data augmentation对效果又直接的提升，此外，我们在实验让模型自身能够学会处理实体词多字、少字、错字的问题。
第二点， 我们提出并设计了一套描述task flow的对话描述语言，该对话描述语言不仅能够刻画slot filling的对话过程，还能够完整地描述整个task的步骤、每一步所需的条件，比如以预定火车票为例，该对话描述语言不仅仅描述搜集信息阶段的对话，还能够完整描述后面选择车次、座次、付款等任务流程。
第三点， 我们开发了该对话描述语言的对话引擎，该对话引擎有两点特色：能够支持cross-domain的属性carry over机制；支持对话的中断和返回机制。关于这两个特色，我这里可以稍微展开一下，第一点，对话能够跨领域自由跳转以及在跳转过程中属性信息carry over机制。比如在买火车票的过程当中，用户有时想看一下目的地的天气，如果天气不好可能要修改一下自己的行程。所以我们设计开发的人机对话系统能够支持让用户在完成一个task的过程中，相对自然并流畅的跳转到一个新的task而不需要用户把之前说的某些信息再说一遍。第二点，我们设计开发的人机对话能够实现对话的中断和返回机制。人机对话中，往往由于各种各样的原因，可能机器没有理解用户的话，导致刚才进行中的对话就中断了。如果没有这种机制，对话断了之后，用户接着还要从头到尾再说。有了这个机制之后，我们可以让用户的下一轮对话能够承接对话中断前的那一轮并进行下去，你就不需要重新说了。这是我觉得比较有意思的。
第四点， 我们提出了一套能够让业务方开发并定制业务特有领域的对话的Open Dialogue解决方案，并以此为基础搭建了完整的人机对话自然交互平台(NUI)。
孙健： 我们开发的智能语音人机对话与阿里巴巴的YunOS操作系统是深度合作，因此，设备端安装了YunOS系统后，自然就配套智能语音人机对话交互的能力。
现在天猫魔盒、YunOS手机和一些智能音箱上，都已经上线使用。另外阿里巴巴与上汽合作打造互联网汽车，我们正在围绕着互联网汽车场景下做对话交互。
互联网汽车是人机对话交互的一个刚需场景，并且非常有意思，因为YUNOS操作系统能够接收到汽车硬件系统的很多信号(比如：油箱里还有多少油、天窗是否打开的状态等)，如果这个汽车快没油了，这些信息可以被操作系统感知到，那么系统就可以主动与车主对话，告诉你前面两公里有个加油站，可以去加油。这对用户是非常大的帮助。
孙健：我觉得主要有三个方面。
第一个，目前的语言理解还是针对特定域(domain)的，这些域都是预先定义好的，可扩展性存在很大的问题，对用户需求理解的覆盖率还不够。所以开放域（open-domain）的自然语言理解是未来的重要方向，也是很大的挑战。
第二个，目前的人机对话交互基本都是单轮对话，即使是多轮对话其只是考虑有限的上下文，基于完整对话上下文的语言理解的建模也是一个值得研究和探索的课题。
第三个，目前的人机对话更多是由人工来定义的，缺点在于随着对话的持续进行而其能力没有任何的增强。建立数据驱动的人机对话机制，让对话能力能够持续自学习，在对话的过程中不断学习不断提高。这也是非常重要的方向。
孙健：阿里巴巴很多BU都没有招人的HeadCount，但智能语音交互是集团非常看重并重点持续投入的方向，所以HeadCount不是问题。我们对于人才有这么几点期望：第一呢是好奇心，要能够对新事物，保持一种好奇心，有积极探索的意愿和主动性；第二呢是学习能力，因为科学技术的发展非常非常快，每天都可能会出现新的科学进展和技术突破，每天都需要学习；第三是思考力，对遇到的问题和现象能够多问自己一些为什么，能够有自己的思考和判断。如果您对智能人机对话感兴趣，我们期待与您有更多的切磋、交流或合作。
文章由雷锋网【AI科技评论按】独家采访报道。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
