数据挖掘失败的根源

出租车司机识别模型是去年我们接到的一个挖掘需求，这个案例经历了数据挖掘工作几乎所有的挑战（除了算法），这里笔者结合这个案例系统梳理下这些挑战，并尝试给出这些挑战的深层次原因和解决建议。

1、目标难以达成事实上的共识

去年接到出租车司机识别挖掘需求的时候，自己并不知道对方的预期是多少，就急着安排人员去推进，这个为后续的模型反复埋下了祸根，你会发现，建模师不停的改，业务人员不停的提要求，启启停停，没有尽头。

直到最近才摸到了业务人员的底线，比如达到XX%的准确率可投入生产，但为什么开始的目标没有定呢，想来有三个原因：

第一、业务人员提数据挖掘需求的时候应该是有个大致预期的，理论上需要有成本的考量，比如数据达到多高的精度才能cover住这次营销的投放成本，但业务人员总是会想越高越好。

第二、建模方在实际探索前很难给出准确的预估，因为缺乏足够的依据，互联网公司可能会好一点，毕竟它们有大量的历史经验值可以参考，但对于大多数公司来讲没有。

第三、数据挖掘的结果是个概率值，比如要准确一点，覆盖率就会降低一点，这种数据上的“弹性”使得双方要达成目标上的共识更困难了。

因此笔者经历的大多数的数据挖掘其实是在未达成业务目标共识的前提下开展探索的，业务人员期待着一个最好的结果，建模师则抱着试试看得心态。

经验告诉我，为了节省你团队宝贵的挖掘资源，启动一个数据挖掘工作事先还是要尽量与业务方达成一个共识，比如业务上能容忍的底线是多少，这个业务方应是有数的，或者是有办法给出的（比如基于历史的营销经验等等），否则就不会提所谓的精准需求了，不愿意认真对待目标的业务方不值得接收他的需求。

业务目标达成共识后，一个很大的好处是对于建模师的工作有个基本的指引，比如第一次挖掘的结果如果大大低于最低目标，就要考虑是否建模方法上出现了重大偏差，或者是数据质量不足以支持目标的达成，或者直接升级问题说明情况，没有基本预期的建模师有点像无头的苍蝇，走到哪算到哪。

2、缺乏生产验证的方案和业务承诺

出租车司机模型的第一个版本出来后，建模师希望立刻去做验证，但业务方告知外呼验证需要排期，大概要等1-2个礼拜才能拿到确认的结果，这种情况在企业内司空见惯。

为什么互联网公司的数据挖掘效率就比较高呢？笔者觉得一个主要原因就是其具备的在线AB测试的能力，大多数传统企业尚不具备这种快速发布模型并进行生产验证的条件。

为什么？

因为大多企业的营销投放流程有大量的线下、人工环节，做一次精准营销的投放代价很大，流程也很长，而这个跟数据挖掘的快速迭代要求相悖。

机器学习、人工智能面临的最大挑战就是先进的生产力跟企业的落后的生产关系的矛盾，你要让数据挖掘快速迭代就意味着要重塑企业的营销管理流程，这个谈何容易。

但即使是这样，我们因地制宜也有提升的空间。

既然企业投放生产的限制条件这么多，那么就要未雨绸缪，提前给出模型大致的发布时间和验证方案，业务人员提前做好准备，比如配备的渠道、产品和政策资源等等，这样就能改善问题。

双方都应该为数据挖掘的快速推进承担具体的责任，很多数据挖掘无法快速推进往往是前端的业务问题（比如协调不动相关资源），这个时候就要升级问题，而不是到时再说。

3、缺乏有效的信息获取方式

出租车司机模型迭代了四个版本，每个版本最大的变化是什么呢？

笔者发现并不是算法做了什么变更，参数做了多大的调优，而是在于随着数据探索和业务理解的深入，特征的选择增加了，特征变量的表征加强了。

在一次分享会上，笔者特意就出租车司机识别的特征变量选择随机问了部分团队成员（1分钟内），如果让你去做建模，你会选择哪些影响变量？

一位产品经理回答了5个，一位开发工程师回答了3个。

然后笔者在3500人的9个微信群提出了同样的问题，共有15位热心的群友给出了回复，他们提供了多少变量？

