【文末福利】聊天机器人的几种主要架构实现

文末福利：聊天机器人的几种主要架构实现

在过去的20年中，互联网，把人们带入了一个全新的时代。在这个全新的时代，我们创造出了四种连接方式：一是人和物品之间的连接，二是人与人之间的连接，三是人和信息之间的连接， 四是人和设备之间的连接。连接不是目的，它只是为交互提供相应的服务。对我们每一个人来说，最友好最自然的交流方式就是采用自然语言的方式进行交互。通过自然语言的方式进行交互完成对话系统的设计与实现。

下面将通过介绍几个行业对话系统的架构实现，抽象出它们的共性，为读者在搭建自己的对话系统提供便利。

客服机器人架构

Gartner 最新的研究调查, 在发达国家到2020年，20%的公民将使用人工智能助手帮助他们完成一系列日常的、可操作的任务。在发达国家，个人的互动与基于人工智能的服务已经变得越来越频繁，虚拟个人助理（VPA）不再是简单的提问和回答。到2022年，中文NLP在对话机器人领域应用的企业将超过80%——高于目前的51%。

在这个背景下，Gartner还预测了，2018年将有超过20亿的人会通过智能手机及其连接的设备，使用会话AI与VPA、虚拟客户助理（VCA）、虚拟执行助理（VEAs）、聊天机器人和其他的人工智能功能的服务。消费者将越来越熟悉使用这些服务。再这样的背景下，客服机器人的需求也表现地更加强势。

客服机器人指帮助客服回答问题提高人工客服效率的机器人。客服机器人可以用于回答客户的常规、重复性的问题，但不是替代，而是辅助人工服务，改变客服工作的模式，进一步提高客服工作效率。

据调查，使用纯机器人完全替代客服的并不多，人机结合模式使用广泛。不满意用户在各模式下占比都非常小，不足1%。满意用户占比相差最大，其中人机结合模式的客户满意度最高。

至于为什么人机结合模式的满意度是三种模式中最高的，分析一下主要有以下几个原因：

（1）机器人响应速度快，且可同时接待多位客户，而且客户不需要等待；

（2）机器人替代人工处理咨询中的重复问题，人工客服不易陷入烦躁情绪，客户体验好；

（3）遇到复杂问题，人机结合模式可以无缝切换人工来处理，顾客体验不会中断。

使用智能客服机器人的优势也是很明显的：

（1）机器人可以7 X 24 小时在线服务，解答客户的问题。

（2）常问的问题，重复的问题都可以交给机器人来自动回复，省去很多重复的输入及复制粘贴。

（3）可以辅助人工客服，在人工服务的时候，推荐回复内容，并学习人工客服的回复内容。机器学习到的人工回复内容，可以挪为机器人的知识库使用。

功能需求

智能客服机器人有很多优势，但它还处于初步发展阶段。现阶段客服机器人还没有完全取代人工客服，客服机器人仍在辅助人工解决问题。技术人员还将客服机器人适当加入推荐和导购领域，比如前文中提到的阿里小蜜机器人。这样客服机器人的作用就不仅仅出现在售后阶段了。机器人客服开始出现在引导用户的购买和消费活动中。下面就具体介绍一个客服机器人的架构，这个客服机器人包括了推荐和导购功能，当然也包括了FAQ机器人。其实这些机器人都是基于任务型的对话系统。这里选了招聘领域场景作为讲解对话系统的切入点，具体分析了一个基于招聘领域的对话系统的架构。

图 1 客服对话系统功能需求分析

图1中描述了整个VCA系统功能的需求。整个系统应该包含了不同的机器人，这些机器人通过一个对话管理系统（Dialog Management）进行统一管理。对话管理系统可以将不同问题根据系统中每一个机器人的处理能力，分发给不同的机器人。每一个机器人都可独立成为一个系统，它们具有不同功能，会产生相应的回复。DM通过收集每一个机器人产生的回复，对回复排序后返回。整个客服系统可以包含多个小的对话系统，比如FAQ Bot的主要功能就是负责FAQ的处理；售后Bot的主要功能负责售后应用场景下的处理；售前导购Bot支持场景覆盖职位推荐，招聘问答，观点回复等；闲聊Bot主要支持的场景应该是客户的闲聊问题。Other Bot表示一种扩展，它可能是基于知识图谱的对话系统，也可能是基于某种技术解决某一类特定问题的专属对话系统。

此外，在设计客服对话系统需要考虑以下几点：

