做过了40+个机器人的总结:对话机器人核心功能要点

0 评论 2548 浏览 8 收藏 37 分钟

导语:本文作者前后经历了40+个机器人的搭建、设计与运营,同时从0-1构建了机器人对话平台。通过对过往经验的复盘总结,作者对“对话机器人”的核心功能要点做了梳理与总结,希望这篇文章对你有所帮助,欢迎大家讨论。

一、对话概述

在讲对话核心功能之前,我们先看一下,什么是对话?

对话是对话双方基于某个话题,通过语言进行信息交互的过程。比如:你早上起来,你妈妈跟你的对话:

Mother:早餐想吃啥?我给你煮

你:我喝点粥就好了

Mother:那煎荷包蛋给你吃吧

你:好嘞,我刚想吃

Mother:要一个还是两个?

你:一个就好了

Mother:再给你弄点腐乳吧

你:好呀

1.1 对话组成部分

对话的定义中,有几个关键的组成部分。

1.1.1 对话双方

即一个对话中的信息传递与交互者,这里一般指的是双方的对话,若是超过2人,则视为“群聊”。可以想想微信中的定义:单聊和群聊。

在上述的例子中,对话双方就是你和你妈妈。你们俩通过语言进行信息的交互,如果你爸也参与进来,那就是三方的对话。相较于双方的对话,三方(或更多)的对话,在信息交互上更为复杂些,这不在我们的讨论范围内。

1.1.2  话题

一个对话的进行,必定有其对应的话题,话题与对话双方的核心需求相关联。

没有话题的对话,几乎不存在。当然,你可能会说,那我就漫无目的的闲聊呗,没有固定话题呀。是的,这里我们把“闲聊”也看做一个话题。

“闲聊”虽然看起来漫无目的,但是其本质也是为了满足对话双方的需求与目的。如果没有这个需求,那双方可能连说话/打字都懒得动,故这里把“闲聊”也定义为某个话题。

在上述的例子中,你和你妈妈这个对话的话题就是“吃早餐”,为什么有这个话题?

因为你妈妈关心你早餐吃什么,你不论出于真的想吃早餐也好,想让你妈妈放心也好,都是基于“吃早餐”这个话题,跟你妈妈聊几句。当然你除了聊“吃早餐”,你可能也会在对话中,突然想起你昨天到的快递,进而问你妈妈“快递是不是拿了”。

此时,对话就变成了多个话题:“吃早餐”、“是否拿快递”。

一个对话中,可能只有1个话题,也可能有多个话题。详情你可以回想下生活中的各种对话。当多个话题交织在一起时,对话的结构也会变复杂。但是,几乎没有对话是没话题,对话双方在那儿对话的(想想是不是挺诡异),这种“牛头不对马嘴”的对话,同样也不在我们的讨论范围内。

1.1.3 语言

语言是信息的载体。在对话中,基于话题,对话双方是需要语言来交流的,语言可以通过语音(也就是说话)、文字(也就是打字)来表达。

而我们为什么需要语言呢?因为语言主要是来传递人要表达的信息的,再看上述的例子:你妈妈说:“早餐想吃啥?我给你煮”.

为啥你妈妈要这么说?因为你妈妈要知道你“早餐想吃啥”这个信息,因为获取这个信息,她才能进行接下去的动作:你想喝粥,她就煮粥;你想吃包子,她就热包子;你想吃龙虾,她可能就把你抓过来打你头并说:“一大早你脑子是睡傻了吧你”。

同样的,你说“我喝点粥就好了”,也是通过语言来传递“你想喝粥”的信息给你妈妈,让她接收到这个信息,你们俩都在使用语言传递各自想要表达的信息。

当然,语音、文字这两种方式,能承载的信息是有差别的。语音能承载的信息更多,因为有语调、语速等更多维度的信息。这个也是目前AI对话领域的ASR信息衰减的一个原因,此处在不赘述。

