五八同城智能客服系统“帮帮”技术揭秘



转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com

AIQ 机器学习大数据 知乎专栏 点击关注

本文根据 58 同城 AI Lab 负责人詹坤林在 DataFunTalk 人工智能技术沙龙所分享的《五八同城智能客服系统“帮帮”技术揭秘》编辑整理而成,在未改变原意的基础上稍做整理。

首先简单介绍一下 58 同城,58 同城是一个生活服务平台,平台连接着 B 端商户和 C 端用户,B 端商户在平台发布帖子信息,平台将这些帖子信息分发给 C 端用户供其浏览。在 58 同城 APP 或网站上,用户可以通过搜索和推荐的方式获取到帖子信息,例如用户可以通过搜索框搜索信息、进入列表页筛选信息、在猜你喜欢和相关推荐等推荐位浏览信息。58 同城提供租房、二手房、找工作、二手车、黄页等信息,这些业务分布于房产、招聘、二手车、黄页等不同业务部门,不同业务部门都有各自独立的客服团队,我们的目标是设计一套通用的智能客服平台来解决所有客服问题,以提高客服效率。

今天的分享将从以下几个方面展开:首先介绍智能客服的背景,然后介绍总体技术架构、算法和工程架构,最后做一下总结。主要想通过这次分享使大家了解到智能客服系统中的技术全貌,希望对大家有些启发。

传统客服工作模式包括客服网站和电话客服两种:

(1)公司提供一个客服网站给用户,用户通过网站提交问题反馈,这些反馈信息会通过一个系统展示给客服人员,客服人员每天逐个解决这些问题,解决后通过站内信或者短信回复用户。这种模式下,用户在客服网站上的操作往往较繁琐,并且问题解决流程周期长,可能会耗时数小时甚至数天,用户体验差。

(2)公司提供一个客服电话给用户,用户通过电话咨询客服。这种模式尽管直接,但是可能存在问题描述不清、沟通成本高的问题,例如客服在解决某个问题时往往需要用户提供额外信息,一通电话会持续较长时间。一般一个客服每天能完成 60-80 个电话的接线,服务效率较低,而且客服人力成本高。

大部分客服问题其实是高频重复问题,这些问题往往都有标准的答案,这可以利用机器去解决,可以构建一套智能问答系统去自动回答用户的提问,当用户对答案不满意时,他可以再寻求人工客服的帮助。这种机器自动问答和人工客服辅助的模式下,大部分客服问题通过机器解决了,只有少部分机器解决不了的复杂问题才会由人工客服来解决,这不仅提升了用户体验也提高了客服人员的人效。

58 同城旧有客服体系就是通过客服网站和客服电话来提供客服服务,我们需要重塑这种模式,构建一套新的客服体系。在新的客服体系下,用户所有的客服咨询首先都会经过智能客服系统“帮帮”,由“帮帮”来自动回答用户的问题,若用户对答案不满意,他可以转接人工客服。人工客服包括旧有的电话客服和新设计的 IM(即时通讯)在线客服,IM 在线客服是指通过 IM 聊天的方式提供客服服务,用户可以和客服人员通过聊天窗口直接一对一进行沟通,智能客服和 IM 在线客服会无缝整合在同一个聊天窗口中。转接人工客服时我们会首先转接到 IM 在线客服上,若用户仍不满意才会通过电话的方式解决问题。新的客服体系下,用户可以获取到业务咨询、投诉建议、产品反馈、闲聊以及工单处理等客服服务。

这种新的客服模式相比旧有模式的优点有:

(1)用户体验好。传统客服网站的方式用户获取答案周期长,这是因为客服人员需要手动解答客服网站上收集的每个用户问题,由于每日问题量大而且客服人员数量有限,大部分用户的问题不能即时得到解答。新的模式下用户可以通过 IM 聊天窗口咨询问题并即时获取答案,简单高效。

