聊天机器人 (Chatbot) 背后的人工智能

Chatbot 已是一个非常热的应用和研究领域，原先基于规则 (rule-based) 的 Chatbot 已经开始与机器学习深度结合，能够表现出具有一些“智能”，这进一步的拓展了它的应用领域和前景。智能 Chatbot 可以帮我们订餐，查询天气，回答问题，以及大部初级的客户支持工作。现阶段的 Chatbot 虽然没有人类那么智能而且开发成本也不低，但也优势明显 ，它可以 24x7 在线，全年无休，秒回客户的询问，长期比人的成本低。在可以预见的未来，Chatbot 必然会大量普及，尤其是会替代那些只需要简单重复工作的在线客户服务岗位。

人们理解人工智能往往有一个误区，认为人工智能就是像科幻电影在很多方面超过人类的机器人，而实际中却远不是如此。我们目前阶段所说的智能，大都指的弱人工智能，即在某一特定的领域可以充当人类助手或者部分替代人的工作，远没有到能在通用领域胜任人类工作的阶段。现阶段的 Chatbot 上也是如此，只能完成一些助手级别的简单重复性质的工作，远不可能完全替代人类。虽然智能技术在不断拓展了Chatbot 的能力，但现阶段我们也不能对 Chatbot 期待过高。

规则还是机器学习

早期的 Chatbot 都是基于规则的 (Rule Based)，需要预先定义规则的，用户必须按照事先定义好的流程一步步的与 Chatbot 对话，否则就会进入死胡同, 导致使用受限很大。现在结合机器学习技术后，Chatbot 可以适用更多情况了，因为机器学习模型可以基于已经数据对未曾见过的数据进行预测，而手中已知数据或者定义的规则总是有限的，能基于已知去预测未知，适用性范围就可以扩展了很多。近些年深度学习 (Deep Learning) 盛行后，还出现了一种完全不需要规则的全开放 Chatbot，NMT-Bot 就是其中之一。NMT-Bot 基于 Seq2Seq 的 NMT(Neural Machine Translation) 模型实现，这是最复杂的深度学习模型之一，它原本用于不同语言间的翻译，训练数据是就是待翻译 (FROM) 到 翻译后 (TO) 语句。一个可用的 NMT 模型需要用海量的数据去训练，这里说的海量大概是百万条以上的 FROM 和 TO 的数据。同样的想要让 NMT-BOT 在没有任何规则的情况下达到较好的聊天效果，也需要海量数据才有可能。

海量级数据是一个很高的门槛，所以这种全开放的 Chatbot 目前能实用的还很少，而且也只有大公司才有实力可以做。现在用的最多的Chatbot 是处于中间地带，综合机器学习和规则的 Chatbot，也下一节要介绍的内容。这样虽然限定的应用领域，而且实现起来还是需要定义大量规则 ，但实现难度相比全开放式大大降低了，是目前开发 Chatbot 的主流方式。

Chatbot 的智能

开发 Chatbot 时有三个重要概念, Intent、Entity和Action。Intent 指的是用户对话的意图，Entity 则是对话中重点要提取的信息，Action 则是根据 Intent 和会话的上下文给采取的动作。 Chatbot 首先是区分用户输入语句的 intent，我们可以把 Intent 理解成对话的分类，对于不同的分类有不同的处理流程，所以要首先把对话对应到一个分类上；其次就是在不同分类中提取对话中的关键信息，比如用户想查询天气，这就是一个 Intent，我们在后台已经设置了查询天气的接口，但进一步查询时需要知道时间和地点，就是两个 Entity，等获取了这些信息之后就是 Action，比如在这里 Action是调用后台，那就会向后台发一个请求查询天气并返回给用户。

目前 Chatbot 主要智能集中在 Intent 识别，Entity 提取和 Action 预测上。在 Dialogflow 和 RASA NLU 模型定义 Intent 时都要输入一些训练数据，就是用户说什么话可以归为这个 Intent，然后会用机器学习的算法去训练一个模型。在把单词向量化时一般使用事先训练好的Word Embedding 向量，比如 GloVe，因为经常一起出现的词在Embedding 空间中的向量接近，所以可以适用于训练集中没有出现的情况，比如在训练集只出现了 "I like apple"，当用户输入 "I like pear"也会进入相同 Intent。

使用预先训练好的向量有一个问题就是有一些专业的词汇并不会出现在向量表中，而且在不同的专业领域对向量的要求不同，对比 balance 和 cash 在通用向量集中相距就很远，而到金融领域，这两个实际上经常一起出现，这样使用预先训练的向量的反而会带来负作用。RASA NLU 中训练算法可由 NLU Pipelien 可以定制，spacy_sklearn 使用预先训练好的向量，而 tensorflow_embedding 则相反，不使用任何预先训练的向量，根据训练样本训练向量，这样可以更适用于某个特别领域，当在训练数据量较大的时候会有更好的效果，参见这篇文章的说明。

识别Entity是自然语言处理中重要问题，对于一些通用的 Entity 已经有成熟的算法，比如地名、人名、组织名称等等，这些算法模型通常也是集成在工具中，RASA 支持把 Entity 识别转到第三方的服务中，可以用 ducking 等第三方服务，Dialogflow 则完全是一个黑盒子。专业领域的 Entity 则需要由用户输入数据训练模型，Entity 的识别对于进一步处理非常关键，要尽可能穷举所有可能性，尤其是在专业领域，才能达到较好的识别效果。

完成Intent 识别和 Entity 提取后，这些信息就交给 Chatbot 核心，核心则需要由用户事先定义的模板(Diaglog 里叫 Flow, RASA 中则叫Story )做出反应动作，即 Action。通常核心还会记忆一些之前聊天的关键信息，这些信息就给到人工智能算法来预测下一步做什么。用户要事先定义一些对话模板，可以要求模型只根据用户定义好的模板给出 Action (Memoization Policy in RASA) 或者可以由让模型做预测 Keras Policy and Embedding Policy，这样如果聊天流程并不在事先定义的模板中时，Chatbot 根据已经的流程和用户的输入预测出下一步最大可能要做什么，或者说转到那个Intent上。

Chatbot 与集成

Chatbot 实际上是引导用户完成了关键信息输入的工作，进一步的处理则是做后台的 webhook 来做，比如天气查询，Chatbot 的作用就是能让用户在各种情况输入查询天气所需要的时间和地点信息，然后向后台的 webhook 发出请求。一个好的 Chatbot 除了可以让用户顺利的输入所需要的信息外，还需要一个强大的后台来实现所需要的功能。当一个 Chatbot 功能变多后，后台就需要实现很多功能，就像是一座冰山，人们看到的 Chatbot 客户端其实只是是浮出水面的那一小部分，大部还在水面以下是后台需要实现的功能，所以集成各种系统来实现 Chatbot 所需要的功能也是开发很重要的一个方面。

作者：自由01

来源：简书