前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >面向NLP的AI产品方法论——如何做好“多轮对话管理”

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

作者头像
半吊子全栈工匠
发布2020-04-26 16:19:30
1.5K0
发布2020-04-26 16:19:30
举报
文章被收录于专栏:喔家ArchiSelf喔家ArchiSelf

本系列文字是一位创业者的投稿《面向NLP的AI产品方法论》,老曹尽量不做变动和评价,尽量保持系列文章的原貌,这是第3篇。

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

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

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

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

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

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

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

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

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

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

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

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

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

一、自己如何问?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本阶段重点:

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

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

二、用户如何答?

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

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

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

(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又不得不从头到尾念完,然后请求用户确认,我自己用都觉得罗嗦,何况是用户,而这类信息又必不可少,如何处理好这类问题?

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-04-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 喔家ArchiSelf 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、自己如何问?
  • 二、用户如何答?
    • (1)用户回复归类:跟随
      • (2)用户回复归类:筛选与修订
        • (3)用户回复归类:关联咨询
          • (4)用户回复归类:无意图表述
            • (5)用户回复归类:命令控制
              • (6)用户回复归类:跳出或退出
              • 三、对话管理思维
              领券
              问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档