自然语言处理(...RasaNLPNLP - 对话系统【feel free】

谈任务驱动型人机对话系统

2018-01-11  本文已影响302人  是neinei啊

一. 任务驱动与非任务驱动型对话系统

二. 任务驱动型对话系统框架

任务型人机对话系统框架.png

当系统输入为语音时,ASR和TTS模块存在。

1. ASR:

产生语音识别结果也就是用户话语 u.

2. 自然语言理解:

这个模块的功能是识别输入话语的领域和意图,获得任务相关的语义信息,进一步可以分解为3个子任务。

1)模块拆分

判定用户谈论的是什么领域的事情

识别用户话语的目的,比如是告知某个信息,还是确认某个信息

旨在标识用户话语中与目标有关的语义类别,比如预订机票时需要的出发地、目的地、时间等语义类别。

客户:『订1 张去北京的飞机票』
聊天机器人:『您想什么时间出发呢?』
客户:『1月11号』
聊天机器人:『好的』
============================================================
1、什么是语义信息?
领域是“ 航班信息服务”;意图是“ 订票”,与订票任务相关的语义信息包括作为“ 订票数量”的“1 张”、作为“起飞时间”的“1 月11号”,以及作为“ 目的地”的“ 北京”。
订票数量、起飞时间和目的地称为槽,句子中提供的这些槽的具体值称为槽值。
2、slot-value槽与槽值的定义
槽是多轮对话过程中将初步用户意图转化为明确用户指令所需要补全的信息。一个槽与一件事情的处理中所需要获取的一种信息相对应。
补充说明:多轮对话中的所有的槽位不一定都需要被填充完整;对话内容并不是获取信息的唯一方式,用户身份以及当前场景也包含着大量值得被利用的隐含信息。
3、槽的分类
以订餐为例, informable slot 是指 food type,price range用来约束数据库中的查询,requestable slot 是指address,phone,postcode 等一些可以被询问的值。

2)近年来,NLU模块的关注点主要在两方面:

客户:『订一张端午节的票,如果那天预报有大雾的话就往后推一天。』

这时简单地在语言表层标注时间槽已经不太可能,需要结合其他信息并通过推理得到正确的槽值。

3 )其他改进方向:
4)主流方法

3. 对话管理(Dialog Management):

对话管理(Dialog Management, DM)控制着人机对话的过程,DM 根据对话历史信息,决定此刻对用户的反应。最常见的应用还是任务驱动的多轮对话,用户带着明确的目的如订餐、订票等,用户需求比较复杂,有很多限制条件,可能需要分多轮进行陈述,一方面,用户在对话过程中可以不断修改或完善自己的需求,另一方面,当用户的陈述的需求不够具体或明确的时候,机器也可以通过询问、澄清或确认来帮助用户找到满意的结果。

总的来说,对话管理的任务大致有下面一些:

1)模块拆分

维护和更新对话的状态。对话状态是一种机器能够处理的数据表征,包含所有可能会影响到接下来决策的信息,如NLU模块的输出、用户的特征等;

基于当前的对话状态,选择接下来合适的动作。

举例
用户:『帮我叫一辆车回家』
此时对话状态包括NLU模块的输出、用户的位置、历史行为等特征。
在这个状态下,系统接下来的动作可能有几种:
1)向用户询问起点,如『请问从哪里出发』;
2)向用户确认起点,如『请问从公司出发吗』;
3)直接为用户叫车,『马上为你叫车从公司回家』。

NLU模块不能完成业务的所有语义理解,如果有多个语义输入,例如用户画像,历史信息,nlu输出等,DM需要将他们汇聚。

第三方服务返回的结果可能会让整个对话朝不同的方向发展(请求成功往下走,请求失败又是另外一条路),如果请求第三方服务作为DM的职责之一,那么会带来很大便利。

2)对话管理模块设计方法

目前主流的方法有基于有限状态和对话语法的方法、基于Frame的系统、基于统计的方法、基于神经网络的方法。

这一部分主要讲基于状态图的结构(Graph-base d 或Call-flow-bas ed)和基于任务的结构(Task-base d)

1.基于状态图的结构
有限状态图结构.png