1.1.4 信息交互

对话的本质在于对话双方间的信息交互。信息交互是让对话进行的必要条件。

比如上述的例子中,你妈妈问你:“早餐想吃啥?我给你煮”。而你没回应她,继续玩弄自己的手机。那你妈妈会怎么样呢?你妈妈大概率会再问你一次“早餐想吃啥?”(生气值上升20%)。

为什么?因为在对话中,信息是需要交互的。你没有回应你妈妈问你的话,这是信息的单向传递,你妈妈并没有获取到她想要的信息,所以她再问了你一次。假如你再不回答,那对于这个话题,对话就进行不下去了。你妈妈可能开始质问你,对话的话题就转变为另一个:“为什么你妈妈问你话你不答”。

所以,信息交互对于对话而言,是至关重要的组成部分,也是让对话进行的基石。

1.2 机器人在对话中的职责

在讲机器人在对话中的角色与职责前,我们先来看一下,机器人能做的事情是什么?对话机器人的兴起,得益于本次AI中的NLP领域的发展。可用于对话的AI能力有什么呢?

  • 语义识别能力:意图识别、实体识别、语义相似度识别
  • 知识构建与识别能力:知识图谱

看着似乎挺抽象是吧?没事,我们后面会具体讲。简单地说,现在的AI技术决定了对话机器人可以解决的问题是:某个特定行业领域下,基于某类特定问题,提供简单固定的解答/服务。

上述的“吃早餐”对话场景,如果是一个“早餐机器人”,它会怎么做呢?

假设它的工作流程是:询问早餐需求->做早餐,那么,“询问早餐需求”跟你的对话应该是这样的:

Bot:早上好,请问你早餐想吃什么呢?(提供选项:粥,包子,面包,花生汤)

你:我想喝粥

Bot:好的。那您喝粥配荷包蛋可以吗?

你:好啊,我刚想吃荷包蛋

Bot:吃一个还是两个呢?

你:一个就好了

Bot:再配点腐乳吗?

你:好呀

看完这段你可能会说:这效果不是跟我和我妈的对话一样嘛!机器人真的有这么厉害吗?

答案是NO,机器人并没有那么厉害。为什么?我们从刚才说的对话机器人可解决的问题看。

1.2.1 特定行业领域的特定问题

上述的对话是基于“吃早餐”这个话题对应的“饮食”这类领域而定的。如果是所有领域(或者说是开放阈),机器人是处理不了的。

比如你突然问它:“我的快递单号是多少”,它可能就没法解答。因为它只是针对你“吃早餐”的机器人。问快递单号的话,你可以打开淘宝,让阿里小蜜机器人回答你:)

1.2.2 提供简单固定的解答/服务

机器人只能提供固定流程的解答与服务,并不能解答复杂、随机性太大的对话问题。

比如刚才的对话,机器人说:“早上好,请问你早餐想吃什么呢?”而你说:“有锅边糊吗”(注解:锅边糊是福建早餐小吃)机器人可能压根就不知道你在说什么。

因为机器人的这个问题,是有人为的预设值,若访客回复内容,未落在预设值内,就会出现机器人无法处理的问题。

所以,在设计机器人时,需要了解当机器人发问后,访客可能会说的内容。语言本身就是开放阈的内容,访客会说什么,设计者只能按照概率大小去设计,尽量去覆盖,并无法穷尽访客的说法。

而访客的语言,又受到个人因素、当时环境因素的影响,从本质上来说,这是永远的矛盾点。

因此,对话机器人能解决的对话问题,是所有对话语言问题中的一部分,或者说一小部分。虽然对话机器人做不了非常智能、随机性很大的对话问题,但是在某些领域,对话机器人还是可以很高效、便捷地帮人处理很多对话问题。

比如智能客服领域、系统内人力资源问答领域等等,这也是目前对话机器人的价值应用领域。

二、机器人对话

2.1 用户对话场景

