写点什么

58 同城对话机器人应用实践:本地生活服务场景中的商家智能助手

  • 2020-07-23
  • 本文字数:5174 字

    阅读完需:约 17 分钟

58同城对话机器人应用实践:本地生活服务场景中的商家智能助手

对话机器人是过去几年国内外互联网巨头最青睐的方向之一,很多公司都对此做出了明确布局。深度学习在机器视觉获得巨大成功后,在 NLP 和对话机器人方向也被研究界寄予厚望。


伴随着工业界和研究界的关注,对话机器人稳步向前发展,越来越多的企业在把对话机器人应用到产品中。那么,目前业界如何构建这些对话机器人?主要使用什么技术?深度学习和 NLP 在这过程中起到了什么作用?如何让对话机器人成为人工智能,而不是“人工智障”?


本期InfoQ公开课的直播间,我们邀请到了 58 同城 AI Lab 智能问答部负责人、算法高级架构师韩伟与我们分享上述话题。本次分享以《58 同城对话机器人应用实践——本地生活服务场景中的商家智能助手》为主题,重点介绍在本地服务(黄页)业务场景下,如何利用对话机器人为商家提高效率和收益。

一、业务背景

在正式内容开始之前,首先做一下简单的自我介绍。我叫韩伟,2011 年硕士研究生毕业于中国科学院大学,毕业后先后在阿里巴巴和猎户星空从事 NLP 相关的研发工作,19 年加入 58 同城 AI Lab,目前负责智能问答部相关工作,主要的产品有 58 同城智能客服系统(帮帮)和 58 智能客服商家版(微聊管家)。


今天的分享将从以下几个方面展开:58 的业务背景、58 对话机器人的总体技术架构、核心能力、总结和展望。我们想通过这次分享使大家了解到 58 对话机器人系统中的技术全貌,希望对大家有所启发。



首先介绍 58 同城的业务背景,58 同城是一个生活服务平台,平台连接着大量 B 端商户和 C 端用户,B 端商户在平台发布帖子信息,平台将这些帖子信息分发给 C 端用户供其浏览。在 58 同城 App 或网站上,用户可以通过搜索和推荐的方式获取帖子信息,例如用户可以通过搜索框搜索信息、进入列表页筛选和浏览信息。58 同城提供租房、二手房、找工作、二手车、黄页、二手车等信息,平台上有大量商家和用户,平台的目标是提高双端连接的效率。



让我们先从生活中的一个实际场景开始,让大家直观感受 58 是如何服务我们平常生活的。


我们经常需要保洁打扫服务,首先打开 58 同城 App,选择家政服务大类页,然后选择自己满意的服务商家,这时候我们可以看到“微聊”入口,通过它可以连接起 C 端用户和 B 端商家。

二、58 对话机器人


基于 58 平台大量的商家和用户,我们构建了 58 同城对话机器人。从功能上讲:58 同城对话机器人提供了智能问答、多轮对话、商机挖掘、智能辅助、在线客服等几大核心功能,目前已经落地在帮帮智能客服系统和智能客服商家版中,智能客服商家版已经在 58 集团各个业务线落地,比如:针对本地服务的商家助手,针对房产的经纪人助手,针对招聘的企业助手以及针对车的车商助手。



接下来,我们介绍一下 58 智能客服商家版的整体架构,为了提升 B 端商家和 C 端用户的有效连接,我们打造了智能客服商家版。


在全 AI 模式下,所有的咨询都会优先转接给自动问答机器人,当遇到机器人无法回答的问题时,则根据用户配置转接人工。支持设置开启时间段,应对商家在不同时间段的接待需求。


智能辅助模式-人机协作共同服务:


人工接待中,用户的提问如果命中知识库的问题,机器人向人工坐席推荐答案,由人工参考回复用户。



这里是智能客服商家版的后台界面,2020 年 Q2 季度我们总共公开通了近百万商家,累计服务了近千万的 C 端用户。



智能客服商家版在生活服务品类落地场景是这样的,在生活服务品类中,我们同时有人工坐席和 AI 对话机器人,根据不同的类目和工作时间段,C 端用户会和 AI 对话机器人或者人工坐席进行沟通,人工坐席和 AI 对话机器人的目的都是解决用户的问题,同时获取用户的电话商机。在取得用户的电话商机后,平台会把商机通过商机中心推送给 B 端商家。最终 C 端用户和 B 端商家通过挖掘出的电话商机进行沟通,最终成单。

