面向NLP的AI产品方法论之如何做好“多轮对话管理”

企业动态
看着这个标题我就想笑,原来的标题是,如何做好多轮对话管理,然后我就默默的加了个引号,用于断句。

看着这个标题我就想笑,原来的标题是,如何做好多轮对话管理,然后我就默默的加了个引号,用于断句。

[[323423]]

本文是前一篇文章《NLP方法论:如何设计多轮语音对话技能》的延续,本文主要讨论的是对话设计,是业务设计中的重中之重。

VUI相比于GUI,没有流程预设,全程使用对话输入,用户可以随意表述,无法有效控制用户的输入行为。

有些人会一句话表达自己的诉求,有些人不能;有些人表述啰嗦,逻辑混乱,不能一次说清所有的要点,需反复追问;有些人频繁改变主意,机器人需要不断理解,并适配更改意图;有些人就是跑题大王,经常性的多个频道切换;有些人压根不知道自己要啥,希望机器人给建议;有些人就是无聊,纯属挑逗机器人。有些人……

毕竟“人工智能皇冠上的明珠”,理解不了,接不好话就是人工智障。

而当用户想怎么说就怎么说,好比脱缰的野马,上下文指代、否定、反问,双重否定、以汉语言的博大精深之处,又会分分钟教计算机做人。

  • “中国:我们这边快完了。
  • ”“欧洲:我们这边快完了。
  • ”“中国:我们这边好多了。
  • ”“欧洲:我们这边好多了。”

以上对话也是2020年3月中旬这个场景才看懂,过一段时间后,大家偶尔翻到这篇文章,未必会理解。

此前的对话管理的学术报告的定义是:“考虑历史对话信息和上下文的语境等信息进行全面地分析,决定系统要采取的相应的动作,如追问、澄清和确认等。主要任务有:对话状态跟踪和生成对话策略。实现途径上,目前有检索模型、生成模型等。”

我自己提炼了一套简单便于理解的,对话设计的本质是管理。目标即:通过问答行为,控制用户的表述,明确其需求,并方便计算机理解。

还是以买电影票举例,我们就是基于各种主副词槽,模拟出用户各种各样的表述,去完成每一轮的查询,检索行为。从结果上而言,用户只要确认好4个主词槽(为什么是4个上篇文章有讨论过思路)就可以完成下单行为了。

当用户的话术中,一旦分析出,用户有买电影票的意图的时候,此时主动权就应该完全由对话管理去掌控了。

接下来的问题是?(以买电影票场景为例)如何设计问题?

一、自己如何问?

设计话术问题之前,先要把基本功打牢固。

问题有两种,一种是开放式,一种是封闭式。

开放问题:问题提得比较笼统,圈定的范围很不固定,给回答者很多自由发挥的空间。用户回答起来比较轻松,更易于展示自己,没有太多的压力。

封闭问题:问题提得很具体,圈定的范围比较固定,要求回答者在范围内给予明确回答。用户会感到压力,有种被审问的感觉。

所以,面试的时候,相亲的时候,尽量提开放性问题,以方便对方自由发挥,更容易展示自己,容易发散,容易给彼此接话,也不会把天给聊死。

而在统计问卷,做填表,调查的时候,封闭问题更容易做到统计,文科生理科生的思维就在于此,要不怎么说程序员严谨刻板不浪漫呢,毕竟跟计算机打交道过多。此处没有黑程序员的意思,毕竟我也敲过一些代码,也认识很多有趣的可爱的程序员。这是社会偏见,是刻板印象,不可取。

故而,我们可以对不同的提问方式做一个总结和提炼。

PS:NER(命名实体识别)常见的有时间、数字、人名、地名……等等,大家理解为方便做填空题即可,具体可以查询百科。

回到买电影票场景,我们的核心目标是引导用户说出4个主槽位,最终完成下单的目标。

我们可以尝试着做下练习,以便自己熟悉语感。

