PaperWeekly 第34期 | VAE在chatbot中的应用

赵天成

卡耐基梅隆大学博士生

研究方向为口语对话系统

欢迎访问以下链接调戏作者开发的chatbot

http://www.cs.cmu.edu/~tianchez/

（Task-oriented）任务驱动对话系统最近在工业界和学术界都大火了一把。不同于最近同样的火热的闲聊 chatbot，任务驱动地话系统往往有一个明确的使用目的。一些常见的应用包括天气查询，机票预定，航班查询等等。用户在使用任务驱动对话系统的时候，通过多轮人机对话，向电脑阐述自己的需求。而电脑在理解了用户的所求之后，通过对于后端数据库的查询和修改，来实现用户要求的功能。假如用户的阐述不够清楚，或者用户的需求比较复杂，系统可以主动询问，澄清的方式来帮助用户找到满意的结果。正因为如此，任务驱动对话系统需要同时解决数个人工智能核心问题。传统的做法是对这些问题逐一分解解决，也就是如下图的对话系统 pipeline，包括：自然语言理解（NLU），对话状态跟踪（State Tracker），对话策略（Policy），和自然语言生成（NLG）。下面我们大致对于每个模块的功能进行一下介绍：

自然语言理解（NLU）：这个模块的功能是把来自用户的句子映射到机器可读的语义结构上，一般包含实体（entity）抽取，意图（intent）识别，话题（domain）识别等。

状态跟踪（State Tracker）：在 NLU 的基础上，状态跟踪需要把多轮对话历史进行总结，理解上下文中的含义。这个模块对于跟踪用户需求有着至关重要的作用，因为很多时候需要通过综合考虑用户多轮输入才能真正理解他们的需求。

对话策略（Dialog Policy）：在有了对话状态后，对话策略需要决定下一步应该做什么行动（action）。行动包括查询数据库，或者产生下面要说的一句话。相当于对话系统的高层决策者。

自然语言生成（NLG）：负责把对话策略的行动装换成自然语言。

 

虽然以上的 pipeline 可以简化每个模块的开发难度，但是它带有很多问题。首先每个模块都是为某一个领域专门定制的，假如我们想迁移到一个新的对话领域，这意味着我们需要重新开发大部分的模块。此外，因为任何模块都不是完美的，所以上游模块的错误会传递到下游，让 debug 非常的困难。近期随着深度学习和端到端学习的（end-to-endlearning）兴起，很多学者开始研究如何用深度神经网络来搭建端到端任务驱动对话系统。端到端学习常见的做法是设计出可以整体 differentiable 的模型，然后利用 backpropagation 把输出端的 gradient 传递到整个神经网络，已达到 joint optimzation 的效果。首当其冲的问题是，数据库的衔接不可微分。这是因为数据库需要通过 symbolic query 来进行检索，而一般的 RNN 在中间层不提供 symbolic representation。为了解决这个问题，本文挑选了近期几篇相关论文，总结了下目前拥有的解决方法。

 

第一种方法是把数据库的操作 action 变成 dialog policy 的一部分。然后通过 supervised learning 或者 reinforcement learning 进行学习 [1,2]。常见的做法是是把数据库 query 的 template 作为系统可选择的 action，例如 select place=x，date=y，然后 dialog policy 在必要的时候可以输出下一个行动是应该对于数据库进行这样的搜索。搜索结果会成为模型的下一轮输入，以便模型输出搜索结果。这种方法的好处是可以适用于任何数据库或者 API，但是缺点是不能很好的 handle 用户输入的 uncertainty，因为每次搜索只能搜索一种最有可能的 query。

 

第二种方法是假设系统可以看到整个 database 的每一行，然后通过用户目前给出条件的概率，来计算出数据库每一行符合用户条件的概率分布 [3]。 这样做的好处是，1. 因为计算概率分布的过程都是可微分的，我们可以用标准的 gradient method 来优化系统 2. 其次是用户输入里存在的不确定性也得到了解决，可以更加准确的推测出哪些结果是用户可能喜欢的。但是这种方法的缺点是它需要能够 access 整个数据库里的内容。这对于使用第三方 API 的开发者来说不是一个好消息。另外，当数据库很大时，概率分布的计算需要很大的计算量，给这个办法的拓展性打上了一个问好。

 

第三种方法是利用 RNN decoder 直接生成数据库的 query [4]. 这种做法利用 sequence-to-sequence model 读取一个对话记录，然后利用 decoder 生成出 database 的搜索句子。这种做法任然处于早起实验阶段，因为 RNN 生成的过程不能保证 query 的格式正确。并且任务驱动对话需要大量的逻辑推理和语义理解，普通的 RNN 可能不能完全满足这样的需求。最近也有大量工作试图改进普通 RN，例如 Memory Network，Attention RNN 等等。尽管这种方法还没有完全实用化，但是这种方法的确非常有前途，因为可以没有任何 query 格式上的限制。

 

[1] Zhao,Tiancheng, and Maxine Eskenazi. "Towards end-to-end learning for dialogstate tracking and management using deep reinforcement learning." arXiv preprint arXiv:1606.02560 (2016).

[2] Williams,Jason D., and Geoffrey Zweig. "End-to-end lstm-based dialog controloptimized with supervised and reinforcement learning." arXiv preprint arXiv:1606.01269 (2016).

[3] Dhingra, Bhuwan, et al. "End-to-end reinforcement learning ofdialogue agents for information access." arXiv preprint arXiv:1609.00777 (2016).

[4] Bordes, Antoine, andJason Weston. "Learning end-to-end goal-oriented dialog." arXiv preprint arXiv:1605.07683 (2016).