(2)客服人效高。“帮帮”能够自动回答大部分问题,人工客服只需要利用 IM 在线客服聊天工具去解答少部分复杂问题,机器和人工处理问题的比例大约是 8:2。每个 IM 客服人员一天大约能处理 120-150 个用户的咨询,这远比电话客服每天处理 60-80 个用户的咨询要高,因此我们会尽量让用户咨询先流转至 IM 在线客服,只有最复杂的问题才会流转至电话客服。通过这种智能客服到 IM 在线客服再到电话客服的方式,我们可以利用有限的客服人员处理更多的用户咨询。

“帮帮”智能客服系统是一套基于深度学习和自然语言理解技术实现的自动问答对话机器人,产品界面如图所示,用户通过聊天窗口的形式和“帮帮”进行对话。对话机器人一般分为业务咨询类、任务类和闲聊类三种,“帮帮”也支持这三种功能:最主要的是提供业务咨询功能,帮助用户解决业务类问题;其次支持任务类型的回答,用户可以实现查询帖子被删除原因、注销账号等任务;此外,为丰富“帮帮”的功能,也支持闲聊功能,用户可以在聊天窗口与机器人寒暄闲聊。

“帮帮”整体技术架构如图所示,包括基础服务层、应用服务层、编辑运营层、接入层以及在线客服系统。基础服务层提供对话系统的基础技术能力,系统需要对用户输入的一段语句进行理解,这里需要自然语言理解模块,对语句进行分词、词性标注、实体识别、关键词抽取和句法分析等;同时需要识别用户的意图,包括通用意图和业务意图,通用意图是指用户是来做业务咨询还是闲聊,业务意图是指若用户是做业务咨询,具体咨询什么业务,这里会使用文本分类的技术去识别用户意图。基础服务之上是应用服务层,这一层具体实现了 KB-Bot 基于问答知识库的机器人、Task-Bot 任务对话型机器和 Chat-Bot 闲聊类型机器人,这是“帮帮”系统的三种核心能力。编辑运营层是指有一个编辑团队支撑着“帮帮”的算法策略迭代,主要完成数据标注、问答运营、数据分析和效果评估的工作,这些工作输出会作用到基础服务层和应用服务层。基于应用服务层,对外提供通用的接口服务以便于业务方接入,我们支持 Android、iOS 和 web 端的接入。此外,机器不是万能的,用户有很多复杂的问题仍需要人工解决,这里有一套在线客服系统提供了人工在线客服的能力,应用服务层会和这套在线客服系统做无缝对接。

“帮帮”系统的核心是提供 KB-Bot、Task-Bot 和 Chat-Bot 三种能力,下面分别介绍下这里使用到的技术。KB-Bot 是指基于问答知识库的对话机器人,它主要实现了“帮帮”最重要的能力——提供业务咨询类服务。58 的用户使用帮帮主要是来进行业务咨询,例如询问账号为何被锁、帖子为何被删、如何购买帖子置顶服务等等。业务咨询类的回答需要基于问答知识库来实现,这里的问答知识库是一个包含众多问答对的数据集。我们将问题划分为标准问题和扩展问题,例如“为什么删除我的帖子”这个是一个标准问题,语句表达很标准,它会有一个标准答案,其近似的问法我们称之为扩展问题,例如“为什么删我贴”、“告诉我为啥删帖”等,这些都表达的是一个意思,这些问题同样对应的是相同的标准答案。有了问答知识库,用户来询问时就是一个问题匹配的过程了,只需要将用户输入的问题和知识库中的问题做匹配,得到意思最相近的那条问题,然后将对应的答案返回给用户,这就完成了一次问答操作。问答知识库的构建非常关键,这里会首先对客服团队历史积累的问题数据进行抽象,形成标准问题,然后结合算法和标注对标准问题做扩展,形成初始问答知识库,在系统上线后,对新产生的数据又会进行挖掘,不断扩充知识库。