（1）时间特性要求。系统接口回复的要求到底是多少需要认真设计。系统极限相应时间到底是多少？如果是以微服务的形式调用，总的时间被分摊到每一步时间消耗应该是多少。

（2）灵活性。系统的各个模块应该在可控的状态内，每一个模块可插拔，保证线上质量。

（3）安全性。内外网隔离，注意网络完全，系统安全，用户安全，数据安全。

（4）可扩展性：系统的各个模块支持扩展，支持跨平台，支持多种语言，算法模型可以灵活切换。

（5）可靠性：系统和集群稳定运行，主要的集群实现双机热备；实现灾备；当单个节点发生故障可以迅速切换。

（6）可用性：系统的各项功能可用，系统上线必须符合一定的正确率。

系统逻辑架构图

这里给出一个客服机器人的系统逻辑架构图。如下所示：

图2系统逻辑架构图

整个系统分为七个部分，数据服务，对话理解，对话场景，中控中心，服务治理和监控系统。

系统采用微服务的方式进行交互，每个服务可以有多个实例，避免单点故障的产生。

底层服务框架：采用Dubbo和Spring框架，所有的服务均是基于这两个框架来开发，以及实现服务的发现和访问，从而降低服务耦合，提高扩展性。

Bot CC服务：是一个中控服务，它本身无状态，用于请求任务的分发以及控制相应会话处理流程的流转。

各种Bot服务：包括闲聊Bot，基于任务的Bot，QA Bot，FAQ Bot等，各种不同类型的Bot会负责各自相应的会话逻辑和状态的维护管理；

NLP服务：包括NLU服务，意图识别服务以及语义相似度计算服务，负责各种Bot里面所需要的和NLP有关的相应计算和分类工作；

存储/缓存：Redis是缓存服务，主要用来存储和维护实时会话状态，MongoDB主要用来持久化会话数据，MySql主要用来存储系统和服务的各种配置信息。

阿里小蜜

阿里巴巴于2015年7月推出了阿里小蜜产品，在面世的仅仅几年中，阿里小蜜发展之迅速令人难以想象。阿里小蜜给出了一个典型的智能对话系统的架构，如下图所示：

图3典型的智能对话系统

这个架构不失一般性，放到任何一家公司，只要替换相应的底层数据，做好与数据对应的具体算法及服务，就可以成为一个实实在在的落地项目。

从上面这张智能对话系统的架构图中可以看出:自然语言处理（NLP）是对话系统的核心部分。通过阿里巴巴公开分享的技术文档来看，在阿里小蜜中有一个比较核心的功能模块。这个核心模块功能，除了自然语言理解和对话管理之外，智能问答模块用来完成问答类任务，智能聊天用来完成闲聊类任务。它对外提供了SaaS平台支持，PaaS平台支持以及BotFrameWork支持，BotFrameWork为用户提供可定制化智能助理平台服务。这两张架构图充分体现了分层架构的思想，也清晰地讲解了阿里小蜜的架构。

图4智能对话交互中的核心模块

在核心模块中可以突显出几个重要的知识点：第一，自然语言理解NLU是整个系统的核心；第二，智能问答和智能聊天是游离在NLU功能模块；第三对话系统提供不同平台的服务功能。

自然语言理解的语义表示主要有分布语义表示(Distributional semantics)、框架语义表示 (Frame semantics) 和模型论语义表示(Model-theoretic semantics) 三种方式。一般地，在对话系统自然语言理解采用的是frame semantics 表示的一种变形，即采用领域（domain）、意图（intent）和属性槽（slots）来表示语义结果。

图5领域知识示意图

同时小蜜的技术分享文档中也给出了自然语言理解的处理逻辑流程。这张图主要讲述了阿里小蜜NLU部分的处理流程，可以看出意图分类，属性抽取以及基于上下文的意图排序是NLU重要的组成部分，这里给出了每一个部分对应所采用的算法模型，这些算法模型在前文中都有所提及，这里就不在详细展开了。如下图所示：

图6阿里小蜜自然语言理解（NLU）流程图

由于篇幅的问题，这里不再展开图6中智能问答模块和智能聊天模块部分的内容。阿里小蜜智能问答模块主要处理的常见问题解答（FAQ：Frequently Asked Questions），它使用的算法也是前文中提到的注意力模型。智能聊天模块部分采用了IR Rerank Generation处理流程和算法。

