首页 体育 教育 财经 社会 娱乐 军事 国内 科技 互联网 房产 国际 女人 汽车 游戏

人机对话技术研究进展与思考

2019-12-16

嘉宾:袁彩霞 博士 北京邮电大学 副教授

收拾:Hoh Xil

出品:DataFun

注:欢迎转载,转载请在留言区内留言。

本次共享的主题为 人机对话技能研讨进展与考虑。 首要梳理了咱们团队近两年的作业,巴望能够经过这样的介绍,能给咱们一个关于人机对话 方面的启示,协助咱们进行更深化的研讨和评论。首要包含:

1. Spoken dialogue system:a bird view

2. X-driven dialogue system:紧接着来解说咱们近些年的研讨主线 X-driven dialogue syatem,X 指构建一个对话体系时,所选用的数据是什么,从最早的 dialogue - FAQ - KB - KG - document 以及咱们一直在测验的图文多模态数据。

3. Concluding remarks

01

Spoken dialogue system: a bird view

学术界关于对话体系有着不同的区分,这种区分现在看来不是十分精确,也不是特别规范的区分了。 可是,接下来的内容,首要是环绕着这两个主线:

限制范畴,专门指使命型对话 驱动的对话; 2016年开端做常识图谱 驱动的对话,比较于 KB,KG 中的常识点发生了相关,有了这种相关人们就能够在大规划的图谱上做常识推理; 2017年开端做文档驱动的对话。 这便是咱们研讨的大致头绪。

2.  Dialogue-driven dialogue 

前期在做  Dialogue driven 的时分,多依靠人工收集数据,可是,从2013年以来,逐渐开放了丰厚的包含多范畴多场景的揭露数据集。 比方最近的 MultiWOZ,从 task specific 视点讲,数据质量足够好、数据规划足够大,一同包含的对话景象也十分丰厚。 可是,现在揭露的中文数据集还不是许多。

这个是和使命型对话无关的数据集,也便是收集的人与人对话的数据集。特别以  Ubuntu 为例,从15年更新至今,现已积累了十分大规划的数据。

以  Dialogue 为输入,咱们展开了使命型和非使命型两个方向的作业。 先来看下使命型对话:

当一个用户输入过来,第一个要做的便是天然言语了解 ,NLU 要做的三件事为: Domain 辨认; Intent 辨认; 信息槽辨认或叫槽填充。 这三个使命能够别离独登时或选用管道式办法做,也能够联合起来进行建模。 在联合建模以外,咱们还做了一些特别的研讨。 比方咱们在槽辨认的时分,总是有新槽,再比方有些槽值十分古怪,例如 XX手机能够一边打电话一边视频吗? ,对应着槽值 视频电话 ,选用序列标示的办法,很难辨认它,由于这个槽值十分不规范。 用户输入或许像这样语义十分松懈,不接连,也或许存在十分多噪音,在进行联合建模时,传统的序列标示或分类为思维,在实践使用中现已不足以处理问题了。

咱们针对这个问题做了比较多的讨论,右图为咱们 2015年的一个作业: 在这三个使命联合建模的一同,在槽填充这个使命大将序列标示和分类进行一同建模,来更好地完结 NLU。

在  NLU 范畴还有一个十分重要的问题,跟着开发的事务范畴越来越多,咱们发现多范畴对话发生了许多十分重要的问题,例如在数据层有些 domain 数据或许许多,有些 domain 数据或许很少,乃至没有,所以就遇到冷启动的问题。 因此,咱们做了十分多的 domain transfer 的作业。 上图为咱们2016年的一个作业,咱们会把数据比较多的当作源范畴,数据比较少的当作方针范畴。 所以,测验了依据多种搬迁学习的 NLU,有的是在特征层进行搬迁,有的是在数据层搬迁,有的是在模型层进行搬迁。 图中是两个典型的在特征层进行搬迁的比方,不只重视范畴一般特征,而且重视范畴专门特征,一同选用了对立网络来生成一个虚拟的特搜集的模型。

紧接着,咱们研讨了  NLU 和对话处理 进行联合建模,由于咱们发现人人对话的时分,不见得是听完对方说完话,了解了对方的意图,然后才构成对话战略,有或许这两个进程是一同发生的。 甚或 DM 还能够反作用于 NLU。 前期咱们依据的一个假定是, NLU 或许不需求一个显式的进程,乃至不需求一个显式的 NLU 的功用,咱们以为 NLU 最终是服务于对话处理 ,乃至便是对话处理 的一部分。 所以,2013年的时分,咱们开端了探究,有两位特别优异的结业生在这两个方面做了特别多的作业。 比方,怎样更好地联合建模言语了解的输出和对话处理的战略优化。 这是咱们在 NLU 和 DM 联合建模的作业,一同提升了 NLU 和 DM 的功能。