练习填入开放性的问题,并且自己写上答案是为了培养自己“写问句”的业务敏感度,确认自己使用的话术是否会引发用户的开发性回答。同样我们可以需要做一下封闭型问句的练习。

之所以每个都写,完全是出于帮大家理解,以及感受合适不合适。

比如确认座位,直接替用户选好,然后用【确认】的问法去请求“肯定”回答,就比较合适,如果用户不满意可以交付给GUI,绝不推荐语音选座。

比如影片名这类,用【确认】问句去求“肯定”回答,就不合适,有限条件下,我们无法命中用户的喜好,视当时的情况,用【填空】或者【选择】比较合适

在实际的过程中,还会加入一些话术比如“为您找到……为您推荐……附近有……请问……您看这个可以么?”等语气助词,显得不那么生硬。

工作中很多的同学,一开始就写句子经常无头绪,毕竟任何一个问句都是合理的。

语感不好的人一定要练习,规避“开放问题”,同时掌握好,使用【填空】【选择】【确认】三种问法结构的选择,做到熟练应用,在我们部门是所有人的基本功。

以后再遇见任何业务,便可基于业务情况做问法选择,做到“运用之妙,存乎一心 ”。

本阶段重点:

  • 理解开放问题和封闭问题,以及封闭问题的三种方案。
  • 使用封闭问题去管理用户答案,以便于计算机理解。

问,是非常重要的基本功,是做好对话设计的前提。

二、用户如何答?

经常有人说用户的回复千奇百怪,就固定域对话交互而言,事实并非如此。本章节主要做预判,尝试穷举用户的可能答复。

直接公布方法论,笔者归纳总结如下:

无论对话行为是单轮还是多轮,只要你把对话的机会交给用户表述,每回复均有可能发生。让我们来看一下各种情况,以及不同场景下的应对方案。

(1)用户回复归类:跟随

以看电影举例,用户如果每个都依据话术,完成指定回答,很容易完成任务,我私下称这类用户为“小乖型用户”。

应对策略:成功提取槽位后,推进程就好。

(2)用户回复归类:筛选与修订

在对话的过程中,对方会基于自己的需求做筛选行为,亦或者是,明明需要用户确认当前词槽(确定电影场次),而用户临时起意,需要改此前的槽位,比如换电影,或者换影院。

首先,如果每次都让用户做肯定否定,必然出现推荐不到位不精准,把用户逼成“挑选型用户”。同时,再者,用户也有挑挑拣拣的权力啊。我十分不好意思,称之为“挑选型用户”。

应对策略:应该基于用户的需求,进行调整,帮助用户完成查询/修订结果。

语境内筛选,非常考虑语义理解,是做好NLP必备的功底,筛选做的好,体验才能够稳稳超过GUI,用户有需求才筛选,当用户筛选完,自然最终完成填槽行为,最终达成目的。

还有一种情况,我称之为无法处理的筛选,请看例句:

“帮我找一个高大上的电影院;好看的/有内涵的/羞羞的电影;舒服的,观影效果好的座位;适合我南山吴彦祖/福田刘亦菲看的电影院;”

人类看来,这是属于无意义的前置条件,其实取决于内容标签和指代关系。

例如,“我想看关于海战的电影;停车比较方便的电影院;想选一个靠门的座位”,这句话在人类看来是有意义的,如果内容层面没有这个标签,筛选也无法做起,从计算机角度,我统一归纳为,无法处理的筛选。而不是无意义筛选。

应对策略统一处理成,随机推荐,并反馈封闭问句,请求对方的封闭回答即可。

如果你反复跟人类纠结,企图让对方定义更为明确的筛选条件。

“抱歉,我不太明白,什么是羞羞的/有内涵的电影。”

“抱歉,我不太明白,什么是海战有关的电影。”

那又变成开放问题了,这种情况是就算是用户给AI解释,AI也未必听得懂,对话变长不利于业务的后续推进,这种体验就十分不爽了。

