一、对话系统概述

1.浅析对话系统

早期的对话系统多是基于“规则”（Rule）的系统。这些系统的一大特征就是，并不只是真正的去“理解”对话，“理解”文字，而是针对某一种模式，或者说是预定好的模板，对对话进行简单的模仿。不过，如果你认为这样基于规则的系统在今天的对话系统中毫无用武之地的话，那就大错特错了。实际上，通过机器学习的手段辅以规则的方式，这样的系统能够在绝大多数的场景下表现出惊人的水平。很多机器学习背景的工程师在接触对话系统研发的时候，其实往往有轻视规则系统的这种情况。

从基于统计学习的机器学习崛起以后，研发人员就开始希望利用自然语言处理和机器学习的 一系列方法，从根本上来改变对话系统的构建方式，其中有一个核心的想法，就是真正理解对话的内容，从而达到真正的智能。在实际的应用中，真正基于机器学习的系统在很长时间里都并不能完全代替基于规则的系统，直到最近几年出现了更加复杂的基于深度学习的模型。

2.对话系统的类别

从方法上，对话系统可以大致分为“基于规则的系统”和“基于机器学习的系统”。除此之外，从应用场景上，对话系统也可以分为“基于任务的对话系统”和“非任务的对话系统”。

基于任务的对话系统其实很容易理解，比如我们打电话到航空公司查询订票，打电话到酒店查询订房信息，抑或打电话到餐厅预定晚餐等。这样的对话系统有一大特点，就是我们的对 话基本上都有一个明确的目的，或者说我们要完成一个“任务”（Task）。比如对于查询 机票而言，通常情况下，我们的任务可以是成功查询到机票信息，或者成功预订了到某个目的地的机票。

对于基于任务的对话系统而言，整个对话的“范畴”是限定好的，很多任务其实都有流程或 者叫作“套路”可以参考。因此，从本质上来说，基于任务的对话系统还是相对比较容易的 场景。在对话系统发展的历史中，很长时间里，基于规则的系统其实就已经可以对于基于任 务的对话系统提供很高质量的服务了。很多用户针对基于规则的系统来应对任务型对话系 统，往往会觉得系统缺乏一定的灵活度，但其实已经可以完成任务了。实际上，即便是今天 的各类智能对话系统，对于任务型对话系统的支持依然是这些智能系统的核心业务能力。

另外一类对话系统，就是非任务型对话系统，这类系统的一个代表就是“聊天机器人”（Chatbot）。聊天机器人，取决于我们构建这类系统的目的，可以非常接近于任务型的对话系统，也可以是非常难以模仿的，真正具有一定语言理解能力的系统。

典型的聊天机器人，需要对一定的知识库进行建模。比如，当用户问到今天的天气，喜马拉雅山的高度，现在美国的总统是谁等问题，聊天系统要能从某种先前存储的知识库中提取信息。这一部分的功能其实和数据库信息查询很类似。

更加复杂的模式无疑是我们不仅需要对已经有的信息进行直接的查询，还需要进行“推论”（Inference）。这就是“智能”的某种体现，往往是能对现有的数据进行简单推导。比如，如果用户问这样的问题：比纽约现在气温高的美国西海岸城市有哪些？这时，就需要 理解比较词“高”的含义，并能够把这个词汇的含义转换成对气温数值的比较。从这些林林总总的情况来看，非任务型的对话系统更加难以建模，对研发者的挑战也更加艰巨。

3.对话系统的基本架构

首先，一个对话系统需要有一个模块对人的语音进行识别，转换成计算机能理解的信号。这个模块常常叫作“自动语音识别器”（Automatic Speech Recognition），简称ASR。比 如，现在很多手机终端、或者是智能家居都有一些简单的对话系统可以根据你的指令来进行 回应。

第二，在通过了语音识别之后，就是一个“自然语言理解器”，也简称为 NLU。在这个组件里，我们主要是针对已经文字化了的输入进行理解，比如提取文字中的关键字，对文字中的信息，例如数字、比较词等进行理解。

第三，对话系统往往有一个叫“对话管理器”，简称是 DM 的组件。这个组件的意义是能够管理对话的上下文，从而能够对指代信息，上下文的简称，以及上下文的内容进行跟踪和监测。

第四，在任务型的对话系统中，我们还需要一个叫“任务管理器”，简称是 TM 的模块， 用于管理我们需要完成的任务的状态，比如预定的机票信息是否完备，酒店的房间预定是不是已经完成等等。

第五，我们需要从管理器的这些中间状态中产生输出的文本，也简称是NLG。这个部分是需要我们能够产生语言连贯、符合语法的有意义的自然语言。

最后，在一些产品中，我们还需要把自然语言能够用语音的方法回馈给用户，这个组件往往简称为TTS。

