随着云计算、大数据、机器学习、深度学习等技术的不断发展，基于人工智能的智能客服机器人应运而生。以同程艺龙客服机器人为例，分析智能客服机器人的意图识别和对话管理构建。

所谓的智能客服机器人，其实就是一个用自然语言与用户交流的人工智能信息系统。它采用了包括自然语言理解和机器学习技术在内的多项智能人机交互技术，能够识别和理解用户以文字或语音形式提出的问题，通过语义分析理解用户意图，以拟人的方式与用户交流，为用户提供信息咨询等相关服务。

智能客服是人机交互在客服领域的应用。本文就简单的和大家分享一下智能客服机器人和程一龙在意图识别和对话管理过程中的一些经验。

目前同程艺龙的智能客服分为单轮问答的QA Bot和多轮对话的任务Bot。多轮对话的智能客服系统一般分为以下几个模块:客人的问题Q进来后被NLU模块抽象成客人的意图和关键信息槽。意向和槽传递给DM模块后，由DST、DPL和NLG模块返回答案。

目前智能客服对话的核心是匹配用户意图。只有意图明确了，才能给出有针对性的答案，所以下面是意图识别的一般原则。

一、关于意图识别的实践

对于智能客服机器人来说，意图识别就是判断用户的问题是什么。用户想表达什么？

例如:

我不想要这张票。-退款

我的火车票已经出票了吗？——督促出票。

我想预订明天的航班。-帮我下订单。

一般采用以下方法提取。

1. 基于命名实体提取和词库

举个例子，如果我的订单已经发出，使用HanLp自然语言处理工具包，会选择以下两个词来下单和出票，并根据停用词词典去除订单。然后根据该票的发行情况，在词库中匹配对应的分类，找到对应的意向。对于复合句，可以统计词频，根据最高频率找到对应的分类意图。

这种方式的优点是操作简单，通过搜索可以快速找到对应的意向。但缺点也很明显。比如这个订单还没发，没发就不用了。本意是退票，很明显提取的票是错的。识别准确率比较低，所以一般用这种方法作为机器学习意向槽数据提取。

2. 基于模板的匹配

非常符合规则的查询类别，通过规则分析获取查询意图。帮我订一张明天从苏州到北京的机票。可以使用规则模板提取【苏州】到【北京】【明天】【车票】如下。

该方法需要命名实体提取、词性规范和语义分析来完成，对于常规咨询具有较好的准确率。然而，这种方法需要R&D和训练者做大量的工作，并且很难推广。

3. 基于机器学习

1)逻辑回归

识别机器学习中意图的分类问题，即使用逻辑回归进行分类。在使用逻辑回归之前，应该首先对单词进行切分和矢量化。分词可以比较每个分词的效果，最常用的分词是解霸。配置专业术语和停用词。在分词之后，你需要对单词进行矢量化。

一般有两种方式，一种是使用One-Hot编码，一般用于专业性较强的领域，另一种是word2vec，可以很好的识别单词之间的关系。

一键编码将所有单词对半排列，相同的地方标为1。比如分词后，按词频排序结果如下:

然后[order，issue ticket，cancel]得到[[1，0，0]，[0，1，0]，[0，0，1]]的词向量如果一句话是这个订单还没发，不要出票，订单出现一次，票出现两次，这句话最后的向量是

使用word2vec得到的结果是相似的。

对于意图识别，一般分为多个类别。然而，多分类问题是由二分类问题扩展而来的。

2)二元分类

对于二分法问题，在概率分布未知的情况下，一般假设正态分布(高斯分布)，多维高斯分布如下，也是多个高斯分布相乘的结果。

带入贝叶斯公式，最后的结果就是关于W，B的函数，也就是sigmod函数。

对于数据较少的分类，我们可以使用生成模型计算p(c1)，p(c2)的均值和公共协方差矩阵σ以及每个分类的样本数据，然后我们可以得到W，B，以及对于任意输入x。

表示数据分类属于c1，否则属于c2。因为是二元分类，所以不需要单独计算p(c2|x)。

但鉴于数据量较大，一般采用判别模型。对于二分类问题，根据最大似然估计，损失函数为

只需要找到W和B

为了计算方便，公式是对数的。

因为sum的概率表达式不统一，所以上面的公式不能写成统一的形式。为了统一格式，这里所有的训练数据都标为0和1，y = 1代表c1，y= 0代表c2，所以上面的公式进一步改写为:

这个形式其实就是两个分布的交叉熵，表示概率分布有多接近。

下面是用梯度下降法求解这个损失函数的最小值，对w和b进行微分，最后得到每次更新的梯度，最后得到w和b，可以带入sigmod函数得到结果。

另外，一般来说，判别模型高于生成模型。

在上述二元分类的情况下，其原理的推导过程与多元分类的二元分类基本相同。

3)多分类

假设我们使用高斯分布，共享协方差矩阵。经过一般的推导，也就是各种变换，就可以得到一个softmax函数。

假设有三个分类:c1，c2，c3。每个C都有自己的分布W，B，w1，w2，w3，代表三个向量，b1，b2，b3代表三个常数，输入X也是向量。

