导语：本文作者前后经历了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协议