zoukankan      html  css  js  c++  java
  • 大数据时代:基于微软案例数据库数据挖掘知识点总结(Microsoft 神经网络分析算法)

    转载:http://www.cnblogs.com/zhijianliutang/p/4067795.html

    前言

    有段时间没有进行我们的微软数据挖掘算法系列了,最近手头有点忙,鉴于上一篇的神经网络分析算法原理篇后,本篇将是一个实操篇,当然前面我们总结了其它的微软一系列算法,为了方便大家阅读,我特地整理了一篇目录提纲篇:大数据时代:深入浅出微软数据挖掘算法总结连载,我打算将微软商业智能中在DM这块所用到的算法全部集中在这个系列中,每篇包含简要算法原理、算法特点、应用场景以及具体的操作详细步骤,基本能涵盖大部分的商业数据挖掘的应用场景,有兴趣的童鞋可以点击查阅。本篇我们将要总结的算法为:Microsoft 神经网络分析算法,此算法微软挖掘算法系列中最复杂也是应用场景最广泛的一个,简单点讲:就是模拟我们的大脑从茫茫的数据海洋中思考出有用的信息,来达到数据挖掘的目的。原理可以参考上篇。

    应用场景介绍

    关于Microsoft神经网络算法的应用场景还是蛮多的,在上一篇原理篇我们就介绍过,其主要是应用在以下领域:

    • 营销和促销分析,如评估直接邮件促销或一个电台广告活动的成功情况。
    • 根据历史数据预测股票升降、汇率浮动或其他频繁变动的金融信息。

    • 分析制造和工业流程。

    • 文本挖掘。

    • 分析多个输入和相对较少的输出之间的复杂关系的任何预测模型。

    当然以上的应用场景说的很泛泛,并且没有一个特定的应用场景,这个是可以理解的,因为此算法为模拟生物行型算法,也就是说在特定的环境中只要有足够的”证据“支持,我们人类自己能通过主观判断出结果的应用场景,Microsoft神经网络算法就能应用,但是当我们人脑思维对于少量”证据“下可以主观的判断,但是面对茫茫的”证据“海洋下我们人类脑子想要理清头绪,然后判断出结果就比较吃力了,这样的就是神经网络应用场景了。

    上面的几种应用场景中,并不是只有Microsoft神经网络算法就能挖掘的,比如:营销中评比邮件还是电台广告这两种方式那种更有效,其实这是Microsoft决策树分析算法的最佳应用场景;历史数据预测股票升降这个是Microsfot时序算法的典型应用场景;....但是所有的这些这些...是因为我们能确定下来前提或者说挖掘范围:比如:营销评比,我们就比较邮件还有电台广告...但是出现一种特殊情况:比如两者都不能促进营销...反而是因为公司最近加强了销售手段而提升的,或者说某种不确定的因素造成的业绩提升,对于这种情况我们利用Microsoft决策树算法也是没用的。而用Microsoft神经网络算法就可以分析出来。

    还有一种更特殊的应用场景:当我们面对一堆的数据而要基于某种目的去数据挖掘时,感觉到无从下手或者在DM中选择不到合适的算法的时候,这时候就是Microsoft神经网络分析算法的应用场景了。

    技术准备

    (1)微软案例数据仓库(AdventureWorksDW208R2),案例数据仓库中的呼叫中心的数据表,一张事实表FactCallCenter,下面步骤中我们会详细介绍这张表里面的数据。

    (2)VS2008、SQL Server、 Analysis Services。

    挖掘目的

    在一些大的商业公司中都有自己的呼叫中心,比如:移动的10086,联通的10000....等等,而这些呼叫中心中除了再联系完他们之后让你选择:满意、不满意、灰常不满意来作为他们的服务等级标准外,在行业中还有一个指标来评比,这个指标被称作:挂断率,用来反映客户的失望度,就是在我们接进他们的客服中心的之间,如果选择人工服务,他让你等待...你不爽,挂断了,这就产生了一个挂断事例,而通过挂断事例总和在所有呼入人数的所占比就是挂断率指标了。挂断率越高说明他们客服中心服务质量越差。

    挖掘的目的就是找出影响“挂断率”的因素有哪些,是客服MM太少?态度不好?声音不甜美?服务不周到?.........从而提高呼叫中心的服务质量,增加营收。

    操作步骤

    (1)我们这里还是利用上一期的解决方案,直接打开,添加数据源视图,方法参照前几篇,我们直接看图:

    右键,来浏览下这个表中的数据明细:

    参照微软案例数据库官方说明,我们将这个事实表里面数据明细列出来。下面是字段说明:

    列名

    包含内容

    FactCallCenterID

    数据导入到数据仓库中时创建的一个任意键。

    DateKey

    呼叫中心的运营日期。

    由于供应商为每个运营日中的每个轮班时间都提供了一个单独的报表,因此日期不是唯一的。

    WageType

    指示当天是工作日、周末还是节假日。

    Shift

    指示为其记录呼叫的轮班时间。此呼叫中心将工作日划分为四个轮班时间:AM、PM1、PM2 和 Midnight。

    LevelOneOperators

    指示值班的一级接线员的数量。呼叫中心员工从一级开始起步。

    LevelTwoOperators

    指示值班的二级接线员的数量。员工必须达到一定数量的工作小时数后,才有资格成为二级接线员。

    TotalOperators

    此轮班时间内存在的接线员的总数。

    Calls

    此轮班时间内收到的呼叫数。

    AutomaticResponses

    完全通过自动呼叫处理(交互式语音应答,即 IVR)来处理的呼叫数。

    Orders

    由呼叫产生的订单数。

    IssuesRaised

    由呼叫产生的需要后续操作的问题的数量。

    AverageTimePerIssue

    应答一次来电所需的平均时间。

    ServiceGrade

    指示此轮班时间的“挂断率”。挂断率是呼叫中心经常使用的一个指标。挂断率越高,说明客户的满意度越差,因此丢失潜在订单的可能性也就越大。挂断率是按轮班时间计算的。

    其实上面的表中已经列出了几个关键字段,我们来看,其中我们上面提到的“挂断率”:ServiceGrade字段了,前面的一些行就是记录一些呼叫中心工作信息了,当我们面对这些信息是无从下手的,因为我们看不出来那些因素会影响到ServiceGrade指标值的大小的,当然这时候我们就用Microsoft神经网络分析算法采取诱探的方式进行挖掘分析了。

    (2)新建挖掘结构

    我们来新建这个数据挖掘模型,简单的步骤,具体内容可参照我之前的博客内容,看几个关键步骤:

    我们点击下一步,然后进行输入和输出的设置

    这里我们不知道那些因素会影响到“挂断率”这个指标,我们就乖乖的全选得了,这叫做:宁滥勿缺!....我去....但是有两个我们还是没选,一个DateKey..这个是上班记录日期,我基本可以肯定这个指标和那天上班没有毛关系,当然你也可以选择,那处理时间更长一些,还有一个是FactCallCenterID,这个是键值,肯定不选择的,然后输出我们选择了:ServiceGrade挂断率、然后还有Orders(产生的订单量),这个和绩效有关,我们顺便看看那些因素会产生更多的订单,选他的原因你懂得!然后还有一个LevelOneOperators,这个是第一个岗位的数量,通过它我们可以分析出这种分两种岗位级别会不会有用。

    我们点击下一步:

    这里提示下,神经网络分析算法是不允许钻取的,这个是可以理解的,因为它不是线性函数,也就是说你钻取的是一个个“神经元”节点,而这些“神经元”同样又依靠其它的“神经元”支撑,所以理论上你的下钻是毫无意义的,不明白的可以参考我上篇原理篇。

    我们来部署该挖掘模型,然后进行处理,过程简单,不废话介绍。

    结果分析

    不介绍,我们直接上图看结果

    神经网络的“模型查看器”很简单,可以看到只有一个面板,里面分为两部分:输入和输出,下面的就是各个变量的属性值,通过操作上面的输入和输出就可以分析不同变量对输出的影响了,这个类似于“聚类分析算法”的特征分析面板。

    输入属性很简单,我们可以选择上面我们选择的各种属性:

    可以选择值

    这里我们可以看到,上面我们选择了“自助应答”这个值,但是它显示的值是一个分段的区间值,这里我们要说明一下神经网络的特点,对于离散型属性值,Microsoft神经网络是采取采样分段来进行区间值截断,但是这个区间值并不是严格意义的按照数学上的等比数列进行分组,比如:

    我们来看一下ServiceGrade这个离散值在vs中的分组方式:

    ServiceGrade 属性在理论上是介于 0.00(应答所有呼叫)和 1.00(挂断所有呼叫)之间的数值,但是在神经网络算法中是按照上面的图进行分组的,会将分组成 0.0748051948 - 0.09716216215 这样的范围。尽管此分组在数学上很准确,但此类范围可能对业务用户并没有太大意义。要以不同的方式对数值进行分组,可以创建数值数据列的一个或多个副本,并指定数据挖掘算法应如何处理这些值。这样更能顺利的接近我们的目标分析值。

    我们可以看到,这个输出也是同样的方式:

    下面我们来分析上面的第一个挖掘目的:那些因素会影响(挂断率)Service Grade.我们选择一个分组最高的,一个分数最低的

    上图总可以看到,我们选择的输出为“挂断率”:Service Grade 这里选择了两个区间:0.030-0.072和0.126-0.210,0.210的概念就是有一百个客户打来电话,人家不爽,给你挂断的人数有21个,已经是一个很高的值了,这个值越高说明服务质量越差,我们来看一下变量,很明显:影响“挂断率”的第一个因素为:Average Time Per Issue(应答花费的平均时间)。

    “应答花费的平均时间”在44.000-70.597之间的更倾向于0.030-0.072这个低分值的应答率,说明啥?也就是说人家打来电话一般在这个时间给你解决掉的,人家都比较满意,都不会挂断你。

    第二个因素“Orders”订单数量,这个也是在321.940-539.000之间的,挂断率更低,其实这个应该是因为挂断率低而导致订单数量增加

    我们来看第三个因素“应答花费的平均时间”在89.087-120.000之间的,挂断率直接飙升到0.126-0.210.....纳尼!!!这是为毛?...客服应答的时间越久...挂断率越高!

     哦哦...我猜这部分一般是客服MM给人家解释的不满意,然后人家一直想问明白,丫的客服MM就是解释不清楚,于是乎客户果断挂电话,不再鸟你了。当然还存在一种情况就是客户打电话一直骚扰着客户MM...然后...然后客服MM就给挂断了...当然..这些就是猜测了...我们不关心过程,只关心结果:在这个区间的挂断率就是高,有图有真相。

    我好奇的比较下“应答花费的平均时间”的两个区间的对比值,我们来看:

    嘿嘿....应答平均时间在区间44.000-70.597之间的“挂断率”就是很低,而且评分在100分!看上图,概率在53.48%,而成为高“挂断率”的概率才为:6.18%。

    下面的应答平均时间在区间89.087-120.000之间的“挂断率”很高,评分在74.01,评分值的高低反映的就是这个判断的可信度大小,并且看成为高“挂断率”的概率飙升为:45.22%。

    再往下看,我们还发现了一个更可爱的情况,截个图看看:

     这个Shift的值代表为轮班时间,看上面的值显示的是midnight....深夜...漆黑的夜晚...给客服MM打电话的挂断率概率都挺低的....这是神马原因.....看来微软给的案例数据库数据还是挺真实的!

    其它的属性我这里就不分析了,方法同上。其实到这里我们已经利用Microsoft神经网络分析算法已经分析出影响“挂断率”最重要的因素为:Average Time Per Issue(应答平均时间),下面我们调整输入,直接来分析这个因素:

    在44.000-70.597之间的,清一色的低挂断率,并且产生的订单量最可能为321.940-539.000,汗...你妹...上班期间最好还是在深夜。下面接着看:

    换了一个区间...结果基本没变,原因不解释

    下一个区间,情况发生了变化,在这个区间里,订单为50.000-181.677之间的已经展现出来高”挂断率“的趋势。

    .....我去...到了这个区间...成了清一色的高”挂断率”,并且上班时间成了(PM2)下午....订单数减少至50.000-181.677....看来下午客服中心应该都放假,全部改成“深夜”上班...嘿嘿...

    为此我通过数据源视图浏览数据,通过透视表来验证一下我们的推断是否正确,看看下面的图就知道了:

    是吧...平均应答时间越久,应答率分数越高,说明挂断率越高。

    我们也可以借助Microsoft神经网络算法的特性,对上面咱们推断的结论进行反向验证,我们将输出改成Average Time Per Issue “应答平均时间”,然后还是选择两个区间值来看看,影响这个属性的变量值有哪些

    看到了嘛...很高的挂断率在0.126-0.210之间的应答平均时间更倾向于89.087-120.000,同样低“挂断率”的就趋向于44.000-79.597了。

    咱们属性值就分析到这里,有兴趣的童鞋可以继续分析其它的。

  • 相关阅读:
    设计模式之备忘录模式
    特殊传参方式
    页面响应效率测试
    composer安装的包git无法提交的解决办法是因为安装的时候生成了.git隐藏文件
    数据结构和算法深入浅出理解
    中缀表达式转换为后缀表达式
    p2p技术
    【自动化测试】WebDriver使用
    pt-query-digest简介使用
    mac编译openJDK8
  • 原文地址:https://www.cnblogs.com/martin-roger/p/6033298.html
Copyright © 2011-2022 走看看