基于知识库的问答可以使用检索或者分类模型来实现。检索式回答的流程是:首先对用户的输入问题做处理,如分词、抽取关键词、同义词扩展、计算句子向量等;然后基于处理结果在知识库中做检索匹配,例如利用 BM25、TF-IDF 或者向量相似度等匹配出一个问题集合,这类似推荐系统中的召回过程;由于我们是一个问答系统,最终是直接返回给用户一个答案,因此需要从问题集合中挑出最相似的那个问题,这里会对问题集合做重排序,例如利用规则、机器学习或者深度学习模型做排序,每个问题会被打上一个分值,最终挑选出 top1,将这个问题对应的答案返回给用户,这就完成了一次对话流程。在实际应用中,我们还会设置阈值来保证回答的准确性,若最终每个问题的得分低于阈值,会将头部的几个问题以列表的形式返回给用户,最终用户可以选择他想问的问题,进而得到具体的答案。

这里还可以使用分类模型来实现问答,一个标准问题有多种扩展问法,每个标准问题可以看做是一个分类,将用户的输入映射到标准问题上即可完成回答,因此可以将问答看做是一个大规模短文本分类的问题。我们采用了多特征、多模型、多分类结果融合的方式来完成短文本分类,在特征层尝试使用了单字、词、词性、词语属性等多种特征,在模型层应用了 FastText、TextCNN 和 Bi-LSTM 等模型,各模型的结果输出最终会做融合得到最终分类结果。

Task-Bot 任务型机器人是在特定条件下提供服务,为了满足带有明确目的的用户,例如查天气、查物流、订机票等任务型场景。用户的需求一般较复杂,通常需要机器人和用户做多轮互动以帮助用户明确目的。我们实现了一个标准的多轮会话系统,首先自然语言理解模块会识别出当前输入问题的意图和槽位,然后输入到对话管理器去决定下一步的回答动作,最终再通过自然语言生成模块生成答案返回给用户。

这是一个具体的应用实例,用户输入“为啥删我贴”,经过自然语言理解处理后,意图识别模块会将其识别为任务类型的服务,用户是想询问删除帖子的原因,通常情况下问答系统会反问用户,要求用户提供帖子 ID 才能查询,这里我们通过另一种设计来完成:首先调用发布中心接口拉取用户已发布的贴子列表展示给用户,让用户去自主选择相应的帖子,用户点击具体帖子之后,帖子 ID 会传递给问答系统,问答系统会再调用相关接口查询到帖子删除原因返回给用户。这一整套流程是用户的自助查询过程,相比以往用户需要查询自己的帖子 ID 给客服人员,客服人员登录相关系统并输入贴子 ID 查询结果要高效很多。

闲聊服务是基于一个闲聊语料库,采用模板匹配、检索式回答以及生成式对话等多种技术来实现的。模板匹配使用了 AIML 和正则表达式匹配;检索式回答类似 KB-Bot 中的方式首先检索然后利用模型排序;当模板匹配和检索式回答都不能给出闲聊回答时,我们会采用 SeqSeq 生成式对话,我们使用了一个标准的 Seq2Seq 模型,问题会首先输入到一个双向 LSTM 编码器,然后加入 Attention 机制,最终使用一个单层 LSTM 做解码,从而得到结果输出。生成式对话往往会生成一些让人难以理解的答案,这也是业界难以解决的问题。

当“帮帮”给出的答案用户不满意时,用户会寻求人工服务。“帮帮”支持人工在线客服的无缝转接,用户只需在聊天窗口一键点击按钮便能连接到 IM 人工在线客服,实现一对一聊天。在转接人工客服成功后,人工客服会在客服工作台中通过一个类似微信的聊天窗口和用户沟通。虽然用户在前端操作简单,其实后面是有一套功能复杂的在线客服系统在支撑。

在线客服系统是用户和客服人员沟通的桥梁,在 58 业务场景下,它支持多个业务部门的不同客服团队注册使用,不同客服团队可以管理自己的客服人员。当用户在智能客服窗口点击转接人工客服按钮时,智能客服会识别出用户转向的目标客服团队,在线客服会分配一名客服人员和用户进行沟通。在线客服系统支持用户排队功能,当同时转接人工客服的用户较多而客服人员人力有限时,用户便会进入等待队列。智能客服识别用户业务意图往往存在一定错误率,有时候客服人员在和用户沟通一段时间后会发现用户的业务问题需要其他客服团队来解决,此时客服人员会将会话转交给其他业务团队,因此在线客服系统还需支持会话流转的功能。此外,沟通过程中的数据是非常重要的,例如可以根据人工的沟通记录去优化自动问答的答案,因此数据监控也是必须必备的功能。