实现:通过有限状态机显示的定义出对话系统应有的状态。
DM每次有新的输入时,对话状态都根据输入进行跳转。跳转到下一个状态后,都会有对应的动作被执行。
优点:简单易用,在对话清晰明确的时候有着很好的应用。
缺点:要求设计者要在设计时预计出所有可能的对话状态和用户可能的操作, 即所有状态之间的转移条件,实现起来要耗费大量的人力; 难以应付没有预测到的情况, 如果用户的反应完全超乎设计师的预计, 则对话必然不能正常地进行。

2.基于任务的结构
任务树.png
实现:任务是指用户为达到某种目的而采取的一系列的操作或对话 , 如“要买两张《特洛伊》的电影票”就是一个任务。一般来讲, 任务包括进度表( Plan) 和目标。目标就是用户想要达到的目的。对于一个应用的领域, 通常采用树型结构来描述任务。
优点:基于任务的结构以任务数为基础, 采用树型结构表达领域内的要素关系, 回答灵活, 是主流的设计方法。
缺点:受树型结构的限制。

Frame-based 系统基本思想是填充槽结构(Slo t-filling)。该方法可以在当前对话轮中填一个或者多个槽位,也可以覆写或修正前面对话轮的填充内容。基于Frame的对话管理系统还有一些衍生系统,如 agenda(Bohus & Rudnicky, 2003), task structuregraphs,和 type hierarchies and blackboards (Rothkrantz et al., 2004) 等。
实现:填充槽结构采用一个多维特征向量来表示对话的情况, 并且在对话的过程中不断地修改向量的值。
优点: 对于操作的顺序没有严格的限制, 只关心当前对话的状态信息, 根据现在的状态作出反应, 然后根据用户的回答或系统的反应修改特征向量。比基于状态图的结构适应更多的对话类型。
缺点:①与基于状态图的结构一样, 也要列出所有的可能状态, 即所有可能的特征向量。②填充槽的数目要有一定的限制, 对于多提问目标的情况就难以应对。

从马尔科夫决策过程(MDP)到部分可观马尔科夫决策过程(POMDP),从Q-Learning 算法到深度Q 网络(DQN)大大促进了这种方法的进步。重点关注POMMDP,这部分在后面也会看一些paper之后详细介绍。【挖坑等填。。。】

部分可观马尔科夫决策过程(POMDP)

简单来说,它将对话表示成一个部分可见的马尔可夫决策过程。所谓部分可见,是因为DM的输入是存在不确定性的,例如NLU的结果可能是错误的。因此,对话状态不再是特定的马尔可夫链中特定的状态,而是针对所有状态的概率分布。在每个状态下,系统执行某个动作都会有对应的回报(reward)。基于此,在每个对话状态下,选择下一步动作的策略即为选择期望回报最大的那个动作。
优点:1)只需定义马尔可夫决策过程中的状态和动作,状态间的转移关系可以通过学习得到;2)使用强化学习可以在线学习出最优的动作选择策略

RL-Based DM 能够对系统理解用户输入的不确定性进行建模,让算法来自己学习最好的行为序列。首先利用 simulated user 模拟真实用户产生各种各样的行为(捕捉了真实用户行为的丰富性),然后由系统和 simulated user 进行交互,根据 reward function 奖励好的行为,惩罚坏的行为,优化行为序列。由于 simulated user 只用在少量的人机互动语料中训练,并没有大量数据的需求,不过 user simulation 也是个很难的任务就是了。

缺点:仍然需要人工定义状态,因此在不同的领域下该方法的通用性不强。

实现:基本思路是直接使用神经网络去学习动作选择的策略,即将NLU的输出等其他特征都作为神经网络的输入,将动作选择作为神经网络的输出。
优点:对话状态直接被神经网络的隐向量所表征,不再需要人工去显式的定义对话状态。
缺点:需要大量的数据去训练神经网络,其实际的效果也还有待大规模应用的验证。目前较少,但更多的还是传统机器学习方法和基于深度学习的方法结合。
更多细节参考论文End-to-end LSTM-based dialog control optimized with supervised and reinforcement learning

4. 语言生成:

自然语言生成的作用是组织适当的应答语句,将系统的答复转换成用户能够理解的自然语言,通常有 3 种解决方案:基于人工模板、基于知识库检索和基于深度学习的序列到序列(Sequence to Sequence)生成模型。


