2015/7/13 下午12:06:19 星期一
当前位置: 主页 > 平步青云 >

阿里千亿级购物节背后,淘宝智能客服架构演进之路
时间:2019-05-31 13:38

摘要:“淘宝上每天都有上百万的客服在线为上亿的买家提供服务,客服服务平台也从一个简单的分流系统逐步演进到覆盖买家、客服和客服主管三位一体的平台解决方案。本文主要分享整个淘宝客服平台架构演进的过程,以及当前服务如何结合AI赋能的实践。2017年12月1日-2日,由51CTO主办的WOTD全球

第二阶段:客服业务系统架构升级

客服业务系统与 AI 能力的融合

由于我的团队是做平台的,而 AI 场景则是由另外一个算法团队来实现的,因此双方需要进行算法相关的对接。

我们提供了一整套服务注册、发现和订阅的关系。虽然同为商品推荐,但是应用于“航旅”方面的推荐算法会与带有图片和搜索功能的“女装”推荐模式截然不同。

当前我们主要运用的还是基于规则路由的机制,但是随着服务场景和服务提供者的增多,我们会更多地融入基于 AI 的决策机制。

在将 AI 与各个 IM 通道相结合的方面,我们基于会话的框架设计,完全可以对标 Facebook 的 Messenger 和微软做的 Bot Framework。所有接入的聊天场景,不管是机器人还是解决方案,都具有会话完成的机制。

系统籍此可以获悉某个传递过来的消息或请求,是由哪个用户在何种场景下触发的。

过去的单轮交互是:有一个请求进来,就给出一个答案。而如今 AI 所应对的复杂业务一般需要进行多轮交互。

如前面提到的航旅推荐的例子:在交互了是否要旅行之后;需要进一步询问是国内还是国外游;如果是国外游的话,还需询问目标地区。可见多轮交互需要 AI 具有语意匹配和意图识别等较强的交互能力。

为了让买家在使用 AI 时有更好的体验,我们在给出算法接入时,允许对方自定义菜单。他们通过沟通,将期望买家输入的答案设置到菜单中。

如此交互式的提醒,不但省去了买家的打字输入,又能固化其反馈的结果。这种友好的交互也提升了平台的整体处理能力。

由于我们本质上是通过基于消息驱动的逻辑来实现的,如上图从左至右所示:事件源接入→标准化安全脱敏事件中心与调度中心的控制。与此同时,外面的 AI 服务接入于此注册授权开放接口整体监控。

我们之所以将 AI 的服务能力单独划分出来,是因为需要通过与其他团队合作,来实现外部的搜索、意图识别、知识库、多轮交互、情感分析等能力。

我们的 Bot 不仅可以与买家端交互,也可以与客服进行交互。类似于店小秘,作为认知服务的 API 可供各个业务方去调用。

对于用户的聊天数据、客服的绩效、其当天的状态、每个客户角色的数据、以及店铺的商品数据,我们通过底层数据的沉淀功能,可供不同场景进行调用,从而实现了快速开发和轻量级的服务提供。

总结

结合场景抽象出业务本质的模型来指导设计:根据前面所提及的基于事件驱动的概念,大量的事件都是由商品交易或聊天互动所触发产生,并形成了联动场景。

我们可以通过一层层的切片来构建一个个具象的场景。而从整体的角度来说,不同事件的组合又能形成不同的驱动模型。

跟随着业务的复杂性不断的调整和优化架构设计:我们没有必要一定采用所谓“最牛”的中间件方案。只有最适合自己的业务场景才是最好的架构设计。团队成员统一架构上的认知:我常在团队里说,“架构只有适合与否,没有好坏之分。使用一个好的架构,你当然能够实现某个业务需求;而使用一个差的架构,你同样也能最终实现该业务需求。”

因此全部团队成员都应当有一致的架构认知。只有这样每个人才能在编写业务代码时,主动思考自己所实现的功能应该如何在整个架构体系里达到平衡与和谐处理,以及放置在何处才最为合适。

相反,如果团队成员对于架构的认知不一致,那么就有可能会导致组织内部的代码风格和运行方式出现不一致的情况。因此统一认识对于带领团队去满足需求和实现业务都是至关重要的。

作者:古墨(邓敏)

编辑:陈峻、陶家龙、孙淑娟

投稿:有投稿、寻求报道意向技术人请联络 editor@51cto.com

淘宝技术部-媒体技术与消费连接平台-消费连接平台-平台业务-自运营,高级技术专家。2010 年加入阿里,2015 年开始负责阿里商家客户服务平台的搭建,推动平台架构升级,为阿里全域(天猫、淘宝、1688、航旅等)商家提供客服整体解决方案。专注于高并发、高性能、高可用的分布式系统研究和实践。

精彩文章推荐:

普通程序员如何变身年薪百万的机器学习工程师?(文末有送书)

阿里技术大牛告诉你:一个NB架构师的必备素质