(3)用户回复归类:关联咨询

在某些对话语境下,很容易问出边界外的问题,毕竟有些问题是影响用户购买决策的。

例如用户买机票的时候会问天气情况,人类能懂能猜测能推理,因为这些是常识,但是计算机是否理解常识并推理,就看各家的设计了。

应对策略:本质上是如何处理好,任务、问答、闲聊之间的关系。其实各家都处理得不一致。

这种基于业务需求的关联咨询,某种意义上也是开放域了,你可以选择认怂,无法回答此类问题,并请求用户重新确认该关键点上的词槽。

再者你比较负责,会尽量覆盖一些对话领域,并训练各种FAQ的响应,但要处理好交叉对话之间的记忆关系。

例如:订机票业务,下单之前。

  • AI:blablabla(介绍机票的各种情况)……需要为你预定么?
  • 用户:哎对了,上海那天天气怎么样?
  • AI:blablabla……
  • 用户:那杭州呢?
  • AI:blablabla……
  • 用户:行吧,下单吧。

此时AI应该如何处理?两轮天气对话之后的下单?好,如果用户再问三轮,关于机场,行李托运,打折情况,然后决定下单,此时AI应该如何处理?

以上并非杜撰,是笔者在用户对话log后台看到用户的真实使用情况。

应对策略的选择,凡事考量性价比,在此前的一篇文章中,在思考场景和确定业务边界的时候,应该考量到位,此处不展开。

(4)用户回复归类:无意图表述

在某些对话语境下,很容易问出边界外的问题,毕竟有些问题是影响用户购买决策的。

例如用户买机票的时候会问天气情况,人类能懂能猜测能推理,因为这些是常识,但是计算机是否理解常识并推理,就看各家的设计了。这也是一种可能存在的情况。这首先是用户的权力,会出现的异常情况。亦或者是自己的语义理解覆盖不到位,用户的明确意图,识别成了无意图。

应对策略:语义理解不到位的不讨论,自己通过对话log强化语义覆盖即可。而真的确定为无意图表述,转向做推荐,请求用户确认。

如果用户反复选择无意图表述,不填槽便始终无法推进,对话进入死循环,AI只需要处理,随机回复策略即可。

(5)用户回复归类:命令控制

命令控制是一个全局的指令,它仅仅在特定的语境、技能、场景、流程点上完成激活行为。买电影票这个例子用命令控制的场景较少。其实相当多的技能在某些场合会激活命令控制,比如播放类的音乐/视频和或者游戏等。

应对策略:

每个流程点的命令控制都是特定的规则是提前定义好的。如果用户在未激活的场景下说了命令控制,也不会响应,而是交由其他业务逻辑完成回复。一种比较通用的回复是AI:抱歉超出我的理解范围……(增加一个封闭提问请求用户回答)?

(6)用户回复归类:跳出或退出

任何轮次,用户都可以做出“跳出或退出”行为。跳出和退出都是结束当前任务的表现。

一般而言跳出是打开某个其他的技能。退出则是明确说再见。

同样存在误识别的可能性,特别是看电影,或者听歌,作品名字可以随意取。比如《我想去拉萨》就是一个歌名,会不会被导航识别呢?比如说有些音乐或者电影名,可以完全可以命名为《滚》《退出》《再见》等等。

应对策略:

1、语义理解增强NER的识别表现,以规避歧义双关语表述。2、明确跳出,开启另一轮任务对话,明确退出就结束对话。3、基于用户付出的成本,增加挽留确认和退出话术引导。

为方便记忆,这一段的知识点归纳于此,做到了以下图中的几点就完成了对话管理,且这种方法论,可用于绝大多数的任务型业务场景。

三、对话管理思维

再次重申对话管理的目标:通过问答行为,控制用户的表述,明确其需求,并方便计算机理解。

达成目标需要行动,而思维是统一行动纲领的。