三、核心能力

QABot


基于上述,我们提供了满足业务咨询的 QABot 能力,提供商机引导的 TaskBot 和商机催留能力,以及提高人效的商机挖掘和智能辅助能力。



首先,QAbot 解决的是用户的问题咨询场景,实际业务过程中,我们核心要解决的问题是:(1)机器人能回答哪些用户提问;(2)如何回答更多的问题并准确回答



我们先看第一个问题,也就是怎么才能知道用户可能的提问有哪些。我们借助机器与人工挖掘结合的方式,先用 KMeans 等聚类方法获取一些种子问题,再由编辑标注,得到业务线知识库,该知识库包含标准问题和扩展问法。



有了业务线知识库之后,我们可以在这个基础上训练问答模型。该模型输入用户 query,输出对应的标准问题编号。


识别出了用户问题,如何回答也很重要。我们使用结构化的答案库,通过查询帖子结构化数据+文本填充相结合的方式,动态生成答案。



大家可以看到,问答模型的效果对用户体验非常重要。为提升问答模型效果,达到 F1 值大于 0.8 的目标,我们结合线上数据进行了多次模型迭代。



在项目初期,我们使用 FastText 作为基准,快速得到问答模型。选择 FastText 这个浅层神经网络,一方面是考虑网络的训练和预测速度快,可以快速验证数据是否存在异常;另一方面是 NGram 能够快速捕捉关键词特征,在一些关键词比较明显的类别上能取得不错的效果。




DSSM 作为一个文本匹配模型,其优势在于对样本少的类别也有较好的匹配效果。句子的表示方法对 DSSM 模型的效果有显著影响。这里我们先试用了 LSTM 模型对句子进行表示。相对于 NGram 而言,LSTM 更能够提取出句中的长程特征,提升了样本中长句子的识别效果。其次我们也对 LSTM+NGram 特征的结合进行了尝试,使得模型在有效处理长句的同时,也能不遗漏关键词特征。



58 微聊场景下积累了大量的无监督数据,在预训练模型出现后,我们得以进一步挖掘这些数据的潜力。实践中,BERT 模型作为此类半监督模型的代表,在分类任务中取得了良好的效果。BERT 的主要特点是预训练掩码语言模型+微调两个步骤的结合,同时为了配合 Transformer encoder 的使用,使用了位置编码机制。



SPTMs 这个轻量级的预训练模型实现比较早,BERT 在 18 年 10 月底发布,这个模型是 19 年 4 月实现的。这里当时看主要创新点是去掉 BERT 的 NSP 任务,另外替换成 Bi-LSTM 也是做一种尝试(实际也可以用一层的 Transformer),在机器资源有限情况下让预训练变得容易。如果直接用 BERT 去预训练,耗时很久,而 SPTM 的推理耗时较低,可以在 CPU 上直接跑,十几到几十毫秒。



SPTM 将每个单句作为一个样本,句子中不超过 15%的字参与预测;参与预测的字中 80%进行 mask,10%随机替换成词典中一个其他的字,10%不替换。在预训练阶段,SPTM 使用 softmax 值与单字 one-hot 相乘作为损失度量;在微调阶段则计算各类别的交叉熵损失。