二、任务型对话系统有哪些技术要点

1.技术型对话系统的基本架构

第一个组件是“自动语音识别器”（ASR），这个组件是把人的语音进行识别，转换成为计 算机能够理解的信号。

第二个组件是“自然语言理解器”（NLU）。在这个组件里，我们主要是针对已经文字化 了的输入进行理解，比如提取文字中的关键字，对文字中的信息进行理解等。

第三个组件是“对话管理器”（DM）。这个组件的意义是能够管理对话的上下文，从而能 够对指代信息，上下文的简称，以及上下文的内容进行跟踪和监测。

第四个组件是“任务管理器”（TM），用于管理我们需要完成的任务的状态。

第五个组件是 NLG，既从管理器的这些中间状态中产生输出的文本，也就是自然和连贯的语言。

最后一个组件是 TTS。在一些产品中，我们还需要把自然语言能够用语音的方法回馈给用户。

2.任务型对话系统组件详情

我们先来看一下 NLU 这个组件。这个组件的目的是把用户输入的文字信息给转换成为任务型对话系统可以理解的内部的表征（Representation）形式。

我们试想一个餐馆的对话系统，当用户输入了一个句子“看一下北京西单附近今晚 7 点左右的西餐厅”，这个时候，我们都需要了解哪些信息呢？

首先，我们需要知道这个输入的“意图”（Intent）。作为一个餐馆的对话系统来说，我们有可能需要处理好几种不同的意图，比如“订餐”的意图，“查询菜品”的意图等。那么对于我们刚才的这个句子来说，很有可能是一个订餐的意图。也就是说，我们针对一个输入的句子来判断当前的意图，而意图其实就是一个离散的输出结果。这其实就是一个多类的分类问题，或者可以看作是句子的分类问题。

当我们知道了整个句子的意图之后，我们就需要进一步理解这个输入句子的细节。而进一步的理解其实就是希望能够从输入的句子中获得可以“执行”（Execution）的信息。当我们真实进行餐馆预定的时候，餐馆的名字，预定的时间，用餐人数等信息就显得尤为重要。我们可能需要这样的操作，能够提取出餐馆名字、预定时间、用餐人数等信息，执行餐馆预定的动作，并且能够在餐馆的后台系统中记录下来。于是，我们需要对刚才的语句进行这样的分析。这种分析有时候也被叫作“填空”（Slot Filling）。

“填空”其实也可以看作是一个分类问题。比如，需要知道“北京西单”是一个地点，要把这个地点给识别出来，而且能够知道我们已经填了一个叫“地点”的空。再比如，“今晚 7点”也需要被识别出来，让我们知道时间的空也被填好了。在这方面有很多方法，有基于传统模型比如“条件随机场”（Conditional Random Field），简称 CRF 的；也有基于“递归神经网络”RNN 的。

经过了 NLU 这个组件之后，我们就来到了对话系统的中枢大脑的位置，就是 DM 这个组件。这个组件重点的是对对话进行跟踪和管理。从整个对话的角度来看，DM 的主要职责就是监控整个对话的状态目前到达了一个什么情况，下一步还需要进行什么样的操作。

还是以刚才我们的输入句子为例，通过 NLU 的分析，我们知道已经有地点和时间两个“空”（Slot）被补齐了，但是很明显有一些最核心的信息依然缺失，比如就餐的人数，订餐人的联系电话等。DM 的一大作用就是对所有的“空”都进行管理，并且决定下面还有哪些“空”需要填写。在传统的系统中，DM 大多是基于规则的，不过在最近的发展中，DM 逐渐变成了基于分类问题的，利用 CRF 或者 RNN 来对 DM 进行建模的也越来越 多。

下一个模块就是 TM。这其实是整个任务型对话系统中执行任务的部分。对于一个“订单”意图的餐馆对话系统来说，当必要的“空”都已全部填齐的时候，TM 就会去触发当前需要进行动作，比如真正对数据库进行操作，从而完成订餐的流程。

在很多现在的系统中，DM 和 TM 都是结合在一起进行构建的。在此之上往往有一个叫作“协议学习”（Policy Learning）的步骤。总体来说，协议学习的目的是让对话系统能够更加巧妙和智能地学习到如何补全所有的“空”并且能够完成模块动作。比如，有没有最简化的对话方法能够让用户更加快捷地回答各种信息，这都是协议学习需要考虑的方面。目前来说，在协议学习方面比较热门的方法是利用深度强化学习来对 DM 和 TM 进行统一管理。

最后一个组件叫作 NLG，也就是希望对话系统可以产生自然和连贯的语言。比较传统的方法当然就是利用“填写模板”的形式，事先生成一些语句的半成品。目前比较流行的办法是使用 RNN，特别是 RNN 中的 LSTM 来对 NLG 进行建模。