赵天成

卡耐基梅隆大学博士生

研究方向为口语对话系统

欢迎访问以下链接调戏作者开发的chatbot

http://www.cs.cmu.edu/~tianchez/

（Task-oriented）任务驱动对话系统最近在工业界和学术界都大火了一把。不同于最近同样的火热的闲聊 chatbot，任务驱动地话系统往往有一个明确的使用目的。一些常见的应用包括天气查询，机票预定，航班查询等等。用户在使用任务驱动对话系统的时候，通过多轮人机对话，向电脑阐述自己的需求。而电脑在理解了用户的所求之后，通过对于后端数据库的查询和修改，来实现用户要求的功能。假如用户的阐述不够清楚，或者用户的需求比较复杂，系统可以主动询问，澄清的方式来帮助用户找到满意的结果。正因为如此，任务驱动对话系统需要同时解决数个人工智能核心问题。传统的做法是对这些问题逐一分解解决，也就是如下图的对话系统 pipeline，包括：自然语言理解（NLU），对话状态跟踪（State Tracker），对话策略（Policy），和自然语言生成（NLG）。下面我们大致对于每个模块的功能进行一下介绍：

自然语言理解（NLU）：这个模块的功能是把来自用户的句子映射到机器可读的语义结构上，一般包含实体（entity）抽取，意图（intent）识别，话题（domain）识别等。

状态跟踪（State Tracker）：在 NLU 的基础上，状态跟踪需要把多轮对话历史进行总结，理解上下文中的含义。这个模块对于跟踪用户需求有着至关重要的作用，因为很多时候需要通过综合考虑用户多轮输入才能真正理解他们的需求。

对话策略（Dialog Policy）：在有了对话状态后，对话策略需要决定下一步应该做什么行动（action）。行动包括查询数据库，或者产生下面要说的一句话。相当于对话系统的高层决策者。

自然语言生成（NLG）：负责把对话策略的行动装换成自然语言。

 

虽然以上的 pipeline 可以简化每个模块的开发难度，但是它带有很多问题。首先每个模块都是为某一个领域专门定制的，假如我们想迁移到一个新的对话领域，这意味着我们需要重新开发大部分的模块。此外，因为任何模块都不是完美的，所以上游模块的错误会传递到下游，让 debug 非常的困难。近期随着深度学习和端到端学习的（end-to-endlearning）兴起，很多学者开始研究如何用深度神经网络来搭建端到端任务驱动对话系统。端到端学习常见的做法是设计出可以整体 differentiable 的模型，然后利用 backpropagation 把输出端的 gradient 传递到整个神经网络，已达到 joint optimzation 的效果。首当其冲的问题是，数据库的衔接不可微分。这是因为数据库需要通过 symbolic query 来进行检索，而一般的 RNN 在中间层不提供 symbolic representation。为了解决这个问题，本文挑选了近期几篇相关论文，总结了下目前拥有的解决方法。

 

第一种方法是把数据库的操作 action 变成 dialog policy 的一部分。然后通过 supervised learning 或者 reinforcement learning 进行学习 [1,2]。常见的做法是是把数据库 query 的 template 作为系统可选择的 action，例如 select place=x，date=y，然后 dialog policy 在必要的时候可以输出下一个行动是应该对于数据库进行这样的搜索。搜索结果会成为模型的下一轮输入，以便模型输出搜索结果。这种方法的好处是可以适用于任何数据库或者 API，但是缺点是不能很好的 handle 用户输入的 uncertainty，因为每次搜索只能搜索一种最有可能的 query。

 

第二种方法是假设系统可以看到整个 database 的每一行，然后通过用户目前给出条件的概率，来计算出数据库每一行符合用户条件的概率分布 [3]。 这样做的好处是，1. 因为计算概率分布的过程都是可微分的，我们可以用标准的 gradient method 来优化系统 2. 其次是用户输入里存在的不确定性也得到了解决，可以更加准确的推测出哪些结果是用户可能喜欢的。但是这种方法的缺点是它需要能够 access 整个数据库里的内容。这对于使用第三方 API 的开发者来说不是一个好消息。另外，当数据库很大时，概率分布的计算需要很大的计算量，给这个办法的拓展性打上了一个问好。

 

第三种方法是利用 RNN decoder 直接生成数据库的 query [4]. 这种做法利用 sequence-to-sequence model 读取一个对话记录，然后利用 decoder 生成出 database 的搜索句子。这种做法任然处于早起实验阶段，因为 RNN 生成的过程不能保证 query 的格式正确。并且任务驱动对话需要大量的逻辑推理和语义理解，普通的 RNN 可能不能完全满足这样的需求。最近也有大量工作试图改进普通 RN，例如 Memory Network，Attention RNN 等等。尽管这种方法还没有完全实用化，但是这种方法的确非常有前途，因为可以没有任何 query 格式上的限制。

 

[1] Zhao,Tiancheng, and Maxine Eskenazi. "Towards end-to-end learning for dialogstate tracking and management using deep reinforcement learning." arXiv preprint arXiv:1606.02560 (2016).

[2] Williams,Jason D., and Geoffrey Zweig. "End-to-end lstm-based dialog controloptimized with supervised and reinforcement learning." arXiv preprint arXiv:1606.01269 (2016).

[3] Dhingra, Bhuwan, et al. "End-to-end reinforcement learning ofdialogue agents for information access." arXiv preprint arXiv:1609.00777 (2016).

[4] Bordes, Antoine, andJason Weston. "Learning end-to-end goal-oriented dialog." arXiv preprint arXiv:1605.07683 (2016).