在联合模型中,咱们发现, DM 的建模涉及到十分多的 DRL 的作业,练习起来十分困难,比方怎样规划一个好的用户模仿器,依据规矩的,依据核算的,依据言语模型的,依据 RL 的等等咱们测验了十分多的办法,也取得了一系列风趣的发现。 2018年时咱们研讨一种不依靠于规矩的用户模仿器,业界管这个问题叫做  Self -play,尽管咱们和 Self -play 在网络结构上差异挺大的,可是咱们仍是学习了 Self -play 练习的特性,把咱们自己的体系叫做 Self -play。 在这样的机制引导下,咱们研讨了不依靠于规矩,不依靠于有符号数据的用户模仿器,使得这个用户模仿器能够像 Agent 相同,和咱们所结构的对话的 Agent 进行交互,在交互的进程中完结对用户的模仿。

在练习进程中还有一个重要的问题,便是 reward 怎样来,咱们知道在 task oriented 时,reward 一般是人类专家依据事务逻辑/规范制定出来的。事实上,当咱们在和环境交互的时分不知道 reward 有多大,可是环境会隐式地告知咱们 reward 是多大,所以咱们做了十分多的临接对和 reward   reshaping 的作业。

Dialogue-driven dialogue 这种办法的对话体系,总结来看:

界说十分好,逻辑明晰,每一个模块的输入输出也十分明晰,一同有特别坚实的数学模型能够对它进行建模。

由于十分依靠数据,一同,不论是在 NLU 仍是 NLG 时,咱们都是选用有监督的模型来做的,所以它依靠于许多的、精密的标示数据。

而 DM 往往选用 DRL 来做。 NIPS 2018 时的一个 talk,直接指出:任何一个 RL 都存在的问题,便是糟糕的重现性、复用性、鲁棒性。

3.  FAQ-driven dialogue

FAQ 是工业界十分常见的一种景象: 有许多的规范问,以及这个规范问的答案是什么。 依据这个规范问,一个用户的问题来了,怎样找到和它类似的问题,从而把答案回来给用户,所以这个 Service 就完毕了。

实践中,咱们怎样建  FAQ? 更多的时分,我会把这个问题和咱们库的规范问题做一个类似度的核算或许做一个分类。

咱们在做这个作业的时分发现一个特别大的问题,便是  Unbalanced Data 问题。 比方,咱们有5000个问题,每个问题都有规范答案,有些问题或许对应的用户问题特别多,比方 屏幕碎了 或许会有1000多种不同的问法,还有些问题,或许在几年的时间里都没有人问到过。 所以,面临数据不均衡的问题,咱们从2016年开端做了 Data transfer 的作业。

大致的思路是:我有一个规范问题,可是很糟糕,这个规范问题没有用户问题,也便是没有练习语料。接下来发现别的一个和这个规范问很类似的其它规范问有许多的练习语料,所以凭借这个规范问,来生成虚拟样本,从而削弱了  Unbalance。

详细的办法:咱们把方针范畴的规范问当作  Query,把和它类似的规范问题及其对应的用户问题当作 Context,选用了 MRC 机器阅览了解的架构来生成一个答案,作为方针问题的虚拟的用户问题,取得了十分好的作用,而且测验了三种不同的生成用户问题的办法。

实践项目中,FAQ 中的 Q 或许有十分多的问题,例如3 000 多个类,需求做极限分类,这就导致功能低下,且十分耗时,不能快速响使用户的问题。所以咱们做了一个匹配和分类进行交互的 model,取得了不错的作用。

现在,大部分人都以为  FAQ 驱动的 dialogue 不叫 dialogue,由于咱们一般说的 dialogue 次序是大于两轮的。 而 FAQ 便是一个 QA 体系,没有交互性。 有时分带来的用户体会十分不友好,比方当答案十分长的时分,体系要把长长的答案回来,就会一直讲,导致用户比较差的体会。 所以,咱们依据 FAQ 展开出了一个多轮对话的数据,如右图,这是咱们正在展开的一个作业。

4.  KB-driven dialogue

KB 最早人们以为它便是一个结构化的数据库,一般存储在联系型数据库中。 比方要订一个酒店,这个酒店有各种特点,如方位、称号、户型、价格、面积等等。 前期 CMU 的对话体系,一切的模块都要和 Hub 进行交互,最终 Hub 和后端的数据库进行交互。 数据库的价值十分大,可是前期人们在建模人机对话的时分,都忽视了数据库。 这儿就会存在一个问题: 机器和用户交互了好久,而在检索数据库时发现没有答案,或许答案十分多,构成用户体会十分糟糕。

从 2012年开端,咱们开端把 KB 引进咱们的对话体系。 图中的对话体系叫做 teach-and-learn bot,这是一个多模态的对话,可是每个涉及到的 object,咱们都会把它放到 DB 中。 和用户交互进程中,不但看用户的对话状况,还要看数据库状况。 这个主意把作业往前推进了一些。

