智能客服系统在机票售后的应用实践体现在哪些方面
无论何时何地，客户的需求不能得到切实有效的满足往往是导致企业客户流失的最关键因素，所以很多企业都会成立客服团队来解答客户（用户）的各类问题以提升满意度。传统的客服服务无论是对用户、客服还是企业来说都有很多弊端。因此智能客服系统也就应运而生，它成为人工智能（AI）重要落地应用之一。
智能客服系统是建立在大规模知识处理、自然语言理解、知识管理、自动问答、推理等技术之上，通过大幅度降低人力成本以及提供人性化服务来优化用户体验。智能客服不仅为企业提供了细粒度知识管理技术，还为企业与海量用户之间的沟通建立了一种基于自然语言的快捷有效的技术手段，同时还能够为企业提供精细化管理所需的统计分析信息。
去哪儿机票事业部有一个庞大且专业的客服团队，业务涉及售前、售后。服务形式有文字客服（Chat）和电话客服。因为机票的业务场景非常复杂，虽然我们的客服工作已经很高效，但也存在着一些问题，例如：航变时业务量暴增导致用户等待时间过长等问题。
本着“提升服务质量，节约服务成本”的目的，推进“智能客服”这一项目，使用AI赋能客服在机票售后业务中做了一些创新和尝试。
为什么说机票客服需要“智能”呢，主要从以下几个方面体现出来：
日志中问题分布分析
我们通过一组数据说话，根据机票积累下来的客服聊天日志，我们发现用户的基本问题和业务问题的占比大约为 3:7，工单的平均对话轮数约为 13 轮，不同业务长短分布有所不同，简单咨询类业务较短，类似行程单等复杂业务会超过 20 轮，在极端情况下部分业务处理比较棘手，长度甚至超过 100 轮。
那么客服在解决业务问题的对话中都在做什么呢：20% 是业务相关的核心问题，剩余 80% 都是闲聊，此“闲聊”不是彼“闲聊”，除了日常寒暄之外还包含对业务涉及信息的问询以及对用户情绪的安抚与调整。可以说客服都是熟读各类百科全书的聊天超人。
客服日常工作模式
人工智能最主要的是让“人工”变得“智能”，所以了解业务人员平时的工作模式是很关键的。根据调研，客服平时的工作模式是根据问题类型的不同而采取不同的解决方案，见图 4。
机票业务极其复杂，用户需求涉及出、退、改等十余个业务场景，每个场景下又能衍生出几十甚至上百个业务意图。以出票场景（见图 5）为例，用户诉求既会涉及到购票类型、支付手段、出票进度等咨询类问题，也会有诸如修改信息、申请购票等操作类型问题。得到这些诉求的解决方案需要根据订单状态、航司政策、用户主观原因等多种因素做出判断，这要求客服有极强的业务素养与信息获取能力。
业务问题之外，客服同样会面对一些琐碎的日常问题。例如托运规则、天气咨询、乘机注意事项等。对于高频的日常问题，每个客服都会手动积累和维护一个文档，日积月累再加上互相交流，渐渐的就成了一个小型文本知识库，这在一定程度上提升了客服的工作效率。
“智能客服”的应用场景
我们在人工客服场景与机器自助场景都进行了智能化的尝试。在人工客服中通过“客服助手”辅助客服与用户沟通。客服助手中的推荐可以分为两类，一类是业务问题，遇到退票、出票、改签等的业务问题，比如图 6 中的申请退票。我们会通过意图识别确认用户诉求，然后基于业务知识库梳理业务逻辑，根据用户当时的订单状态生成相对应的退票规则，生成合理的业务答案，推送给客服。另一类是非业务问题，我们会通过搜索匹配的方式在基本问答知识库中进行检索，搜寻合适的答案反馈给客服。如果客服觉得可以采纳，轻轻一点，话术就推送给用户了。项目推进到现在我们的客服助手在每天发生的会话中有 90% 以上的会话会出现答案推送，消息维度的推荐覆盖率为 60% 以上。意图识别准确率 90% 以上，答案准确率也达到了 70%。
“智能客服”的技术实现
智能客服中包含一套完整的对话逻辑控制系统。图 7 中是智能客服控制逻辑的核心结构，首先通过 query 理解模块对用户输入进行预处理和意图识别，预处理包含 query 清洗、命名实体识别、query 改写、向量化等操作。当确定用户 query 为闲聊（基本问答）时，通过 QA 知识库检索的形式搜索合适的答案。当确定用户 query 包含业务意图时，则进入对话管理模块。模块中通过对话上文信息与当前槽位填充情况确定新的对话状态，最后通过业务知识库生成合适的备选答案。
下面分别介绍解决基本问答与业务问答的思路与方案。
基本问答
智能客服能够回答用户基本问题的前提是它具备相关的知识，这些知识是客服在经验和交流中积累起来的，我们就通过历史日志来挖掘这些知识。知识挖掘涉及的技术较多，我们通过训练语言模型进行问题质量判别、使用 textRank 提取语料中的领域词，通过句向量相似性，答案相似性以及检索策略扩大有效问答对的召回。考虑到篇幅长度，具体细节考虑在之后的挖掘专题文章中再详谈。使用挖掘得到的基本问答 QA 对进行检索推荐服务，见图 8。
为了提升推荐服务效果，我们在 Query 理解模块做了很多前期工作，通过收集与挖掘我们积累了多个基础词库，同义词库协助 query 改写，领域词与英文专属词词库能够提升切词的准确率，通过海量日志数据学习词权重，引入了正排索引的同时，使用 word2vec 的向量相似度进一步修正计算结果。现在我们尝试新的预训练模型计算 query 相似度，通过 ES+bert 的形式升级现有的问答检索框架。
意图识别
在项目初期，考虑到模型迭代效率与样本规模，智能客服一直采用 fasttext 作为主要的意图识别模型。但随着项目进展，类别种类膨胀，样本语料数量低且质量差的问题逐渐凸显出来。Google 推出的 bert 预训练模型很好的帮忙解决了我们的痛点。它支持在少样本情况下微调模型，使模型能够支持识别 200+ 的意图，在语料质量有保证的情况下，准确率会非常理想。
Bert 也有一些明显的缺点，模型庞大，微调需要设备资源，我们通过一些简单的策略在一定程度上降低了模型迭代的成本。在 Bert 模型输出预测结果的同时我们使用模型的副产物(词向量)作为 SVM 模型的输入，来给当前输出意图做进一步细分。这样就可以在仅调整 SVM 的情况下根据实际 badcase 快速的迭代模型。
模型迭代至今，线上推荐服务在支持近 200 个意图的情况下的准确率稳定在 91%。
技术实现方案
在技术实现上智能客服问答推荐系统划分成 4 个模块：
基础服务模块
负责 query 分析、实体识别、意图识别以及 NLP 相关基础服务的实现。
对话控制模块
主要负责对话状态管理以及槽位填充，对其他模块的服务进行封装，对接业务线不同的服务和需求。
对话生成模块
基于现有的业务知识库，通过现有的订单状态与用户意图生成合理的业务答案。
数据管理模块
由于客服助手需要根据用户诉求与客服的输入同时更新对话状态，所以实时更新答案推荐的采纳情况，辅助更新对话策略。
未来规划
现在智能客服在多个业务场景得到应用，从人人对话到人机对话，从售前到售后。接下来我们会对系统做进一步的完善：继续优化现有的意图识别体系，打造机票业务知识图谱。同时继续尝试新的深度学习技术，进一步提高现有意图的准召。提升实体识别、时间提取等技术的准确率，完善多轮对话中的槽位填充逻辑。不仅在 NLU 方向提供支持，尝试使用历史日志语料结合场景下订单状态，使用模型在 NLG 方面提供支持。进一步与相关业务解藕，模块化各个功能，提升整个体系的独立性，形成一个专注于 NLP 的技术服务平台。