如何打造敏捷的数据挖掘能力?


作者:傅一平
大家都知道数据挖掘是发现规律的一种手段,但在很多传统企业里数据挖掘有点像奢侈品,因为数据挖掘的过程一般较长,总体来讲性价比不是那么高,规则取数往往成为了企业数据驱动业务的主流。

笔者一直在思考传统企业敏捷数据挖掘的可能性,这里主要从挖掘引擎、数据准备、训练方法、迭代方式、产品思维等方面进行阐述,希望于你有启示。

1、打造全流程挖掘引擎

诸如阿里等企业的机器学习平台逐步形成了一个自有生态,其机器学习引擎一般是跟企业的整个IT环境无缝集成的,无论是在数据准备、数据输入、算法选择、模型训练、模型输出或是生产部署等各个阶段。

商用的数据挖掘引擎则一般只能做点的事情,强调的是算法的多样选择及模型训练的可视化体验,在数据准备、数据输入、模型输出、生产发布等数据挖掘的其它阶段是游离在之外的,需要跟企业的数据环境进行交互才能完成一个数据挖掘过程,而这些交互一般不是自动的,也不具备可视化能力,这造成了整个数据挖掘流程的割裂,而企业在这些阶段花费的代价是很大的。

随着一般算法使用门槛的降低,当前商用挖掘引擎都在朝着人工智能算法+海量计算平台化方向转变,但其并不会变得更敏捷,因为整个流程仍然是割裂的。

怎么办?

一种就是全套采用诸如阿里云的方案,全部数据上云,还有一种就是自己定制,这里谈谈定制方法的思路。

所谓的定制方法就是将通用的数据挖掘引擎跟企业自身的数据开发管理平台无缝集成,复用原有企业的数据开发整个流程,以下一张图道尽了一切:

大数据_数据分析_数据挖掘

它的价值点就在于以企业的数据开发流程为核心,而不是数据挖掘为核心,数据挖掘只是作为一个组件集成进来,比如封装R和Python的训练结果,最大限度的复用原有数据管理的能力。

因此,企业在采购商用数据挖掘软件的时候,除了考虑算法,还要强调开放性,要考虑是否能深度集成到自身的数据环境中。

这是敏捷的第一个要点。

2、降低变量准备时间

数据挖掘中数据准备时间过长,企业除了考虑数据仓库建模,还需要考虑是否在此基础上建立一个数据挖掘的数据中台,笔者在《企业的数据中台的价值》、《数据中台到底是什么?》、《如何清晰的实施“大中台,小前台” 大数据运营策略?》等文章中系统的介绍过数据中台的价值,数据挖掘中台属于数据中台的一部分,行业特性会比较明显,比如电商有电商的数据挖掘中台,运营商则有运营商的数据挖掘中台,只要你在某个行业数据挖掘做多了,变量准备做多了,你自然会找到一些共性的东西,如果能把它们沉淀下来,就能降低变量准备时间,比如在运营商中经常会设计平均ARPU这个变量,但到底是三个月平均,六个月平均还是什么,全赖历史经验。

建立数据挖掘中台涉及IT战略问题,对于传统被动型的数据管理机制流程都是挑战,比如要建立一支中台团队就不容易。

这是敏捷的第二个要点。

3、选对模型提升的方法

一般来讲,如果数据不变,数据挖掘训练的边际效益并不高,同样的一份数据用不同的算法反复训练,比如F1差值并不是很大大,如果要尽快的提升模型的效果,要讲究点方法,尽量遵循以下优先级:业务>数据>算法。

没有深刻的业务理解去做数据挖掘往往是事倍功半,行业的业务理解越透彻,就越能抓住数据中本质的特征,诸如图像识别等场景已经可以靠神经网络来自动查找特征了,但大多数行业领域不行,还是要靠业务专家,多组织一次讨论获取的灵感可能远远好过于在算法上折腾一个月。

没有更多更好的数据去训练模型,巧妇也难为无米之炊,一定要相信数据的重要性远远超过算法,很多初级的建模师算法能力很强,但就是做不成事,往往是因为其对于自身企业的数据理解太浅所致,外来的和尚念不好经也是这个道理。

一般企业的数据挖掘师都需要通过长时间的取数训练,如果能做过数据仓库的更好,这样对于企业的数据体系有个全局的认识,在特征选择时有更多的发挥空间,大数据中最强调的一个特征是维度多,也一定程度说明了数据多样的重要性。

比如基于运营商的语音通话数据可以初步判定欺诈电话,但这个准确率还不高,如果加上社交网络数据,判定就八九不离十了,这就是多维数据的力量,同时数据建模师如果不理解运营商的业务和数据,则可能无法想到这个维度。

这是敏捷的第三个要点。

4、快速迭代及时止损

大家都知道建模需要快速迭代,但传统企业中数据挖掘的快速迭代总是起不来,原因当然很多,包括渠道问题、沟通问题,流程问题,外包问题,机制问题等等,这里笔者提一个数据挖掘“四个一”原则,即要为数据挖掘设置一些时间底线。

第一个“一”是一线沟通,就是业务理解要跟生产人员沟通,而不要只跟管理者沟通,确保能够听到一线真实的炮声。

第二个“一”是一周训练,整个模型的训练需要控制在一周完成(注意不是算法研发),如果训练倒腾超过一个月,性价比一般很低。

第三个“一”是一周验证,训练的结果要在一周内让一线反馈结果,传统企业模型做不好往往是第一时间拿不到反馈数据所致,这牵涉到企业复杂的线下执行流程,需要在管理层面进行控制。

第四个“一”是一周优化,确保能用反馈的数据进行模型的快速优化,第三和第四反复迭代。

当然这里的一周更多是象征意义,企业可以基于自身的实际进行周期的调整,关键是要有成本意识,及时止损,时间拖的越长风险越高,因为市场变化很快,业务人员的耐心有限。

这是敏捷的第四个要点。

5、通过运营保有挖掘资产

据笔者统计,离网模型在某些企业做的次数会超过几十次,重做有很多理由,比如市场环境变了,原来模型不好用了等等,但重做意味着对原有投入资源的极大浪费,是最大的不敏捷。

“重建设,轻运营”是企业IT建设常见的毛病,由于数据挖掘的模型受业务和数据变化的影响很大,随着时间推移效果下降是必然的事情,而且这个折损跟固定资产折损还不一样,人家折损好歹还能正常用,但模型效果变差就意味着效益变差,模型更要拼运营能力。

从这个角度看,如果你觉得一个模型重要,就要把它当成一个产品,用产品化的思维去运营它,比如设置独立的模型经理,从用户、流量和效果等角度去持续的做提升,很多企业模型建完推广完了就成鸟兽散,这注定了模型的悲剧。

模型运营投入的代价是巨大的,一个有1000个挖掘模型的公司,负担和压力会非常大,如果很轻松,基本也就是些僵尸模型了。

这是敏捷的第五个要点。

就谈以上五点,一家之言,但的确是感到困惑且想解决的,希望于你有启示。
来源:与数据同行