数据挖掘中易犯的几大错误

数据库
数据挖掘是一种技术,它将传统的数据分析方法与处理大量数据的复杂算法相结合。那么这些易犯的错误,你犯过吗?

按照Elder博士的总结,这几大易犯错误包括:

  •  缺乏数据(Lack Data)
  •  太关注训练(Focus on Training)
  •  只依赖一项技术(Rely on One Technique)
  •  提错了问题(Ask the Wrong Question)
  •  只靠数据来说话(Listen (only) to the Data)
  •  使用了未来的信息(Accept Leaks from the Future)
  •  抛弃了不该忽略的案例(Discount Pesky Cases)
  •  轻信预测(Extrapolate)
  •  试图回答所有问题(Answer Every Inquiry)
  •  随便地进行抽样(Sample Casually)
  •  太相信最佳模型(Believe the Best Model)

0. 缺乏数据(Lack Data)

对于分类问题或预估问题来说,常常缺乏准确标注的案例。

例如:

-欺诈侦测(Fraud Detection):在上百万的交易中,可能只有屈指可数的欺诈交易,还有很多的欺诈交易没有被正确标注出来,这就需要在建模前花费大量人力来修正。

-信用评分(Credit Scoring):需要对潜在的高风险客户进行长期跟踪(比如两年),从而积累足够的评分样本。

1. 太关注训练(Focus on Training)

IDMer:就象体育训练中越来越注重实战训练,因为单纯的封闭式训练常常会训练时状态神勇,比赛时一塌糊涂。

实际上,只有样本外数据上的模型评分结果才真正有用!(否则的话,直接用参照表好了!)

例如:

-癌症检测(Cancer detection):MD Anderson的医生和研究人员(1993)使用神经网络来进行癌症检测,惊奇地发现,训练时间越长(从几天延长至数周),对训练集的性能改善非常轻微,但在测试集上的性能却明显下降。

-机器学习或计算机科学研究者常常试图让模型在已知数据上表现最优,这样做的结果通常会导致过度拟合(overfit)。

解决方法:

解决这个问题的典型方法是重抽样(Re-Sampling)。重抽样技术包括:bootstrap、cross-validation、jackknife、leave-one-out...等等。

2. 只依赖一项技术(Rely on One Technique)

IDMer:这个错误和第10种错误有相通之处,请同时参照其解决方法。没有对比也就没有所谓的好坏,辩证法的思想在此体现无遗。

“当小孩子手拿一把锤子时,整个世界看起来就是一枚钉子。”要想让工作尽善尽美,就需要一套完整的工具箱。

不要简单地信赖你用单个方法分析的结果,至少要和传统方法(比如线性回归或线性判别分析)做个比较。

研究结果:按照《神经网络》期刊的统计,在过去3年来,只有1/6的文章中做到了上述两点。也就是说,在独立于训练样本之外的测试集上进行了开集测试,并与其它广泛采用的方法进行了对比。

解决方法:

使用一系列好的工具和方法。(每种工具或方法可能最多带来5%~10%的改进)。

3. 提错了问题(Ask the Wrong Question)

IDMer:一般在分类算法中都会给出分类精度作为衡量模型好坏的标准,但在实际项目中我们却几乎不看这个指标。为什么?因为那不是我们关注的目标。

a)项目的目标:一定要锁定正确的目标

例如:

欺诈侦测(关注的是正例!)(Shannon实验室在国际长途电话上的分析):不要试图在一般的通话中把欺诈和非欺诈行为分类出来,重点应放在如何描述正常通话的特征,然后据此发现异常通话行为。

b)模型的目标:让计算机去做你希望它做的事

大多数研究人员会沉迷于模型的收敛性来尽量降低误差,这样让他们可以获得数学上的美感。但更应该让计算机做的事情应该是如何改善业务,而不是仅仅侧重模型计算上的精度。

4. 只靠数据来说话(Listen (only) to the Data)

IDMer:“让数据说话”没有错,关键是还要记得另一句话:兼听则明,偏听则暗!如果数据+工具就可以解决问题的话,还要人做什么呢?

4a.投机取巧的数据:数据本身只能帮助分析人员找到什么是显著的结果,但它并不能告诉你结果是对还是错。

4b.经过设计的实验:某些实验设计中掺杂了人为的成分,这样的实验结果也常常不可信。

5. 使用了未来的信息(Accept Leaks from the Future)

IDMer:看似不可能,却是实际中很容易犯的错误,特别是你面对成千上万个变量的时候。认真、仔细、有条理是数据挖掘人员的基本要求。

预报(Forecast)示例:预报芝加哥银行在某天的利率,使用神经网络建模,模型的准确率达到95%。但在模型中却使用了该天的利率作为输入变量。

金融业中的预报示例:使用3日的移动平均来预报,但却把移动平均的中点设在今天。

解决方法:

要仔细查看那些让结果表现得异常好的变量,这些变量有可能是不应该使用,或者不应该直接使用的。

给数据加上时间戳,避免被误用。