既然对话机器人是针对某个特定行业领域的对话,那么在设计对话功能之前,第一步是需要明确,对话机器人解决的是哪个行业领域,什么访客,具体什么场景的的问题。这是对话机器人的框架与边界,只有先确定,后面的设计才可以进行。

2.1.1 确定行业领域

比如:“电商行业”、“金融行业”、“医疗行业”等等,行业决定了访客特性、机器人应答策略、机器人知识库内容与结构。

2.1.2 确定对话场景

比如:“售后场景”、“售前场景”、“企业内部接待支持”、“微信群聊”等等。不同的对话场景,可能对应不同的对话目的,决定了机器人“该如何应答”。

场景往下拆分,根据颗粒度从大到小,又可分为:场景->意图,指的是场景从大到小的拆分。

有的机器人根据业务需要,还会更细地拆分为:场景->主题->意图(父意图)->意图(子意图)。每个意图下分别对应不同的机器人对话流程,同时流程间会设定各种规则,以应对在对话中访客不同的发问情况。

如何确定对话场景?

一般需要AI训练师/AI PM,根据行业内的场景情况,通过人工对话数据,或查阅相关资料/访谈的方式,了解行业场景特性,并拆分出具体的访客意图。

比如:在“电脑培训售前场景”中,根据访客对话场景,会划分“咨询网页设计”、“咨询JAVA课程”、“咨询SEO课程”,“咨询Python课程”等等。常见的,对话场景的数量,一般在20个-50个之间不等(当然,某些特定对话场景会超出这个范围)。

对话场景的划分,需遵循MECE原则:相互独立,完全穷尽。即:所有意图需覆盖所有的访客意图情况(完全穷尽),且意图之间尽量相互独立,互不交叉(相互独立)。这会为后续的应答策略,做一个良好的场景设定,让后续的对话设计更好进行。

2.2 机器人应答策略

虽然不同的对话场景中,机器人具体的应答策略是不一样的:比如售后场景的机器人主要以解答为主,而售前场景的机器人是引导访客留联。但是在所有场景的机器人中,是有一套适用于对话机器人设计的应答策略方法论的,差别点在于具体落地机器人的实现展示方式。

2.2.1 单轮对话、多轮对话

根据机器人与访客对话形式的不同,可以将对话形态划分为单轮对话、多轮对话,通俗地讲即:你想让机器人如何解决访客的问题。

2.2.1.1 单轮对话:访客问一个问题,机器人立即回答

比如:

访客:“你们培训地点是在哪儿啊?”

BOT:“我们是在海淀区知春路25号百事大厦13楼”

这类访客问题中,访客问的是一个客观的,不随访客信息/其他信息等的不同而不同的回答。即:不论访客是小明,还是小红,“培训地点”它永远都是“海淀区知春路25号百事大厦13楼”。所以机器人只需要根据事实(通常将该类知识配置在知识库中),直接回答即可。

由于其交互是一问一答,在一个对话轮次中即可解决问题,故称之为“单轮对话”。

2.2.1.2 多轮对话:访客问一个问题,机器人通过询问访客信息,根据访客不同的信息作出回答

比如:

访客:“我可以报六级英语培训班吗”

BOT:“请问下您通过四级英语考试了吗?”

访客:“通过了”

BOT:“嗯好的,您可以报六级英语培训班的,这边登记下您的信息”

这类访客问题中,若要进行回复(无论是机器人/人工),则需确定某些参数信息才可回复。“是否通过四级英语考试”,是上述例子中的参数变量。

“通过”对应一个回答;“未通过”则对应另一个回答。机器人需要通过询问访客这些信息,才能进行回答。所以对话需要进行多轮的交互,一般为“机器人询问-访客答”的方式,故称之为“多轮对话”。

这两种对话形式,也构成了目前对话机器人的对话,是对话的框架基础。为什么没有其他类型的对话形式呢?