直到 2016年,MSR 提出的 KB-InfoBot,第一次提出了进行数据库操作时,要考虑它的可导性,不然,就没办法在 RL 网络中像其它的 Agent action 相同进行求导。 详细的思路: 把数据库的查询和 Belief State 一同总结起来做同一个 belief,从而在这样的 belief 基础上做各种对话战略的优化。

在上述办法的基础上,咱们做了有用的改进,包含  entropy regularities 作业。 是每次和用户进行交互时,数据库的 entropy 会发生改变。 比方当机器问 你想订哪里的酒店? ,用户答 阿里中心邻近的。 ,所以数据库马上进行了一次 entropy 核算进行更新,接着持续问 你想订哪一天的? ,用户答 订7月28号的 ,所以又进行了一次 entropy 核算进行更新。 这样在和用户进行交互的时分,不但看用户的 dialogue 输入,还看 DB 的 entropy 输入,以这两项一起驱动 Agent action 进行优化。

这儿咱们做了特别多的作业,信息槽从 1个到5个,数据库的规划从大到小,都做了特别多的测验,这样在和用户交互的时分,agent 能够自主的查询检索,乃至能够填充和修正数据库。

这是咱们 2017发布的一个作业,KB driven-dialogue,其长处:

操控全能高频回复

赋予 agent 对话主动性

5.  KG-driven dialogue

刚刚讲的依据  KB 的 dialogue 使命,根本都以为对话使命便是在进行槽填充的使命,假如一个 agent 是主动性的,经过不断的和用户进行交互来收集槽信息,所以叫槽填充,当槽填完了,就相当于对话使命成功了。 可是,当咱们在界说槽的时分,咱们以为槽是相互独立的,而且是扁平的。 但是,实践中许多使命的槽之间存在相关性,有的是上下位联系,有的是束缚联系,有的是递进联系等等。 这样天然的就引出了常识图谱,常识图谱能够较好地描绘上述的相关性。 所以,发生了两个新问题:

常识图谱驱动的对话了解:实体链接

常识图谱驱动的对话处理:图途径规划

这儿首要讲下第二个问题。

举个比方,咱们在处理电信事务,注册一个家庭宽带,需求供给相关的证件,是自己去办,仍是托付人去办,是房东仍是租户等等,需求供给各种不同的资料。所以这个景象就发生了条件的束缚,某一个  node 和其它 node 是上下位的联系,比方证件能够是身份证,也能够是护照或许户口簿等等。 所以咱们能够经过常识图谱来进行处理。

当一个用户的对话过来,首先会链接到不同的 node,再依据 node 和对话前史结构一个对话的 state,咱们会保持一个大局的 state 和一个活泼的 state,一同活泼的 state 会界说三种不同的操作动作,一个是先人节点,一个是兄弟节点,还有一个是孩子节点。所以,在这样的常识图谱上怎样寻优,比方当经过某种核算得到,它应该在某个节点上进行交互的时分,咱们就应该输出一个 action,这个 action 要和用户承认他是一个租户,仍是自有住宅等等。所以,这个 action 是有差异于此前所说到的在特定的、扁平的 slot 槽上和用户进行信息的承认、修正等仍是有很大不同的。处理这样的问题,一个十分巨大的应战便是状况空间十分大。比方图中的节点大概有120个,每个节点有3个不同的状况,常识从节点的状况来看就有3 120 种或许。这也是咱们正在展开的待处理的一个问题。

在端到端的对话模型 中,也开端逐渐地引进常识图谱。下面介绍两个比较具有代表性的引进常识图谱后的人机对话。其间右边是 2018年 IJCAI 的出色论文,清华大学黄民烈教师团队的作业,引进了经过 KG 来表明的 Commonsense,一同到底在编码器端仍是在解码器端引进常识,以及怎样排序,排序的时分怎样结合对话的 history 做常识的推理等等,都做了特别全面的研讨。

另一个比较有代表性的作业是在  ICLR2019 提出的,在架构中引进了 Local Memory 和 Global Memory 相交融的技能,经过这种交融,在编码器端和解码器端一同加入了常识的推理。

总结下  KB/KG-driven dialogue:

现已有大规划揭露的数据 。

练习进程可控 安稳,由于这儿大都都是有监督学习。

由于选用有监督的办法进行练习,所以存在如下问题:

① 环境确定性假定

② 短少对动作的建模

③ 短少大局的动作规划

Agent 被迫,彻底依靠于练习数据,所以模型是不赋予 Agent 主动性的。

构建 KB 和 KG 本钱贵重!

6.  Document-driven dialogue

Document 驱动的对话,具有如下长处:

景象对话 ,比方针对某个抢手事情在微博会发生许多对话,这便是一个情办法的对话。

电信事务处理 ,比方10086有十分多的套餐,怎样从中挑选一个用户心仪的套餐?每个套餐都有说明书,咱们能够环绕套餐的说明书和用户进行交互,如 您期望流量多、仍是语音多 ,假如用户答复 流量多 ,就能够依据文本知道给用户引荐流量多的套餐,假如有三个候选,机器就能够依据这三个候选和用户持续进行交互,缩小候选套餐规模,直到用户选出心仪的套餐。

电商产品引荐 ,能够依据产品的描绘,进行各式各样的对话。这儿的输入不是一个 dialogue,也不是一个 KB,乃至结构化的内容十分少,彻底是一个 free document,怎样依据这些 document 进行引荐,是一个很好的使用场景。

交互式信息查询 ,许多时分,一次查询的成果或许不能用户的需求,怎样依据非结构化的查询成果和用户进行交互,来更好地达到用户的查询意图。

......

比较于  dialogue、FAQ、KB、KQ 等,Document 充满着互联网的各式各样的文本,都能够当作是文本的数据,获取便利,本钱十分低。

依据文本,不再依据专家界说的  slot,也不再依据受限的 KB/KG,从技能上讲,所结构的 model 自身是和范畴无关的,所以它赋予了 model 很强的范畴移植性。

这是咱们正在进行的作业,景象对话倾向于闲谈,没有一个用户方针。 这儿需求处理的问题有两个:

怎样引进文档:编码端引进文档、解码端引进文档

怎样编码文档:文档过长、冗余信息过多

咱们在  DoG 数据的基础上模仿了一些数据,构成了如上图所示的数据集,分 Blind 和 Non-blind 两种景象结构了不同的数据集。

咱们发现,依据文本的端到端的谈天,有些是依据内容的闲谈,有些还需求答复特定的问题。所以,点评的时分,能够直接用  F1 点评答复特定问题,用闲谈通用的点评来点评依据内容的谈天。

刚刚讲的是偏闲谈式的对话,接下来讲下使命型对话。

这儿的动机分为两种状况: 单文档和多文档,咱们现在在应战多文档的状况,单文档则选用简略的多轮阅览了解来做。

怎样界说对话动作:由所以依据Document进行交互,而不再是依据slot进行交互,所以需求从头界说对话动作。

怎样建模文档差异:以刚刚10086的比方为例,总共有10个事务,经过一轮对话,挑选出3个,这3个事务每个事务或许都有10种特点,那么其间一些特点值相同的特点,没必要再和用户进行交互,只需求交互它们之间不同的点,所以交互的视点需求随对话进行动态地改变。

这儿选用的数据是  WikiMovies 和模仿数据,详细见上图。

7.  A very simple sketch of dialogue

上图为使命型对话和非使命型对话的几个重要节点,咱们能够了解下。

03

Concluding remarks

使命型对话具有最丰厚的落地场景。

纯闲谈型对话体系的学术价值尚不清楚。

使命型和非使命型鸿沟愈加含糊,一个典型的人人对话既包含闲谈,又包含信息获取、引荐、服务。

引进外部常识十分必要,外部常识形态万千,建模办法也因此千差万别。

Uncertainty 和 few-shot 问题,是简直一切的对话体系最大的 卡脖子 问题。

X-driven dialogue 中的 X 还有哪些或许? 刚刚说到的 X 都仍是依据文本的。 事实上,从2005年开端,咱们现已开端做 image 和文本数据交融的对话; 从2013年开端做 Visual QA/Dialogue,应战了 GuessWhat 和 GuessWhich 使命。

X=multi media ,X 还能够很广泛的便是指多媒体,不但有 image 还或许有 text,2018年现已有了相关的使命,而且开源了十分多的电商事务。 这是一个十分有应战性的作业,也使人机对话自身愈加拟人化。

04

Reference

这是部分的参考文献,有些是咱们自己的作业,有些是特别出色的他人的作业。

今日的共享就到这儿,感谢咱们的倾听,也感谢咱们的团队。

北京邮电大学 | 副教授

2009年结业于北京邮电大学和日本国立德岛大学,别离获信号与体系、智能信息科学工学博士学位。2009年9月至今,任职于北京邮电大学核算机学院智能科学与技能中心。自2003年以来,从事天然言语生成、人机对话体系方面的研讨,地点团队研制开发的人机对话技能已被三星、中兴、中国电信北京研讨院、国家电网等多家企业选用。

——END——

文章引荐:

人机对话关键技能及应战

阿里云小蜜对话机器人背面的中心算法

DataFun:

专心于大数据、人工智能范畴的常识共享渠道。

一个「在看」,一段韶光! :point_down:

热门文章

随机推荐

推荐文章