SPTM 经调整后能达到 F1>0.8 的目标,同时其推理耗时也在控制范围内。目前 LSTM+DSSM/SPTM 模型已在 github 开源,大家可以参考我们之前分享的文章《开源|qa_match:一款基于深度学习的层级问答匹配工具》(链接:https://mp.weixin.qq.com/s/2NahwBgAnptiK5pv6vTLNQ)进行详细了解。

TaskBot


TaskBot 是一类帮助用户完成特定任务的聊天机器人。借鉴通用的 Frame 数据结构,我们采用意图+词槽的组合对用户 query 进行知识表示。在 58 场景下,我们将用户提供的特定词槽值称作商机,TaskBot 的目标即是引导用户提供商机。



58 作为提供本地生活服务的头部平台之一,同时服务于 C 端用户与 B 端商家。为提高平台效能,促进增收,我们基于 TaskBot 开发了商机引导功能,由机器人代替人工,引导用户透露商机,目标是转化商机、促成交易。




在 58 服务寻求场景下的会话中,用户需求的复杂性给商机引导带来了诸多挑战(如图中实际的用户对话)。实践中我们发现,20%的用户在问了一轮后就退出会话,而余下的 80%用户中,有 45%在被问到电话时,表示拒绝或不愿透露。



通过学习人工客服的会话,我们发现人工客服回复存在固定的模式,一般人工客服会先回答用户的提问,再根据需要问的信息对用户进行反问。在这个基础上,我们选用了结合一问一答的 QABot 和商机引导多轮 Taskbot 的方案,实现类似人工客服回答模式的商机引导过程,目前已在房产等多个业务线落地。



举个例子,在实际会话中,用户的第一个问题命中某标准问题,此时我们先查询答案库,获取到一问一答(QABot)的答案,同时,我们根据 TaskBot 的触发条件判断,如果触发 TaskBot,则继续回复 TaskBot 的反问。


在触发 TaskBot 后,用户在 TaskBot 的依次引导下,逐步透露商机,此时 QABot 不会命中标准问题,TaskBot 引导用户直到对话结束。



通用的 TaskBot 包含 NLU、DM 与 NLG 模块。我们将 DM 和 NLG 模块集成在统一的对话管理服务中,加上 NLU 模块单独对应一个服务,共两个 SCF 服务。



基准版的对话管理服务,以一个可以从静态配置信息中初始化的状态机作为核心。状态机的每个节点对应于一组槽位的组合,每条边对应于意图与一组槽位的组合。当前的状态存放在 58 存储服务 WRedis 内。用户输入被解析为意图和词槽的组合后,对话管理服务根据状态机状态选择出一个回复策略,这个策略由动作与参数组成。查询得到参数值后,根据动作类型选择合适的回复模板,便得到了最终的回复。



随着 TaskBot 接入业务的增加,业务侧对其灵活性和通用性都提出了更高的要求。这里我们借鉴业界经验,对原有的状态机进行进一步抽象,定义出触发、填槽、函数与回复这 4 种节点类型,每种类型应用特定的配置,使状态机配置大幅简化,复用成本大大降低。



与 Frame 将知识区分为 Procedure 和 Data 相似,TaskBot 区分了标准问题和词槽。标准问题直接复用自 QABot 的结果,用于判断是否需要触发 TaskBot 进入商机引导流程,词槽则对应于具体的商机信息。

智能商机催留


我们分析线上用户数据发现,未提供商机的用户中,48%的用户在 AI 机器人询问电话之后就退出了对话,用户不再与机器人进行沟通,这样这部分用户的商机就流失掉了。



同样我们分析了人工客服的对话记录,发现用户同样存在退出会话的问题,但是人工客服会主动与 C 端用户进行沟通,一般在用户不回复后约 30 秒的时候,人工坐席就开始进行主动会话催留,经统计发现,针对 3 次催留的用户,其中有 80%的用户留了电话商机。



所以,我们构建起基于对话管理器中对话状态+智能主动发问的能力,赋予 AI 对话机器人主动对话的能力,与用户展开主动聊天,智能催促用户留下电话商机。


这个地方,我们使用多轮对话用户的商机状态,结合微聊消息队列的定时器,通过模拟人工坐席的催留节奏和话术,达到智能商机催留的目的。



在本地服务品类,智能商机催留功能上线后,我们的商机转化率绝对提升 14%,效果显著。

商机挖掘


在智能客服商家版中,存在对话机器人和人工坐席,目前支持的人机协作模式有以下三种:


①机器人接待用户,机器人回答不了转人工客服


②机器人和人工客服各自接待一部分用户


③机器人全部接待,无人工客服参与



这张图展示的是人工坐席的后台工作界面,一个人工坐席会同时与多个店铺的多个用户进行在线沟通,所以,提升人工坐席的工作效率是非常重要的。


我们提供了商机自动挖掘的能力,在人工和用户沟通过程中,AI 会自动挖掘 C 端用户的商机并且自动填写到商机管理中,同时针对 C 端用户的问题,我们会提供智能辅助的能力,给人工坐席提示可能的候选答案,供人工坐席采纳以提高回复效率。



我们利用了 IDCNN 提取上下文语义特征能力,以提升远距离建模的能力,CRF 建模状态转义的能力。CRF 层引入序列的转移概率,避免标签偏移,最终计算出 loss 反馈回网络。AI 提供了多种商机的挖掘能力,包括核心商机:电话,地点,时间,业务商机属性。



无论是机器人引导的商机还是人工坐席产生的商机,最终都会流入商机管理系统,商机挖掘后,我们会实时推送给商机中心,商家与用户进行及时的沟通最终促成交易,从而达成了整个服务的闭环。



目前,从商机转化率上,我们对话机器人达到了人工坐席大约 95%的水平,部分类目对话机器人甚至高于人工客服的电话商机转化率。同时,商机挖掘的准确率和召回率也都超过了 90%,提高了坐席的人效。

四、总结展望


未来我们会加速算法创新和业务落地,从强化学习、预训练等技术进行深入研究,提高对话机器人的效果。


58AI Lab 实验室介绍



最后介绍一下我们的 58AI Lab,AI Lab 隶属于 58 同城 TEG 技术工程平台群,旨在推动 AI 技术在 58 生活服务行业的落地,打造 AI 中台能力,以提高前台业务的人效和用户体验。AI Lab 目前负责的产品包括:智能客服、语音机器人、智能写稿、语音分析平台、AI 算法平台、语音识别引擎、智能营销系统等,未来将持续加速创新,拓展 AI 应用。


AILab 大力推进开源社区,目前我们基于开源了 58 智能问答匹配算法开源项目和 58 通用深度学习推理服务开源项目,欢迎大家 star/fork。


欢迎关注 58AILab 公众号



58 同城 AI 算法大赛开放报名啦!关注上面的公众号快快进行报名吧!



我们还在大力招人,后端工程师和算法工程师,欢迎发送简历到我的邮箱hanwei10@58.com


感谢大家的聆听。


2020-07-23 14:083204

评论

发布
暂无评论
发现更多内容

《MySQL入门很轻松》第5章:数据完整性及其分类

乌龟哥哥

数据库 2月月更

模块七作业

黄秀明

「架构实战营」

【行业云说直播间】就在明天下午!聚焦园区数智化转型

云计算运维

大数据培训:Flink窗口的开始时间的计算

@零度

flink 大数据开发

聊聊 Pulsar: 在 Linux 环境上搭建 Pulsar

老周聊架构

云原生 Apache Pulsar 2月月更

基于LSTM模型的共享自行车需求预测

Peter

Python 机器学习 深度学习 算法

架构实战营 第 4 期 模块七作业

架构实战营 模块七 王者荣耀 「架构实战营」

王者荣耀异地多活架构设计

AUV

「架构实战营」

WebRTC 服务器架构 | 社区征文

liuzhen007

音视频 新春征文 2月月更

web技术分享| WebRTC记录音视频流

anyRTC开发者

前端 音视频 WebRTC web技术 实时通讯

用命令行做数据科学(上)

Render

Numpy可视化绘图

Peter

机器学习 数据分析 Numpy

从线程与进程的区别这一问题出发

宇宙之一粟

操作系统 2月月更

机器学习入门知识

Peter

Python 机器学习 算法 监督学习

剑指offer笔试题 · 常量字符串

安然无虞

C语言

AngularJS + Ionic 开发移动端 Hybrid 项目实战总结| 社区征文

No Silver Bullet

angular.js 经验分享 Ionic 新春征文 2月月更

哪个低代码平台上手度对小白更友好?专业测评来了!

优秀

低代码 应用开发

产品经理沟通技巧

史前靓仔

职场 产品经理 沟通技巧

模块七

撿破爛ぃ

架构训练营

MySQL RR级别的实现

JavaEdge

2月月更

图解Numpy教程

Peter

Python 机器学习 Numpy

实力与颜值并存 —— Apache Pulsar PMC 成员刘昱专访

Apache Pulsar

开源 云原生 Apache Pulsar 社区

基于随机森林模型的心脏病人预测分类

Peter

Python 机器学习 算法

机器学习神器Scikit-Learn入门

Peter

数据挖掘 机器学习 算法

Nacos中服务删除不了,怎么办?

王磊

springcloudAlibaba

尚硅谷Kafka新版视频教程发布

@零度

大数据开发 kafka 3.X

裸辞全职开源的监控告警项目

TanCloud探云

开源 云服务 监控系统 监控告警

musl堆利用技巧,你知道多少

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 安全漏洞

从冬奥看中国科技(四):“一鱼多吃”的5G

脑极体

再见收费的Navicat!操作所有数据库就靠它了!

沉默王二

Java

Linux系统编程-进程间通信(管道)

DS小龙哥

2月月更

58同城对话机器人应用实践:本地生活服务场景中的商家智能助手_AI&大模型_韩伟_InfoQ精选文章