编辑导读：ChatBot这个概念已经提出很久了，意指可帮助人进行对话交互的对话机器人，也简称为Bot.。本文主要阐述ChatBot的概况，方便你了解NLP领域目前主流的应用对话机器人的基础详情，一起来看一下吧。

一、ChatBot 类型

按照访客预期的机器人应答方式的不同，ChatBot分为3个类型：咨询型、闲聊型、任务型。

咨询型：通常为访客期望就自己提出的问题，机器人能给出相应的专业解答。表现为一问一答的形式。机器人相当于一个“知识顾问”，做“答疑解惑”的事情；闲聊型：访客的预期是可陪伴自己聊天的机器人。无论访客说什么问题，机器人都可以接得上，聊得上。访客期待的不是某个具体目标的完成，而是情感上的陪伴；任务型：通常为访客期望就自己提出的问题，机器人不仅能给出专业解答，还能主动反问获取相关信息，根据不同信息给出不同的解答。同时还可完成一些任务指令。广义上将，无论是“专业解答”，还是“完成任务指令”，都是完成任务，故为“任务型”。

Why：为什么这么分？

这样的划分方式，相信大家已经见得很多了。但是为什么这么划分呢？主要有两个原因。

1）对话的本质

对话的本质是：对话双方的信息同步。（此刻停留10秒钟可回想下你接触过的各种对话）

对话只是工具，在对话中的信息传递，即对话双方想通过对话传递的信息，才是对话的意义。

举个例子：你跟你的朋友说：“我们去玩吧！”你的朋友接收到这个信息的时候，他心里会有几个问题想问你：“为啥突然要去玩”、“啥时候去玩”、“去哪里玩”。因为这些信息，你没告诉他，他需要获得这些信息，以达到与你同步的阶段，才能进行下一步：去完成“去玩”这件事。而对话，就是达成信息同步的工具。（难道他跟你眼对眼对视下就可以知道嘛？）

2）AI现有的技术发展限制

虽然AI迎来了新的一春（相对于以前的发展），但是基于机器学习/深度学习的NLP技术，目前只能解决一部分问题，或者说，一小部分问题。一个对话系统中，真正用到AI技术的，目前是基于【意图】【实体】框架的识别体系，而这部分，也仅仅占对话系统10%-20%（具体我们可以专门开一篇文章详细分析，这里暂不赘述）。

而基于【意图】【实体】识别框架，目前最容易达成的，就是“指令式”的对话（没错，这里是我给它取的名字）。比如，你对机器人说：“帮我订张火车票”（抱歉我还是用这个快被说烂的例子）。“订张火车票”这是一个非常明确的指令。机器人通过识别意图“订张火车票”，马上可进行相应信息的填充（词槽填充追问），帮访客完成“订火车票”的任务目标。

相反的，一些“非指令式”的对话，对话系统很难通过现有的AI技术处理。比如，在医疗营销机器人中，访客问“我最近肚子有点痛”。这是一个很模糊的指令，机器人并不知道访客的意图是什么，甚至人也很难知道。“肚子痛”很可能是肠胃的问题，可能是女性疾病问题，等等。现有的NLP技术无法识别，因为无法做 逻辑推理。

所以，现有的ChatBot能处理的，且擅长处理的问题，是那些指令式的问题，这就对应了我们刚才说的3种分类中的两种：咨询型、任务型，这也是目前应用于商业中最广泛的两种类型的ChatBot。而另外一种 闲聊型，是基于 记忆神经网络模型 的对话方式，是现有神经网络可支持的实现方式

What：他们的联系与区别是什么？

从访客的预期来看，可以分为2大类：任务达成（Get things done）与 情感陪伴（Get company）

1）任务达成（Get things done）

咨询型ChatBot 与任务型 ChatBot

识别角度上，二者机理一致。均是通过分类（相似度匹配）的方式。

咨询型（FAQ相似度计算）：通过访客问句与每条FAQ的问题，计算相似度匹配，从而回复问题相应的回答。任务型（意图识别）：通过访客问句与每个意图配置的对应query，计算相似度匹配。通过多轮的询问交互，最终解决访客的问题。

应答功能上：任务型是升级版的咨询型

咨询型是针对访客query，直接给予答案回应任务型是针对访客query，收集query相关的信息（意图-词槽 机制），根据收集的情况给予答案回应（答案回应包括：富文本、链接跳转、外部资源调用），是以任务达成为目的的对话。

2）情感陪伴

闲聊型ChatBot 的对话宗旨在于，基于话题让对话延续。在对话理念上与前者有较大区别。其目的是让访客，通过对话得到情感上的支持与陪伴。比如你跟iPhone Siri 说“我想你”，她会回复你“我也想你”等之类的话，让你得到情感上的陪伴体验。

但是从NLP现有的发展情况来看，闲聊型ChatBot的效果并不是太理想。因为对话没有一个主题，机器人是因访客问题回答而回答，是一种“被动式”的应答，并无主导对话的能力。所以通俗讲，目前的应用基本就是让访客“图个乐”的阶段。

二、ChatBot平台

What and What For？为了解决什么问题？