原因很简单,因为现有的NLP技术,在支撑具体业务场景下,这两种对话形式是最有效的。或者换句话说,暂时没有第三种方式让机器人更好地服务访客。

而对话机器人的设计,主要在于对话策略的设计,具体表现在对话流程的逻辑设计。单轮对话由于其一问一答的形式,基本不需要对话逻辑的设计,其重点在于知识的构建和回答的设计。所以,对话设计的重点,在于多轮对话的设计。

2.2.2 多轮对话设计

多轮对话的设计要点:场景、对话流程、信息流转。

2.2.2.1 场景

定义对话场景,行业内机器人的做法主要是通过意图定义场景。比如:“咨询Python课程”这个意图,通过对意图的解答和服务,来完成机器人对话。

2.2.2.2 对话流程

这个是对话机器人的核心,包括:对话流程如何运转、异常情况该如何处理、多轮对话与单轮对话的协作配合。

2.2.2.3 信息流程

对话内的信息,是对话的核心要素。所以需要设计:对话内信息如何流转;同时,由于机器人是需要和对话外的系统做信息交流,所以也需设计对话外信息如何与对话内信息进行交互流转。

2.3 核心功能要点

2.3.1 场景识别

场景识别,是对对话场景、用户意图的识别。这也是对话中体现AI技术运用的核心功能。行业内主流的做法,是用意图来定义,对应的AI技术就是意图识别,本质上是一种分类算法。

比如:“咨询Python课程”这个意图,需要提供访客关于这个意图的各式各样的说法,进行模型训练,从而“教会”模型去识别。所以需提供让用户可进行意图定义、语料定义的功能,让用户可进行配置。

通常的做法是:

2.3.1.1 让用户构建语料

主要有2种方式:

  1. 让用户自行构想创建。但这种方式是及其枯燥和艰难的,因为定义一个意图,需要几十条甚至上百、上千条的对话语料(对模型来说,数据量越多越好)。对于用户来说,任务艰巨且乏味;
  2. 抽取人工对话数据,通过系统推荐构建语料库。这种方式是在用户创建数条语料后,系统根据相似度,从人工对话数据语料中,推荐给用户。用户可自行决定添加/不添加,省去了自己凭空想象的枯燥过程。

2.3.1.2 让用户构建意图句式

与第一种方式不同,这种方式是让用户抽象意图的各种表达方式,通过一个句式,来涵盖访客的说法。句式内容可包括:关键词、正则表达式、实体。通过配置词顺序、匹配度,来构建句式,从而实现匹配访客说法的目的。

值得注意的是,这种构建方法,本质上是通过“写规则”来设计,与AI的理念实际上是相反的。所以一般作为补充第一种方式使用。

其弊端也很明显:往往句式写多了,句式之间可能出现交叉、互斥的情况。而配置的人却较难发现与调整。当句式越来越多后,就更难进行调整,对对话机器人实则是一种隐患。

当然,这种方式在机器人冷启动时相当好用,这也是其存在的可能是最大的价值。

除了上述通过意图来定义用户场景外,还能通过其他维度进行定义。比如,通过关键词、实体、正则表达式、变量,来定义用户场景。

定义的维度越丰富,能支撑的业务也就越多,同时对于后续流程的处理,也就需考虑更为复杂的情况。所以基于当前需解决的业务形态来设计,至关重要。

2.3.2 流程逻辑

流程逻辑的构建,可以说是对话机器人的骨架。流程决定了对话机器人是否可为访客提供价值。流程与场景一般是一一对应的关系,通常我们若用意图来定义场景的话,那么每一个意图,将会对应一个对话流程。

还是上述“电脑培训行业”的机器人,当机器人向访客询问:“请问你想了解哪方面的培训课程呢?”

  • 访客若说:“我想了解Python课”,那么对应意图识别的结果为“咨询Python课程”,于是进入“Python课程”的对话流程;
  • 访客若说:“我想了解JAVA课”,那么对应意图识别的结果为“咨询JAVA课程”,于是进入“JAVA课程”的对话流程。

