精华内容
下载资源
问答
  • 对话系统笔记

    2021-10-27 10:58:54
    对话系统一般分为两种:任务型对话系统和闲聊型对话系统。本文主要讨论前者。 任务型对话系统,也称目标导向型对话系统,多用于垂直领域业务助理系统,如微软小娜、百度度秘、阿里小蜜等。这类系统具有明确要完成的...

    原文链接:https://www.jiqizhixin.com/articles/2020-01-31-7

    对话系统一般分为两种:任务型对话系统和闲聊型对话系统。本文主要讨论前者。

    任务型对话系统,也称目标导向型对话系统,多用于垂直领域业务助理系统,如微软小娜、百度度秘、阿里小蜜等。这类系统具有明确要完成的任务目标,如订餐、订票等。

    任务型对话的架构

    在这里插入图片描述
    框架主要包含如下几个模块:

    • ASR:输入为语音,输出为文字;
    • TTS:输入为文字,输出为语音;
    • 自然语言理解模块(NLU):输入为文字,输出为语义帧(包含领域、意图、语义槽);
    • 对话管理模块(DM):输入为语义帧,输出为对话动作(如询问出发地);包含状态追踪和策略优化两个部分;
    • 自然语言生成(NLG):输入为对话动作,输出为自然语言形式的文本;
    • 知识库及APIs:在语言生成的过程中会调用知识库和一些APIs,比如一些查天气和地理位置的APIs,这些都包含在任务型对话的资源里

    对话管理

    在这里插入图片描述

    对话策略以对话状态为输入,通过一个 π \pi π函数来产生对话动作。由于对话状态集合和对话动作集合都是有限的,所以可以在集中进行枚举。

    在这里插入图片描述
    也就是说,对话策略模型就是根据对话状态序列生成对话动作序列。

    对话策略方法论

    1 基于规则的对话策略

    对话策略最简单的方法论就是规则。如果用户是模糊查询,包含不确定性,就去问用户。如果不模糊,就生成对话动作去处理,每处理一块就生成一个对话状态的维度和特征。最后,判断是否需要回退到系统,如果需要就生成一个系统的回复,并更新对话历史和对话状态,否则不需要就回退到最开始的地方,采用一种澄清的方式让用户确认输入。如下图所示:

    在这里插入图片描述
    可以看到整个的方式其实就是一个比较偏向于规则的对话控制流程。在特定的领域或者特定比较小的任务上面,效果比较好。而且系统比较稳定,规定了这样的流程,规定了状态的转移的过程,就做的比较好;劣势也比较明显,动作状态序列都是固定的。算法与对话过程绑定,修改算法即修改对话过程。然后必须规规矩矩地按照系统的提示回答问题,否则流程就无法响应我们的需求。

    2 基于有限状态自动机的对话策略

    在这里插入图片描述

    整个过程就是把对话和对话状态之间的转移过程看成有限状态自动机,可以转换成一个树形结构。这种有穷状态自动机有什么好处呢?状态转移很容易设置,有状态转型的图模型,就转成树形的结构。整个系统是可预测的,适应用树状的策略决策模式。劣势也是比较显而易见的,跟ATIS没有特别大的区别,完全是系统主导的,人要配合系统,对话的状态不是特别灵活,用户没有回退的机制。

    3 基于表格的对话策略

    在这里插入图片描述

    用表格的形式表示对话的信息。整个过程有一个好处,我们人和机器可以混合主导,我们可以问机器一些问题,机器在这个过程当中也会问人的问题。不断地维护、更新表格的信息。表格上的信息有一个好处,我们可以更新。假如说这一轮说错了,下一轮还可以更新出来,这个更新的就在条目上。首先是混合主导,再就是容错性比较好且可更新。劣势是整个过程需要一个预设的脚本,就像我们说的系统生成的话都是预设的。根据什么样的上半句,拼接后半句,也不够灵活。

    4 基于脚本的对话策略

    在这里插入图片描述
    MIT的Galaxy2是通过脚本流控制的,表格的形式没有一个明确的结构的过程,是通过不断地更新的过程,最终找到上面还有什么信息,缺什么信息,更新了什么信息,最后给你什么信息。但是这个Galaxy2有一个明显的自顶向下的规划结构,把这个大的Domain意图当成server,然后把Domain下面的一些意图当成Program。对每一个下面的这些语义槽当成更下层的规则。最后针对每一个槽或者针对每一个意图规定了一些若干个操作,比如有输入操作,有检索操作,有存储操作,有输出操作。一个脚本化或者流化的对话控制就是这样一个过程。我们看每一个节点都是对话的动作,但是这种对话动作序列的过程不是自动化生成的过程,而是由脚本控制的。这个也是一样的,下边四个变量,rule是什么样的,Input、output怎么实现的。

    • 优势:任务扩展方便。多层的结构有点像现在的层次化或者是Domain到意图再到槽的自顶向下的构架,逻辑比较清晰,任务扩展相对方便一些。
    • 劣势:这些规则都是手工定义的,对话流控制需要预设,也没有可学习的过程。

    在这里插入图片描述

    5 基于规划的对话策略

    Wasson在1990年的时候给规划进行了一个定义,通过创建一个动作序列来实现某个目标的求解方法,并尝试预测执行该规划的效果。创建一个动作序列就是人机对话中的若干问题和若干回复,最终实现的目标是帮人完成相应的任务,后面的人就想能不能通过规划的方法来做对话策略的学习,也就是后面的基于规划的方法来求解对话策略学习的过程。
    在这里插入图片描述
    规划分三种:一种是固定的、静态的规划。比如,我们知道已有的数据里面,动作的序列是什么样的,就一条一条的把动作序列写出来,相对来说这种就比较的简单。当然如果写的规划库的数量足够多的话,其实鲁棒性还行;另一种是动态的规划。给定这样一个输入的序列,希望是一个整体的考虑,是建模联合分布,但是实际的过程中,我们其实可以进行Markov的假设,动态规划的过程就是给定若干个前续的动作序列,预测后续的动作序列是什么样的。这个过程就是通过规划的方式进行进行求解对话的过程;初次之外还有基于层次化的规划
    在这里插入图片描述
    这个可以看成是基于层次化的对话策略学习的,在规划版本上的扩展。把这个任务自顶向下做一个分解,这个里面涉及到了一个事儿,我要告诉有一个A同学,在寝室楼下阿姨这里来了一个电话,正好A的同寝的人来了,阿姨就说你告诉A同学说有电话找他。这个B同学就要做几件事情,第一件事情要知道A到底是在寝室,在洗澡间还是在厕所。知道A的位置之后就要走到A这块,说你有一个电话在楼下找你,就把这样整个任务分成了三个子任务。总体来说,这种层次化的方法,一方面有一个比较清晰脉络的逻辑。整个规划的方法从上层大的任务分解到子任务,子任务分解到操作,每一个都有相应的属性,跟之前的层次化的方法特别的像。这样的方法还是存在一定的问题,首先对系统的错误比较敏感,鲁棒性比较差。对话策略清晰归清晰,但是相对固定,灵活性不够。第三是策略和任务绑定,很难在任务间迁移,策略决策过程是和任务和领域是强相关的。

    6 基于概率的对话管理模型

    在这里插入图片描述
    最简单的一种方式,或者能够比较自然地应用这种策略矩阵求解概率化的方式就是强化学习。强化学习的框架也比较简单,主要有对话的Agent,这个里面有对话状态跟踪和对话学习两块。这个里面有Action,在对话里面就是对话的动作,这个对话的动作是问用户一个问题,或者跟用户确认一下信息,或者向用户展示一个信息。

    动作之后,还有就是用户会针对对话管理系统给出的动作进行一部分反馈,有的人把这块表示成大的就叫环境(Environment),也有的人把这块表示成Interpreter和一个Environment,这里面表示这两种形式都可以。但是这里面其实不光是Environment,还要对对话产生的动作进行一个表示,表示之后产生一个对话的奖励,回馈给对话系统。整个过程之中,除了Interpreter的奖励之外,还会产生对用户输入的识别以及对话状态的建模。Agent这边对话管理的动作实际是到Environment这块,出口是从Interpreter出去的。

    在这里插入图片描述
    我们把强化学习的比较粗的框架和我们的任务型对话的策略学习相关联的。Action就是对话的动作,系统产生什么样的话。针对用户产生的话,我产生什么反应,我是接受还是反馈,有一个相应的reward。整个对话管理对应着对话策略的优化过程。已有的基于强化学习的对话策略学习或者对话管理这个部分都完成哪些事呢?针对不同类型的,如果是闲聊的,问答的和任务型的,在强化学习框架下面,它的状态、动作、奖励都不大一样。

    比如,任务型的bot在强化学习的框架之下,这个对话状态就是用户当前的输入以及历史对话的上下文。这里面不一定是这种纯文本的方式,包括了前面的对话状态追踪过程当中对话的表示。这些动作其实刚才给大家解释地比较清楚了,系统采取什么样的方式回复,以及里面到底是否包含确认的话。例如,我跟用户确认是不是要订12月16日的航班,这是典型的确认的动作,这里还包含了12月16日信息槽的信息。整个动作之中,还包含着若干个对话的值,这个过程之中调一些API过来,这些都是一部分。

    我们从系统中已经拿到了这样一个动作之后,我们会给动作打一个分,或者系统会评论一个值,但是任务中,第一个事就是经过这样系统的反馈之后,我们对话到底成没成功,我帮你完没完成具体的任务,这个是指示性的信号,要么是0,要么是1。当然这个轮次要尽量的少,所以我们整个在任务型对话之中的状态、动作和奖励函数表达的是什么意思,我给大家简单的解释一下。

    我们关注的就是对话管理这一块,对话管理这一块我们主要关注于对话策略学习的过程。这里面涉及到怎么样去收集或者定义reward,怎么样优化状态和动作之间的关系,当然现在通常来说用的都是Q函数。
    在这里插入图片描述
    我们说基于强化学习的对话管理,通常来说有两个比较重要的过程。一个是我们怎么样让用户能够参与到整个系统的构建的过程中,现在比较火的就是叫Human-in-the-loop。当然这种方式有一种不好,就是确实耗时耗力,那我们不用它的话,初始系统化又不是太好。所以现在比较大的方向就是要有一定人的参与,但是又不能太耗费人力。另外就是怎么样定义对话奖励函数,两个方面,尽可能提高完成的任务成功率和尽可能的减少平均对话的函数。
    在这里插入图片描述
    如果用形式化的方式表示,这也是现在比较多的任务型对话奖励的形式,我们完成任务对话的之中,我们设置系统轮次最大值。我们给系统20轮机会,20轮之后再无法完成用户的任务就把你停掉,这个就是Nmax,取值就是0和1。这个N是我当前进行任务型对话的过程之中,我实际已经进行了多少轮,我们看什么时候是0呢?虽然最终成功了,达到了轮次,也是最大的轮次,这个时候20-20就是0。如果你用20轮,我只用10轮就搞定了,而且还成功了,这个R就是10,是比较大的数值。当然最好的就是1轮,但是这个不太可能。
    通过奖励函数的定义,就可以大概知道整个系统优化的方向是什么样的方向。最简单的方式,刚才也说整个大的背景就是概率的策略学习的框架下,采用强化学习的方式去做策略的估计和学习。最简单的方式我们就假设一下,好的方式是我们给定之前所有对话状态的联合分布和估计后面对话动作的分布。但是实际不大可能,因为计算量太大了,通常就会采用Markov假设,假设下一轮的动作只跟当前的对话状态有关系。这种情况下,自然而然地就用MDP的方式进行建模。
    在这里插入图片描述
    MDP建模对话策略的过程分为三个部分。这个策略矩阵就是对话状态和对话动作之间概率的对应关系。上面是转移函数,根据给定对话状态和给定这样当前轮次的对话轮次的动作,产生下一次对话状态是什么样的。我们可以看成是当前状态和下一个状态的转移过程。如果A有所有的对话空间的话,实际上就是一个分布,或者说我们可以把它取成一个从某一个对话状态所有的可能动作的估计。
    在这里插入图片描述
    最后是比较重要的奖励函数,通常来说,这个奖励函数都被估计成所有的奖励。在所有的动作状态空间之上,再估计的时候就是动作期望的值。后面的奖励函数就不那么简单了,是一个期望概率的估计值。这里面实际上策略矩阵就是对话策略,奖励函数就是对话策略学习优化的目标函数。
    在这里插入图片描述
    整个过程也比较简单,目标就是用MDP的方式给定对话状态序列,优化对话奖励函数。整个过程就是要建模期望,这个期望就是整个基于值迭代方式的这后半部分。这部分可以认为是奖励,这部分可以认为是状态转移的函数。

    整个过程可以采取值函数的方式,更自然的方式是采用Q函数的方式。最重要优化的方式就是用Q值来模拟给定当前的状态和当前的动作,然后求解能够使Q函数达到最大值A的过程。其实这整个过程跟我们对话策略优化的根本目标是一致的,根据这个状态求取这样一个对话动作,决策下一步回复给用户什么内容。
    在这里插入图片描述
    大家可能觉得这个对话状态可能是有穷的,对话动作也是有穷的,为什么要进行策略优化。比如,做好之后就查那个表,给定一个状态之后就查表里面哪一个动作的概率最大。但是通常来说不这么做,通常来说少量数据的情况下表是不准的。所以我们只能不断地训练去更新那个表,当然训练好了之后,实际应用过程中可以进行查表的,怎么样取样,怎么样变得更好。在实际的更新或者是学习过程中,这个对话状态和动作的组合空间是非常大的。
    在这里插入图片描述
    所有的问题都在于现在的空间大,精确估计转移函数非常难,要求期望的一部分,第一项就是转移函数的T,我们没有精确地估计这个转移函数,为什么呢?假如说有这样四个动作,这四个Action每一个slot,假如说这个slot有四个槽,这四个槽上面,每一个槽认为有多种取值,在日常中这是非常常见的。确认与否的有4个确认的动作,每一个动作的值上面也是已确认和不确认两种。这438也可以看成是438种情况,在这种动作和空间中组合一下看对话策略有多少种。这个状态空间就是2的8次方×438就是112128。也不要被理论上的状态空间吓倒,其实很多是无效的,通过预测的剪枝,大大缩小这个状态空间。但是仍然非常巨大,所以整个对话策略需要进行优化的。

    比较简单的方式就是我们用动态规划的方式。这有一个好处,大家学过算法都知道,动态规划有一个好处就是算过的东西不用再算了,下一次直接拿过来就行了。基本思想就是给定一个初始的对话策略,假如说每一个都是均匀分布的,都是1/N,给定一个初始化的状态之后,扫描整个对话状态和动作空间,从而递归地估计值函数。典型的方式就是值迭代的方式,通过后一个状态的值,定义前一个值,这种方法也是往前看一步,尽管当前的值不知道怎么回事,但是可以往前看。真正选择下一个状态的时候,递归往回带的时候,可以选择下一个状态里面值最大的状态把它带回去。当值函数被替代之后,不断地重复,直到把对话状态都计算一遍。
    在这里插入图片描述
    这里面还有一个问题,就是动态规划的方式,尽管可以通过策略缩小状态空间,缓解对话状态和动作空间巨大的事情。但是基本假设其实还是扫描整个的空间,可以通过剪枝,可以通过什么样的规则预先制定对话状态和动作之间的冲突方式,缩小这个状态空间。不管缩到多小,这种方法的特点就是要扫描整个状态空间。那能不能通过采样的方式部分的估计,通过部分的样本估计整个样本的分布。训练深度学习也会使用采样的方式,包括以前做LDA也是采样的方式估计的。
    在这里插入图片描述
    自然而然就想到能不能采样一下,不一定每一次都求全局最优解,就求最近的最优解就可以了。比如说利用随机的策略,随机的初始化对话的策略,我们用π表示对话的策略函数,对于序列中出现的训练数据中的(s,a)对,就是状态和动作之间的组合对,然后更新Q函数。这里面a*表示的是当前使得这个Q函数达到最大值的动作状态的A是什么样的。我们当前选择到A等于最优状态A的时候,我们就以这样对话的方式更新已有的矩阵。总之这是一种比较简单的方式,这种方式叫做epsilon-soft policy。大家更多的听见的是叫epsilon-greedy,但是这个epsilon-greedy跟这个类似。
    如果看epsilon-soft policy的更新策略,如果让这个epsilon趋近于0,就变成了什么呢?当a使得这个Q最大的时候,就让整个的动作对话状态是1,否则就是0。如果是采用这种方式,其实就不是概率性的空间,就是确定的。假如还是对话策略矩阵的话,本身能看到基本上都是经过行列交换,总能换出来若干个单位变向量组成的矩阵。当epsilon-soft policy趋近于0的时候,就是一个相对的对话策略。
    在这里插入图片描述
    刚才提到了我们要求当前的状态,求一个当前的Q函数值最大的动作。怎么样进行Q函数的更新,两种方式,也是通过采样的方式,第一种方式就是通过Monte Carlo采样的方式。这里面先查数,看这个已有的训练数据里面当前给定的状态和动作出现多少次,出现次数越多,当前给出这个动作的可能性就越大,执行度就越高。另外一个是实际上给定这样一个动作和这样一个状态之后,产生一个即时奖励是什么样的。这个即时奖励不是说往后看,不是像Alpha go似的,下一步棋看最终的胜利是多少,而是当前下一步棋,吃了你几个子,我就可以拿到一个reward,或者叫即时的reward。
    更新的过程就是一个平均采样的过程,因为除了一下当前的(s,a)出现对数的总和,我们Q函数的更新策略就是算一下当前的Q值得到了多少的奖励,然后把所有可能性都加到一起,再除以所有的可能性,整个Q就是更新的过程。另外一种更新的过程,当前的这一步的决策,不足以支撑我们选择最优的Q函数,再往后看一个状态,看一个动作,我们让这个动作和当前的Q函数之间的差值加上一个相应的因子,加上一个相应的参数再乘以相应的因子,更新这样的Q值。这个里面的α就是一个learning rate,是当时可调的参数,这里面的r就是给定当前动作的即时奖励。这里面最大的差别要么只看当前,要么我们往下看一下,差别就在这里。

    刚才讲到动态规划方法扫描动态空间比较费事,虽然达到全局的最优,后面采样的方法也可以达到一定的近似的解。这里面有人对比一下基于动态规划的方法和采样的方法。
    在这里插入图片描述
    其实这里面可以看到,动态规划的方法,要访问到很大很大的状态空间才能够准确地估计出规划策略的值。基于采样的方式我们就这么多对话状态和动作的空间之后,我们可能进行一个值估计,等到访问到的对话状态的空间到了动态规划初始空间的时候,采样的方式基本上达到最优了。整个采样的方式相对于动态规划的方式来讲还是比较高效的,能够在一个相对少的访问的对话状态和对话空间之上达到比较优化的方式。
    总结一下对话策略学习的方式有哪些优缺点。首先DP动态规划的算法要搜索整个状态空间,效率比较低,但是通常来说能够达到最优解。采样的方式不一定能够达到最优解,通过实际的图也可以看到实际的效果还成。另外采样的方法在通常的实际的过程中,不是一次采样就结束,需要多次采样的方式。如果这样采样的方式把人融合进来的话,或者拿到真实用户反馈情况的话,多次采样也不是很实际的。每次采样尽管比动态规划的方式访问的空间低,但是也有很大的状态空间,不能拿这样的状态空间进行反馈。所以我们说整个的实际理论上有真实用户参与学习的方式下,这种采样的方式也不是特别实际。有没有相对来说不需要人介入那么多,还能在整个过程当中比较实际应用起来的呢?既然真实的用户用不起来,我可以用一个模型进行左右互博来学习。这种方式,如果大家对阿尔法的算法有所了解,媒体上也宣传AlphaGo左右互博自我更新的过程,就是说的用户模拟器的过程。整个用户模拟器的动机就是没有办法用大量的人,即使是采样也没有办法进行在线的对话策略学习,产生对话状态你就给我一个分数,不切实际,成本比较高。
    在这里插入图片描述
    能不能用简单的方式训练一个模拟器,模拟器再去训对话模型。在整个过程中,相当于一个模型训另外一个模型。数据库有多少个空间,多少个槽的范围,通常来说对话的模型是知道的。这个模型就是所说的用户模拟的过程,怀揣着这样的意图,人的意图也可以通过这种方式告诉模型,如果用用户模拟器的话,就可以用最简单的方式,每一次都用熵值最大的槽,用这种方式不断地训对话模型,试错成本特别低。AlphaGo一晚上要下几万盘棋,而且它能够探索到很大的范围。我们说动态规划方式可以探索对话状态的空间,采样的方式没有办法探测整个空间。用户模拟的方式可以用低成本的方式去试,同时可以把整个的空间试到,不需要那么多人参与。讲了相对比较基础的对话策略基本的做法,以及我们怎么样去把人的因素考虑进来,怎么样让对话模型自己训练自己。
    通过刚才的介绍,看到有几方面。首先就是怎么样定义,或者怎么样初始化,怎么样更新这个对话的策略,以及采用什么样的Q函数去学习。我们有没有更优化一点的Q函数的学习方式?还有没有更客观的,就拿任务完成的方式和对话轮次的方式定义这个奖励函数,有没有更好一点的。比如说你同样是两个系统,以同样的任务完成率完成一个任务,用户就是喜欢用你的,但是已有的奖励函数就没有定义,所以我们想优化的方向,其中一个方向就是能不能够更好地定义更客观的一个奖励函数。最后一个方向,就是我们刚才说的对话模拟,我们怎么样让这个对话模拟器更接近于人。最简单的实现方式就是用这种有限状态自动机的方式去训练模拟器,用模拟器访问数据库,不断地问模型这个问题,整个过程中提升模型跟人的交互的能力。最后一个就是可能优化的方向,也是最近有进展的方向,就是能不能有更真实的对话模拟器。
    在这里插入图片描述
    接下来就是分四个工作分别介绍一下四个方向的进展。第一个进展就是更简单的对话策略学习的方式。现在随着2014年深度学习火起来,大家就给出一大套对话策略估计的方式,有深度学习,深度神经网络。能不能用深度神经网络的东西做这个事情,一个想法就是用单层的神经网络结构的对话策略学习器。最开始就是Policy network的方式,这个也是非常的纯粹,输入就是对话状态,输出就是对话动作,所有的智能都是参数里面蕴含着,整个架构就是这样的架构。然后我们忽略上面的NLG的过程,实际它的输入就是state,输出就是Act。每一个阶段是总归有少量的或者上千条的人人对话数据对,我拿它做一个初始化,初始化的过程中是有监督的学习,我们通过这种方式来学习到对话的动作的分布是什么样的,当前的Query里面蕴含着哪些slot也是用这个估计的,以及需要问用户哪些问题,每一个过程都是一个独立的二分类的过程,通过这样的方式先训练一下。再一个过程之中就有Policy的强化学习和方式,不断探索这个策略空间,就是初始化加上后学习的内容。
    在这里插入图片描述
    更优化的Q值函数,这个深度Q值网络,最深的时候就是AlphaGo的时候,这个Q函数之前的方式可以用值迭代的方式更新。但是有一个问题,我们怎么样来估计下一个状态S和给定这个A,下一个动作A1的奖励值。传统的方法可以用Bernoulli方程的方式去求解,但是时间复杂度特别高。深度神经网络出来之后,就想反正输入是一个状态和动作,你就要估计一个Q值,我用一个MLP行不行,就把这个对话策略学习形式变化一个前馈全连接网络,从而变得更加简单,不管什么参数都蕴含在W矩阵里面。当然这个训练过程中还是采样的方式,采用采样的方式,去更新那个π函数,我们说用Monte Carlo的方式来更新所有W的参数,这种方式也是后面提到的微软2018年发表的BBQ-learning的方式。
    在这里插入图片描述
    更加客观的奖励函数上面的进展。现在定义的奖励函数特别刚性,要么成功,要么不成功。同样成功的情况下,用户对哪一个系统更满意不知道。一个简单的方式就是把用户的满意度,用变量的方式,比如定五档,从1-5,5是最满意的,1是不那么满意的,2可能是稍微满意一点,3是满意,4是很满意,5是特别满意。把用户的成功率转化成满意度的方式,离散化的取值范围弄到奖励函数里面,这个奖励函数是原始没有变过奖励函数的变化形式,把原来的用对话成功率的方式建模,变成满意度的建模方式的时候,相对来说客观一点的奖励函数的时候,是可以通过这个方式是近似的。
    在这里插入图片描述
    更加真实的一个用户模拟器方面,也是微软提出来这样一个模型。原来要么是机器人,要么是人跟NLU,要么就是这个机器人,就叫对话模拟器,根据dialogue corpus去学,学完了之后不断地去训练dialogue model,人参与度不高。在整个框架下,分成左右两部分,第一部分是人教Simulator,整个过程中,投入很小的精力初始化,初始化之后就跟这边去学。人看到有一些状态和动作之间的转移方式不对,再去纠正它,再去训练它。通过这种分时分阶段的对话的模拟,能够训练更好的,就是Simulator和这个人越来越像。
    在这里插入图片描述
    对于任务型对话系统,在对话管理之后,就是对话生成的过程。对话生成的过程,也是在这样一个整体框图下面,这个对话管理之后已经产生了一个动作。假如说这个动作就是我们期望的动作,根据这个动作怎么样产生一个类似于人一样的回复呢?这种方式可以简单,也可以复杂。简单的方式,我们说可以整个从对话的动作到自然语言语句的过程任务是非常明确的。以前主要的步骤分为三步,一个是文本规划,生成句子的语义帧序列,再就是生成关键词、句法等结构信息,最后就是表层规划,生成辅助词及完整的句子。这个里面自然语言的生成不特指对话系统的自然语言生成,NLU那是一个大概念,只不过我们在对话系统里管的第一步也叫NLU。同样NLG也是比较大,生成新闻、评论,生成高考作文、公文、假新闻,这都是自然语言生成的过程。
    在这里插入图片描述
    还有比这个更简单的方法,是什么方法呢?就是写文本,反正对话动作是有限,询问出发地或者确认目的地,雇两个人写一条给一块钱,你就写吧,询问出发地。一个人写“您从哪里出发”,另一个同学写“请问您从哪里出发”,确认目的地还是两个人分别去写,当然这个里面会把相应的目的地的槽空出来。总之我们雇了一些人,就能够实现我们这个目的,假如对话系统够简单,我们再用比较简单的策略选择的过程的话,搭起任务型对话系统挺简单的,特点就是简单、机械,成本有点高,你得给标注者一定的钱,有多少人工就有多少智能。
    在这里插入图片描述
    其实通常来说,我们都不会这么做,最简单的方式就是流水线式规划生成自然语言生成。通过这种Dialogue manager已经产生了对话的动作,然后还是“三步走”,第一步生成一个语义帧的序列,这种序列里面包含着我要生成什么样的句子。我现在就要生成一个确认句子,确认句子之后,要生成一定的句法、关键词和结构化的成分,这个部分相当于把句子主干拼出来了。然后往这个里面塞助词、标点符号、感叹号,最终通过这个“三步走”的方式,把自然语言的句子分出来了。当然如果是一个语音对话系统,最后还要把文字转化成语音播出去,如果是文本的话,直接把完整句子反馈给用户就完事了。除了流水线式的规划的方式之外,因为我们说这是2001年左右的工作,后面到了2002年我们能不能用一些统计学习的方式代替一下部分的流水线的规划方法的某一个模块,就出现了这种方式。
    在这里插入图片描述
    统计学习方法能够事先决策。句子生成过程中,规划多少属性,以及属性的空间里面,我们要规划了若干个属性之后,具体挑哪几个进行规划的生成。整个过程有一个表层规划的过程,就是句子规划、表层规划和句子生成的过程。流程没有太大的变化,还是规划的“三步走”。但是表层规划上面,用统计语言模型进行训练之后,就变成了用n-gram的方式去训练,这是传统的统计模型。我们再用基于语言模型句子生成的方式,比如说这里面“吃苹果”就比“吃太阳”的概率高,我们在规划过程中生成“吃苹果”的概率就比较高。
    在这里插入图片描述
    最后再若干个生成。不止生成一个,有若干个候选。我们有一套规则生成若干个候选进行打分,这个规则包括但不限于:句子长度。包含的语义槽有合理的取值。如果生成的语义槽不给一个合适的值,你生成的句子是不完整的句子,可能也不太有特别高的分值。还有生成的语义槽是否是需要的,我最开始规划的属性你生成出来没有,或者你生出来不是规划范围之内,我们就可以认为你这个槽是不需要的。最终通过这种方式得到完整的自然语言的句子。

    后面到了深度学习的时代,这是2015年的时候,很自然的方式就是统计语言模型可能有一个局部的相关性。我们用RNN的方式建模整体的特性,用双向的RNN做了一下,整个过程分为两步走,跟规划的方式前两步捏在一起,前两步捏在一起之后,有一个去词汇化的过程,把这个槽和值抽出来,抽出来这样一个方式,抽成slot name和slot food这样的方式。通过这样的方式之后RNN建模,等到最后形式的时候,其实跟上一个自然语言生成的方式有点像,只不过最终用RNN生成模板,再通过对话已有的状态和对话采集到的语义槽的值,生成自然语言句子的时候,把值填进去。这个过程跟之前比较相似,但是比较好的就是采取了双向RNN的模式进行的语言模型的生成。
    在这里插入图片描述
    这个是双向的RNN,但是这个里面的每一个unit替换成了LSTM,加入了Domain Act,就是对话动作的信息。除了对话动作的信息,还加入了槽值对的信息,整个过程还是用双向的LSTM生成句子。把DA信号加进去主要加的是这部分。这个就是自然语言生成这部分,这部分没有特别多的工作,大家可能大部分的工作集中在NLU和DM方面。
    在这里插入图片描述
    随着技术发展的过程,把这种Pipeline的方式从头到尾的生成,走了一圈的技术模块把回复返回给用户。这个过程中有一个问题,在语音识别和自然理解过程当中有错误,这个错误传到DM这块就会叠加,DM再传到自然语言生成还会叠加,自然语言生成再往语音合成还会有错误,这就是错误累积的过程。能不能联合学习的方式,整个的错误累积的过程能不能用神经网络优化方式取代这种人工接待的方式。研究端到端学习的人就开始做工作了,端到端成为一个黑盒,整个系统不要那么多步骤。
    在这里插入图片描述
    实际的状态就是端到端的生成式对话模型,最开始可以看到的不是任务型的对话,是开放域的对话,是2016年蒙特利尔大学他们提出的模型叫做HRED的模型,这样一句话建模的时候,你可以从第一个词建模到最后一个词。如果你说给你一个对话历史,建模多轮的情况下,建模整个的对话历史,建立多轮的形式下,给我一个合理的回复,怎么样建立对话历史。他们就提出一个简单粗暴的方式,句子和句子之间也用RNN去Encoder。
    在这里插入图片描述
    HRED不是针对任务型对话做的,出来以后在开放域对话的表现还可以,没有那么多诟病,其实更好一点的方式不是以那种粗暴的建模方式去建。既然现在的深度学习发展的这么好,我们能不能用深度学习把Pipeline保留,但是我把Pipeline中的每一个部分都用深度神经网络去代替,比如说NLU用数据标注的方式去识别,用MLP的方式去识别意图,填充槽。整个的Policy network这块因为也提出来过基于深度学习,对话策略学习的方式。自然语言生成的方式也可以用RNN的方式学习。可以串联在一起,虽然不是完完整整的端到端的过程,但是每一个过程都是端到端。当然用的就是CNN+RNN的方式。这个句子模板也是用Attention-based RNN实现的。
    在这里插入图片描述
    除了深度学习之外,大家也知道这个强化学习,能不能用Pipeline的方式在结合过程当中,错误累积尽可能的少。微软他们提出来的工作框架比较好,唯一的不好在于所有的工作都是拿已有的工作做的。这个是模板+生成的方式,这个是基于LSTM的序列标注模型,这个是符号化输出,这个是基于规则初始化的多层感知机,这个工作唯一的创新就是提出了强化学习的框架,但是里面任何的东西都是用的别人的。整合到一起也是不错的方式,第一次实现了除了模块内部是端到端可学习的过程之外,把若干个模块之间用强化模式串联起来了。
    在这里插入图片描述
    为了想做到完全的端到端,Eric和Manning提出了一个完整的端到端模型和相关的数据集。这种模型不把语义槽东西显式建模,把任务型拆成若干个单轮对话。问你一个问题回答一个槽,把整个过程当中一个一个离散化,变成了用Seq2Seq的模型一步一步的生成。生成过程之中会用注意力的机制,在解码过程中会选当前的输出。因为有一个数据库,这个数据可以认为是所有的任务型对话的数据,无论是状态还是取值的可能性,都包含在数据表达里面。解码的时候就想,解码这句话的时候究竟是从用户输入的词里面拷贝,还是在给定的候选的数据库里面揪一个词出来的过程。整个过程就变成了一个Seq2Seq的过程,生成的话还是像任务型的这种方式。
    在这里插入图片描述
    后续的能不能不采用这种方式去决策,每一个过程当中到底是拷贝值还是生成值。数据库里面的词是有限的,把那些词都拿出来,解码的过程中,每生成一个词看解码,是从正常的词表中做decoder,如果判断出来是在后面数据中的词做decoder,实际上就把整个任务型问用户槽的特征加入到了这样一个回复之中,也是关键词的方式进行的一个生成过程。
    在这里插入图片描述
    既然有若干个数据库里面的值,能不能采用一种更有意思的方式,先把用户输入表示成一个对话的状态。当然我们说这个里面可以考虑更长的上下文,整个任务型对话进行了10轮了,我们把10轮对话的历史表示成对话的状态,对话建模的过程可以用Seq2Seq的方式建模。表示成对话状态的分布之后,我们把可能用到的数据库里面的unit的值拿出来进行表示。表示成之后,进行一个联合的拼接,拼接了之后,加入了decoder的也包含了可能用到的数据库里面的Unit的值。利用检索的方式,结合Seq2Seq的方式建立多轮的对话。
    在这里插入图片描述
    这个不足就在于可能对于检索回来的Unit的里面值,一个unit对应一个entry,有一个问题,解码出来的值。尽管对应的是这样的条目,但是我们解码中,因为我们是一个unit一个unit去建模的,因为建模了所有的unit,解码这个东西的时候,不一定真正的能把它拿出来,在解码具体值的时候,就用错相应的数据里面的值,对于我们生成的过程是有问题的。整个这个过程,我们在数据库或者Interpreter建模之下,我们加一个约束。只让它在确定的某一行之后,在这一行里面决定用哪一个Unit的值参与到解码过程之中。这个工作的模型图就是这样的。整个过程采用的训练方式就是知识库检索部分是采用无标注的训练数据,我们检索出来哪一个是知识库需要的数据不一定。采用两种训练的方式,第一种就是规则式的训练方式,用检索模型去检索,检索最多的,每一次检索的时候都有几列,如果整个队列出来比较多的列,我搜索十次有五次就对应到其中一个列,我们就认为这个列就是我们当前的Query对应的结果,通过这种方式就实现了无标注。除了这种方式之外,我们假如检索了10次,有5次就是同一个,那那个就是1,上面的就是0,这种1、0的这种方式就导致了训练过程中不可微的问题,比较简单的解决方法就是把1、0的方式进行建模。建模的方式就变成了5次是相应的过程定义成0.9,的剩下五次定义成0.002的方式,通过这种Gumbel-Softmax的方式进行连续化的表示,使之变成了可微的过程。通过这种方式,看到都能提升一定的效果,利用这个Gumbel-Softmax的方式会提升更高。
    在这里插入图片描述
    最后总结一下端到端任务型对话系统的状态。任务型对话系统整体的基本框架还是没有变。但是在端到端这块的努力,最有效的尝试就是在每一个过程当中用一个端到端的模型去训练,但是整体上面要么用Pipeline的方式,要么用强化学习串起来,每一个模块都进行统计化、学习化,模块之间的联系仍然存在而且必要。
    在这里插入图片描述
    任务型对话系统这么多模块,怎么去评价是另一方面。第一方面就是评价什么,这个任务型对话系统中哪些需要评价,其实每一个过程都需要评价。这里面就涉及到整体和部分之间评价的关系,整体上面其实我们也之前也说到了,整个任务型对话系统优化两个大的方向,一个是对话成功率,一个是平均对话轮数。其实整个过程之中,既然有这样优化的目标,相对来说就有一个这样的客观评价的指标。
    在这里插入图片描述
    这个就是我们对话奖励优化的目标和方向,这两个就是一个客观的指标。我们也说了更优的奖励函数是考虑到主观指标就是人的用户满意度,把用户满意度离散化,离散成若干值,这个用户满意度就是刚才所列的交互的质量,就是IQ的值。我们说用户满意度可以是一个连续值,也可以是一个离散的值,我们如果把它弄成离散的1-5的值,跟客观的指标有对应的关系,能够建立不同的用户满意度的不同的奖励函数。

    介绍完整体的评价之后,介绍分布的评价,这个NLU就是为了得到语义帧,意图也有相应的识别,语义槽也有相应的识别,整体的评判可以在Frame Acc过程里面做。DM的过程,对话管理分成两个大的部分,一个是对话状态追踪,一个是对话策略优化,对话状态识别包括这个里面有主题的对话行为和对话类型的识别。对话策略优化,优化的还是两个部分,最终的对话成功率,因为没有单独的对话奖励函数的方向进行评价。
    在这里插入图片描述
    自然语言生成这块,就是NLG也有一定评价的方式。但是NLG看成语言模型的方式,评价指标可以采用语言模型的评价指标,这里面用的比较多的有几个统计的指标,包括字符串级别的,还有语义级别的。这个也有一个问题,这里面所有的字符串级别的评价指标是从机器翻译和文档文摘摘要借鉴过来的,是否适合对话生成这样的任务,我们值得商榷。当然也有人讨论过,如何不用这个评价指标来评价,他们觉得这些指标和人主观评价指标相关性比较差。更合理的方式就是用主观的方式叫几个人过来打分,这种方式比较费时费力,目前来说生成式的对话评价比较难,当然这一块也是持续可以做的方向。

    最后我们给一些对话技术评测的介绍,每一个相应的评测都有相应的数据集,如果感兴趣的话可以下载这样的数据集做做这样的任务。
    在这里插入图片描述
    最后介绍一下我们中文人机对话技术评测,我们举办第三年了,联合了科大讯飞和华为。这里面有几个任务,每一年推出两个任务。第一个就是用户意图分类,对于一个对话系统或者任务型对话系统来说,不可能就处理一个领域的事,手机上的Siri可以让它查天气,可以搜索,还可以问有没有日历或者信息的需求。我们认为每一个东西都是一个Domain。Siri要做的第一件事就是我们要分到哪一个Domain去处理,如果查天气一定不能弄到定闹钟那里去,我们就想做这个任务。科大讯飞第一次给我们的数据,相对来说比较简单,我们有31个类。两个大类要么是聊天,要么是任务类。任务类下面细分为30个垂直领域,你给我讲一个笑话,还是讲一个故事都算是一个垂直的领域。实际上这个任务就是做31分类的任务。
    在这里插入图片描述
    第二个就是比较难,让你搭一个完整的对话系统。我们评测的过程都是由科大讯飞语音资源部的人员评测,真的是人工的评测,哪一个任务型对话系统比较好。然后我们给定了大概三个领域,机票、火车票和酒店。给它已有的讯飞的数据库,数据库里面包含很多酒店、机票和火车票的信息。评价的难点在于给定相同的输入的时候,即使是同一个人,跟不同的系统聊的时候,系统的反馈不一样,很难在两个对话片断上通过客观的方式上判断哪一个好,哪一个不好。只能使用人工评价,这就是用了大量的人力来做这个事,就是为了保证整个评测数据比较客观。
    在这里插入图片描述
    数据也是提供完整的用户意图,描述事例和静态的数据集、数据库。我们这里面也设置了最大的轮数50轮,即Nmax我们设置成50。对参赛队伍的容忍度还是很高的,一般都是设20,我们是设50。另外一个评价指标除了客观的对话轮数和完成度之外,我们还有四个指标。第一个指标是用户的满意度,还有一个是回复语言的自然度。另外我们问到了你这个数据库里面没有的值,或者没有的领域之后,你整个对话系统能不能够合理的引导或者拒绝我这个问题,这个也是一个评价的指标。
    我们今年换了两个任务,提升了任务的难度,任务1不再是领域分类,而是要做领域、意图、语义槽的识别。这个特别难,跟我们以前说的任务1来说任务增加了很多的难度,我们评测的指标也比较严苛,要让这些全做对才叫对。最终我们看一下指标,出门问问在Domain上面刷了到了0.9分,全体的ACC能达到0.61,这个是整个参赛队伍整体的排名。
    在这里插入图片描述
    最后对我们今天讲的任务型对话做一个总结和展望可能的趋势。我们今天从自然语言理解讲到对话管理和对话状态追踪,也说到了多领域和多语言的趋势,这个也是特别重要的。我从对话策略开始讲,从规则到规划到概率再到神经网络的方式。我们也给了自然语言生成和端到端的进展,紧接着讲了评价的方式。最后我们给出一些展望,自然语言理解有多任务学习的方式,融合外部知识,知识的引入,另外还有就是结合上下文自然语言理解的推断。对话状态跟踪这一块都是神经网络的方式,但是除了单独的技术发展趋势之外,NLU和DST联合建模的时候也有。对话策略学习这块, BBQ-learning怎么采样,怎么更新的,用什么样的方式去做这个事情。除了本领域以外,一个Domain之内可以进行一个跨领域、跨任务的学习,包括策略学习和端到端自然语言的生成的结合。整个的发展趋势,从流程优化到模型泛化再到端到端是一个大的趋势,但是端到端不是那么自然的。先是NLU与DST的结合,然后是PL与NLG的联合。
    在这里插入图片描述

    展开全文
  • 人机对话系统具有四大功能 人机对话系统又分下面这三方面:自然语言理解、对话管理、自然语言生成。这里面聊天、知识、任务、推荐,都有各自相应的研究点。具体内容请看PPT。 对话管理(Dialog Management, DM)是...

    人机对话系统具有四大功能
    在这里插入图片描述人机对话系统又分下面这三方面:自然语言理解、对话管理、自然语言生成。这里面聊天、知识、任务、推荐,都有各自相应的研究点。
    在这里插入图片描述


    对话管理(Dialog Management, DM)是对话流程中的核心环节,充当了重要的角色。如图1所示:
    Dialog Management

    图1 对话流程图

    图1 是常见对话流的信息流动图。 首先,用户发出语音指令,1)通过语音识别ASR将语音转换为文本uu; 2) 文本通过语言理解NLU获得用户行为au; 3)通过用户行为生成对应系统行为au; 4)通过action生成对应的回复话术NLG; 5) NLG通过人工合成生成语音。

    Dialog Management

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

    对话管理包括如下任务:

    • 对话状态维护(dialog state tracking, DST)
      维护 & 更新对话状态
      t+1 时刻的对话状态 st+1,依赖于之前时刻 t 的状态st,和之前时刻 t 的系统行为at,以及当前时刻 t+1 对应的用户行为at+1。可以写成 s t + 1 ← s t + a t + o t s_{t+1}\leftarrow s_{t} + a_{t} +o_{t} st+1st+at+ot
    • 生成系统决策(dialog policy)
      根据 DST 中的对话状态(DS),产生系统行为(dialog act),决定下一步做什么
      dialog act 可以表示观测到的用户输入(用户输入 -> DA,就是 NLU 的过程),以及系统的反馈行为(DA -> 系统反馈,就是 NLG 的过程)
      DA 的具体介绍将在 NLU 系列中展开
    • 作为接口与后端/任务模型进行交互
    • 提供语义表达的期望值(expectations for interpretation)
      interpretation: 用户输入的 internal representation,包括 speech recognition 和 parsing/semantic representation 的结果

    本质上,任务驱动的对话管理实际就是一个决策过程,系统在对话过程中不断根据当前状态决定下一步应该采取的最优动作(如:提供结果,询问特定限制条件,澄清或确认需求…)从而最有效的辅助用户完成信息或服务获取的任务
    在这里插入图片描述
    如图,DM 的输入就是用户输入的语义表达(或者说是用户行为,是 NLU 的输出)和当前对话状态,输出就是下一步的系统行为和更新的对话状态。这是一个循环往复不断流转直至完成任务的过程,其中,语义输入就是流转的动力,DM 的限制条件(即通过每个节点需要补充的信息/付出的代价)就是阻力,输入携带的语义信息越多,动力就越强;完成任务需要的信息越多,阻力就越强。

    case 1
    在这里插入图片描述
    实际上,DM 可能有更广泛的职责,比如融合更多的信息(业务+上下文),进行第三方服务的请求和结果处理等等。

    Initiative

    对话引擎根据对话按对话由谁主导可以分为三种类型:

    • 系统主导
      系统询问用户信息,用户回答,最终达到目标
    • 用户主导
      用户主动提出问题或者诉求,系统回答问题或者满足用户的诉求
    • 混合
      用户和系统在不同时刻交替主导对话过程,最终达到目标
      有两种类型,一是用户/系统转移任何时候都可以主导权,这种比较困难,二是根据 prompt type 来实现主导权的移交
      Prompts 又分为 open prompt(如 ‘How may I help you‘ 这种,用户可以回复任何内容 )和 directive prompt(如 ‘Say yes to accept call, or no’ 这种,系统限制了用户的回复选择)。

    Basic concepts

    • Ground and Repair
      对话是对话双方共同的行为,双方必须不断地建立共同基础(common ground, Stalnaker, 1978),也就是双方都认可的事物的集合。共同基础可以通过听话人依靠(ground)或者确认(acknowledge)说话人的话段来实现。确认行为(acknowledgement)由弱到强的 5 种方法(Clark and Schaefer 1989)有:持续关注(continued attention),相关邻接贡献(relevant next contribution),确认(acknowledgement),表明(demonstration),展示(display)。

    听话人可能会提供正向反馈(如确认等行为),也可能提供负向反馈(如拒绝理解/要求重复/要求 rephrase等),甚至是要求反馈(request feedback)。如果听话人也可以对说话人的语段存在疑惑,会发出一个修复请求(request for repair),如

    A: Why is that?
    B: Huh?
    A: Why is that? 
    

    还有的概念如 speech acts,discourse 这类,之前陆陆续续都介绍过一些了。
    人的复杂性(complex)、随机性(random)和非理性化(illogical)的特点导致对话管理在应用场景下面临着各种各样的问题,包括但不仅限于:

    Challenges

    模型描述能力与模型复杂度的权衡

    • 用户对话偏离业务设计的路径
      如系统问用户导航目的地的时候,用户反问了一句某地天气情况
    • 多轮对话的容错性
      如 3 轮对话的场景,用户已经完成 2 轮,第 3 轮由于ASR或者NLU错误,导致前功尽弃,这样用户体验就非常差
    • 多场景的切换和恢复
      绝大多数业务并不是单一场景,场景的切换与恢复即能作为亮点,也能作为容错手段之一
    • 降低交互变更难度,适应业务迅速变化
    • 跨场景信息继承

    Approaches

    1) Structure-based Approaches

    1. Key Pharse Reactive Approaches
      本质上就是关键词匹配,通常是通过捕捉用户最后一句话的关键词/关键短语来进行回应,比较知名的两个应用是 ELIZA 和 AIML。AIML (人工智能标记语言),XML 格式,支持 ELIZA 的规则,并且更加灵活,能支持一定的上下文实现简单的多轮对话(利用 that),支持变量,支持按 topic 组织规则等。
    <category>
    <pattern>DO YOU KNOW WHO * IS</pattern> 
    <template><srai>WHO IS <star/></srai></template> 
    </category>
    
    <category>
    <pattern>MOTHER</pattern>
    <template> Tell me more about your family. </template> 
    </category>
    
    <category>
    <pattern>YES</pattern>
    <that>DO YOU LIKE MOVIES</that> 
    <template>What is your favorite movie?</template> 
    </category>
     
    
    1. Trees and FSM-based Approaches
      Trees and FSM-based approach 通常把对话建模为通过树或者有限状态机(图结构)的路径。 相比于 simple reactive approach,这种方法融合了更多的上下文,能用一组有限的信息交换模板来完成对话的建模。这种方法适用于:
    • 系统主导
    • 需要从用户收集特定信息
    • 用户对每个问题的回答在有限集合中
      这里主要讲 FSM,把对话看做是在有限状态内跳转的过程,每个状态都有对应的动作和回复,如果能从开始节点顺利的流转到终止节点,任务就完成了。
      在这里插入图片描述
      在这里插入图片描述

    FSM 的状态对应系统问用户的问题,弧线对应将采取的行为,依赖于用户回答。

    FSM-based DM 的特点是:

    • 人为定义对话流程
    • 完全由系统主导,系统问,用户答
    • 答非所问的情况直接忽略
    • 建模简单,能清晰明了的把交互匹配到模型
    • 难以扩展,很容易变得复杂
    • 适用于简单任务,对简单信息获取很友好,难以处理复杂的问题
    • 缺少灵活性,表达能力有限,输入受限,对话结构/流转路径受限

    对特定领域要设计 task-specific FSM,简单的任务 FSM 可以比较轻松的搞定,但稍复杂的问题就困难了,毕竟要考虑对话中的各种可能组合,编写和维护都要细节导向,非常耗时。一旦要扩展 FSM,哪怕只是去 handle 一个新的 observation,都要考虑很多问题。实际中,通常会加入其它机制(如变量等)来扩展 FSM 的表达能力。

    2) Principle-based Approaches

    1. Frame-based Approaches
      Frame-based approach 通过允许多条路径更灵活的获得信息的方法扩展了基于 FSM 的方法,它将对话建模成一个填槽的过程,槽就是多轮对话过程中将初步用户意图转化为明确用户指令所需要补全的信息。一个槽与任务处理中所需要获取的一种信息相对应。槽直接没有顺序,缺什么槽就向用户询问对应的信息。
      在这里插入图片描述
      Frame-based DM 包含下面一些要素:

    Frame: 是槽位的集合,定义了需要由用户提供什么信息
    对话状态:记录了哪些槽位已经被填充
    行为选择:下一步该做什么,填充什么槽位,还是进行何种操作
    行为选择可以按槽位填充/槽位加权填充,或者是利用本体选择
    基于框架/模板的系统本质上是一个生成系统,不同类型的输入激发不同的生成规则,每个生成能够灵活的填入相应的模板。常常用于用户可能采取的行为相对有限、只希望用户在这些行为中进行少许转换的场合。

    Frame-based DM 特点:

    • 用户回答可以包含任何一个片段/全部的槽信息
    • 系统来决定下一个行为
    • 支持混合主导型系统
    • 相对灵活的输入,支持多种输入/多种顺序
    • 适用于相对复杂的信息获取
    • 难以应对更复杂的情境
    • 缺少层次
      槽的更多信息可以参考填槽与多轮对话 | AI产品经理需要了解的AI技术概念

    Agenda + Frame(CMU Communicator)

    Agenda + Frame(CMU Communicator) 对 frame model 进行了改进,有了层次结构,能应对更复杂的信息获取,支持话题切换、回退、退出。主要要素如下:

    • product
      树的结构,能够反映为完成这个任务需要的所有信息的顺序
      相比于普通的 Tree and FSM approach,这里产品树(product tree)的创新在于它是动态的,可以在 session 中对树进行一系列操作比如加一个子树或者挪动子树
    • process
      • agenda
        相当于任务的计划(plan)
        类似栈的结构(generalization of stack)
        是话题的有序列表(ordered list of topics)
        是 handler 的有序列表(list of handlers),handler 有优先级
      • handler
        产品树上的每个节点对应一个 handler,一个 handler 封装了一个 information item

    从 product tree 从左到右、深度优先遍历生成 agenda 的顺序。当用户输入时,系统按照 agenda 中的顺序调用每个 handler,每个 handler 尝试解释并回应用户输入。handler 捕获到信息就把信息标记为 consumed,这保证了一个 information item 只能被一个 handler 消费。

    input pass 完成后,如果用户输入不会直接导致特定的 handler 生成问题,那么系统将会进入 output pass,每个 handler 都有机会产生自己的 prompt(例如,departure date handler 可以要求用户出发日期)。

    可以从 handler 返回代码中确定下一步,选择继续 current pass,还是退出 input pass 切换到 output pass,还是退出 current pass 并等待来自用户输入等。handler 也可以通过返回码声明自己为当前焦点(focus),这样这个 handler 就被提升到 agenda 的顶端。为了保留特定主题的上下文,这里使用 sub-tree promotion 的方法,handler 首先被提升到兄弟节点中最左边的节点,父节点同样以此方式提升。
    在这里插入图片描述
    系统还能处理产品树中节点之间的依赖关系。典型的依赖关系在父节点和子节点之间。通常父节点的值取决于其子节点。每个节点都维护一个依赖节点的列表,并且会通知依赖节点值的变化,然后依赖节点可以声明自己是无效的并成为当前对话的候选主题。

    给一个例子,能够回应用户的显式/隐式话题转移(A1-A3, U11),也能够动态添加子树到现有的 agenda(A8-A10)。
    在这里插入图片描述
    具体还是看论文吧
    AN AGENDA-BASED DIALOG MANAGEMENT ARCHITECTURE FOR SPOKEN LANGUAGE SYSTEMS

    Information-State Approaches

    Information State Theories 提出的背景是:

    • 很难去评估各种 DM 系统

    • 理论和实践模型存在很大的 gap
      理论型模型有:logic-based, BDI, plan-based, attention/intention
      实践中模型大多数是 finite-state 或者 frame-based
      即使从理论模型出发,也有很多种实现方法
      因此,Information State Models 作为对话建模的形式化理论,为工程化实现提供了理论指导,也为改进当前对话系统提供了大的方向。Information-state theory 的关键是识别对话中流转信息的 relevant aspects,以及这些成分是怎么被更新的,更新过程又是怎么被控制的。idea 其实比较简单,不过执行很复杂罢了。理论架构如下:
      在这里插入图片描述
      介绍下简单的一些要素:

    • Statics

      • Informational components
        包括上下文、内部驱动因子(internal motivating factors)
        e.g., QUD, common ground, beliefs, intentions, dialogue history, user models, etc.
      • Formal representations
        informational components 的表示
        e.g., lists, records, DRSs,…
    • Dynamics

      • dialog moves
        会触发更新 information state 的行为的集合
        e.g., speech acts
      • update rules
        更新 information state 的规则集合
        e.g., selection rules
      • update strategy
        更新规则的选择策略,选择在给定时刻选用哪一条 update rules
        意义在于可以遵循这一套理论体系来构建/分析/评价/改进对话系统。基于 information-state 的系统有:
        TrindiKit Systems
        –  GoDiS (Larsson et al) – information state: Questions Under Discussion
        –  MIDAS – DRS information state, first-order reasoning (Bos &Gabsdil, 2000)
        –  EDIS – PTT Information State, (Matheson et al 2000)
        –  SRI Autoroute –Conversational Game Theory (Lewin 2000)
        Successor Toolkits
        –  Dipper (Edinburgh)
        –  Midiki (MITRE)
        Other IS approaches
        –  Soar (USC virtual humans)
        –  AT&T MATCH system

    Plan-based Approaches

    一般指大名鼎鼎的 BDI (Belief, Desire, Intention) 模型。起源于三篇经典论文:

    • Cohen and Perrault 1979
    • Perrault and Allen 1980
    • Allen and Perrault 1980
      基本假设是,一个试图发现信息的行为人,能够利用标准的 plan 找到让听话人告诉说话人该信息的 plan。这就是 Cohen and Perrault 1979 提到的 AI Plan model,Perrault and Allen 1980 和 Allen and Perrault 1980 将 BDI 应用于理解,特别是间接言语语效的理解,本质上是对 Searle 1975 的 speech acts 给出了可计算的形式体系。

    官方描述(Allen and Perrault 1980):

    A has a goal to acquire certain information. This causes him to create a plan that involves asking B a question. B will hopefully possess the sought information. A then executes the plan, and thereby asks B the question. B will now receive the question and attempt to infer A’s plan. In the plan there might be goals that A cannot achieve without assistance. B can accept some of these obstacles as his own goals and create a plan to achieve them. B will then execute his plan and thereby respond to A’s question.

    重要的概念都提到了,goals, actions, plan construction, plan inference。理解上有点绕,简单来说就是 agent 会捕捉对 internal state (beliefs) 有益的信息,然后这个 state 与 agent 当前目标(goals/desires)相结合,再然后计划(plan/intention)就会被选择并执行。对于 communicative agents 而言,plan 的行为就是单个的 speech acts。speech acts 可以是复合(composite)或原子(atomic)的,从而允许 agent 按照计划步骤传达复杂或简单的 conceptual utterance。

    这里简单提一下重要的概念。

    • 信念(Belief)
      基于谓词 KNOW,如果 A 相信 P 为真,那么用 B(A, P) 来表示
    • 期望(Desire)
      基于谓词 WANT,如果 S 希望 P 为真(S 想要实现 P),那么用 WANT(S, P) 来表示,P 可以是一些行为的状态或者实现,W(S, ACT(H)) 表示 S 想让 H 来做 ACT

    Belief 和 WANT 的逻辑都是基于公理。最简单的是基于 action schema。每个 action 都有下面的参数集:

    • 前提(precondition)
      为成功实施该行为必须为真的条件
    • 效果(effect)
      成功实施该行为后变为真的条件
    • 体(body)
      为实施该行为必须达到的部分有序的目标集(partially ordered goal states)

    计划推理(Plan Recognition/Inference, PI)
    根据 B 实施的行为,A 试图去推理 B 的计划的过程。

    • PI.AE Action-Effect Rule(行为-效果规则)
    • PI.PA Precondition-Action Rule(前提-行为规则)
    • PI.BA Body-Action Rule(体-行为规则)
    • PI.KB Know-Desire Rule(知道-期望规则)
    • E1.1 Extended Inference Rule(扩展推理规则)

    计划构建(Plan construction)

    找到从当前状态(current state)达到目标状态(goal state)需要的行为序列(sequence of actions)
    Backward chaining,大抵是说,试图找到一个行为,如果这个行为实施了能够实现这个目标,且它的前提在初始状态已经得到满足,那么计划就完成了,但如果未得到满足,那么会把前提当做新的目标,试图满足前提,直到所有前提都得到满足。(find action with goal as effect then use preconditions of action as new goal, until no unsatisfied preconditions)
    backward chaining 在 NLP 笔记 - Meaning Representation Languages 中提到过。
    还有个重要的概念是 speech acts,在 NLP 笔记 - Discourse Analysis 中提到过,之后会细讲。

    更多见 Plan-based models of dialogue

    值得一提的是,基于 logic 和基于 plan 的方法虽然有更强大更完备的功能,但实际场景中并不常用,大概是因为大部分的系统都是相对简单的单个领域,任务小且具体,并不需要复杂的推理。

    Statistical Approaches

    1. RL-Based Approaches
      前面提到的很多方法还是需要人工来定规则的(hand-crafted approaches),然而人很难预测所有可能的场景,这种方法也并不能重用,换个任务就需要从头再来。而一般的基于统计的方法又需要大量的数据。再者,对话系统的评估也需要花费很大的代价。这种情况下,强化学习的优势就凸显出来了。RL-Based DM 能够对系统理解用户输入的不确定性进行建模,让算法来自己学习最好的行为序列。首先利用 simulated user 模拟真实用户产生各种各样的行为(捕捉了真实用户行为的丰富性),然后由系统和 simulated user 进行交互,根据 reward function 奖励好的行为,惩罚坏的行为,优化行为序列。由于 simulated user 只用在少量的人机互动语料中训练,并没有大量数据的需求,不过 user simulation 也是个很难的任务就是了。
      在这里插入图片描述

    参考文献

    展开全文
  • 当时的我觉得,对话系统要给这个世界带来一波重要的变革了,它将是最能让大众体验人工智能技术的产品了。 抱着这个坚(天)定(真)的信念,先是轻松屠了当年某知名的智能客服天池竞赛的榜单,然后义无反顾的将简历...

    点击上方,选择星标,每天给你送干货!


    文 | 兔子酱
    编 | 夕小瑶

    源 | 夕小瑶的卖萌屋

    大家好,我是可盐可甜的兔子酱,一枚卖萌屋的资深潜水小编,今天终于有了自己的第一篇文章,希望耗时一周撰写的本文能让大家有所收获~

    这篇文章,算是对自己在头部大厂2年算法岗炼丹经历的一个经验浓缩和总结(不算实习的话实际是工作一年多的萌新)。时间倒退到2018年,从我找算法岗实习开始,先问两个问题暖个身:

    Q1: 2018年工业界最火的算法岗是什么?

    答:CV、NLP、推荐。

    Q2: 2018年工业界招人最多的NLP方向是什么?

    答:对话系统、机器翻译。

    虽然读研的我沉溺于做着文本表示、模型鲁棒性相关的工作,但是,一方面目睹了小度、天猫精灵、小爱同学为代表的C端对话产品正面厮杀,另一方面领略了10086和各大银行APP里宛如智障般的智能客服和“正在接入人工客服,您前面还有999+人”。当时的我觉得,对话系统要给这个世界带来一波重要的变革了,它将是最能让大众体验人工智能技术的产品了。

    抱着这个坚(天)定(真)的信念,先是轻松屠了当年某知名的智能客服天池竞赛的榜单,然后义无反顾的将简历投到了那个将AI、对话作为公司核心战略的大厂。很开心,顺利拿到了实习和秋招提前批special offer。没成想,最想去的团队,一下子就去了,以至于事后都有些遗憾没体验过其他小伙伴口中惊心动魄的秋招。

    至此,我与对话系统的故事正式开始了。

    谈谈对话这个“顶流”行业

    先简单介绍下全球视角下的工业界对话产品发展史吧,行内的小伙伴可以快速跳过。

    2011年,世界闻名的人机大战主角——IBM的Wastson,在智力竞猜节目中战胜人类,向全世界宣告了计算机拥有了自然语言理解能力和人机对话能力。同年,乔布斯收购Siri,Siri担起了苹果向AI领域进军的大旗,作为智能数字助理搭载在iPhone上。2014年,微软在中国区发布会上发布了第一款个人智能助理Cortana(中文名小娜);同年,亚马逊推出自己的智能语音助理Alexa和智能音箱Echo,凭借新颖性和稳定性迅速占据了全球市场。2016年谷歌也完成了它的对话产品-谷歌assistant。

    到了2017年,中国本土的对话产品开始觉醒、登场。17年下半年,阿里的天猫精灵、小米的小爱同学正式推出,2018年,百度的小度智能音箱,以及华为AI音箱相继跟上,这些头部大厂率先抢占了市场和人心,而后第二梯队的思必驰、出门问问等产品又进一步参与了对话市场的瓜分。

    初露锋芒

    看起来一片欣欣向荣啊,怎么会跟“凉”扯上关系呢?

    首先,C端对话产品成本巨大但盈利空间不明朗,加上激烈的市场竞争,一边是用户打开了新世界的大门,直呼nb!另一边,企业在头疼变现手段,在线广告?电商推荐?会员付费?硬件输出?似乎传统的商业模式在这个场景下都能搞搞,仔细一看又发现似乎都不太能大搞。

    长期高额的技术投入却得不到真金白银的反馈,怎么办呢?于是企业将目光投向了B端市场。电信运营商、银行、政务司法、能源电力等各大传统行业都需要部署大量的人工客服,客服就是一个天然的对话场景,如果用对话技术替代掉人工坐席,不仅降低人力成本而且提升服务效率,况且传统企业面临技术更新转型,纷纷想踏上AI这趟快车,所以智能客服的前景一片春天呐。

    谈谈需求和技术

    当我真正开始战斗在企业对话产品的一线,却发现事情没有那么简单。下面我们讲讲技术话题~

    工业界对话系统的核心目的是通过人机对话接口让机器为用户提供服务。这里的服务可以是 解答用户一个疑问,帮用户办理一件事,或者是单纯的聊天(情感服务) ,这三个核心需求对应的技术模块分别是:

    • 问答(基于FAQ、文档、表格、KG等)

    • 任务式对话

    • 闲聊

    请记下这三个需求和三套对应的技术模块,接下来这三点将分别简称为 一类需求、二类需求和三类需求 ,并贯穿本文重点内容。

    三类需求:闲聊

    显然,前两个需求都是在满足用户的刚需,而最后一个需求,抖音不香么?吃鸡不好玩吗?陌陌用过吗?淘宝两块钱的陪聊不满足吗?

    一句话讲,工业界对话系统最能满足用户刚需,创造商业价值的更多还是在于问答和任务式对话,微软小冰的结局正是对第三条需求的证伪。

    有人说,闲聊的商业化之所以失败,是因为闲聊技术不够成熟!只要我预训练模型足够大,等我打败了Google的Meena[1],Facebook的Blender[2],微软的DialoGPT[3],百度的PLATO[4],我就能像人一样逼真幽默,会聊天了!想象一下,哪怕你做到了像人一样会聊天,又能怎样呢?满足情感和娱乐化需求,创造大规模商业价值,那你的对手将会是整个文娱产业。游戏、短视频、网剧、音乐,甚至陌生人社交APP,一个终于做到像人的产品能干掉哪个呢?

    当然了,你如果说要再给这个闲聊系统装一个肉体,那当我没说。。。可能确实有更大的商业化想象空间,就要看下法律、伦理答不答应。。。

    证伪了第三类需求,再来说说第一类需求——问答。

    一类需求:问答

    没错,“解答用户一个疑问”看起来是很刚需的功能。但仔细一想,百度做了20年,知乎做了10年,不就是这个需求吗?

    问答是什么?就是精准满足用户query,那就可以理解成百度搜索的TOP1搜索结果,或者知乎上的回答最高赞。换句话讲,就是做一个 缩小版、精准版、垂直版的搜索引擎 。这下你是不是可以理解为什么出道最晚的小度,反而会比天猫精灵和小爱音箱“更聪明”了?

    既然都说了可以用搜索引擎的方式去满足对话的第一个需求,那去做不就是啦?有啥好凉的呢?

    首先来说说理想层面。问答,或者说搜索TOP1,中文做的最好的显然就是某度了。大家可能平时搜索时都有遇到这种前端样式。

    这就是搜索TOP1问答的典型场景。如果每次用户在对话产品中的提问都像在通用搜索引擎中这样这么理想、生活化就好了。但是不知道大家有没有试过在百度里面搜索一些稍微冷门的问题?比如:

    你会发现根本没有搜索TOP1问答卡片的影子了。然而,这种垂直行业、细节化的用户query恰恰是对话产品第一类需求中的高频问题!在通用搜索中,由于TOP1的准确率要求非常高,因此面对这种冷门、细节化的query,模型回答不了可以直接展现搜索的相关结果,让用户自己去底下找答案。但是,在对话产品中,几乎注定了是一问一答,如果你没有高精准的找到那个TOP1的回答,那你几乎只能跟用户说“对不起,我好像不明白”。然后用户就“玛德智障!给我转人工!”

    尽管学术界对问答对匹配问题研究的挺彻底了,但是SOTA模型放在业务数据中翻车的情况太常见了,所以脱离了业务的模型不算好模型。问答对的质量决定了模型效果的上限,更何况随着数据的增加,问题之间的边界模糊和交叉现象会进一步增加匹配的难度。

    当然,我们做问答引擎的过程中,在搜索范式之外,可以增加针对问答场景设计的辅助模块,来缓解无法精准回答的尴尬局面,比如在召回、精排和后处理阶段增加复杂的处理逻辑。可是,若要同时做到垂直而精准,同时还试图通用化,用一套模型/系统实现跨场景跨行业的大规模落地变现,在现有技术范式下几乎是一件不可能的事情。

    再者,学术界的问答系统的研究重点普遍聚焦在开放域问答和阅读理解问题上,所谓迁移学习、domain adaption、预训练、小样本学习等技术,还不足以经受的住现实的考验,撑不起一个通用和垂直兼备的问答引擎,依然免不了要一个行业一个行业的做,一份数据一份数据的标。用一个模型去精准的覆盖多个场景和行业是非常不现实的。

    总结一下,对话中的第一类需求表面上是一个垂直领域的搜索TOP1匹配问题,而实际操作中的难点诸多。如果技术上无法实现通用、垂直且精准的问答满足,要么技术平台方一个订单一个订单的啃,导致平台方大规模变现艰难;要么就降低标准,导致业务方的用户用脚投票,不停的对机器人喊“我要转人工”,导致业务方重金砸来的智能客服系统也没有真正节约多少运营成本。

    这个问题,是我认为对话系统第一类需求的技术硬伤,是打开百亿规模市场的最大障碍。更不必说,第一类需求中还存在query描述冗长/超短、FAQ库不完备、甚至ASR解析噪声等问题。当然,相比上面的最大问题,这些优先级都可以后排。不过话说回来,毕竟算上实习,我做对话也就2年时间,目光有限,或许将来会出现更好的解法呢?

    好了,第三类需求和第一类需求都聊完了。最后聊聊第二类需求,也就是任务式对话。

    二类需求:任务式对话

    前面讲的问答需求(一类需求)本质上是一个文本相关性问题,因此技术抽象上更多的是一个搜索、问答问题;而任务完成式需求(二类需求)由于要帮助用户完成任务目标,比如订票、订餐、查天气等,就免不了要跟系统功能性的API打交道,就注定了要做query结构化,即意图识别、实体槽位填充,将文本转成系统查询API。

    然而,像智能音箱这种C端对话产品因为是面向所有用户的,我们无法预先知道用户所有的意图(永远不要低估一个用户的脑洞),即意图是开放域的。对于一些高频意图,如询问天气、播放周杰伦的歌等,我们可以富集、标注大量数据,甚至写个规则就搞定了。然而,对大量的长尾意图就处理困难了,不仅难以采集到充分的数据进行标注,甚至难以穷举并定义这些意图是什么。更加糟糕的是,意图的权重还是不一样的,比如“投诉”的意图识别错了,代价要比“订票”高的多。此外还有一个在论文中不会提及的真实问题,那就是如何在开放域下识别一句话“没有意图”(比如一只猫爬过用户键盘并按下了ENTER)。

    再来谈实体识别,这也是学术界已经研究烂的技术了,为什么工业界还是做不好呢?

    主要的原因是,实际业务中的实体不只是机构名/人名/地名这么简单和理想,而是些和业务紧密联系的专有名词,往往是某一家公司所独有的词汇。比如运营商场景中的套餐实体,“30元每月30G”,这个时候既没有足够的标注数据,套餐每隔一段时间还会变化,所以学术界的那一套NER的方法太fragile了。所以工业界采用的方法目前还是以规则为主,模型为辅。

    此外,任务式对话还会面临多轮问题,这就涉及到了对话管理的概念。

    工业界的对话管理的第一要义是绝对可控性,所以技术选型上都是pipeline系统,而非端到端系统(尽管学术界从2015年就有了端到端任务式对话相关的研究工作[5])。

    对话管理模块是多轮对话的控制中枢,决定了对话如何进行下去以及对话的质量,作用是维护和更新对话状态以及判断系统的下一步动作。目前工业界的普遍做法是基于有限状态机,这种方法需要事前显式定义对话系统的所有可能状态,优点是可控,缺点是状态转移过程是人为定义的,一旦出现定义范围之外的情况,无法处理就变成人工智障了;此外,对于用户回答偏离业务设计的情况,怎么拉回到对话的主流程上?再比如用户前一个意图还没结束,可能就开启了下一个意图,这个时候如何处理?即使对话流程配置的很精细,也无法应对可能的突发和未知状况,这些都是实际应用中经常面临的问题。

    因此,虽然学术界普遍认为任务式对话的各个子模块似乎都做的差不多了,甚至端到端也看似不少paper了,但来到真实场景,才会发现学术界的问题定义和测试集太过理想了。

    联想到,很多产品都在吹“我们的产品用了A学习,B技术,能做到C效果”,可是,它真的给产品的用户体验带来提升了吗?提升了多少呢?对话的痛点问题又解决了多少呢。

    路在何方

    在当今深度学习大风口与预训练小风口的带动下,不可否认的是NLP领域迎来一波质的飞跃,但是在对话问题上,却远远没有乐观到能一下子解决实际问题的程度。对话领域要迎来颠覆,必须有超脱于单纯的炼丹技术和预训练范式之外的突破。

    这个突破是什么?我也不知道,但至少是个机器学习命题。我也一直在思考,该怎么跳出这个不断挖字典+写规则和不断标数据finetune的桎梏。我也希望真正热爱对话的学术界研究者们能将更多的精力放在对话框架层面的痛点问题上,而不单单是DSTC又屠了榜、训了个更大的闲聊模型能聊的更像人了、意图识别准确率又提升了1%。这些都不是影响对话大规模落地的痛点问题。

    回到标题上来,对话系统凉透了吗?相信认真看完本文的小伙伴心里已经有了答案。对话确实很难,过去的一年里,某AI Lab解散,多个C端产品面临调整,B端业务订单难啃,难以大规模变现,学术界对话研究热点又似乎跟工业界痛点不合节拍,外界一片看衰。但,对话依然是个很有意思&有意义的研究课题,它的社会价值和人类憧憬一直没有改变。 

    说个正事哈

    由于微信平台算法改版,公号内容将不再以时间排序展示,如果大家想第一时间看到我们的推送,强烈建议星标我们和给我们多点点【在看】。星标具体步骤为:

    (1)点击页面最上方深度学习自然语言处理”,进入公众号主页。

    (2)点击右上角的小点点,在弹出页面点击“设为星标”,就可以啦。

    感谢支持,比心

    投稿或交流学习,备注:昵称-学校(公司)-方向,进入DL&NLP交流群。

    方向有很多:机器学习、深度学习,python,情感分析、意见挖掘、句法分析、机器翻译、人机对话、知识图谱、语音识别等。

    记得备注呦

    整理不易,还望给个在看!
    

    [1]Adiwardana, Daniel, et al. "Towards a human-like open-domain chatbot." arXiv preprint arXiv:2001.09977 (2020).

    [2]Roller, Stephen, et al. "Recipes for building an open-domain chatbot." arXiv preprint arXiv:2004.13637 (2020).

    [3]Zhang, Yizhe, et al. "Dialogpt: Large-scale generative pre-training for conversational response generation." arXiv preprint arXiv:1911.00536 (2019).

    [4]Bao, Siqi, et al. "Plato-2: Towards building an open-domain chatbot via curriculum learning." arXiv preprint arXiv:2006.16779 (2020).

    [5]Wen, Tsung-Hsien, David Vandyke, Nikola Mrksic, Milica Gasic, Lina M. Rojas-Barahona, Pei-Hao Su, Stefan Ultes, and Steve Young. "A network-based end-to-end trainable task-oriented dialogue system." arXiv preprint arXiv:1604.04562(2016).

    展开全文
  • 每天给你送来NLP技术干货!来自:复旦DISC引言对话系统(dialogue system)是 NLP 中的的重点研究方向之一。其可以分为任务型对话系统和开放域对话系统。两者在现实生活中都...

    每天给你送来NLP技术干货!


    来自:复旦DISC

    引言

    对话系统(dialogue system)是 NLP 中的的重点研究方向之一。其可以分为任务型对话系统和开放域对话系统。两者在现实生活中都有着广泛的应用。

    本次 Fudan DISC 实验室将分享 ACL 2021 中关于对话系统的 3 篇论文,介绍了任务型对话系统和基于人设的开放域对话系统的相关创新。

    文章概览

    HyKnow: End to End Task-Oriented Dialog Modeling with Hybrid

    论文地址:https://arxiv.org/pdf/2105.06041v2.pdf

    这篇文章提出了一个基于联合知识的任务导向型对话系统HyKnow,该模型通过延伸信念状态来管理结构化知识和非结构化知识,它是第一个基于两类知识进行联合优化的端到端对话系统。实验证明,HyKnow 模型展现了优于现有模型的强大的端到端性能。其更加出色的非结构化知识检索准确率,也证明了模型胜于管道知识管理策略的联合知识管理能力。

    BoB: BERT Over BERT for Training Persona-based Dialogue Models

    论文地址:https://arxiv.org/pdf/2106.06169.pdf

    当前对话数据的人设稀疏性,阻碍了鲁棒且一致的基于人设的对话系统的构建。本文提出了 BoB 模型,通过将基于人设的对话生成任务分离为一致性理解子任务和回应生成子任务,利用非对话关系数据集训练一致性,解决了上述困难。模型在少量训练数据和人设稀疏的数据集上均展现了出色的性能。

    Modulating Language Models with Emotions

    论文地址:https://aclanthology.org/2021.findings-acl.379.pdf

    针对情感对话生成任务,本文受 CV 领域相关技术的启发,在Transformer 模型的层归一化模块中融入了情感信息,使得能够利用大规模的预训练的语言模型来生成情感回应。

    论文细节

    1

    论文动机

    现有的基于人设的对话模型严重依赖和人设相关的对话数据,比如 PersonaChat 数据集。这类众包数据集包含了大量的人设特征,但是其规模受到两个因素的制约:其一,标注者根据给定的人设来设计一致的对话会消耗大量精力;其二,日常生活中的对话常常不具备鲜明的人设特征,因此很难获得现有的涉及丰富人设的对话。所以,在这类人设稀疏的对话数据集上训练的模型不能充分地学习一致性。

    一个合格的基于人设的对话模型应当具备以下功能:一是能够理解“人设-回应”的一致性,二是能够根据对话上下文生成人设相关的回应。显然,当下缺乏合适的数据集支持这些功能的实现。然而,一旦将基于人设的对话生成任务分解为一致性理解子任务和对话生成子任务,就很容易得到大量的训练资源。对于一致性理解子任务,可以利用大规模的非对话关系数据集,比如 SNLI 和 MNLI 作为训练数据。至于对话生成子任务,我们已经有了充足的大规模人设稀疏的数据集。

    模型

    文章提出的模型主要分为三个模块,包括一个编码器( ),一个用于回应生成的解码器( )和一个一致性理解解码器( )。模型框架如下图所示

     编码器

    编码器的输入包括人设 P 和上下文 Q,对于人设,只需将人设句子简单地拼接即可。模型将一个 special token 放在人设序列和对话上下文之间,得到编码器   的输入

    接着嵌入层将输入   转化为表示,这种表示是词嵌入,类型嵌入和位置嵌入的和,其中在类型嵌入中,用 0 和 1 分别表示人设和上下文。用   和  代表人设   和上下文   独立的表示,用   代表    和   的联合表示,即

    其中   表示输入   的最大长度。

    然后编码器   对   做多头注意力,将其转化为隐向量的序列   ,

    即其中   ,MultiHead是带有   的全连接层,   是编码器   的最终输出,即   。

    回应生成解码器

    一个交叉注意力被植入在   和   之间,其中   来自   的最后一层,且   和   均来自   :

    包含多个相同的层,每一层的输出都会作为下一层的输入,最终输出   被送往  。这里的   是模型产生的粗糙回应,其不一定和人设保持一致,一致性学习和调整将会在一致性理解解码器模块上进行。

     一致性理解解码器

     利用   进行初始化。在   的每一层中,多头注意力被执行两次

    以上得到的结果   融合了人设信息   和 粗糙回应   最后一层的输出   连接一个线性层即可得到模型生成的最终回应 

    训练目标

    模型针对文本生成子任务采用了负对数损失,针对一致性理解采用了非似然损失。

    回应生成

    模型在   和   上分别生成粗糙和精确的回应,两者的负对数损失可以表示为

    非似然训练

    在一致性理解模块的训练中,模型主要利用非对话的关系数据集。对于一个样本,将 premise 和 hypothesis 输入解码器   中。如果两者关系是 entailment,则应当促进这种生成,那么训练目标是最大化这类输出的概率;如果两者关系是 contradiction,则应当抑制这种生成,那么训练目标是最小化这类输出的概率。经过上述训练模式,一致性理解模块可以隐式地判断人设   和粗糙回应   的关系,并倾向于产生一种和人设   保持一致的回应。具体而言,将关系数据集划分为两类,一类是关系为 entailment 的样本组成的子集  ,另一类是关系为 contradiction 的样本组成的子集  。在   和   上的损失可以表示为(记 premise 和 hypothesis 为 

    生成损失和一致性理解损失可以表示为

    总损失可以表示为

    其中   和   是超参数。

    实验

    本文为了验证 BoB 在人设稀疏的数据集上依然能够保持优秀的性能,挑选了两个数据集 PersonaChat 和 PersonaDialog,前者包含了充足的人设信息,后者人设信息较少。本文在两个数据集上分别进行实验。基线模型选择了包括 GPT-2 在内的预训练模型和一些非预训练模型。评价指标包括人工评价和自动评价,人工评价主要评估模型生成的流利度,信息量和相关性;自动评价中,利用困惑度评价回应的内容质量,利用 Dist 评价回应的多样性,利用 C.Score 和   来评价回应和人设的一致性。在人设密集的 PersonaChat 数据集上实验,得到如下结果

    实验证明,在各项评价指标上,BoB 都超过了基线模型。同时当数据量减少为 1/2,1/4,1/8 时,模型依然展现出比肩基线模型的强大性能,证明了 BoB 模型的优越性。

    在人设稀疏的 PersonaDialog数据集上实验,得到如下结果

    我们发现,即使在人设信息不足的情况下,BoB 依然能够产生和人设高度一致的回应,这得益于一致性理解模块的训练脱离了有限的人设对话数据,转而依赖大量的非对话关系数据。因此,一致性的学习不受人设信息多少的影响。这也是 BoB 最核心的创新点!

    2

    论文动机

    近几年,任务型对话系统在达成用户目的方面已经收获了不错的效果。大部分这样的对话系统基于用户需求查询结构化知识,比如表格和数据库等,并利用查询到的结果引导系统回应的生成。然而,现实生活中的对话常常涉及到非结构化的知识,比如餐厅的广告,用户用餐反馈等等。这些出现在非结构化知识中的信息通常无法在结构化知识中查询得到。但是现有的任务型对话系统缺乏利用非结构化知识的能力,这样的缺陷可能导致对话进程的终端,造成追踪用户需求和生成系统回应的困难。

    针对以上问题,本文考虑在任务型对话系统中结合不同形式的领域知识,构建了一个同时基于结构化知识和非结构化知识的对话系统 HyKnow。在基于结构化知识的对话轮中,系统需要用三元组来跟踪用户需求,以此查询数据库条目,最后利用查询结果生成回应;在基于非结构化知识的对话轮中,模型管理文档库来检索相关信息来做回应的生成。

    模型

    下图给出了模型 HyKnow 的框架。模型总共分为三个部分:第一,模型使用拓展信念追踪(extended belief tracking)来追踪用户需求;第二,模型基于拓展信念状态(extended belief state)来搜索和用户需求相关的结构化知识和非结构化知识;最后,模型利用拓展信念状态和相关知识来生成系统回应。

    信念状态

    信念状态有着特定的格式 。信念状态均由以上形式的三元组构成,每个三元组表示用户的某个需求,以(restaurant, food, Italian)为例,该三元组表示用户需要了解餐饮领域关于意式食物的讯息。所谓拓展信念状态,就是随着对话轮的进行,用户需求的更新,信念状态中添加了一些表示用户新需求的三元组,我们将这样的三元组集合记为  ,其中   表示第   轮对话。除此之外,信念状态中也会包含关于用户需求的话题,记作  。注意到,  和   在解码时所用到的词表是不同的!!

    拓展信念状态解码

    遵循 Seq2Seq 框架,首先利用上下文编码器来编码对话上下文  ,其中   的最后一维输出用来初始化解码器的隐层。基于上下文编码器的隐状态   和上一轮对话的拓展信念状态   ,接着解码本轮对话的拓展信念状态  ,具体可以采用两种方案。

    因为   和   基于的词表是不同的,所以用两种方法实现   的解码:

    第一,利用一个信念状态解码器来生成整个  ,优化过程是联合的,即

    第二,对   和   用各自的解码器分别解码,两个解码器的参数是不共享的,优化过程是非联合的,即

    知识查询

    基于拓展信念状态  ,模型查询数据库得到  ,检索文档库得到相关文档  ,两者用来引导系统生成。在数据库的查询中,只需要用三元组匹配条目即可。在文档库的检索中,只需预处理文档库,提取每个文档的话题,和三元组的相关内容匹配即可。

    回应生成

    基于上下文  ,拓展信念状态   和查询结果  ,生成回应由以下公式给出

    其中   和   表示信念状态编码器和文档编码器。

    实验

    本文选择了修改的 MultiWOZ 2.1 数据集,并将 HyKnow 模型和以下几类基线模型相比较:一、现有的端到端任务型对话模型(E2E TOD)和对话状态跟踪模型(DST),以证明结合非结构化知识的好处;二、非结构化知识管理模型,以证明 HyKnow 检索非结构化知识方法的优越性;三、上述两者的结合,以证明 HyKnow 不仅强大在同时结合了结构化知识和非结构化知识,而且知识的管理,组织和查询方式以及两类知识的融合方式都是非常优秀的。实验结果如下图所示

    实验表明,HyKnow 在各项性能指标上都超过了基线模型,包括用户需求的完成度,知识查询准确率等等。除此之外,实验证明,当模型采用联合优化的时候,表现会更高,这说明两类知识的模块在共享参数时能够彼此促进。

    3


    论文动机

    当前对话系统领域的一个重要任务是基于情感产生合适的回应。关于这个任务,研究者提出了一些经典的模型,比如 Seq2Seq 模型的变体,变分自编码器,对抗网络等等,不过这些模型生成的回应通常较为枯燥乏味,可能是带有情感标签的数据量有限的缘故。最近的研究提出了预训练模型来解决这类问题,比如 GPT-2 等等。不过,从头训练一个预训练模型成本太高,并且收集用于预训练的包含丰富情感的对话数据非常困难。

    针对上述困难,本文提出了一个简单且易于部署的技术,使得大规模的预训练模型能够产生细粒度的情感回应。首先,利用 emoji 表情作为情感标签;其次,在 Transformer 块的每个层归一化模块中引入情感 emoji,使得在每次做层归一化的时候模型都能向着目标情感进行自我调整,这种方法简单而自然,且易于推广。

    方法

    模型的创新主要集中在对 Transformer 模型的层归一化的改造,我们称经过改造的层归一化模块为 Mod-LN。具体操作如下:对于输入层归一化模块的隐状态向量 x,,按照如下方式进行归一化

    其中   是磨光参数,以避免分母为 0。  和   是两个可训练的模块,运行机制如下

    其中   和   是属于层   的全连接层,  表示情感标签的表示向量,  表示偏置,  表示激活函数。模型结构如下图所示

    实验

    本文在 MojiTalk 数据集上进行实验,其中有 64 个细粒度的情感 emoji。基线模型选取 R-CVAE。本文分别在 BERT-to-BERT,GPT2-to-GPT2 上利用 Mod-LN,和基线模型相比较,以证明添加的 Mod-LN 的优越性。关于情感分析性能,作者对模型生成的回应用情感分类器预测情感,将其和正确情感比较,从而得到模型的情感预测准确率,准确率越高,情感分析质量越高。除此之外,采用人工评价的方式,评估回应的情感性和可读性。以上两个评价方面的结果如下表所示

    实验证明,添加了 Mod-LN 的模型不仅在各项性能指标上超过了基线模型,而且在有限数据集上依然表现尚佳。这是因为,将目标情感渗透到每个层归一化模块中,每个 Transformer 中,使得模型总是频繁地向着目标情感的方向进行自我调整。


    投稿或交流学习,备注:昵称-学校(公司)-方向,进入DL&NLP交流群。

    方向有很多:机器学习、深度学习,python,情感分析、意见挖掘、句法分析、机器翻译、人机对话、知识图谱、语音识别等。

    记得备注呦

    整理不易,还望给个在看!
    
    展开全文
  • 前不久,OPPO旗下的人工智能助手“小布助手”月度活跃用户数突破一亿,成为国内首个月活用户数破亿的手机语音助手...对话系统是一项接近30年研究历史的技术,代表人机交互的未来。近十年来随着语音、NLP领域的阶段性突
  • 闲聊式对话系统是一种针对开放域的生成式对话系统,目前主流的技术是seq2seq+attention。 现有的API:微软小冰、图灵、腾讯、青云客等;成熟的开源项目:chatterBot。 这类对话系统的难点在于聊天属于开放域,没有...
  • 这周主要是看了3篇对话系统的综述,主要是为了对对话系统有一个更深的了解,所以就把看的所有综述都放在一起了~~ 《智能对话系统研究综述》 《A Survey on Dialogue Systems:Recent Advances and New Frontiers》 ...
  • 任务型对话系统是以完成特定任务为目标的对话系统。例如可以以订机票为一个特定的任务,实现的对话系统。我们这里重点关注任务型对话系统。 任务型对话系统分为语音识别、自然语言理解NLU、对话管理DM、自然语言...
  • 当时的我觉得,对话系统要给这个世界带来一波重要的变革了,它将是最能让大众体验人工智能技术的产品了。 抱着这个坚(天)定(真)的信念,先是轻松屠了当年某知名的智能客服天池竞赛的榜单,然后义无反顾的将简历...
  • 一、豆瓣多轮对话数据集 1、简介: 测试数据包含 1000 个对话上下文,对于每个上下文,创建 10 个响应作为候选。正确的响应意味着响应可以自然地回复给定上下文的消息。每对收到三个标签,大多数标签被视为最终...
  • 对话系统综述 Advances and Challenges in Conversational Recommender Systems: A Survey 对话推荐相比于传统推荐的两大好处: 用户的真实偏好是什么? 为什么用户喜欢这个item? 从五个方面总结对话推荐系统...
  • 1.1 背景知识简介 因为本项目是对话系统中的NLU任务,所以我想在具体介绍项目之前,先和大家在大体上看看一个对话系统,需要具备哪些模块。 对于一个对话系统来说,通常由以下几个模块组成,和用户语音相关的 ASR...
  • 此外,“AMiner微信小程序”正式上线啦~~ 在任何时间、任何地点,只需要手机打开“AMiner微信小程序”即可体验AMiner智能推荐系统,第一时间获取领域最新论文,必读论文集合和最新科技资讯推送等~ 小程序首页添加...
  • UNITY 对话系统

    千次阅读 2021-04-26 20:24:47
    //存放对话内容 前面的特性是为了在Inspector窗口中文字区域显示成三行 public int currentIndex;//对话数组索引 写好保存后将这个脚本回到unity中给这些变量赋值。 (2)写三个方法 public void CloseDialog() //...
  • 图1 理解对话回复中的一致性 在图1中,左边部分是对话系统预设的角色信息,该信息是以结构化键值对(key-value pairs)的形式给出的;右边部分是一个对话片段,包括一句对话输入和若干对话回复。在这些对话回复中,...
  • 对话系统简介

    2020-12-26 09:11:27
    口语对话系统(Spoken Dialogue System, SDS)在虚拟个人助手(virtual personal assistants ,VPAs)方向上是一个比较重要的应用。在这些VPA中,Microsoft的Cortana,Apple的Siri,Amazon Alexa,Google Assistant...
  • 本文将以2021年南洋理工大学发表的论文《Recent Advances in Deep Learning-based Dialogue Systems》为基础,介绍「深度学习对话系统」综述系列,共分七篇,本文是开篇。论文制作了一个图表,以帮助读者熟悉整体...
  • ©PaperWeekly 原创 ·作者|褚维芜学校|北京邮电大学研究生研究方向|自然语言处理笔者最近阅读了一些对话系统预训练相关的文章,其所采用的模型大致可以分为两类:生成式...
  • 每天给你送来NLP技术干货!来自:复旦DISC作者:陈伟引言对话系统是自然语言处理领域的核心任务之一。对话系统的最新进展绝大多数是由深度学习技术所贡献的,这些技术已经被用来强化各类大数据应...
  • 槽函数_意图识别和槽填充
  • 文章目录一、对话系统概述二、对话系统的分类及其对应得解决方案三、检索及倒排索引四、召回及重排五、倒排索引的空间优化方法—Variable Byte Compression六、倒排索引搜索算法—Weak and(WAND)七、检索系统的...
  • 使用Xnode试着做了简单的对话系统 可视化了看起来是挺方便的,就是节点多了窗口会卡… 运行效果预览 需要的插件 Xnode 用于绘制节点 Odin 用于定制inspector窗口 自定义节点 首先要新建一个Graph脚本 ...
  • ©PaperWeekly 原创 ·作者|褚维芜单位|北京邮电大学硕士生研究方向|自然语言处理任务型人机对话系统旨在帮助用户完成特定领域中的特定任务,例如:餐馆预订、天气查询和...
  • UNITYTextAssest去创建一个对话系统 UNITYTextAssest去创建一个对话系统 TextAsses: Inherits from Object Text file assets. 文本文件资源。 You can use raw .txt files in your project as assets and get their...
  • 最新对话系统综述

    2021-12-17 14:57:22
    前言 ...首先介绍一篇对话系统领域综述最新的paper,写的非常好 ...第一章:简要介绍对话系统和深度学习。...第二章:讨论现代对话系统中流行的神经模型及其相关工作。...第四章:介绍开放域对话系统中的
  • 因此PLATO系列利用了大规模的对话语料,对对话系统进行训练,从PLATO到PLATO-XL,用的数据越来越多,模型大小也越来越大。之前开放PLATO的微信体验机器人,也着实让它又火了一遍。 那么本文就来梳理下PLATO家族,...
  • EMNLP 2020 | 开放域对话系统的属性一致性识别 论文:Profile Consistency Identification for Open-domain Dialogue Agents 作者:宋皓宇,王琰,张伟男,赵正宇,刘挺,刘晓江 论文链接:...
  • 展品讲解语音对话系统 实验报告1. 任务定义2. 实验环境3. 系统功能4. 方法说明4.1 本地录音4.1.1 初始化4.1.2 录音4.1.3 保存音频4.2 百度语音识别4.2.1 初始化4.2.2 语音识别4.3 图灵机器人回答4.3.1 在图灵机器人...
  • 接下来的五篇博客会从对话系统搭建五个步骤上仔细进行学习。 文章目录一、定义对话系统的方法二、确定场景边界1.创建机器人定位(机器人的性格定位)2.明确机器人的产品场景案例:三、梳理业务要素和知识库1.确定...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 161,058
精华内容 64,423
关键字:

对话系统

友情链接: IAR103例程.rar