由ChatBot 应运而生的就是ChatBot对话平台。什么是对话平台呢？对话平台即为了让机器人使用者可以配置自己想要的机器人而与之对应的机器人配置工具。在这个工具上，用户可以根据自己不同的业务需求，搭建与之对应的机器人，以实现自己的业务目标。

举个栗子：比如A用户要搭建一个用于接待访客问题的客服机器人A，与B用户要搭建一个个人助理类的机器人B。

二者的业务目标不同：A主要用于答疑解惑，比如解答“你们银行借记卡怎么办理”的问题；B主要用于任务执行，比如发出一个指令“帮我看看附近有什么适合约会的餐厅”，机器人会根据用户的需求做相应的任务动作。

但是二者可以使用同一套ChatBot 平台，来搭建其相应的业务。因为二者基于的AI基础、对话基础是一致的（或者说是类似的）。

So，ChatBot有几个特性：

顺便说一句，现有的对话平台厂商，同质化相当严重。各家基于的对话框架可以说基本相同。不同点，也是商业落地突围点，在于如何落地，如何基于垂类行业的精细化设计与运营。

What’s good？什么样的对话平台才是好的对话平台？

基于上述的几点，我们可以反推过来，什么样的ChatBot平台，才是好的对话平台呢？

高度抽象：高度抽象ChatBot的基本元素，使之成为所有对话构建的基石。

高度抽象意味着将ChatBot组块化，类似于“搭积木”进行搭建。每个积木，都需要做得具有高度通用性高度抽象其实是个“反推”的过程。即从业务侧反推，抽象各种业务的共性，得到适用于诸多场景的对话元素。如现有ChatBot平台框架，“意图”、“词槽”、“上下文”等对话元素。当然，最通用的部分，已经由国内外大厂ChatBot平台定义好了，并形成了行业内的规范，这部分对于从业者来说，更多的是沿用，而不是重复造一个轮子。

拼装规律明确：明确与Highlight 组装拼接元素的规律，帮助ChatBot使用者快速理清思路，高效配置出符合自己业务需求的ChatBot

搭建机器人是有一套规律的，通俗讲叫做“套路”。比如从分析与划分机器人场景，到确定每个意图，再到意图内多轮对话、意图间多轮对话，都是可以有一套可复用的规范和配置规律的。在ChatBot中，这套规律应该是足够明确，有效帮助用户理清思路的

简单易用：简单、高效、易用，降低新手成本，尽可能预置通用的的对话原材料，开箱即用。

简单，对于ChatBot平台来说，是个不简单的词。如果是一个新手小白，未受过AI训练师的培训，来配置一个机器人的话，学习成本是很高的。因为ChatBot本身就不是一个C端易用的产品。我们以行业标杆Google DialogFlow为例，即使Google已经做得足够易用了（交互体验较于其他B端产品），但是对于小白用户，还是需要参照操作手册学习上手。所以，尽量做得简单，对ChatBot来说是较难的事情。基于1，在“预置通用的对话原材料”的维度上，可作为的地方大得多。有资源的厂，可以利用自己的行业积累，为用户提供预置语料的服务。可别小看，在搭建机器人中，语料数据的重要性，可以说是重中之重。不仅影响的是冷启动的效率与质量，更影响机器人运营的效果好坏，直接或间接觉得机器人产品的生命周期。基于2，目前行业的一个论调是，在【算法】【算力】【数据】这AI三驾马车中，【算法】已通过开源代码受到广为人知，且现有的深度学习的能力阈限大家也都了解一二，用深度学习可以实现的对话领域的巨大突破可能性极小；【算力】通过GPU等技术硬件的购买，花钱都能达到差不多的算力水平。现在的【数据】是各厂间做出产品差异化的重要点。因为【数据】以为着技术落地业务的关键桥梁，一个能解决业务问题的机器人，好过一百个用牛逼的技术堆出来但不解决业务问题的机器人。【数据】作为ChatBot的养料，至关重要。

四、ChatBot Skill 5要素

ChatBot Skill 5要素（当然，也是我这么划分的）分别是：意图、实体、词槽、回复、上下文。为什么是这5个要素？这5个要素具体是什么作用？他们背后有什么具体逻辑呢？

我们可以这么理解，ChatBot是要帮访客做事的（此处我们只讨论应用最广也最容易落地的任务型ChatBot）。这个“事”，有可能是回答问题（答疑解惑），也有可能是帮助访客完成一个任务（任务执行）。回答问题通常我们通过FAQ的问句相似度匹配即能完成。

回到我们上文说的，对话的本质是信息的交换与同步。机器人要帮访客做一件事，首先得知道访客要做什么事（意图），所以，现有ChatBot系统的首要任务，就是确定访客想要干嘛，也就是 意图识别。只要当ChatBot信息与访客对等了（至少在访客想做的事情的维度），ChatBot才能帮访客做相应的任务。

1. 意图

意图描述的是某个访客query领域内的封闭问题。一次意图框架的完成（意图识别-词槽填充-回复），会完成一次对话闭环。 相比于意图，上下文 描述的是对话上下文不同意图之间的问题。