智能客服系统需要有一个完备的评价体系去评价它的好坏,在我们的评价体系中有基于人工标注的评价和基于用户反馈的评价两种方式:

(1)基于人工标注的评价。“帮帮”能够自动回答业务咨询、任务和闲聊类型的回答,业务咨询类是基于问答知识库来回答的,系统的回答能力受限于知识库的丰富程度,因此并非能回答用户的所有问题,系统最佳的状态是将能回答的全部回答准确,不能回答的全部拒识,即拒绝回答。因此这里的评价指标包括有结果率、拒识率、召回率和准确率等,我们的目标是让系统的有结果率无限接近数据的真实有结果率,召回率和准确率尽量高。这里我们是通过标注标准评测集来计算系统的各项指标,我们会从每日的全量数据集中抽样出一个小数据集,保证小数据集的数据分布尽量符合全量数据集,然后由标注团队对数据集做标注,标注出每个问题的实际答案,一般标注完成后还有质检的环节,以保证标注结果尽量准确,这样便生成了每日数据的标准评测集。基于该标准评测集我们会去评价系统的好坏,并且每次做新模型迭代时都会使用标准评测集去评价新模型,只有新模型的效果好了才允许上线。

(2)基于用户反馈的评价。人工评价能够评价智能客服系统的准确率,但是答案是否合理,能否为用户解决问题,需要用户去反馈评价,整个智能客服系统的最终目标是帮助用户解决问题。我们会在产品上设计智能客服和在线客服的评价功能,例如会让用户评价智能客服的每个答案或者某次会话,在和人工客服聊天完毕会发送评价卡片给用户去评价满意度。最终我们会统计参评比例、满意度等指标,这些指标能够真正反应智能客服系统的好坏。实际中往往用户参评比例低,我们会使用各种方法去刺激用户评价。

上述内容介绍了“帮帮”智能客服系统中的技术和评价体系,我们在做算法策略迭代时会不断优化评价指标。首先在离线模型迭代时,会基于标准评测集计算离线指标,只有指标提高了才允许模型上线。上线时会做 ABTest 上线,首先将新模型小流量上线,然后看数据效果,若效果好会切换更多的流量进行上线。

“帮帮”后台系统总体架构如图所示,“帮帮”前端页面是一个 IM 聊天窗口,用户在聊天窗口中可以和“帮帮”即时对话。这里的具体实现分为两种:第一种是通过微聊(58 同城 TEG 自研的 IM 即时聊天工具)来实现,用户在前端的提问会被当做一条消息发送给微聊,我们有一个 IM 消息中转模块从微聊接收消息,并将消息转发给问答引擎,问答引擎是一个 RPC 服务,使用 SCF 框架(五八同城 TEG 自研的服务通信框架)实现,问答引擎给出答案后返回给 IM 消息中转模块,中转模块将答案组装成消息发送给微聊,最终微聊返回消息给用户,这种方式的实现需要使用我们的微聊通道。还有一些业务方不希望通过微聊来获取“帮帮”自动问答功能,只希望我们提供一个接口,业务方输入问题,接口能够返回答案即可,针对这种方式我们在问答引擎之上封装了一层 http 服务,业务方只需要调用该服务即可。

下面介绍下问答引擎的后台架构,问答引擎分为数据层、逻辑层和接入层。数据层包括问答知识库、标注和运营数据以及构建的问答索引。逻辑层里各个功能模块都基于 SCF 框架封装成微服务,包括 NLU 服务、模板匹配服务、检索服务、排序服务、预测服务、闲聊服务、主体服务,主体服务负责对外提供通用接口,接收问答请求,调用各个子服务完成问答逻辑以得到答案,并将答案返回给接入层。这里我们会做 ABTest 实验,主体服务会请求 ABTest 平台“日晷”(自研的包括请求分流和数据监控功能的 ABTest 平台)获取具体分流实验信息。此外,我们的所有算法迭代都是通过自研的人工智能平台来实现,标注和运营数据由 Web 标注管理系统来提供。

