数据挖掘，想说爱你并不容易

随着大数据平台建设在各个领域的展开，人们越来越关心一个问题：基于大数据技术能带来哪些新的应用类型，进而为客户带来新的价值增长点？要回答这个问题，有关数据挖掘方面的讨论是一个不可回避的，但是数据挖掘，在应用层面引起的争议也是非常大的。

数据挖掘，在应用层面之所以争议很大，主要还是理想与现实之间的距离太大，“Amazon的商品推荐”、“沃尔玛啤酒与尿布”、“Netfix的纸牌屋”等例子当前阶段还经常有些人提到，所以不少人对数据挖掘提出了质疑：能不能有点新鲜的事情，以后还能不能愉快的玩耍了

当前大部分人对数据挖掘的理解还是停留在下面这个图的阶段：数据挖掘等于算法!

为什么因为算法在数据挖掘应用中的重要性相对于其它类型的应用要高很多。同时算法实现中涉及到的复杂的数学知识，又提升了它在人们心中的神秘感，进而产生好奇感(因为大部分人日常需要的数据知识，小学阶段就学完了);当然也有部分人士已意识到分析模型的重要性，但对最终的商业理解和价值变现这一块依然缺少应有的重视。正是这认识上的偏差，重技术偏商用，导致了数据挖掘应用在落地环节上的失败。

这里先把具体问题放在一边，我们还是以终为始的方式来思考数据挖掘应用。

首先，需要明确数据挖掘项目成功的标准是什么

成功的数据挖掘项目，要求分析模型、业务模型是可解释的，并在实际业务中得到使用。

数据挖掘项目，不应该只是一项很炫的技术展现。只有客户在处理日常业务时，应用到了分析系统输出的数据或模型时，才算是成功的。这个标准对一般应用，是一个基本要求，但对数据挖掘应用来说，却是一件难事。

一般应用，需求方和实施方，对数据的输入、输出、中间主要处理过程，理解是一致的。而数据挖掘应用，对系统的输出及中间的处理过程，要求实施方对需求方进行详细解释并得到需求方发自内心的认可，然后，在后续的系统中才有可能得到应用。举个例子：

银行信用卡欺诈识别系统中，一个分析系统通过建模、学习，实施等过程，最后输出一批名单，告诉银行客户经理，这些人的近期交易记录非常可疑。客户经理就会问，可能性有多大可能性太少没有价值，可能性很大，但总有误报的可能吧，你的模型是怎样的，为什么认为这些人的行为可疑，等等。而现实情况是,对分析模型的解释，有某些场合，甚至是关键算法的设计者都难以给大家一个满意的答案，所以才有了那名名言：在大数据时代，知道“是什么”就够了，没必要知道“为什么”。

再举个百度迁徙图例子，从数据的可视化方面，的确做的非常炫，但是进一步的思考，除了技术，这个迁徙图给相关部门带来了哪些决策参考，铁总能根据这个迁徙图，能够规划几条线路估计很难。迁徙图描述的只是一个现象，甚至是现象的一部分，譬如：南方到东北，选择在北京转乘的不在少数，转乘还可以分为，火车转火车，火车转汽车、汽车转飞机的等等，还有很大一部分是私家车、甚至是摩托车回家的，等等，这些迁徙图都已经考虑进去吗如果不能很好的回答，就不能轻易进行决策。

不知道前因后果，不能对客户的疑问提供满意的回答，客户是很难对数据建立信心的。所以在数据挖掘应用研发的各个阶段，需要牢记模型的可解释性，除非你在某个领域就是一个品牌了，譬如：SAS在金融领域的分析应用。

那么，什么是好的模型解释

好的模型解释应该与一个人读到一篇好文章的感觉一样：“人人心中有，个个笔下无”。好的模型解释，是大家都能看懂的，数据挖掘，解决的问题是现实中存在的，不在天上飞的。还是上面那个图，如果实施方从中间的分析模型为原点思考，最终的解释还是可能很技术性的，在客户那里还是很难得到认可。

所以好的模型解释，还是要以商业理解为基础，业务理解为支撑，但现实是实施人员基本属于技术型，对业务不熟悉，甚至对商业方面可能还有点排斥心理。为了让分析模型最终产生效益，技术人员必需深入了解业务，至少要与业务资深人士一起探索创建模型。

好的模型解释，在知识产权上存在一个悖论，模型毕竟是一个软件，这一点与文章还是有点不一样，你看到一篇好文章，抄一篇，对原作者不会带来任何影响。但对于软件产品，既然你说把原理说的这么清楚了，我就山寨一个，收益是大大的。

说到这，模型到底还要不要解释呀怎么和砖家一样一样的，有点晕了，我想“静静”了。

模型肯定是要解释的，主要区别是向谁解释，这个又和产品提供商的定位有关:

第一类，自产自销型

这类公司Amazon、Netfix是典型，他们的推荐系统只在内部使用，生产系统、分析系统自成一个闭环。说到底，自己能给自己讲明白就可以了。

第二类，细分市场重点突破型

典型的代表就是SAS，将分析模型直接做成面向不同分析需求的组件产品，内部分析过程就是一个黑盒子，留个客户能做的事情，就是选择合适的模型及模型效果的评估。SAS之前在金融分析领域有绝对的权威，近年在文本分析方面的能力也是突飞猛进。

其它公司都说好了，你还要什么解释