#p#

6. 抛弃了不该忽略的案例(Discount Pesky Cases)

IDMer:到底是“宁为鸡头,不为凤尾”,还是“大隐隐于市,小隐隐于野”?不同的人生态度可以有同样精彩的人生,不同的数据也可能蕴含同样重要的价值。

异常值可能会导致错误的结果(比如价格中的小数点标错了),但也可能是问题的答案(比如臭氧洞)。所以需要仔细检查这些异常。

研究中最让激动的话语不是“啊哈!”,而是“这就有点奇怪了……”

数据中的不一致性有可能会是解决问题的线索,深挖下去也许可以解决一个大的业务问题。

例如:

在直邮营销中,在对家庭地址的合并和清洗过程中发现的数据不一致,反而可能是新的营销机会。

解决方法:

可视化可以帮助你分析大量的假设是否成立。

7. 轻信预测(Extrapolate)

IDMer:依然是辩证法中的观点,事物都是不断发展变化的。

人们常常在经验不多的时候轻易得出一些结论。

即便发现了一些反例,人们也不太愿意放弃原先的想法。

维度咒语:在低维度上的直觉,放在高维度空间中,常常是毫无意义的。

解决方法:

进化论。没有正确的结论,只有越来越准确的结论。

8. 试图回答所有问题(Answer Every Inquiry)

IDMer:有点像我爬山时鼓励自己的一句话“我不知道什么时候能登上山峰,但我知道爬一步就离终点近一步。”

“不知道”是一种有意义的模型结果。

模型也许无法100%准确回答问题,但至少可以帮我们估计出现某种结果的可能性。

9. 随便地进行抽样(Sample Casually)

9a 降低抽样水平。例如,MD直邮公司进行响应预测分析,但发现数据集中的不响应客户占比太高(总共一百万直邮客户,其中超过99%的人未对营销做出响应)。于是建模人员做了如下抽样:把所有响应者放入样本集,然后在所有不响应者中进行系统抽样,即每隔10人抽一个放入样本集,直到样本集达到10万人。但模型居然得出如下规则:凡是居住在Ketchikan、Wrangell和Ward Cove Alaska的人都会响应营销。这显然是有问题的结论。(问题就出在这种抽样方法上,因为原始数据集已经按照邮政编码排序,上面这三个地区中不响应者未能被抽取到样本集中,故此得出了这种结论)。

解决方法:“喝前摇一摇!”先打乱原始数据集中的顺序,从而保证抽样的随机性。

9b 提高抽样水平。例如,在信用评分中,因为违约客户的占比一般都非常低,所以在建模时常常会人为调高违约客户的占比(比如把这些违约客户的权重提高5倍)。建模中发现,随着模型越来越复杂,判别违约客户的准确率也越来越高,但对正常客户的误判率也随之升高。(问题出在数据集的划分上。在把原始数据集划分为训练集和测试集时,原始数据集中违约客户的权重已经被提高过了)

解决方法:先进行数据集划分,然后再提高训练集中违约客户的权重。

10. 太相信最佳模型(Believe the Best Model)

IDMer:还是那句老话-“没有最好,只有更好!”

可解释性并不一定总是必要的。看起来并不完全正确或者可以解释的模型,有时也会有用。

“最佳”模型中使用的一些变量,会分散人们太多的注意力。(不可解释性有时也是一个优点)

一般来说,很多变量看起来彼此都很相似,而最佳模型的结构看上去也千差万别,无迹可循。但需注意的是,结构上相似并不意味着功能上也相似。

解决方法:把多个模型集装起来可能会带来更好更稳定的结果。

【编辑推荐】

  1. 代号:Denali,SQL Server再出击
  2. 说说SQL Server编年史
  3. 简单说说SQL Server上的加密术
  4. 擦亮自己的眼睛去看SQL Server
责任编辑:艾婧 来源: suokun的博客
相关推荐

2014-06-23 09:41:28

数据挖掘

2014-06-24 09:23:03

数据挖掘

2015-05-21 09:24:13

生成树生成树协议STP

2009-01-05 18:53:53

服务器管理

2022-06-20 08:02:20

架构

2022-06-20 14:08:32

企业数据转型IT

2013-08-20 10:56:08

BashBash编程Bash错误

2015-01-26 14:46:13

数据中心迁移

2012-03-14 09:38:36

网络布线

2012-09-10 09:43:21

编程编程学习编程错误

2016-10-13 10:07:00

网络布线错误

2010-11-09 10:43:14

面试

2012-06-18 09:20:38

亚马逊云服务Amazon

2013-10-10 11:04:41

虚拟化建设

2016-01-11 11:32:41

Java程序员错误

2015-06-03 13:54:37

JavaScript小错误

2024-05-08 12:41:29

Python编程语言

2012-12-18 10:09:26

虚拟化应用错误

2017-06-27 10:39:20

机器学习易犯错误

2012-09-13 09:33:46

创业团队体验
点赞
收藏

51CTO技术栈公众号