我们还会通过运营来提高问答效果,针对问答系统的高频 badcase 回答,我们会进行人工修正,并即时同步到线上系统,以保证回答准确。“帮帮”每天产生的问答数据,我们会抽样一部分去做标准评测集的标注,从标注结果中我们可以看到哪些问题回答错误了,我们会将这些问题标上正确答案并即时上线。这是因为线上问答模型的更新周期较长,一般是数天或者一周,通过人工运营可以快速将 badcase 给去掉。标准评测集数据较少,只会包含少量的 badcase,我们还会挖掘每日的全量数据,发现高频相似问题,并交由标注同事标注,若回答错误,也会进行标注运营上线。通过这种结合人工运营的方式,我们可以提高“帮帮”的回答准确率。

我们还会通过产品设计来提高问答准确率,“帮帮”最主要的功能是解决业务咨询,这是基于我们构建的问答知识库做回答的。因此,可以设计一个输入提示的功能,在用户输入问题时去问答知识库中匹配相关的问题,若匹配到,用户直接选择相关问题即可,此时我们的回答逻辑就是在知识库硬匹配,而不用走算法模型匹配,可以大大提高回答准确性。在实际应用中,我们发现有很大一部分问题会从输入匹配中匹配到,这种方式最终给回答准确率带来了 8% 的提升,效果非常可观。

智能客服系统有一个主要目标是提高人效,我们会将很多较复杂的咨询服务做到聊天窗口中,让用户去自助完成,而不是像原来那样用户和人工客服沟通,人工客服去操作内部各个系统以得到答案返回给用户。这样可以减轻我们客服人员的压力,并能提升用户体验。例如用户需要彻底删除自己发布的帖子,旧模式下必须让客服人员去操作,新模式下,只要用户在“帮帮”界面上问到了该问题,我们便会向用户返回他的发布列表,他可以选择某条贴子,直接点击彻底删除按钮即可完成删除。

“帮帮”是一个通用的智能客服平台,需要对接 58 集团内多个业务方,为了提高接入效率,我们设计了一个通用的 Web 接入平台。业务方注册登录接入平台后,只需要简单配置机器人和导入知识库即可获得智能客服能力,例如配置机器人欢迎语、热门问题、配色等,平台会自动生成一个前端页面的链接,业务方可以嵌入到相关入口上。智能客服上线后,我们会将线上数据反馈给接入方,接入方可以再 Web 平台上查看统计数据和明细数据。另外要强调的一点是,我们将知识库的管理开放给接入方来管理,接入方可以导入和更新自己的问答知识库,我们也会对问答数据做分类、聚类、主题抽取等操作,将相关中间结果提供给业务方,业务方基于此来更新知识库。

“帮帮”已接入了五八集团内五八、赶集和安居客三大平台的三十多个业务场景,每日可以解决数万用户的客服咨询,此外,“帮帮”也被应用于公司内部的 HR、行政和运维系统之中,以提高内部工作人员的办公效率。经过我们持续开展算法策略迭代,目前“帮帮”问答系统召回率达到了 90%,准确率达到了 85%。

作者介绍:****

詹坤林,58 集团 AI Lab 负责人,算法高级架构师,负责推动 AI 技术在 58 生活服务行业的落地,为集团打造全面 AI 能力。曾任腾讯高级工程师,负责腾讯微博 / 腾讯新闻推荐算法研发。

团队介绍:

58 集团 AI Lab 人工智能实验室隶属于 58 集团 TEG 架构平台线,旨在推动 AI 技术在 58 生活服务行业的落地,驱动各产品业务在人效、用户增长、用户体验等方面的提升。目前主要产品包括人工智能平台、智能客服对话机器人、智能外呼电话机器人、智能写稿、推荐系统和推送系统等。

——END——


更多高质资源 尽在AIQ 机器学习大数据 知乎专栏 点击关注

转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com