当然,访客也有可能什么都不说,或者压根就不回答机器人的问题,只顾自己描述自己的问题。这就需要机器人设计者(AI训练师),构建“无意图”/“通用意图”,来覆盖访客的各种场景,让机器人应对自如。

以下讲讲流程逻辑功能设计中的关键要点:当你开始设计对话机器人时,你就会发现,对话机器人的骨架,其实是一棵对话树。

除了对访客问题的识别,通过AI能力进行外,这棵树几乎全部是由AI PM/AI训练师,通过定义对话规则,来构成的。这也就是我们说的对话策略。而流程的设计,即使这棵树的设计。

2.3.2.1 流程间逻辑

一个机器人中,必定有多个流程,一般数量在几十个,流程间逻辑的设计尤为重要。

  • 流程优先级

众多流程中,当访客的问题,同时满足多个流程进入条件时,哪一个流程优先触发?

通常的做法是,让用户给意图/流程做一个优先级的排序。如按照编辑顺序从上往下,越重要的意图,用户可以放在越前面。这是一种对于大多数场景有效的做法,但是真的就没问题吗?

答案是NO,比如:

访客:“Python课和JAVA课,哪个好学啊?”

这种情况下,访客意图是“咨询Python课程”,还是“咨询JAVA课程”呢?

按照我们刚才说的策略,用户意图“咨询Python课程”排在“咨询JAVA课程”前面,则进入“咨询Python课程”意图的流程,反之则对换——这能解决访客的问题吗?

这是通过人工预判的方式,来提前设定访客问题的意图归属。而访客的意图,可能随着对话场景、对话语境、自身情况的不同,而存在差异的。简单来说,就是我们用一种简单的一刀切的方式,来解决访客的可能复杂的意图问题。这是一种概率押赌的方式,只能解决一大部分问题,而非所有问题。

很遗憾,目前的AI技术,只到这个能力,还尚未到真正的“人工智能”时代。所以技术不够,产品来凑,需要产品经理来不足AI不好解决的问题。

我们的做法是,针对这句访客问题,可用知识图谱进行答疑(当然也可配置FAQ+规则,但是需要做的排列组合较多,如:Python+JAVA;Python+C语言,等等),同时进入一个“无意图”的流程。通过进一步询问来确定访客的意图及对应的流程。

  • 流程间跳转关系

流程间分为同级流程,与父子流程。

同级流程:同级流程之间的跳转,一般和流程中新意图的识别有关。当访客触发新的意图时,即做流程跳转,比如:

访客:“我想学Python”    —-进入“Python课程”流程

BOT:“可以的,我先了解下您的情况”

访客:“C语言怎么样啊?”—-跳转至“C语言课程”流程

父子流程:子流程的准入条件,需为先触发父流程。二者为并非同级关系,而是从属关系。

比如:在医疗口腔中,“牙齿美白”与“冷光美白”是父子流程关系。因为“冷光美白”是“牙齿美白”中的一种方式。

访客:“你们能做牙齿美白吗?”    —-进入“牙齿美白”流程

BOT:“可以的,我先了解下您的情况”

访客:“冷光的你们有没有啊?”—-跳转至“冷光美白”流程

一般而言,进入子流程后,将不再返回至父流程。因为子流程是更细的场景,对话机器人的服务原则是,进入更细的场景,即能提供更有针对性的服务。

  • 流程执行唯一性

同级流程中,当流程执行后,访客问题再次出发了该流程,是否可再次进入呢?

这个问题其实根据不同的行业与业务场景,策略的选择是不一样的。通常来讲,对于售后服务等来说,重复进入同一个流程,要求是较低的。

