1. 背景介绍
在线客服作为商业银行互联网金融服务的第一线，是客户出现问题最先求助的对象，其服务水平可直接影响到银行的品牌形象。通过客服系统，支持企业和客户更好的交流与互动，使客户获得高效的服务体验，是商业银行提高核心竞争力的重要一环。当下客户服务要求不断提高，客户更期望等待时间短，问题解决快，服务质量好。因此，推动快速解决方案和为客户提供一流的服务是商业银行更应该关注的重点。
在线客服的日常工作不仅包括客户业务受理，也包含故障反馈处理，比如手机银行无法登陆、客服电话无法进线等。针对此类问题，常规处理流程如下图 1，该流程可能会出现两个问题：
(1) 及时性问题：从客服接受顾客故障反馈，到该故障问题反馈至相关项目组，整个处理流程较长，及时性不足，导致客户服务体验感不好，且对实际业务影响较大;
(2) 触发机制问题：由顾客自身的设备或网络问题导致的个别故障，并未排查出真实原因，启动故障处理机制，导致浪费人力与计算资源。
图 1 在线客服故障处理流程
2. 解决方案
我们首先利用自然语言处理技术来构建故障检测模型，识别出顾客所反馈的内容是否包含故障信息、以及故障的类别。利用该模型，对在线客服人工聊天记录进行实时检测，及时将检测结果反馈至呼叫中心，再根据异常触发阈值来判断是否触发高频舆情预警，如半小时出现5例则触发告警，反馈至相关项目组。
图 2 在线客服故障-解决方案
该方案整体逻辑框架如图2所示，可解决上文所提到的及时性问题和触发机制问题，但是有两个技术难点：
(1) 算法模型：在没有大量标注数据的情况下，如何开发故障检测模型？
(2) 工程实现：故障检测模型服务部署成功后，如何实现实时检测功能？
下文将着重阐述针对这两个难点的解决方案。
3. 少样本故障检测（Few-shot Fault Detection）
3.1 算法逻辑
少样本自然语言处理指的是NLP任务只附带少量的标记样本，这是当下人工智能领域必须学会应对的现实挑战。目前，我们只有业务所提供的带有故障标签的少量样例数据，如表格1所示。因此，故障检测是一个少样本的自然语言处理任务。
表格 1客服电话故障示例
对客服聊天记录表历史数据进行调研后发现，顾客说话的文本长度较短，约90%数据都在5~40个字之间；一组客服聊天记录是由多条数据组成，实时检测要求对每条数据进行检测，但是单条数据存在高噪声，上下文依赖性较强，指代情况明显等特点；在海量的历史数据中，绝大部分是低价值的短文本数据，真实的故障数据占比极低。
巧妇难为无米之炊，根据当前的数据情况，直接训练分类模型不太现实。
我们基于Sim-BERT所提供的相似句匹配功能为检测样本打分，分数大于一定阈值则判定为故障。相似句匹配的结果依赖于足量的故障样本，一方面我们可以使用AC自动机并结合人工筛选，尽可能增加样本的数据量；另一方面也可以基于Sim-BERT所提供的相似句生成功能进行数据增强，尽可能增加样本的多样性。
3.2 多模式匹配- AC自动机
AC自动机（Aho-Corasick automaton）是一种著名的多模式匹配算法，即给定多个模式串和一个待匹配主串，判断模式串是否出现在待匹配主串中以及出现的位置和次数。该算法的实现，首先基于模式串构造Trie字典树，作为AC自动机的搜索数据结构；然后构造fail失配指针，使当前字符失配时跳转到具有最长公共前后缀的字符继续匹配；最后扫描主串进行模式匹配。
如表格2，以客服电话故障为例，若服务关键词和产品关键字同时被匹配到，则检测出客服电话类故障类别。对于其他类别的故障，在没有标注数据的情况下，我们也可以根据少量的故障样例，基于AC自动机对其进行初步的故障检测。
表格 2 客服电话故障检测
该方法上手快、开发周期短而且后期迭代维护成本低，但是直接用来做故障检测会出现误检的情况， 例如 “如果电话打不通，我该找谁咨询”，服务关键词“电话”与故障关键词“打不通”都匹配到了，但并非真正的故障。因此，初期利用该方法从客服聊天记录历史表中筛选故障候选样例后，还需结合人工筛选出准确的故障样例补充故障库。
3.3 相似文本检索- SimBERT
SimBERT是基于微软所提出的UniLM思想，设计融检索与生成于一体的任务，并进一步微调后得到的模型。UniLM的核心是特殊的Attention MASK机制，利用双向前缀Attention来赋予模型Seq2Seq文本生成能力，利用Masked Language Model预训练任务增强文本的向量表达。
如图 3右边是构建Seq2Seq任务，通过输入文本去预测对应相似文本；左边是构建语义相似度任务，会根据文本对应的CLS向量来计算相似度。
图 3 SimBERT训练方式
相似文本生成
相似句生成就是数据增强（Data Augmentation，简称DA），是指根据现有数据，合成新数据的一类方法。有了更多数据后可以提升效果、增强模型泛化能力、提高鲁棒性等。根据生成样本的多样性程度，将DA方法分为了以下三种：改写（Paraphrasing）：对句子中的词、短语、句子结构做一些更改，保留原始的语义；增加噪音（Noising）：在保证label不变的同时，增加一些离散或连续的噪声，对语义的影响不大；采样（Sampling）：旨在根据目前的数据分布选取新的样本，会生成更多样的数据。
基于Sim-BERT相似句生成功能，针对当前故障库进行数据增强，其结果如表格3所示。
表格 3 相似句生成样例
相似文本检索
相似句检索，是指在样本库中检索出与检测样本语义最接近的样本以及匹配得分。SimBERT所提供的相似句检索功能，本质是获取文本的语义向量，结合Faiss向量检索框架，并利用相似度计算获取文本库中与检测样本语义最接近的文本以及相似度得分。常用的相似度计算方法如余弦相似度，测量两个向量的夹角的余弦值来度量它们之间的相似性，获取两者在0至1范围内的相似度得分，分数越接近于1相似度越高。若匹配得分大于0.9，则判定为故障。
如表格4所示，我们基于数据扩充后的故障库进行语义匹配，对于3、4检测样例，AC自动机误检的情况，通过语义匹配可以矫正其检测结果。
表格 4 模型融合检测示例
4. AI实时链路
图4 故障检测AI实时链路
在线客服聊天记录实时故障检测方案的实现，首先要保证的是从源端数据库到底层模型服务链路的畅通（下文称AI实时链路），而目前行内还没有针对AI实时服务的借鉴案例，因此打通该链路具有一定的挑战性、同时也是十分有价值的。
如图 4所示，故障检测AI实时链路总体上包括前台、中控台、后台三个平台。前台指的就是在线客服系统，实时生成聊天记录表并同步至源端数据库；后台指的是在底层机器学习平台所部署的模型服务，并且该服务需注册在数据服务平台，形成可供调用的统一域名形式的API地址；实现实时调用功能的中控台，核心部件主要是自研的Kafka流数据平台和智能决策平台。
- Kafka流数据平台
Kafka是一个分布式、多分区、多副本、基于zookeeper协调的的发布订阅式的消息系统，它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性而被广泛使用，不但具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能，还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
Kafka的消费机制主要依赖以下三个组件：Topic即主题，通过对消息指定主题可以将消息分类；Producer即生产者，向Kafka集群指定主题下发送消息；Consumer即消费者，只关注自己需要的Topic中的消息，与集群建立长连接的方式，不断地从集群中拉取消息，然后可以对这些消息进行处理。
- 智能决策平台
企业级智能决策平台（以下简称“智策平台”）是本行自主研发的企业级决策服务开发和管理平台。它所提供的模型引擎，针对PMML等常规机器学习模型，支持用户自定义上传，具备本地化服务能力；针对基于NLP技术训练的深度学习模型，支持直接调用机器学习平台和数据服务平台发布后的模型服务。
AI实时链路，利用Kafka的消费机制，将其作为实时数据的中转站，实现了客服聊天记录和故障检测结果的实时的、有序的生产、存储和消费；利用智策平台模型引擎，向上对接Kafka平台，向下对接数据服务平台，实现实时调用功能。
如图4所示，实时调用的4个核心子链路功能描述如下：
1) 利用百川AR实时同步功能，将客服聊天记录实时同步至Kafka平台聊天记录主题；
2) 智策平台作为消费者，订阅Kafka平台聊天记录主题，拉取客服聊天数据并将其作为模型输入，请求数据服务平台发布的故障检测模型服务，获取模型检测结果；
3) 智策平台作为生产者，将检测结果发送Kafka平台检测结果主题；
4) 呼叫中心可以订阅Kafka平台检测结果主题，实时拉取数据，最终可实现根据阈值判定高频舆情预警功能。
5. 结论与展望
本文针对当前故障反馈处理机制所存在的问题，提出了基于NLP实时服务的解决方案，可以及时、准确的响应顾客反馈的故障问题，为顾客提供一流的服务。其中，比较有借鉴意义的是，打通了AI实时链路，其他AI模型也可根据此链路来满足业务的实时需求。
目前，故障检测实时服务已经成功上线。后续优化主要在算法层面，一方面，结合业务反馈逐步扩展故障检测的类型；另一方面，当某类故障样例达到一定量时候，再次尝试不同的算法，进一步优化故障检测模型。