使用softmax进行输出正则化。最大值计算如下:

可以是任意值，但是softmax完成后，输出值必须在0和1之间，它们的和必须是1。多分类任务的输出是目标属于每个类别的概率，所有类别的概率之和为1，其中概率最高的类别就是目标所属的类别。

即第二分类使用sigmod函数输出结果，而多分类使用softmax得到结果。

如下图所示，输入X分别由三个公式生成，再由softmax转换成输出。分别是这三类的概率。由于sum=1，所以Y的分布可以看作是softmax之后的一个概率分布。

训练的时候我们也需要有一个输出。因为是三类，所以对应的输出也是立体的。为了满足交叉熵的条件，输出也必须是概率分布。这里不能用1，2，3作为分类的区分。为了确保所有分类之间的关系相同，我们在这里使用了类似于one-hot编码的方式。

如同二元分类解决方案一样，可以通过使用交叉熵和微分来获得最优的w1、w2、w3。

4. 基于神经网络

当输入参数比较复杂时，比如输入可能是一个100*100的矩阵，此时需要处理数据，或者输入特征不能在数据源上处理，那么就需要在逻辑回归之前连接一个逻辑回归来处理数据源。

多元逻辑回归形成一个神经网络，也就是深度学习，比如(CNN，LTSM)。

对于分类问题，深度学习的最终输出函数是sigmod或softmax函数。

通过最后的语义提取和意图识别，对话会进入后续的对话树模块。根据前面模块提取的数据和用户自己的数据，将数据填充到会话树的相应部分，会话号节点还可以根据条件拉取其他数据，最终这些数据会保存在当前会话中。根据用户的提问，如果满足条件，NLG模块可以生成相应的语音返回。

完成最后一个用户会话的过程

5. 应用与实践

目前，同程艺龙智能酒店的订单咨询问题采用交叉熵和L-GFGS算法进行意向训练。初步打样上线后，准确率在93%左右。

第二，建立对话管理平台。上面，我们提到了智能客服相关的核心技术。此外，我们还希望有一个相对完整的对话管理系统解决方案，并期望它:

更灵活:可以灵活支持上述不同形式、业务、运营商的使用。

更易用:运营团队可以独立训练自己的机器人，定义对话流程。

同程艺龙对话管理平台:

面向同程艺龙和外部租户的公共对话管理支持系统，包括机器人训练、对话流程配置功能(字槽和意图配置、对话条件和执行动作配置)、相关数据报告和机器人自学习优化等。

1. 多租户管理

考虑到不同的内外部需求，平台采用SAAS租户管理模式，对不同的业务进行分离和解耦。租户支持创建多个业务线和系统角色、成员等。

2. 可视化任务场景搭建

我们将对话交互抽象概括为一系列元素模块，如条件判断(入口)、信息收集(填槽)和响应。支持运营商在平台上使用这些元素，快速自由组合配置对话流程。

该服务可以通过系统的公共API访问全局变量，并将这些变量应用于对话流配置。同时也可以利用系统预设的条件参数或者对话中收集的信息来完善任务场景。

例如，在预订机票的场景中，首先需要确定是否存在未支付的冲突订单。业务系统可以在此判断节点访问全局变量【查询订单】【订单状态】并选择。

在决策树中增加信息收集节点(SlotFilling)，配置多轮对话参数，明确语音技巧，完成复杂场景和多对话。系统预置了常用的实体供选择，如时间、城市等。支持特殊实体类型的自扩展，以补充与业务强相关的行业特定实体，如航空公司、水果等。

比如【订机票】这个场景，如果没有冲突订单，就需要确认购票信息:定义【出发时间】【出发地点】【目的地】三个槽位，明确演讲技巧。系统将根据流程完成填槽信息的收集。

3. 响应类型

任务执行响应结果包括文本响应、自定义类响应(提交数据或完成一个任务)、跳转(跳转到其他场景/节点)等形式。

比如在【预订机票】的场景下，通过文字回复确认客户的购买需求后，可以提交订单，发送支付链接，代替客户完成下单流程。

整体来看，智能客服业务和技术部分是解耦的。相关业务信息的设置和操作都是通过智能客服平台，包括不同业务条线的意向和字槽的设置、答案配置、资料审核、测试、标注等。创建一个新的业务线智能客服应用，只需要在平台上新建一个项目，输入设定意图、对应语料库、必要槽位、对应答案即可。

此外，平台上的答案配置也非常灵活。可以是固定答案，可以是知识图谱的图式，可以是外部接口，也可以是不同词槽的回复集，等等。

三、写在最后

以上是同程艺龙智能客服产品技术推广过程中的一点点经验分享。未来智能客服将向多模态、多语言方向发展，支持语音、图像等多种模式的分析。智能客服还将提供智能外呼、主动服务、人机协作等多维度服务。未来将实现从售前到售后、从服务到产品的所有服务、所有服务流程的智能化，构建服务业全智能模式。

本文由@Candy原创发布。每个人都是产品经理。未经许可，禁止复制。

来自Unsplash的图像，基于CC0协议。