同时由于词槽收集可避免重复发问,所以可接受再次进入流程;而售前引导性的场景,就较为几回再次进入同一流程,因为这样往往会让机器人看着更加“不智能”,降低访客对服务的信任感,所以一般是不能再次进入的。

但是无论如何,这个问题都是在对话机器人中,流程逻辑设计中应考虑的要素。

2.3.2.2 流程内逻辑

流程内的逻辑,指的是当访客进入某流程时,机器人的应答策略。

  • 流程准入条件

前面说了,流程一般的准入条件为意图。但一些较复杂的场景,除了意图外,我们还可以用关键词、正则表达式、实体、变量来定义访客的场景,作为流程准入的条件。

流程准入条件,可以看成是流程的大门:条件定义得宽泛,则门越大,进入流程的访客问题类别更少,在流程中需处理的情况就越多;条件定义得苛刻,则门越窄,进入流程的访客问题类别越少,在流程中需处理的情况就越少。但是同时,需定义的流程数量也更多。

  • 流程进展

流程进展是对话处理的关键。简单来说就是,机器人如何发问?当机器人发问后,访客的各种回复情况,怎么处理?

a. 机器人如何发问?

a)发问内容

发问内容与当前意图下,机器人需获取的信息相关。通常为设计者设计的固定询问话术,进行发问。

这里顺便提到AI技术:NLG,即对话生成。可通过AI通过对话场景,生成相应的话术内容。但从实际效果来看,目前的NLG尚未达到业务对话要求,固定的话术效果会更好。

b)发问顺序

发问顺序通常是固定的预设顺序。通常设计者会根据用户场景,设计某个意图下,机器人发问的具体顺序。当然,在发问之前,若机器人已收集到相应信息,可做跳过处理。

b. 访客回复后,机器人如何处理?

访客回复后的处理,是对话流程往下进行的必要条件。机器人发问后,访客的回应可能有几种情况:

a)提供了机器人发问的信息

情况1:提供了单一信息,比如:

BOT:“你想咨询什么课程呢?”

访客:“Python课”

这种情况是最理想的情况。我们只需要设定不同信息下对应不同的对话分支走向即可,对话树也即顺利进行下去。

情况1:提供了多信息

BOT:“你想咨询什么课程呢?”

访客:“Python和JAVA的课程我都考虑”

这种情况中,AI算法会从访客的回复中提取“Python”和“JAVA”两个信息,并且并不知道访客到底是想要哪个。这种情况就需要做特殊处理,有几种常见的处理方式:

  • 随机选取一个信息,进行后续对话分支的执行;
  • 构建句式,选取其中一个信息,作为分支执行的条件;
  • 进入除预设分支外的默认/其他分支,执行后续的动作。

具体适用哪种策略,也需根据不同机器人而设计。

b) 访客回复,但未提供机器人发问的信息

情况1:访客的回复内容,未在预设的对话分支中,比如:

BOT:“你想咨询电脑培训的什么课程呢?”

访客:“我想咨询画画的班”

这种情况下,一般设计者也较难预知这种访客的回复,一般会让对话走“默认/其他”分支流程,以便让对话继续。当然,事后发现了问题,也可以通过补充对话分支的方式,来扩充机器人应答能力。

情况2:访客的回复内容,新起了一个话题,比如:

访客:“我想咨询下Python课程”

BOT:“好的。请问您是什么学历呢?”

访客:“对了,你们的JAVA课怎么样啊?”

这种情况,访客已经新起了个话题“JAVA课”,对话可以进入“JAVA课”的意图流程中。当然,也可以不进入,这就涉及到“新流程优先”还是流程内“分支优先”的问题。

一般而言,对于场景较为垂类,较无多话题交叉的对话,使用“分支优先”是更优的选择;而对于对话中较长有多话题交叉的对话,使用“新流程优先”效果会更好一些。这也是策略的选择,通过概率大小决定应答策略。

c) 访客不回复