最开始我想说“理性思维”和“感性思维”的,但是从个人语感上,从各位读者的理解角度而言,用在这个场景下,不精准,遂修订为“直男思维”和“暖男思维”。

直男思维:目标性强,简洁准确,不绕弯。

暖男思维:识别意图,幽默风趣,有温度。

我们设计一个技能,就是利用VUI的特性,快速帮助用户达成目标。即:任务导向,结果导向。

全程是帮助用户快速完成任务的心态,想让对方快速达成结果的,用封闭提问。

用户找AI助手是解决问题的,而不是调情的。所有的填槽行为都是为了完成某个任务,用户有需求,就应该快速给结果,不墨迹。

下面我用一个例子来解释这两个词儿的准确与方便记忆所在。

就好比,女生跟男生说肚子痛。

男生的身份如果是医生,直接封闭型问题走起:“痛了几天了,具体哪个位置啊,睡眠好不好”,基于用户的特征判断,填槽即可,然后开药、休息、多喝热水都是解决方案。

男生的身份如果是男朋友或者男同事,上来就“多喝热水”,直男无法识别意图(渣男往往更有嗅觉),直男回复无法满足其预期,就别怪女生翻白眼了。

这一切的原因是,AI助手在用户心中是一个怎样的角色定位,以及用户使用AI助手的目的。如果AI助手的定位是情感机器人,那么处理策略又另当别论了,受限于篇幅此处不展开讨论。

其实直男思维和暖男思维并不对立冲突,跟理和感性思维一样,可以融合统一,但在不同的场景下,分主次。

在快速帮助用户解决问题的前提下,AI助手一样能做到幽默风趣有温度。

处理策略归属于理性,实际话术表现处理归属于感性。这一块需要大量的语感练习,有天赋才能够发现对话文字之间的细微差别之处。

对话设计,在掌握了理性的逻辑思考之后,余下部分其实是文科生发挥优势的战场。

这里,一张图片整理本篇方法论知识点。

文末提几个问题,给大家思考,也留作后续的NLP方法论文章的递进,同时也是做好一个对话助手的递进。

以下是工作中的同事以及一些读者朋友留言的问题。

1、新用户对VUI是陌生的,有时候看用户使用非常挣扎,偶尔突破性的提问就会碰到边界,如何教会用户使用各种巧妙的表述,快速达成任务目标?

2、机器人的回复是固定套路,很多时候用户仅仅改了一个筛选条件,AI又不得不从头到尾念完,然后请求用户确认,我自己用都觉得罗嗦,何况是用户,而这类信息又必不可少,如何处理好这类问题?

私以为,只有当我们面对的问题,达到这种颗粒度,才更能够做好对话管理行为。欢迎各位同学留言评论,期待着与你的交流。

【本文来自51CTO专栏作者“老曹”的原创文章,作者微信公众号:喔家ArchiSelf,id:wrieless-com】

戳这里,看该作者更多好文

 

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2020-04-20 10:10:44

NLPAI语音

2020-04-13 13:13:20

NLPAI语音

2020-05-07 11:13:44

NLPAI产品

2020-06-19 09:58:53

人工智能

2023-04-28 09:02:24

智能客服人工智能Siri

2016-11-17 10:46:10

2013-12-25 09:50:27

华为马悦企业业务

2015-04-13 16:00:24

数据库选型关系型数据库NoSQL

2022-06-27 08:47:29

BEM修饰符元素

2021-11-05 08:28:27

内存泄漏调试

2017-04-19 14:23:08

项目管理分配

2018-11-21 10:13:35

2019-04-29 09:52:46

容器安全漏洞网络安全

2023-04-21 15:54:46

AI开源

2022-03-14 08:40:48

数据MRDPRD

2022-06-08 10:05:43

技术管理数据

2011-05-26 16:27:24

SEO

2020-07-22 07:00:00

微服务架构

2015-08-12 17:06:28

2019-08-19 09:01:54

项目管理
点赞
收藏

51CTO技术栈公众号