语言生成seq2seq今年发展方向.png

由于对话系统目前还处在起步阶段,基于深度学习的对话系统大多都是先从问答系统的方法改进,多数开放的数据集回答都是一个单词,或者在一个单词上选择模板,生成完整的一句话。

5. 语言生成:

生成的语言由语音合成模块 TTS 朗读给用户听。

三. 实现

端到端的对话系统.png

模块化的对话系统中每个组件单独训练,各个模块分别优化一个单独的中间目标(如 slot-filling)。有两个主要缺陷:一个是分数分配问题,最终用户的反馈很难会传到上游模块中。另一个是模块间依赖度高。每个模块的输入都依赖于另一个模块的输出,当调整一个模块到一个新环境或者用新数据进一步更新,所有其他模块都要进行相对应的调整以保证全局的优化。槽和特征可能也会相对应的改变。这种过程需要大量的人工操作。
端到端的对话系统 用一个系统替代了上图中框起来的四个组件,并使其与结构化的外部数据进行交互。因为task oriented对话系统一般都要结合数据库操作,所以下面总结一些目前实现端到端的对话系统与数据库的衔接,主要有四种方法。通过几篇论文带入。

参考论文:Towards End-to-End Learning for Dialog State Tracking and
Management using Deep Reinforcement Learning

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

参考论文:End-to-end reinforcement learning ofdialogue agents for information access

假设系统可以看到整个 database 的每一行,然后通过用户目前给出条件的概率,来计算出数据库每一行符合用户条件的概率分布 。
优点:① 计算概率分布的过程都是可微分的,从而可以使用梯度下降优化系统 ;② 用户输入里存在的不确定性也得到了解决,可以更加准确的推测出哪些结果是用户可能喜欢的。
缺点:需要能够 access 整个数据库里的内容。对使用第三方 API 的开发者提出挑战。另外,当数据库很大时,概率分布的计算需要很大的计算量,不易扩展。

参考论文:Hybrid code networks: practical and efficient end-to-end dialog
control with supervised and reinforcement learning

这里的回复模板指的是:
“prezzo is a nice restaurant in the west of town in the moderate price range”
都是来自于
“<name> is a nice restaurant in the <location> of town in the <price> price range”

混合编码网络(HCNs)除了学习RNN,也允许开发者表示领域知识通过软件和操作模板。RNN之后经过密连接层和softmax,输出向量维度为动作模板的数量,与Action mask点乘,结果的概率重新进行规范化,得到下一步的action。之后在“实体输出”模块,替换上具体实体值,组织回答句子;控制分支根据行为类别不同调用API或者返回文本应答。
优点:需更少训练数据,就取得同等甚至更优成绩。

参考论文:Key-Value Retrieval Networks for Task-Oriented Dialogue
通过一种新颖的键值对索引机制,使用(subject,relation,object)的表示方式来存储知识库的每个条目。

例如:
(event=dinner, time=8pm, date=the13th, party=Ana, agenda=“-”)将被规范化成4个单独的三元组形式(dinner,time,8pm)。每个知识库最多有230个标准化的三元组,类似新戴维森(neo-Davidsonian)或RDF式表达。

在每次解码时,取出解码器隐层状态,并使用每个规范化的知识库条目的键来计算一个注意力分值。一个条目的键(key)对应于主题(meeting)和关系(time)的词向量(word embeddings)总和。然后,注意力的分对数就成为了该知识库条目的值(value)。在运行时,如果要解码这个规范化表示的表征,我们将通过知识库查询(lookup)将它转换成知识库条目的实际值(actual value)。

参考论文:Learning end-to-end goal-oriented dialog

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

参考:
PaperWeekly 第34期 | End-to-End任务驱动对话与数据库的衔接
对话管理的一些思考
填槽与多轮对话 | AI产品经理需要了解的AI技术概念
NLP笔记 - 多轮对话之对话管理(Dialog Management)
关于人机对话系统的思考-王小捷
对话系统原理和实践
PaperWeekly 第40期 | 对话系统任务综述与基于POMDP的对话系统
NLP笔记 - 多轮对话之对话管理(Dialog Management)

上一篇下一篇

猜你喜欢

热点阅读