30个。

顶级的信息获取能力，就是让全网的数据从业者为你贡献智慧。

笔者在《数据挖掘军规》一文中提出了一系列管理提升的建议，重要的一点就是确保你能站在巨人的肩膀上去做事，你一定要想到自己的业务常识肯定受限于自己的经历，因此一定要善于采用各种手段从外部获取更多的信息，在参数调优阶段你可以做孤独的舞者，但在方案设计阶段，一定要努力成为一个连接者。

下图显示了某个版本的部分变量选择示意：

4、缺乏足够的数据分析经验

我们发现前三次的模型中存在大量的误识别问题，比如外卖员、物流配送人员、公交车、班车司机有很高的概率被识别成出租车司机，建模人员还是习惯于用技术的手段去解决这种问题，但调优的结果往往并不是很好。

有的建模师就会沮丧的说已经做到极致了，真的提升不了了，但事实真的是这样？

笔者做过数据分析，发现很多数据建模师其实缺乏足够的数据分析训练，不善于采用比较鉴别的手段去洞悉数据上的一些规律，自己写过一篇文章《经验，套路还是逻辑？从我的一次数据分析经历中能得到什么？》说过分析的方法，建模师会算法、会调参不等于会数据分析，而数据分析能锻炼你的常识能力，比如数据的敏感度。

下面的视频显示了出租车司机、外卖员、物流配送人员、公交车、班车司机在轨迹上的特征，其实很容易分析出之间的差异，然后设计合适的指标去表征这个差异，比如：出租车司机的活动轨迹、不固定、较杂乱，外卖员有较固定的轨迹发散点，公交车、班车司机则有较固定的活动区域、活动轨迹、往返点等等。

出租车司机典型路径

外卖员典型路径

公交车司机典型路径

下图示例了用新的位置变量来表征正负样本活动区域的不固定性程度，很好的解决了误识别问题。

5、缺乏足够的数据质量稽核

在第四次建模的时候我们发现了大量的样本问题，比如在业务部门提供的2148个司机原始清单中，近20%的司机位置轨迹行为不显著，处于低水平，甚至有60余人无行动轨迹，核实发现很多人的确曾经是滴滴司机，但已经不干了，样本的时效性问题突出。

即使是将前三次外呼的结果作为样本，也发现在84个正样本中，还有25个正样本活动轨迹非出租车司机，谁都无法保证外呼的结果是绝对准确的。

因此，相对于互联网较好的在线数据，传统企业的数据建模师其实面临更多的数据质量的挑战，只要有业务验证的可能，就要对于样本进行常识的分析和判断，机械的进行样本清洗、过滤和转化是简单的，但如果样本的真实性出现了问题，那是比较致命的。

数据建模师对一切数据都要持怀疑态度，然后老老实实的去验证，不要想着走捷径。

6、缺乏合理的机制流程保障

出租车司机的四次模型迭代，并不是依靠团队力量的一个有机协调的逐步推进的一个过程，而是非常混乱的，无论是目标的设定，设计的评审，效果的反馈，后续的优化，都存在管理的缺位。

虽然数据建模师似乎也能称为码农，但其并不是纯粹意义上的码农，你会看到大多数企业的数据建模师实际要兼顾开发者、建模者、分析者、运营者等诸多角色，笔者写过一篇文章《数据挖掘师，要从一个人活成一支队伍》说明过这个道理，这些角色要完成工作需要依赖大量的周边资源，这个需要机制和流程的保障。

因此笔者近期写了篇《数据挖掘军规》的文章，列出了数据挖掘中的一些关键节需要在流程上进行强行的控制，确保其能够高效低成本的进行，包括需求可行性汇报、设计方案汇报、问题升级汇报、试点结果汇报、推广评估汇报等等，下面是一张流程图示意，请仔细研读。

当然数据挖掘失败的原因远不止于上面提到的这些，从技术的角度来讲还有更多，但考虑到大多数企业基于数据挖掘驱动业务还处于起步阶段，在大多的应用场景，算法能力的高低还没有成为决定性的因素，我们可以考虑先把上面提到的一些低垂的果实摘了，然后再对算法去攻坚克难，这可能是性价比更高的方式。

作者：傅一平 （微信号：fuyipingmnb）