案例基于机器学习的智慧感知运营体系应用文档格式.docx
《案例基于机器学习的智慧感知运营体系应用文档格式.docx》由会员分享，可在线阅读，更多相关《案例基于机器学习的智慧感知运营体系应用文档格式.docx（31页珍藏版）》请在冰豆网上搜索。
系统引入基于hadoop的申告预处理方法，实现了申告的自动预处理定位，远程定位问题准确率65％以上，一次解决率达30.6%，处理响应时长提升50%，用户重复投诉压降至10.1%。
第二，项目实现了感知投诉数据与规划工具的对接，传递了用户的建设需求，利用基于AHP的站址自动规划，快速响应用户需求，精准投放站址资源，使用自动站址规划工具，可以在10分钟内输出站址规划，而人工规划则可能需要5个人一周左右的时间，大幅度提高规划工作效率和精度，提升用户感知。
第三，项目实现了基站故障的自动预警管控和智能决策指导，利用基于CBR案例推理的故障定位方法，加快了故障的预警，保证了故障的精确管控，提供了可借鉴的定位指导压缩故障响应时长，在用户感知之前将故障消灭在萌芽状态。
对于正确预测故障原因的基站大面积退服，现场处理时间平均缩短129分钟；
采用智慧化管控方案，基站大面积退服的现场处理时间平均缩短57分钟。
第四，项目实现了客户感知的自动预警和集约优化，利用基于BP神经网络的网络质量投诉预警方法，找到潜在投诉客户，在其投诉之前分级实施优化，提前解决问题。
同时结合预处理工作实现了4G故障的集约远程优化，降低现场处理率。
自动预警投诉倾向用户125人，通过远程优化及关怀措施对用户实施了主动服务，53%的用户对服务表示认可，92%的用户在3个月内没有投诉。
推送重点投诉233次，响应时长由原来的30分钟缩短至目前的2分钟，极大的提高了处理响应效率。
最后，项目打造了移动投诉客户的营销维系体系，利用基于聚类分析的客户分类影响维系策略，拓展触点功能，深挖客户价值，助力市场发展。
从6月开始开展电话随销以来，针对目标客户共计派发商机单1039件至营业厅或前台，通过实施人员根据实施结果进行商机反馈发现，直接商机变现201件，其他后期升级变现121件，转化率31%，粗略估计价值升级获得15000元创收。
2.2感知引领基于AHP的建设规划决策方法
在移动运营商竞争激烈的今天，只有提高服务质量,为用户提供优质的网络服务才能在这场激烈的竞争中取得胜利。
其中移动基站站址的合理选择,是移动网络为用户提高良好通信服务的关键。
建立结合客户感知的建设规划决策流程，以服务支撑模块获取客户申告数据和MR数据为主要输入，按照先优化再建设，以优带建的原则，最快速响应客户需求，最大化企业投资效益。
2.2.1目前站址规划存在的问题
（1）规划质量难以保证且效率低
目前4G站址规划主要依靠建设和网优人员汇总路测和用户投诉记录数据在地图（googleearth或mapinfo）上对应分析匹配确认合适的站址，由于数据量大且为人工处理操作，站址规划标准化程度低，需要消耗大量的人力和时间，且规划效果受规划人员经验和责任心影响大，站址规划质量难以保证。
（2）用户感知响应速度慢，市场需求无法得到快速满足
由于规划周期较长，市场业务需求可能较长时间难以满足，用户反映网络覆盖问题难以得到及时解决问题，对于企业市场竞争极为不利，急需找到快速响应市场和用户需要并精准投放网络资源获取效益的网络规划方法，4G站址自动规划势所必须。
2.3.2智能化基站退服预警流程
传统的基站大面积退服管控机制比较落后，完全依赖于值班人员的主观能动性，如果值班人员不再关注基站大面积退服，那么将没有人提醒现场人员基站是否已经恢复。
同时，各种信息的传报也依赖于值班人员手动发送，不利于实际工作的快速响应。
因此，期望通过自动化手段，实现基站退服管控过程的智慧化、智能化。
管控流程如下：
（1）服务器通过接收亿阳I3接口基站告警以及恢复数据，监控现网基站状态，通过设定的规则判断是否出现基站大面积退服。
（2）发生基站大面积退服时，服务器执行基于案例推理的故障预测算法，通过案例知识库预测故障原因，生成基站大面积退服告警消息。
（3）移动端利用root获取超级管理员之后的高权限，通过APP定时访问服务器数据，服务器接收到移动端访问请求，向其发送基站大面积退服告警消息。
（4）移动端接收到服务器发送的消息后，调用易信客户端以及系统输入法，向指定的易信群发送消息。
（5）当产生基站大面积退服后，服务器会定时（间隔60分钟），根据接收到的告警恢复消息，判断基站是否已经恢复正常。
全部恢复则生成大面积退服恢复消息，否则生成跟踪的续报消息。
具体流程图如图2.2所示：
图2.2智慧化基站退服过程管控流程图
与之前的基站大面积退服过程管控相比，新的过程管控机制有以下优点：
（1）能够在基站大面积退服发生后，现场维护人员未到达之前，提醒维护人员最可能的故障原因，指导维护人员现场维护工作；
（2）自动发送基站大面积退服消息，跟踪退服基站状态，减轻值班人员工作量。
（3）快速将故障信息推送给预处理客服人员，便于第一时间向客户进行投诉拦截和申告反馈，提升客户感知。
2.3.3实施效果
统计自9月开始使用智慧化管控方案以来，全湖北省出现的60起基站大面积退服数据，移动端（手机）成功自动发送55起退服消息，漏报2起，误报3起，发送告警消息准确率达到91.67%。
漏报2起原因为手机电量不足关机，无法发送消息；
误报3起原因为基站闪退，系统没有及时接收基站恢复正常数据。
发布迅速：
对比55起准确发布的基站大面积退服消息，智慧化管控方案平均比全障工单系统提前6.34分钟发现基站大面积退服。
提升效率：
对于预测的55起大面积退服，发现成功预测故障原因24起，预测准确率为43.63%。
未成功预测故障的退服抢修平均时间为342分钟，成功预测故障的退服抢修平均时间213分钟，55起基站大面积退服平均抢修时间为285分钟。
因此，对于正确预测故障原因的基站大面积退服，现场处理时间平均缩短129分钟；
由以上数据可以看出，采用智慧化过程管控确实能够更快的发现基站大面积退服故障。
同时采用的基于案例的故障预测算法，能够有效的指导现场维护人更快速的定位故障原因，减少现场维护处理时间，压缩基站故障持续时间，对于提高用户感知有一定作用。
但是，正确预测准确率只有43.63%，在预测上仍存在较大的误差，需要继续收录更多的案例改善预测准确度。
2.4结合感知预警呈现的集约服务网优
传统的基于网元的KPI与真正的用户感知存在很大的差异。
很多情况下，基于不完整甚至不科学指标的保障和提升，无法直击要害解决问题。
运营商的网络优化体系建设已经向以用户感知为中心转变，从更多地关注网络设备性能、网络性能，转移到端到端的业务性能，从而提高用户的感知。
2.4.1感知申告集约网优流程
以更好的服务客户为目标，本项目按照“能远程不现场、能集中不分散、能自动不人工”的原则，快速的呈现目前感知及服务的劣化及严重程度，指挥指导后续网优工作的方向。
基于客户数据与网络数据，一方面利用机器学习方法预测实施流程，提前于客户感知之前发现问题，将故障消灭在萌芽状态，主动服务客户压降投诉；
另一方面，通过KPI映射KQI方法，当客户感知劣化时找到质差小区，集中由客服人员通过远程优化和派发现场网优人员核实处理；
而当产生投诉时，能自动产生预警信息并通过易信派障升及处理管控。
生产流程如下：
图2.3感知优化生产流程
2.4.2系统实现
（1）大屏呈现及预警
系统通过对数据进行综合分析，一方面通过GIS及图形化界面、topN问题分析法的方式传递了感知严重劣化的区域及用户，全面提升了预警能力和覆盖面，能够指导客服人员进行服务决策及时升级。
另一方面，通过易信自动推送相关群和处理人员，提升重点问题的优先级，有效缩短了处理时长，提升用户感知。
图2.4大屏呈现
（2）易信送障预警：
其次推送重点投诉233次，响应时长由原来的30分钟缩短至目前的2分钟，极大的提高了处理响应效率。
图2.5自动预警跟踪
（3）感知集约网优：
最后通过感知预警处理问题28处，及时定位发现问题派发工单或远程优化，在3月内无一人产生投诉。
2.5移动业务感知申告中的营销维系
2.5.1移动业务感知服务的营销维系策略
在海量的客户中我们会直接面对的是从服务支撑模块投诉处理中获取的用户，提前做好客户细分的意义在于为不同类别群体制定精细化的营销策略，运用基于机器学习的客户分类方法，找到目标客户，结合客户申告情况开展相匹配的营销维系方案。
图2.6移动网络感知申告重点客户随销维系结构图
移动商机单生成流程：
由于各地市资费不同、营销活动变化快、用户需求多样，在预处理和审核中随销暂只做商机单的生成，后期业务咨询及办理由各分公司及10000跟踪受理。
具体操作如下：
2.7移动商机单生成流程
（1）变危机为商机
根据基于机器学习的方法将客户聚类后，客服人员在预处理时根据号码输出提示策略针对不同定位用户进行精准营销。
2.5.2实施成效
通过客户感知“运+营”的智慧服务新模式的打造，推动了客户建设优化需求的传递，加快了故障的响应，转化了感知问题为效益提升。
（1）建设需求传递精准：
通过该项目模块的优化，对网络规划优化工作进行了指导，极大提高了网络优化和规划的合理性、准确性和高效性，避免由于方案不合理造成成本的浪费。
2017年4G网络五期规划中，对各种方式产生的规划站点（自动规划、网优会战、系统优化、工程优化、日常优化、专项优化等）进行统一评估，自动规划产生的785个站点站址规划价值评分为7.9，明显高于其他方式生成的规划站址。
同时对提高站址规划质量和工作效率起到关键性作用。
表2.3站址规划价值评分表
（a）大幅度提高规划工作效率，以1个月的覆盖类投诉工单（约250条）和自动路测弱覆盖点（约4000个点）数据为例，使用自动站址规划工具，可以在10分钟内输出站址规划，而人工规划则可能需要5个人一周左右的时间，大幅度提高规划工作效率。
（b）站址规划分析更方便快捷：
网络结构、地理信息、覆盖情况、投诉数据、规划站址等数据综合化GIS呈现。
（c）有效压降相关投诉，直击感知痛点。
经过4G网络后期的优化建设实际解决覆盖类投诉230件，有效提升感知，并获得用户的认可。
（2）维护故障响应迅速：
智慧化管控方案平均比全障工单系统提前6.34分钟发现并预警基站大面积退服。
预测准确率为43.63%。
（3）营销转化效益初显：
利用基于聚类分析的营销维系手段，明确了在投诉处理触点服务人员如何将投诉过客户升级为目标潜并进行一系列营销维系动作，提高了营销维系效率，在解决问题的同时最大化用户价值并转换为企业利润。
清单级推送：
利用该方法对历史（2月-9月）投诉用户进行关联匹配，找到623个潜在升级客户推送市场部做专题升级发展，通过一个多月的结果核查，发现其中21%的客户已经更改套餐或资费，其中改不限量套餐12%，较大提升了现网用户价值。
商机单传递：
存量维系：
2018年7月移动预处理专班共受理网络质量类申告用户数为7455，其中2017年10月有电信业务行为或有出账的用户为7369，在网率98.84%（在网率=有电信业务行为或有出账用户数/申告用户总数），离网率1.16%，远低于10月现网移动业务客户离网率4.38%；
三、基于Hadoop的智能感知申告处理服务平台
为此开发了“移动网络质量投诉管理系统”，通过该平台获取了电话和互联网渠道全息的移动网络质量需求，经过预处理触点的高效沟通和有效分析，将问题定性定界并高效传递给其他“建维优营服”相关支撑系统协同解决。
传统网络质量申告处理方法存在不足：
电信客户申告的传统预处理方法，需要多平台人工切换查询，并且根据多个指标综合判断，过程比较繁杂，处理的效率相对比较低下，标准依人而定，对预处理人员专业知识要求较高，预处理判断人为因素影响较大。
在此背景下，为了提高申告预处理效率，实现申告预处理步骤标准化和自动化，提出了基于hadoop的电信话单投诉自动预处理方法。
3.1感知申告处理与管控流程
（1）需求收集
目前预处理专班客服通过客服平台及互联网渠道收集客户问题及需求，为解决数据在多个业务系统中均可获取，但是未经过整合的问题。
通过数据接口，建立统一投诉数据仓库的方法将各业务系统中和分散在Web侧的投诉数据进行平台整合，全面监测用户投诉情况。
同时对投诉信息进行分词存储便于后期的客户研究分析。
（2）问题界定
网络问题的界定：
由于前台客服的受理量大、受理时长限制等原因导致有大量的非网络问题传递至预处理专班，利用专家分析法，形成典型案例知识库，通过故障位置、故障人数、故障现象的三维关联，排除网络问题。
无线问题的界定：
通过系统问题诊断，界定感知故障是否为无线问题。
（3）需求传递
将预处理为非网络问题的及时指导用户解决。
一般为客户终端和卡等外部原因的故障，预处理专班通过知识树的查找，指导用户进行相应操作解决故障。
将预处理为非无线网络问题的由后台复核岗重新核实并加派处理，保证客户的每一个问题都能直接处理。
将预处理中属无线网络问题的可远程优化或派发至各地市无线中心现场核实，并将最终处理结论入相应库进行下一步网络调整的实施。
（4）处理管控
短期解决：
预处理岗或地市网优人员通过优化调整或障碍处理后，预处理专班回访客户，督办解决。
短期不能解决：
进入远期规划，定时反馈进度。
转化为其他业务的补充服务，间接解决问题的同时升级客户价值。
图3.1申告处理与管控流程
3.2基于hadoop的申告自动预处理方法
图3.2申告自动预处理方法
本文设计了一个电信话单投诉预处理系统，电信客服人员通过电信客户的投诉获取得到原始的投诉信息，然后将原始信息录入到投诉系统。
经过系统的自动处理，查询Hbase数据库获取该客户的话单信息并对客户进行定位，结合原始信息里面的投诉地点信息能够判断用户投诉地点附近的基站运行状况、覆盖状况、性能状况和投诉状况等信息，通过数据关联分析定位得出本次投诉的预处理判断结果。
预判结果采用主要原因和次要原因组合的方式，主原因定义为能够根本解决投诉现象，次原因为可以改善投诉现象。
（1）关联小区
（a）话单关联小区
根据投诉号码查询话单，查问题发生时刻前4小时内的前20条（最多20条）通话记录，取记录中的接入及释放小区并去重。
小区接入距离及信号强度取其平均值。
如下示例，投诉问题发生时间为15：
31，则话单搜索时间范围为13:
00-15:
59，搜索出话单按时间排序，groupby小区求平均距离/ECIO和连接次数，得到话单（类型I）关联小区列表。
（b）地理关联小区
根据用户投诉地址描述转化得到经纬度，所搜一定范围内且处于在主覆盖方向内的小区.记做类型II关联小区。
（c）将类型I和类型II中的小区去重，形成最简投诉关联小区列表，作为后续故障和性能的查询对象，该表仅在投诉分析过程中存在，不要求显示和存储。
（2）关联栅格
查找投诉预处理记录表，得到与投诉单号对应的投诉记录，提取该条记录中的经纬度信息，以虚拟坐标系的原点坐标经纬度为基准，计算出命中栅格的编号，根据栅格编号查找栅格数据库表，获得该栅格的信息。
处理的过程如图3.3所示，根据用户的投诉信息，获取其中的地点信息，如果没有地点或者该地点不能转为经纬度信息，就无法确定投诉栅格的信息，就退出该模块的处理。
图3.3关联栅格获取过程
如果有经纬度信息，那么就可以根据经纬度计算精确匹配得到栅格的编号，最后得到投诉栅格的信息。
也就是投诉地附近的话务热度和覆盖质量等信息。
（3）关联故障
搜索故障记录生成（入库）时刻在投诉时刻前N小时范围内，关联小区（基站）的故障信息。
可配置故障信息过滤器，目前过滤规则为查询并显示[alarmlevel!
=major且alarmtype!
=EQUIPMENT_MALFUNCTION]的所有告警。
经过搜索和过滤后，得到投诉关联小区故障记录信息。
图3.4小区故障获取过程
如图3.4，关联小区故障获取过程，先是获取关联小区列表，如果这次投诉都无法获取得到关联小区，也就没有了故障查询的操作了。
找到关联小区后，就根据关联小区的编号信息问题发生时间、和时间范围，查故障信息表得到关联基站的故障信息。
若无故障，则返回无故障信息。
处理结束之后，最后退出故障查询模块函数。
（4）关联小区性能预警
按小区统计每天的【C10.3业务信道承载的话务量（含切换）】之和，【C10.2业务信道拥塞次数（含切换）】之和，【1X:
RSSI均值（主集）】最小值。
对单一小区性能记录分析和性能预警分析子项打标后，根据各个关联小区的性能标签，按RSSI>
BLOCK>
SLEEP>
GOOD的顺序覆盖然后生成性能预警分析子项的整体标签。
图3.5小区性能预警获取过程
如图3.5，先是获取关联小区列表，如果这次投诉都无法获取得到关联小区，也就没有了小区性能预警查询的操作了。
找到关联小区后，就根据关联小区的编号信息问题发生时间、和时间范围，查故障信息表得到关联小区性能预警信息。
若无小区性能预警，则返回无小区性能预警信息。
处理结束之后，最后退出小区性能预警查询模块函数。
小区的性能预警获取过程与故障获取十分类型，过程几乎是一样的。
区别在于性能预警找到预警信息之后，还要判断并分类别RSSI、BLOCK、SLEEP和GOOD。
最后取得是这四种中某一种类型。
（5）关联话单
（a）话单关键字段
话单数据字段长度分为两种形式的数据。
一种数据只含有164个字段，一种含有317个字段。
其中164字段长度的数据中，这类数据大致是呼叫失败的话单。
通过数据库的聚合查询，在164字段长度的数据中大部分的数据完全没有任何基站信息。
剩下的行数仅仅存在一些基本的基站信息，这些信息无法进行定位操作。
将数据分为两大类，一类是164字段长度的数据，一类是317字段长度的数据。
317字段长度的数据占比较大，且数据重要性高，作为重点进行分析。
话单基本信息，1-164字段。
类别二：
基站详细信息，164-317字段。
每个记录行都至少有话单基本信息，无论该话单是否呼叫成功，只要呼叫了就会有该话单基本信息。
提取出164个字段中的一些重要字段进行分析。
这些字段如下表3.1所示：
表3.1部分话单字段含义表
序号
话单字段
字段含义
1
A3
通话开始时间
2
A4
通话总时长，单位毫秒
3
A6
主叫用户号码
4
A10
建立通话的时候的基站编号
5
A11
建立通话的时候的所在扇区（一共有3个扇区，每个扇区120°
）
6
A14
结束通话的时候的基站编号
7
A15
结束通话的时候的所在扇区（一共有3个扇区，每个扇区120°
8
A21
基站切换数量
9
A49
通话是否建立（类型一的数据该字段为0，表示未建立通话！
10
A52
被叫用户号码
11
A84
通话建立时间
12
A140
初始基站通话时间
13
A141
最后基站通话时间
（b）话单分析
根据投诉号码查询话单，查问题发生时刻前N小时内的前20条（最多20条）通话记录并解析，默认显示异常事件记录。
图3.6关联话单分析过程
如图3.6，话单分析过程所示，根据用户的投诉号码，查询HBase数据可以获得其在一段时间内对应话单记录。
接着根据这些话单记录中含有的基站信息进行定位，得到用户最近通话时候所处的地点。
然后分析话单是否属于异常类型，如果是异常话单就进而分别出其所属类型。
计算话单的距离、信号质量、CFC、CFCQ、接入导频、接入基站、释放导频、释放基站和通话时间时长等信息。
（6）基于hadoop的源数据采集
源数据采集子系统由脚本文件定时读取并且处理，处理之后的数据主要分为两大类，一类是话单数据，另一类的基站数据。
话单数据保存在HBase，基站数据、包括基站信息数据、基站故障数据和基站性能预警数据，则保存在Mysql数据库。
H
升级会员 