当机器人发问后,访客不回复。有可能是访客离开了对话,也有可能是访客切换了应用程序(常见于手机中)。访客若不提供相关的信息,对话不好进行下去。

处理的方式有:间隔一段时间(如几十秒)后,机器人再次发问(话术可有所变化),以获得相应信息;或是静默等待,若访客依然不回复,则自动填入信息默认值,执行下一步对话动作。

  • 流程打断处理

在机器人发问-访客回复的多轮对话 交互中,我们预想的是访客会按照我们预设的对话节奏进行。但是实际过程中,访客并不在意机器人是按照什么规则、什么节奏进行对话的,所以会出现当机器人正在应答,访客进行打断的情况(特别是在语音机器人的场景中)。

一般的处理方式是:被打断后,机器人暂停回复,等待访客表述完。被打断的流程,若进入了新的流程,一般会等新流程执行结束后,再次回到原有流程。这个可根据不同的流程而设定“打断后恢复”的设置。

2.3.3 信息流转

前文讲了,对话中的信息流转,是对话的重要属性,信息流转分为对话内与对话外的信息流转。

2.3.3.1 对话内信息流转

即通过获取访客信息,做信息的记录、传递、更新与使用。其中,有两个要素是最重要的:

  • 实体:实体是系统获取访客信息的来源。可以通过AI的实体识别能力,也可通过定义关键词库的方式进行识别,这是信息获取的源头;
  • 变量(词槽):通过实体识别获取了访客信息后,需要存在一个载体中,这个载体就是变量(词槽)。变量就像人体血液中的红细胞一样,获取、运输、更新对话信息,并把信息给对话的中控系统使用。可作为条件判断的依据,也可作为话术的内容。

2.3.3.2 对话外信息流转

在对话机器人中,对话信息不仅在对话中流转,也可跟对话外部的系统做信息的交互,比如:

访客:“帮我查一下明天的天气”

BOT:“好的。明天北京天气晴,气温15-23摄氏度。”

对话机器人需要通过外部系统(查天气系统),才能获取具体的天气信息。其中,通过将具体的日期、地点信息传递给查天气系统,获取相应的天气信息,这就是对话外信息流转。

一般会设置接口调用的方式,通过设定接口和参数,与对话 机器人外的系统做信息交互。从而实现各种对话机器人技能的落地,如:查天气、订火车票、开电视、打开音乐等等

2.3.4 流程与知识库协作

如果说流程是整个对话机器人的骨架,那么知识库就如同机器人的血肉,因为机器人做答疑的一大部分内容,是通过知识库进行的。而流程与知识库需通过写作配合,才能让对话机器人在解答访客问题的同时,又让对话顺利无缝地进展,从而最终达到对话目的。

流程与知识库协作的策略,主要有以下2种:

  1. 访客发送的每条信息,先使用知识库做解答,后执行流程的动作与话术:该策略适用于“解答型服务”的对话。即:尽量解答访客的每个问题,即使机器人的对话显得啰嗦,也可接受。
  2. 当访客回复未在预设的对话分支中时,才使用知识库做解答

该策略适用于“引导性服务”的对话,对话重点在于让对话引导的体验更加,而不在于解答访客的每个问题。两种策略均各有利弊,侧重点不同,提供的服务体验也不同,可根据具体情况而确定。

三、总结

对话机器人产品,鉴于现有的AI技术,可以说有一大部分是需要AI PM做规则设计、策略设计的。

设计思路可概括为:用判断概率的方式,选择其对话策略。所以对话中有大量的逻辑设计、策略选择,根据对话机器人所处的行业领域与用户场景,做不同的取舍和侧重点设计。

本文主要概述了对话机器人的设计要点,但有些要点中,又有其丰富的设计理念和实操细节,本文不在此方面赘述。后续会针对重点要素做详细讲解,希望对你有帮助。

 

作者:咖喱鱼丸,5年PM经验,2年AI PM经验

本文由 @咖喱鱼蛋egg 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!