首页 观点正文

不完美的数据+不完美的方法=完美的数据产品

数据产品开发:不完美的完美

  从2007年开始和大批量数据打交道,到现在已经将近10年了。拿数据干过各种事情,搞科研做实验写论文、干工程编算法带项目,(不值一提的)活儿干了一大堆,玩的数据量也从百万级飙升到百亿级。虽然还是一只菜鸟,可是填过的坑已经数不胜数。对数据可以说爱恨交加。爱的是:有了数据,就有了非常多的可能性,数据中蕴涵着很多有趣的现象和规律,等着被发现;如果能发现并确认一些不为人所知的有趣的现象和规律,感觉非常美妙。恨的是,数据几乎没有不糟糕的,方法几乎没有合用的;有时候想干的事情没数据,或者数据糟糕得一塌糊涂;有时折腾很长时间,出来的结果和想象的完全不同。经常气得一点办法都没有。

  可是,入了数据分析这行,数据再烂,也要想着法子咬着牙把活儿干好。换个高大上的说法,就是:“不完美的数据 + 不完美的方法 = 完美的数据产品(论文也可以看成是一种数据产品)。这个等号怎么才能画上去?这里总结一下我的血泪史以及思(tu)考(cao),算是抛个砖,供大家参考。

  01、不完美的数据

  现实环境中产生的数据一定会有非常多的问题。人工采集的数据有问题,网上采集的数据有问题,从服务器后台直接拿的数据照样问题很多。每一份数据,拿到手之后,都得深入地评估这批数据的质量,对重复数据、空值、错误数据、数据的分布等等都要进行评估。评估完数据质量问题之后,需要清洗出一份合用的数据来。这个过程非常漫长和痛苦。然而,更痛苦的是,看到数据有致命缺陷,却无能为力。

  举个例子。在交易型数据的分析中,用户的很大一部分特征是从交易数据中抽取出来的。对于有大量记录的用户而言,特征比较容易抽取准确。而对于只有有限几条记录的用户,特征抽取就不靠谱了。举个例子,假如支付可以用现金和银行卡,我们可以统计一个“刷卡率”的指标。如果用户有1000条记录,刷卡率可以较为准确地统计出来;如果用户只有1条记录,刷卡率不是0%就是100%,这就扯得太厉害了。然而,如果我们把各种特征可能不准确的用户删掉,又往往删得过多,使得样本有偏。这个问题,我也没太好的解决办法,还求各位大神指点。

  上面的问题其实还好,因为这些问题在数据分析开始的时候就明确了。然而,有时样本有深层次的问题,直到数据分析工作完成才被发现。之前做过一个好友推荐算法,具体的实验是学生做的,设计的算法的准确度奇高,完美地干掉了所有的竞争对手。我有点怀疑这个结论,一直琢磨为什么我们的算法表现如此出众。苦思冥想了三四天,终于想明白,我们的数据集中,好友和非好友在某个抽取的特征上存在显著的差异,这个差异完全来自于数据集的缺陷,而不是别的原因。后来,这个好友推荐项目不得不搁置。

  02、不完美的方法

  All models are wrong.

  ——George Box

  常用的模型基本上就是两个套路。一种是回归分析(计量模型),侧重于解释性,预测能力一般都很差;另一种是机器学习模型,侧重于预测能力,解释性一般都不强。然而,不管是什么模型,都依赖于模型自身的假设,如正态、线性等等。

  以正态为例,很多统计指标、模型、方法总是假设正态分布。然而,绝大部分现实生活中的数据都不是正态。对数正态、幂律的可能性更高一些。对于这样的数据,传统的方法很有可能会出问题。举个例子,平均值是刻画正态分布特征的一个很好的指标,但是在幂律分布中,平均值是一个非常糟糕的指标。

  此外,预测模型的准确率一般都不会太高。在总体分析、趋势描述这些方面可能还可以用一用,但是到了针对个体的预测,准确率就不太理想。直接输出这样的预测结果给个体,很有可能会惹来不少麻烦。

  03、完美的数据产品

  然而,客户不会接受不准确的结果,读者(审稿人)也不会接受有漏洞的文章。我自己折腾了将近10年,慢慢地总算和数据能比较融洽地相处(其实是被数据折磨得没脾气了),慢慢地能(bei)够(po)接受:没有完美的数据,也没有完美的数据分析方法,更没有完美的数据分析结果,还得做出完美的数据产品,这就是数据分析民工的命。那么,如何基于不完美的数据和方法,开发完美的产品呢?

  1、划定边界——有所为,有所不为

  这里指的“边界”,既有功能边界,也有性能边界。

  先说功能边界。所有的算法,准确度都是大问题。这导致将算法应用于具体的场景时,需要做大量的工程优化,才能满足使用需求。例如,实验环境里的人脸识别技术已经能优于人工识别能力,但是这一基础是较高解析度的相片。在一些需要人脸识别的场景(如摄像头),图像解析度不高,人脸识别技术的性能就大打折扣。把人脸识别技术用于能采集到高清相片的场景,效果应当会不错。然而,把人脸识别技术用于街上的摄像头采集的图像,很可能就砸了自己的招牌。因此,对不同的应用场景得有敬畏之心,得划定数据产品的功能边界,不要轻易地跨出去。

  再说性能边界。这个道理其实很容易理解,每个方法/工具/系统都有它的极限,一般不能超出极限太多去使用。比如一个年轻的小伙子,身体非常棒,一次扛200斤都不成问题,你非得让他一次扛2吨,他一下子就被压死了。幸亏还能复活。复活了继续让他扛2吨,他就再被压死。一天被压死几十回,烦都烦死了。这个问题的解决办法很简单,不许这个小伙子一次扛超过200斤,就可以了。

  这个边界的问题非常重要。我最近在实验系统上倒腾一个规模非常庞大的数据集。入库的时候频频出问题。数据库系统被我搞得屡屡宕机。其实我用的数据库管理系统是一个非常成熟的商业系统,具有非常强悍的健壮性,但是也经不住那么大规模数据的折腾。实验系统倒也罢了。反正崩了就重新来过。但是作为一个数据产品,反复地崩溃重启,会导致用户严重怀疑系统的质量。与其这样,还不如在数据量过大时,系统直接拒绝请求,并提示数据量过多。虽然本质上没啥区别,但是用户会觉得这个不会反复宕机和重启的系统靠谱多了。

  道理虽然简单,但是在数据产品的开发中,很少有人注意这样的问题。不能只告诉用户能做什么,还要告诉用户不能做什么。

  2、输入商业模式——算法有所短,商业模式有所长

  基于大数据的计算机算法很难做到100%准确,因此还不能取代人类去做决策,只能辅助人类做决策。找准计算机算法的定位,开发出合适的商业模式,才能扭转算法不精确的问题。

  Farecast的案例是一个很不错的案例。尽管Farecast预测飞机票价涨跌的准确度只有70%左右,然而,把票价预测与类似保险的商业模式结合在一起,就可以比较完美地解决用户买便宜机票的问题。

  再例如,通过用户画像的手段可以判断出用户的购买能力。有些公司据此进行动态定价——对有钱的买家,设定较高的价格;对没钱的买家,设定较低的价格。事实证明,这是一个糟糕透顶的主意,骂声一片。另外一些公司根据用户购买能力进行商品推荐,给有钱的买家推荐较贵的商品(利润较高),而给没钱的买家推荐较便宜的商品(利润较低),效果是一样的,却可以得到买家的好评。

  3、界面设计——友好

  完美的数据产品除了良好的功能,还得有友好的界面。那什么叫友好?友好意味着更少的认知成本和更少的操作成本。

  对于数据可视化,友好的衡量标准不是好不好看,而是认知时间。有个原则叫5秒原则。看受众是不是能在5秒时间内读懂一幅图。5秒原则有些苛刻,但是可以用认知时间来衡量一个数据可视化产品的好坏。如果图已经展示了5分钟,观众还得费劲琢磨,这个图到底是什么意思,这样的可视化产品可以说是完全失败的。

  对于操作,衡量的标准不是菜单目录是不是整齐,而是操作步骤。比如说,想要的一个结果能不能在3次鼠标操作之内达到。举个例子,我们在拨打某些客服热线查账单的时候,经常要折腾几分钟,按好几次键。有些公司对客服热线的请求做了分析,根据拨打电话的时间和之前拨打的历史纪录,提供快捷通道,比如拨过去就听到“您的余额为xxx元”,省去漫长的等待和操作过程。

  此外,友好的界面还得有必要的信息提示。例如,启动一个计算以后,得提示用户执行的进度、预期的执行时间,屏幕上得有一些东西(比如葵花)在动,提示用户没死机。要不然,很容易被用户中断计算,提前退出。

  4、版本迭代——小版本、多批次

  这里的版本迭代,有两方面。一方面是产品的版本迭代;另一方面是开发过程中的版本迭代。

  一个工程项目往往分为很多个阶段,如果在每一个阶段都追求完美,就很容易掉入某一个坑中出不来。这个问题非常普遍。因此,比较倡导的做法是,先拉通,再优化。 所谓拉通,是指把功能从前到后实现一遍,做出一个原型。所谓优化,是指找出原型存在的问题,优化整个数据产品的表现。这个问题在项目管理和敏捷开发中讲得很多,这里就不赘述了。

  数据量太大的时候,每计算一轮都需要漫长的等待,因此数据产品的开发过程还需要另外一种形式的迭代,我称之为开发迭代三步曲:功能、效率、性能。第一步实现功能;第二步提升效率;第三步提高性能;之后才大规模计算。我以前干过各种傻事:写一段代码,丢进系统里,等一晚上,完全没动静,才发现循环语句没写对。程序写好,跑了老长一段时间(三四天),结果都出来了,发现程序写错了。后来学乖了,写完一段代码,先不真的执行,把关键执行步骤打印一遍,看看流程是否正确;再跑一个小规模的测试,评估一下执行效率,如果执行效率很低,要等很长时间,那就要修改程序,提升效率;最后,再评估一下小规模测试的结果,是否如预期。三个问题都有肯定的答案,才开始做大规模的计算。

  04、小结:

  总而言之,在数据产品开发的相关工作中,数据是不完美的,方法也是不完美的(数据和方法完美的可能性非常小),而我们还要交付完美的产品,这其实是非常有挑战的事情。 以结果为导向,合理地组合数据、方法与商业模式,才能给出完美的解决方案。这也是为什么大数据时代需要统计、计算机及管理专业的人员协同工作的原因。

  注:作者:刘跃文,版权著作权属原创者所有。编辑:Fynlch(王培),数据观微信公众号(ID:cbdioreview) ,欲了解更多大数据行业相关资讯,可搜索数据观(中国大数据产业观察网www.cbdio.com)进入查看。

责任编辑:王培

分享:
2022全数会
贵州

贵州大数据产业政策

贵州大数据产业动态

贵州大数据企业

更多
企业
更多