任务驱动型人机对话系统设计
编辑导读:Apple Siri、天猫精灵等智能对话产品如今越来越多出现在大众视野,也获得了人们的喜爱,其对话系统也引起了人们的注意。本文将围绕任务驱动型人机对话系统,对其设计展开六方面的分析,希望对你有帮助。
近年来,随着NLP技术的进一步发展,越来越多的智能对话产品走进大众的视野。如Apple Siri、亚马逊Echo、Google Home、天猫精灵等,在便捷我们生活的同时,对话系统也开始逐渐引起人们的注意。
本文笔者将会结合工作实践,对目前主流的对话系统进行相关介绍,包括对话系统构成、设计原理、应用实践及其重难点问题。
一、对话机器人类型及应用
对话机器人目前从应用场景和功能功能来看,主要可以分为三种类型:问答机器人、任务机器人、闲聊机器人。
问答机器人:问答机器人主要依托于强大的知识库,可对用户提出的问题给出特定回复。对回复内容的准确性要求高,但仅限于一问一答的单轮对话交互,对上下文信息不作处理,目前多用于客服领域。
任务机器人:机器人通过多轮对话交互满足用户某一特定任务需求。对任务完成度要求高,其中机器人主要通过对话状态追踪、问槽、澄清等理解用户意图,然后进行回复或调用API等形式完成用户任务需求,如订票、订餐等任务。
闲聊机器人:机器人与用户互动比较开放,用户没有明确目的,机器人回复也没有标准答案。对回复内容的准确度不做要求,主要以趣味性和个性化的回复满足用户情感需求。
而对综合类型对话机器人而言,往往是以上对话类型的组合,可以同时满足用户问答、任务或闲聊等多种需求,如上文提到的天猫精灵,百度小度等智能音箱产品。
下面笔者将着重就任务机器人核心对话系统的设计做详细阐述。
二、任务机器人对话系统实现方式
任务型对话系统目前主要有两种实现技术,一种是基于流水线(pipeline)的实现方式,另一种是基于端到端(end-to-end)的实现方式。
2.1 流水线(pipeline)
上图是基于流水线(pipeline)实现的对话系统的经典结构图,又称规则对话系统。
整个系统有四大核心模块,分别由NLU、DST、DPL和NLG依次串联构成的一条流水线,各模块可独立设计,模块间协作完成任务型对话。
- 自然语言理解(NLU):主要对人机交互过程中产生的对话进行语义理解;
- 对话状态跟踪器(DST):管理每一轮对话状态,包括历史状态记录及当前状态输出;
- 对话策略(DPL):基于当前对话状态执行的下一步系统回应策略;
- 自然语言生成(NLG):将对话策略输出的语义转化成自然语言。
2.2 端到端(end-to-end)
端到端(end-to-end)的对话系统,主要是结合深度学习技术。采用数据模型驱动,通过海量数据训练,挖掘出从用户自然语言输入到系统自然语言输出的整体映射关系,而忽略中间过程的一种方法。
就目前工业界整体应用而言,虽然端到端(end-to-end)的方法灵活性和可拓展性较高,但其对数据的质量和数量要求也很高,同时还存在不可控性和不可解释性等问题,因此工业界的对话系统目前大多采用的还是基于规则的流水线(pipeline)实现方式。
下面笔者结合自己工作实践,着重将为大家分析下基于规则的对话系统是如何设计与运作的。
三、基于规则的对话系统设计
上图为基于规则的对话系统架构,主要由语音识别(ASR)、自然语言理解(NLU)、对话管理(DM)、自然语言生成(NLG)、语言合成(TTS)五大模块构成。各模块间相互协同,共同完成对话任务。
其中ASR和TTS主要在语音机器人中有所运用,目前国内这块的技术已较为纯熟,一般可直接采用阿里云、科大讯飞等供应商的服务,下面将重点针对NLU、DM、NLG三个核心模块做详细解析。
3.1 自然语言理解模块(NLU)
自然语言理解(NLU)模块主要是通过意图识别和槽识别(信息抽取)来理解对话中用户语句的语义。
意图识别(Intent Prediction):目的是理解用户所表达的意图,核心其实是处理一个分类问题,将用户的话分类到事先预定义好的意图类别中去。目前主要基于深度学习的方法,使用CNN(卷积神经网络)对query进行特征提取和意图分类,类似的方法同样适用于领域的分类。
槽填充(Slot Filling):提取对话中关键信息,本质是将句子中的词打上语义标签(如上图Slots日期、地点),具体方法有CRF(条件随机场)、Deep Brief Network(深度信念网络)以及RNN(循环神经网络)等。
NLU的结果(intent和slot)会作为用户状态输入到对话管理模块,应用于对话状态的更新和维护。
3.2 对话管理模块(DM)
对话系统中对话管理(DM)模块由对话状态跟踪器(DST)和对话策略(DPL)构成,此模块就相当于任务型机器人的大脑,是很重要的决策模块。
常见的DM实现方式有多种:基于规则的有限状态机,基于统计的方法,基于神经网络的方法。
几种方法各有利弊,但基于通用性、可控性和数据成本等考量,目前工业应用还是以有限状态机为主流,根据多维状态的组合输出对应策略,规则简单也比较适用于冷启动。
对话状态追踪(DST):每一轮对话中估计用户的目标,常用的状态结构是槽填充(slot filling)或语义框架(semantic frame)。参照上图,对每一轮对话进行状态的记录和更新,主要通过记录历史状态、用户状态(槽位&意图等信息)和系统状态(初始信息&配置信息),来更新当前对话状态。
对话策略学习(DPL):根据当前对话的状态,产生系统下一步执行动作(回答、澄清、动作执行等),对话策略的设计也与任务场景强相关。可以使用监督学习和强化学习的方法,不过目前工业上多采用规则的方法,事先定义好state对应的action。
3.3 自然语言生成模块(NLG)
自然语言生成主要是将策略模块生成的抽象系统动作转化为自然语言形式的浅层表达,输出到用户端。目前有三种方法:基于话术模版、基于知识库检索、基于深度模型。模版与知识库主要是基于规则的策略,深度模型可以用如LSTM,seq2seq等网络生成自然语言。
基于规则的方法虽简单易用,但适应不了更开放的场景,当场景复杂动作较多时,策略规则的制定也会耗费大量的精力。一旦规则确定,回复基本固定,灵活性较差,多样性不足,造成体验感不高。
而好的NLG需具备4个特性:恰当、流畅、易读、灵活,即回复的自然语言不仅要精确表达出策略动作的语义,还要具备一定的“类人性”,让人机对话尽可能靠近人与人之间的对话,这也是后续NLG模块需要持续探索与改良的核心关键点。
四、应用案例
我们以58一个二手车回访真实场景的人机语音交互对话为例,阐述下对话系统各模块间是如何协同运作的。
我们从第四轮对话开始切入:当机器人第一次执行问槽策略时,槽位名称”需求了解“,执行话术“请问新车和二手车是否都在您的考虑范围内?”
4.1 语言理解
此刻当用户回复”只考虑二手车“时,用户的话会做前处理经ASR转译成文本,后将文本输入到语言理解(NLU)模块。
- 意图识别:NLU模块一般会优先匹配预设QA,若无QA能匹配上,则进入深度意图模型进行意图识别,此刻识别意图为”提供信息“。
- 槽识别:同时进行NLU模块的另一任务”槽识别“,我们也称这一过程为填槽(Slot Filling),本轮“需求了解”的槽值(Slot Value)识别为“二手车”。
4.2 对话管理
- 对话状态:然后NLU模块的意图和槽位信息作为用户状态输入DM状态模块,状态模块结合系统状态、用户状态、历史状态,更新当前状态:当前匹配QA:“None”;当前意图:“提供信息”;当前槽位名称&槽值:“需求了解”&“二手车”;是否还有需要询问的槽位;
- 对话策略:根据当前对话状态,设计好的策略中系统应执行的下步策略:继续询问“车型了解”槽位,更精准定位用户需求。
4.3 自然语言生成
随后在自然语言合成模块(NLG)根据设定好的策略规则确定输出话术,机器人执行问槽回复“那您最近在关注哪款车呢?我们可以将最新的降价信息推送给您。”
至此,对话系统从用户输入到机器人输出,完成了一轮完整的对话流程。后续就是进行重复的对话流程循环,由此对话持续一轮一轮进行下去,直到机器人任务主动或被动结束。
五、任务型对话机器人难点问题
要想任务型对话机器人在应用中真正表现出色,体验感好,各个模块也都有自己需解决的重难点问题。
如意图模块,如何降低ASR误差带来的影响,解决语言的多样性和歧义性问题,槽位模块中如何提高抽取模型的复用性,解决实体消歧问题。整体上看自然语言处理(NLP)领域,还存在上下文理解、语义推理、场景可移植性等亟需研究突破的问题。
以上基于规则的任务对话系统,虽然简单易用,但其缺点也是显而易见的:对话管理模块中状态策略的定义与规则都高度依赖于人工设计,复杂的场景下状态和策略维度多起来的时候,就会耗费大量的设计与维护成本。同时用户的反馈数据难以传给模型再学习,各模块间的依赖和影响也比较高。
如何在简单任务下,提高DM模块的可复用性,降低机器人生产和更新成本,是快速商业化落地的关键点。目前业内很多公司已自行开发机器人工厂,将机器人生产的各环节模块化、抽样化、流程化、提升其通用性和兼容性,在尽可能多的任务场景下,实现机器人快速复制、设计、生产、上线的能力。
六、结语
对话机器人的能力成长依赖于NLP领域的技术进步,目前更多的应用落地还只是在特定场景下的简单任务。由此,对话机器人未来的发展也必定会倾向于更大的知识体系 ,更强的自然语言理解能力、逻辑推理能力及情绪交互能力,实现Bot进一步的智能化和人性化。
以上内容基于笔者结合学习和工作实践的思考,若有理解不到位之处,还望大家指正,更希望通过这篇文章能与各位多多交流。
本文由 @岑为 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
- 目前还没评论,等你发挥!