任务型对话系统
介绍
我们将对话系统分成四个主要的功能：第一个是任务型对话系统，也可以认为其他都是非任务型对话系统，又可以进一步划分为聊天类、知识问答类，以及推荐类，这几个类型的机器人我们研究中心都在做。我今天主要介绍任务型的对话系统。
任务型的对话机器人有很多用处，如智能汽车控制、个人助理等。
组成
任务型对话系统主要构成包括三模块：第一个模块为自然语言理解（这个名字不是特别好，因为我们做自然语言处理整个大方向也叫自然语音理解，这个名字是在人机对话领域约定俗成的，也可以叫口语语言理解），它主要实现两个功能，一个是意图识别，一个是语义槽填充。比如“请帮我订一张去北京的机票”，意图是订机票，语义槽为“到达地=北京”。
第二模块为对话管理，又包括对话状态跟踪和对话策略优化。对话状态一般表示为语义槽和值的列表，如有出发地、到达地等。通过自然语言理解，我们知道到达地是北京，出发地和出发时间仍然是空，这就是当前的对话状态。获得当前对话状态后，我们要进行策略优化，选择下一步采用什么样的策略，也叫动作。动作有很多种，我可以问出发时间，也可以问出发地。如此时可以寻问出发地。
第三部分为自然语言生成。在对话系统里面语言生成工作相对比较简单，通过写模板即可实现。比如要询问出发地，就直接问“请问你从哪里出发”，然后经过 TTS 系统给用户反馈。整个过程可以一直循环下去，随着每次提问的不同，对话状态也随之变化，然后采用不一样的回复策略。
技术方法
下面介绍这几个模块的技术发展趋势。其中，意图分类可以看成是文本分类，而且是短文本分类问题。早期采用SVM等线性分类器，最近主要采用深度学习方法，比如CNN或者CNN-LSTM。有人说深度学习需要大数据，对话领域数据不多，为什么还采用深度学习技术呢？这主要归功于预训练模型，使得深度学习在只有较少数据的情况下，仍然可以取得比较好的效果。
语义槽填充是要识别句子中规定好的语义槽的值。可以看成序列标注问题，即标注出序列中每个词的标签，如出发地的开始或者出发地的继续等。传统的序列标准模型是CRF，现在双向LSTM之后还可以再加CRF模型。
对话管理负责识别出下一步采用什么动作。这个问题比较麻烦就是我们很难标注出数据，告诉对话系统每一步采用什么动作，因为很多时候没有标准答案。比如刚才那个例子，询问出发时间还是出发地都是合理的动作，只有对话全流程结束后才知道该步骤采取的动作是否合适。这是强化学习擅长解决的问题。早期对话管理的研究往往采用基于规则的方法，后来出现基于有指导，即标注每一步所谓的标准动作，目前研究主要集中在基于强化学习的方法，其中的奖励可以是对话轮数、任务完成情况等。
最后是对话生成，通常采用基于模板的简单方法，也可以采用语言模型，目前也出现了基于深度学习的模型。与之前基于序列到序列的深度学习模型不同，这里采用的是状态到序列的模型。基于深度学习的模型还多处于研究阶段，实际应用中还是多采用基于模板的方法。
我们可以看到，用户即开发者如果想构建自己的对话系统，都需要这实现这三个模块，大大增加了开发的难度。有没有可能帮助用户，快速的构建自己的对话系统呢？用户只需要提供各自领域相关的数据，无需关注太多的技术细节。为此我们开发了对话技术平台。实际上，整个的产业界，包括微软、谷歌、脸书和百度等都在这做方面工作。如微软开发的LUIS系统，脸书收购的wit.ai，谷歌收购的api.ai，百度自研的UNIT以及收购的kitt.ai等等这些都在做对话平台。
开发者若想做一个对话系统，不需要亲自实现刚才介绍的三个模块，只要上传数据并进行标注，最后就可以提供对话API，来回答用户的问题或者进行对话。背后是我们积累多年的自然语言处理技术。
新技术的优势
传统的对话系统还有一些不足。首先，各个模块之间都是相互独立的，这样我需要为每个模块去标注大量的数据，特别是跟领域相关的数据；底层模块的错误会影响上层模块，如果语言理解错了，就会影响到对话的管理，这也叫错误的级联；上层模块信息无法反馈到下层模块。其次，针对每个领域都需要人工设计语义槽，动作空间也都不一样，导致系统的设计跟领域非常相关，很难切换到新的领域。
因此，我们希望把原来的三个模块用统一的端到端模型替代。系统只需要知道输入以及相应的输出，也就是对应的回复即可。这种数据也比较容易获得，如各大银行、电信、携程等有大量的客服对话数据。
之前有一些相关的工作，如所谓的联合学习，就是将多个模块放在一起学习，这样可以减小错误级联的问题。Yang et al. 2017把对话管理模块和语言理解模块进行联合学习。Wen et al. 2016把更多的模块放在一起端到端的训练，包括语言理解、对话管理和对话生成。但是对于数据库的查询，仍然需要显式地转成SQL语句。
Eric and Manning (2017)直接使用序列到序列的模型，从用户的提问生成相应的回复。针对任务型对话，传统的序列到序列模型有一个明显的问题，就是我们不能简单地从历史对话数据中学习，比如问“明天天气怎么样？”如果训练数据有回复说“晴天”，但是不能每次都一样的回答，需要根据当前天气预报数据进行回复。所以在他们的工作中，生成的词有两个来源，一个数据库，如“晴天”或者“阴天”，第二就是从原始文本中拷贝过来。
后来他们把这个工作进一步进行延伸，能够更好的对数据库进行查询 (Eric et al. 2017)。先把数据库的表示方式进行修改，原来数据库是多种属性的关系表。现在拆分成构成的三元组，然后在三元组列表上进行打分，分数最高的即为最能回答当前问题的知识。
以上工作是纯粹端到端的模型，而进行对话时，要对对话的状态进行表示和跟踪。我们不想显示的定义对话状态，所以我们用向量表示对话状态，向量每一维代表哪一个槽需要自己学习，这相当于隐式的对话状态表示。一方面可以用它直接查数据库，使得查询更准确，另一方面它更有利于对话回复的生成。