三、聊天机器人核心技术点

1.基于信息检索的对话系统

对话系统，特别是非任务型对话系统，也就是聊天机器人，有一个很重要的 功能，就是在一个知识库的基础上和用户进行对话。这个知识库可以是海量的已经存在的人 机对话，也可以是某种形式的知识信息。

比如，一个关于篮球的聊天机器人，那就需要这个系统能够访问有关篮球球队、运动员、比 赛、新闻等有关篮球信息的知识库。同时，在这个对话系统运行了一段时间之后，我们就会 慢慢积累很多有关篮球的对话。这些对话就成为了系统针对当前输入进行反应的基础。

针对当前的输入，利用之前已经有过的对话进行回馈，这就是基于信息检索技术的对话系统的核心假设。一种最基本的做法就是，找到和当前输入最相近的已有对话中的某一个语句， 然后回复之前已经回复过的内容。

比如，当前的问话是“迈克尔·乔丹在职业生涯中一共得过多少分？”如果在过去的对话 中，已经有人问过“迈克尔·乔丹为芝加哥公牛队一共得过多少分？”。那么，我们就可以根据这两句话在词组上的相似性，返回已经回答过的答案来应对当前的输入。

当然，上面这种对话系统可能会显得比较原始。但是，一旦我们把整个问题抽象成广义的搜索问题，其实就可以建立非常复杂的检索系统，来对我们究竟需要回复什么样的内容进行建模。

比如，我们可以把输入当作查询关键词，只不过从性质上来说，当前的输入语句往往要长于传统的查询关键词，但是在技术上依然可以使用各种搜索技术，例如通常的排序学习等方法都适用于这样的场景。

从理论上来讲，基于检索的对话系统有很多先天的问题。比如，从根本上，搜索系统就是一 个“无状态”（Stateless）的系统。特别是传统意义上的搜索系统，一般没有办法对上下 文进行跟踪，其实从整个流程上讲，这并不是真正意义上的对话，当然也就谈不上是“智 能”系统。

2.基于深度学习的对话系统

那么，如何能够让对话系统真正对状态进行管理，从而能够对上下文的信息进行回馈呢？ 最近一段时间以来，基于深度学习的对话系统逐渐成为了对话系统建模的主流，就是因为这些模型都能够比较有效地对状态进行管理。

那么，在这么多的深度对话系统中，首当其冲的一个经典模型就是“序列到序列”（Sequence To Sequence）模型，简称S2S模型。S2S 模型认为，从本质上对话系统 是某种程度上的“翻译”问题，也就是说，我们需要把回应输入的句子这个问题看作是把某 种语言的语句翻译成目标语言语句的一个过程。S2S 模型也广泛应用在机器翻译的场景中。

具体来说，S2S 把一串输入语句的字符，通过学习转换成为一个中间的状态。这其实就是 一个“编码”（Encode）的过程。这个中间状态，可以结合之前字句的中间状态，从而实 现对上下文进行跟踪的目的。这个部分，其实就成为很多具体模型各具特色的地方。总的来 说，中间状态需要随着对话的演变而产生变化。然后，我们需要一个“解码”（Decode） 的过程，把中间的状态转换成为最后输出的字句。

从整个流程上来说，S2S 其实非常像我们已经介绍过的深度序列模型，例如 RNN 和 LSTM。从实现上来说，很多 S2S 模型，其实都是直接利用 RNN 或者 LSTM 而得以实现 的。因此，很多深度序列模型的技术都可以直接应用到对话系统中来。

另外，我们可以看到，相比于基于信息检索的系统来说，S2S 模型并没有一个“显式”的 搜索过去信息的步骤，因此可以更加灵活地处理语言上的多样性，以及不是完全匹配的问 题。因此，从实际的效果中来看，S2S 模型在对话系统中取得了不小的成功。

3.实际系统的一些问题

在实际的开发中，非任务型对话系统会有一系列的实际问题需要解决。

首先，因为是开放性的对话系统，其实并没有一个标准来衡量这些聊天机器人式的系统的好坏。究竟什么样的系统是一个好的聊天系统，依旧是一个非常具有争议的领域。

其次，人们在实际的应用中发现，基于深度学习的序列模型，虽然常常能够给出比较“人性化”的语句回答，但是很多回答都没有过多的“意义”，更像是已经出现过的语句的“深层 次”的“翻译”。因此在最近的一些系统中，人们又开始尝试把信息检索系统和 S2S 模型结合起来使用。

最后，我们需要提出的就是，非任务型对话系统和任务型对话系统有时候常常需要混合使用。比如，在一个订票系统中，可能也需要掺杂一般性的对话。如何能够有效地进行两种系统的混合，肯定又是一种新的挑战。