对话管理（DM：Dialogue Management）的主要功能是对输入进行结构化语义表示，根据上下文来管理整个对话的状态，决定下一步采取什么样的动作。阿里小蜜将对话分为两个阶段：第一阶段通过多轮对话交互，利用NLU收集相关完成用户的需求，将用户需求结构化；第二阶段就是请求服务阶段。下面是阿里小蜜的DM框架图实例。

图7阿里小蜜对话管理框架图

百度对话系统

百度依托搜索的天然优势也研发有相应的对话系统。百度对话系统目标是实现人与机器的自然对话，百度的对话系统是基于多任务，多领域的对话系统。在百度的对话系统的架构中明确了服务，模糊了算法层和数据层。阿里小蜜相比将对话管理明确拆分成了两个部分：对话管理和用户对话流管理。百度的机器人通过对话系统中的分发功能模块，被分发到相应的服务。在对话系统中，百度共实现了三种类型的服务子系统，即基于知识的信息查询子系统、可完成特定任务的对话子系统以及开放域聊天子系统，如图8所描述的那样。

图8百度对话系统架构图

图9 支持信息查询与特定任务完成的系统架构

从图9可以看出，在和用户交互的过程中起重要作用的都是两部分功能——自然语言理解（NLU）和自然语言生成（NLG）。图9中对话管理模块给出了一份非常详细处理逻辑。

百度和阿里对话机器人都把意图分析作为对话机器人最重要的组成部分。百度采用了三种方法进行意图识别：融合了知识与统计的意图分析技术；基于文法规则的意图分析技术；基于语义匹配的意图分析技术

(1) 融合了知识与统计的意图分析技术

百度面向特定任务的对话中，用户意图可以用语义框架来表示。语义框架包括用户的意图以及槽位（Slot）填充。通过从用户的Query中识别出意图及槽位。具体的做法是首先基于已有的大规模文本数据、知识库、以及人工标注数据通过知识图谱，RNN，Bi-RNN以及CRF等算法将用户意图和槽位的联合学习相互融合。

如下：

表1 意图分析模块详解

(2) 基于文法规则的意图分析技术

对话系统中意图分析技术的目标就是将Query转化成可查询的结构化数据以及逻辑表达式，然后系统可以执行这些命令。如

Query =提醒我明天查下张震的动作电影好吗？

图10基于文法规则的意图分析示意图

对上面这句Query 经过乔姆斯基文法规则分析后，最终产生了一个机器可以识别的指令。在引导分析和识别的过程中也使用了NLP中多个相关技术作为支持。

(3) 基于语义匹配的意图分析技术

百度对话机器人技术中引入了意图图谱技术解决意图表示、需求满足和交互引导等问题。意图图谱采用了基于图结构的方案表示用户意图以及各个图节点之间的关联关系。意图图谱中每个节点都代表一个意图，节点之间的边代表意图的关系。例如，“阿拉斯加à阿拉斯加州 |阿拉斯加雪橇犬”这里“阿拉斯加”从语义的角度上看并不是很明确，但是在意图图谱中就可以通过和用户交互细化到某一个意图图谱的节点上。

图11 意图图谱示意图

开放领域对话系统的架构

开放领域的对话系统，因为用户不一定有明确的目标或意图。如Twitter这样的社交媒体网站上的对话通常是开放领域的，之所以是开放领域就是因为他们可以谈论任何方向的任何话题。无数的话题和生成合理的反应所需要的知识规模，使得开放领域的对话系统实现相当困难。下面给一个开放领域对话系统的架构，如下图所示：

图12开放领域机器人架构

微软小冰是开放领域聊天的代表，它是微软亚洲院于2014年推出的一款人工智能聊天机器人。微软凭借在大数据、自然语言语义分析、机器学习方面的技术长年累月地积累开发出了微软小冰。自它推出到现在，微软小冰通过语料和技术不断更新，已经慢慢开始对开放领域聊天和搜索引擎进行了整合。

小结

本文内容的组织也是从如何架构一个一般性的对话系统开始，后续又详细介绍了两个个机器人：阿里小蜜和百度对话的架构设计。本章中间部分介绍了一些对话系统常用的一些工程技术以及工程运维相关的知识。最后，通过介绍两种不同领域对话系统的一般性架构来串联所有对话系统架构设计共性知识。通过学习本章，可以使我们在设计架构对话系统时有一个全新的认识。

以上内容摘自《聊天机器人—入门，进阶与实战》一书，经出版方授权发布