2017年9月23日阿里客户服务技术论坛

智能调度

一.让好用户遇到好客服

1.根据客户意图路由

2.根据模型最优匹配

3.数据赋能客服

 a.智能辅助咨询解答(方寸)

  解决方案无需记忆,用户数据无需翻找

 b.智能辅助工单处理(瓦力)

  系统通过机器学习客服处理工单,自动学习工单判定规则,输出判定结果

  算法代替人工配置规则

 c.仿真培训机器人(黄冈密卷)

  利用用户分层模型和客服能力模型进行最佳匹配

二.阿里客服系统的特点

1.用户视角

2.解放50%以上人力资源

3.服务万人如一

4.数据驱动

5.弹性服务,从容应对双11

6.功能组件化,快速接入

三.阿里客服工作台

  来电弹屏、在线服务、工单中心、方寸、统计分析、坐席管理、仿真培训(黄冈密卷)

四.永恒的挑战

  消费者(用户体验)-客服(成长/成就)—平台(效率/成本)

五.系统演进

  ORM+MVC->RPC->MSA->DT

    All-In-One CRM NG

六.调度问题

  输入:M个智体(客服|资源|...),N个任务(任务|作业|...)

  输出:将N个任务指定匹配至M个智体

七.单机基于业务技能组分配

  准实时,没有并发问题

  调度策略静态,忙闲不均

  性能:调度会成为性能瓶颈

八.分布式分片调度

  分布式动态扩展

  基于静态业务分配

  独立的RPC服务

九.按业务部门分布式分片

  支持横向动态扩容

  可用性保障

  分配策略还是hardcode

十.传统模式的痛点

  用户:被安排,缺少人文关怀;技能不对常被转交,多次解释;长尾个性化诉求无法被满足

  客服:小二能力固化;干好干坏一个样;没有榜样

  平台:粗粒度(技能组);重运营,基于经验配置;弱弹性;服务多样性被束缚

十一.弹性人力云

  用户:减少等待;精准推荐;个性化服务体验

  客服:全技能学习成长;服务主动性、积极性;用户问题和服务水平区分

  平台:细粒度(多维特征);轻运营,基于机器学习;强弹性,灵活调度;服务多样性自由扩展;FCR、AHT、SAT提升

十二.策略中心+算法

  微服务拆分,和单一业务解耦

  模型抽象、可扩展

  算法结合

十三.客服画像

  推荐最匹配小二

十四.系统是解决问题中迭代抽象出来的

  围绕领域模型有:商业机会、快速反应、增加、混乱增加\放缓、重构

基于React的插件化SPA设计

一.什么是SPA

二.插件化的SPA

  技术:为平台型系统而生

  业务:平台业务要支持垂直领域

  什么是插件化?为什么要做插件化?

  信息架构、规范化、总控管理、赋能

三.插件动态加载

  过去:本地打包,React Component、import、webpack

  现在:线上动态引入,React Component、AMD

  如何加载:Webpack->AMD(requirejs)

  插件独立:版本管理&开发调试,libraryTarget

四.共享代码:Webpack loader

  JS:require.config & Webpack externals

  CSS:style loader

五.组件能力

  跳转其它页面gotoPage

  离开当前页面leavehook

  是否处在当前页面isCurrentPage

  组件之间通信

  高阶函数(HOC)

六.皮肤

  方案1:CSS使用预编译语言(Less)、使用{color}.variable.less

  不足:线上统一编译,本地同步主题文件

  方案2:使用class(btn-primary、btn-info、hightlight...)

  不足:class较多,记忆困难

七.代码

  AMD Module & React Component

  Redux store & reducer & actionCreator

  样式污染、z-index规范

  统一类库及版本

  性能:Component Diff、Stateless Component

八.工具

  语法解析器:eslinter、postcss->lesshint

九.总控管理

  插件异常隔离(try catch)

  全局站点 监控(window.onerror crossorigin)

  请求异常(hook XMLHTTPRequest)

  国际化(react-intl)

  ...

十.总结

  SPA让前端开发人员拥有页面架构更多的主动权

  可利用IESM(信息架构、规范化、总控管理、赋能),架构插件化的SPA

  插件化SPA,让开发者之间的协作更加容易,让系统有能力支持不同的业务场景

智能UI自动化测试系统

一.UI自动化你会想到什么?

  技术:selenium、webdriver、css/xpath、关键字驱动、数据驱动...

  问题:业务更新快,脚本维护成本高;脚本不稳定;项目周期短,没有时间投入...

  挑战:页面不停变化,如何维护我们的脚本;关键问题是如何定位页面元素;无法解决适配&样式等问题

二.目前行业的通用解决方案

  测试脚本->测试API&Step&场景->数据驱动(excel、xml)->页面元素(对象库)->页面

  问题:复杂度较高;仍然无法规避页面元素调整带来的问题;适配,样式等问题仍然无法解决

三.目前行业的“智能”解决方案

  原始页面、测试页面->“智能识别”(1.个性特征对比(白屏、空窗);2.图片相似度对比(ORB、SIFT))->测试结果

四.智能UI测试方案主要特征

  智能识别:可以识别未见过的错误;业务变更不受影响

  低成本:对现有脚本改动小;业务变更不受影响

  可进化:随着使用越来越智能;可以定制出特定的错误

五.智能UI测试方案介绍-系统架构


六.实现过程

  多层神经网络

七.脚本编写



八.智能UI测试方案介绍-测试结果处理

  脚本执行->模型判断->结果分析->后续处理

  脚本运行&记录日志->日志监控&badcase更新->增量训练&优化模型

九.后续展望

  更智能:识别更多类型的错误

  更个性:识别特定类型的错误

  更明确:识别准确的错误类型

复杂业务流程管控架构演变

逆向交易服务系统系统演变:

  ORM:RULE ENGINE

  MVC:CASE TASK ACTION

  RPC:WORKFLOW

  SOA:DDD EDA多终端

  MicroService:DevOps敏捷开发快速部署

重要的状态变更发送事件

  标准化事件格式

  提供异步、同步消费方式

  集成了重试机制

一致性

  重试队列

  并发加锁

  异步监听

可用性

  拆分

  超时逻辑优化

  客户端缓存

可靠性

  服务分组

  过载保护

  规则缓存

思维决定软件设计,设计决定系统

  产品需求->竟品分析(京东、亚马逊、其它真实用户体验)->业务语义阶段(用最贴近客观规律的方式去思考)->领域建模(沙盘演练)->工业标准(团队分工)

猜你喜欢

转载自bijian1013.iteye.com/blog/2395454