词槽、回复与意图挂钩。即：一个意图，对应特定的词槽、回复

1）如何进行意图识别？

意图识别本质上是分类问题。目前行业主流的做法就是，将同类的句子做句子集合，相应的边成为一个意图。即：将所有相同含义的话，抽象为一个意图。比如【订火车票】这个意图，同类的句子是：“我要订火车票”、“给我订张火车票”、“火车票能订不”，等等。所以本质上讲，ChatBot是通过判断访客问句与意图中配置的问句是否相似，来判定是否属于该意图的，即进行归类。

2）意图的配置

意图配置的原理：通过预测访客会问的问题，与意图建立关系。在机器学习以前，这些类似的表述，是需要人工一句一句地去配置的，只有配置了某问法，机器才会做相应的匹配命中，触发相应的回答，即通过规则来判断。配置这么多问句，是不是现在想想都头皮发麻？

而NLP的意图识别能力，就是可以通过配置少量的语料，进行自主地泛化。把那些未配置的，但是表述又相近的问句，也可识别到该意图中（当然，识别也是有准确率的，跟算法模型、训练数据相关）

举个例子：刚才【订火车票】这个意图，假如配置的几个问句：“我要订火车票”、“给我订张火车票”、“火车票能订不”。ChatBot不仅可以识别到这几个问句，也能识别到如“你能给我订个火车票么”、“给我来张火车票”，等等的表述，归为该意图。

2. 实体

1）什么是实体？

实体是对话（表现为访客query）中，有实际意义和指代的词。

2）为什么需要实体？

通过定义实体，让系统去采集访客query中有用的、人想要采集的信息实体识别（NER）：相当于是使用AI技术的采集器枚举实体/规则实体： 相当于是使用人为规则的采集器

3）如何进行实体识别？

NER过程：从访客query–>分词–>实体识别 的过程

3. 词槽

1）词槽是什么？

词槽是与意图绑定的变量

2）为什么需要词槽？

因为词槽是对话中信息传递的载体，对于对话的信息来说至关重要。

3）如何进行词槽的填充？

通过实体识别，将实体识别的值，赋值给词槽

回到刚才的例子，当识别到意图后，如：访客说“帮我订张火车票”（原谅我还是举这个被说烂的例子，谁让它通俗易懂呢），识别到意图为【订车票】，那么ChatBot需要知道你要定啥时候的票，从哪儿到哪儿，乘车人是谁，要几等票。对应的参数为：出发时间，出发地点，到达地点，乘车人，票类型。所以ChatBot接下来需要做什么？当然需要问访客这么些个信息呀。所以，这几个参数信息，就是【订车票】这个意图下，关联的几个词槽。

这几个词槽该如何收集呢？没关系，交给NLP算法。现有NLP一个很重要的成就是就NER，即实体识别。通俗地说，就是可以把访客问句中的重要信息给抠出来，作为对话的关键信息（相当于机器人理解了访客的意思，虽然在人看来还是挺智障的程度，但是谁让它可以在某些领域应用的好呢）。所以回到刚才的问题，NLP算法可以把ChatBot想要的几个参数信息，通过发问的形式，从访客问句中提取出来：出发时间，出发地点，到达地点，乘车人，票类型。

4. 回复

一旦获取了这些信息，ChatBot就该干正事儿了所以ChatBot就应该基于收集到的信息，给出相应的回复。回复分为纯文本回复、调用接口回复、执行动作回复。“订火车票”的最终结果是帮助访客“订成功火车票”，所以需要执行“订票”的动作，并把订票信息返回给访客。

5. 上下文

最后，上下文 的意思是指不同意图间，可能存在继承信息与意图切换的情况。

举个例子：访客问“今天北京的天气怎么样？”，ChatBot回复：“今天北京晴转多云，有阵风，25摄氏度”。访客接着又问“那上海呢”，那么ChatBot应该需要知道，“那上海呢”这句话，还是意指“查天气”这个意图，而不是在问“上海的空气质量”、“上海的限号是多少”其他意图的问题。所以需要用到【上下文】的概念来配置ChatBot。

一个对话的进行，是跟对话进行中的信息继承与更新相关的。所以不同的意图之间，不止存在同等并列的关系，还存在嵌套关系（父意图、子意图、子子意图）、上下继承关系，等等。这些均需使用上下文这个对话元素来实现。

五、总结

ChatBot在目前的各行业、各领域，有广泛的应用，也不乏各大厂、中小厂进入ChatBot平台开发的赛道。万变不离其宗，无论ChatBot在领域中多垂直、应用多丰富，其始终离不开上文阐述的基础要点内容。原因其实也很简单，因为目前的AI技术、NLP技术发展到这个层面，其对应的底层原理是相对固定的。国内外对于ChatBot的设计理念，大致是趋同的。同时也期待AI的发展，可以突破目前的一些壁垒和限制，基于AI的设计就可更加智能、更加灵活。希望对你有帮助。

作者：咖喱鱼丸，5年PM经验，2年AI PM经验

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

题图来自Unsplash，基于CC0协议