数据挖掘类竞赛经验总结与分享:人人都可以是赢家

随着天池穿衣搭配推荐比赛的结束,我也该暂且退出竞赛江湖,一心一意搞科研了。今年共参加了3场公开比赛,成绩虽不是特别好,但也还说的过去,在搞比赛上面花费了不少时间和精
力,耽误了不少事。如果有一天问自己这么辛苦玩这些和毕业要求无关的事值得吗?还是不自找麻烦纠结这些问题吧,呵呵,正道是——满纸荒唐言,一把辛酸泪;都云作者痴,谁解其中

味。

做竞赛有哪些好处?

1. 让你100%清楚哪些数据挖掘的算法在实际应用中最有效。有效包括效率和性能。很多人往往看了几章data mining的教程,就以为知道了数据挖掘是怎么一回事了。甚至在高端会议发过

一些paper的同学也有些停留在理论的乌托邦,最典型的例子就是他们觉得SVM是最好用的分类器。比赛往往采用工业界的数据,所以通过PK,我们可以很清楚的知道哪些算法好用,哪些参

数靠谱,以及自己和别人的差距。

2. 认识很多有意思的人。当然这个要求你排名越靠前越好了,毕竟人以群分嘛。 例如Kaggle 上可以和别人组队, 竞赛top k的team有可能被邀请去参加答辩,这些都是认识大牛,

多交流的好机会。
3. 提高自己快速写代码的能力。 要知道每场比赛你要实现很多很多的想法。 所以敲代码都是噼里啪啦的一挥而就,不会像做项目一样有code review, unit test什么的。我们都

讲究速成,一次到位。
4. 有钱赚。 这个好像比较难。 大牛人也不能保证每次都挤进前3名。 除了money, 还有积分, 比如天池的积分就可以换一些礼品。

坏处呢? 当然就是时间了。 做比赛真的是很费时间和体力。 人的时间是有限的,你在这里花的时间多了,做别的事就少了。

以上都是概括性的东西,各位看官也许就一笑而过,下面就来点详细的经验吧。 我会总结3场比赛的经验,每场的收获都或多或少有些不一样。

1. IJCAI 2015 competition http://tianchi.aliyun.com/datalab/introduction.htm?spm=5176.100075.5678.1.tYIFBT&id=1
很多主流的数据科学类学术会议都会有一个竞赛,例如KDD, ICDM, CIKM等。 它的特点是吸引很多有学术背景的同学来参赛。 获得较高名次的同学受邀去会场workshop 做报告。 今

年的IJCAI是阿里巴巴赞助的,这个比赛的内容是预测双十一的回头客。 这算是我参加的第一个公开竞赛吧。 说来有趣,也就是我的上一篇博客,“用R分析时间序列(time series)数

据”, 是为了参加微软内部一个time series 预测的比赛,现学现卖了一把,很走运地拿了第一名。 然后觉得做比赛很有挑战性,于是又搞了一把。 IJCAI比赛分两个赛季,第一赛季名次不是很靠前,只排第15. 前50名可以进入第二赛季。 第二赛季换了个平台,很幸运的得的第二名,拿了奖金去阿根廷玩了一把。 为什么说很幸运呢?因为第二赛季换了平台,提交的是MAPREDUCE类型的java程序包,它严格规定了程序的流程必须是提取feature-》指定分类器,参数-》得到预测结果。 也就是说,每个人只能选一种分类器,不能像第一赛季一样把多个分类器的结果融合。 而我的强项就是提取feature和选参数,这个时候我还很年轻,不懂得“融合大法”的厉害,所以说很幸运的得了第2.
什么是“融合大法”呢? 原来在做比赛的时候,光靠同一个算法产生的结果是不行的,必须要把多种算法的结果融合起来。 目前最好用的算法是GBDT,其中Xgboost工具包是最火的。 但是简单地把GBDT和 logistic regression的结果加权, 其性能会超过单个GBDT的。 所以一般人都是训练多个分类器,每个分类器都用不同的参数训练几组。 换句话说,不要只钟意于最好结果的那组模型,结果弱一点的模型/参数也不能放弃。 这就是典型的ensemble思想,从弱分类器中得到强分类器。
但是光在模型上做花样也是不行的,还需要在feature集上做花样。 用feature的全集训练的模型,效果无疑是最好的。 但是如果只取一部分feature,用这个部分feature集训练出一些弱一点的模型,再把它们全部融合起来,性能又可以提升。很神奇吧? 我也是在这次比赛结束后才明白这个“秘密”的。 写到这,各位读者是不是觉得做比赛确实很费时间和体力呢?
最后提一句,GBDT的参数,把learning rate尽可能调小,把num of tree 尽可能调大,这样单个DBGT的成绩就提高的比较明显。

2. Kaggle上的 Springleaf Marketing Response https://www.kaggle.com/c/springleaf-marketing-response
这个比赛的特点是钱多(总共10万美元),所以吸引了世界各地超过2000个队伍来争夺,其激烈程度一点不逊于KDD competition。 我最终排名14. 很遗憾是一个人在做比赛。这次的秘诀是不同的人的结果融合,所以一个team的成员数量越多,越有优势。 比赛结束的当天,我把我的结果和第10第11的人的融合,就超过了第2名的成绩了;再和第9名的融合,就超过冠军队的得分了。 事实上冠亚军也正是靠组队飚上去的。 当然我这是事后诸葛亮了,要及时醒悟这个道理也是一个难点。

这个比赛的特点是不告诉你每个feature的实际意义,只是给你一堆数据,让你从无知的概念中获取结果。 这次我充分吸取了IJCAI的经验,用了不同的算法,同一种算法用了不同的参数,也在不同的feature 子集上训练了模型。 其中值得一提的有两点:
1. 在第一次用GBDT预测之后,可以得到所有的feature的重要性。根据这个重要性从1开始编号,按照idx % 5 把所有feature划分成5份;同时再随机产生5份 feature 子集。 这10份feature 子集每一份得到的模型成绩都不是很高,只能排在400名左右,但是简单地把这10个结果平均一下,成绩就是前50了。很神奇吧! 我自己都惊呆了。 再和别的分类器融合融合,最终就是第14.
2. GBDT的参数,还是按照把learning rate尽可能调小,把num of tree 尽可能调大的原则,这样单个GBDT就够让我的机器跑5个小时了,要知道如上所述,我只用80%的feature就能排在400/2200名,说明大部分用户是不懂得如何调参数或者选分类器的。 (我的参数举例:12000 trees , step size=0.02)

期间我还设计过许多高级的算法,例如用deep learning加工feature, 定义不同的算子来产生/加工raw feature等等,然而并没有什么卵用,这里就不装了。

3. 天池 穿衣搭配推荐 http://tianchi.aliyun.com/competition/introduction.htm?spm=5176.100066.333.8.s9zH6X&raceId=231506
这个比赛,总结一句就是理想很丰满,现实很骨感。这个比赛看起来很有意思,我原本是抱着学术研究的态度去做的,结果自己设计的模型没有用,还不如一些简单地baseline。
说一说我的方法,各位估计要笑了,特别简单,就是考虑几条简单地规则:1 根据文本计算一个相似度,按照相似度排序,取top200 2.计算商品之间有多少个共同购买的用户(注意区分同一天购买,同一周,同月,同季度等等),排序取top200 3 trianing set中有一个搭配集,对于每一个item01,找到在搭配集中和它相似的/和它有过共同购买的 商品(item02), 然后把item02的搭配推荐给item01 , 取top200. 最后把这3条规则的结果穿插融合,就是我最终的排名(第13
名).
做完这些我就开始兴致勃勃地设计自己的“高级”模型了。做了好几天的矩阵分解,发现AUC是挺高的,但是MAP却很低。 失望之余只好重新回到提取feature的思路上来。最后设计了一组新的feature,包括文字匹配概率,商品季节搭配概率,商品类别流动概率等等,线下测试得分挺高的,但是不妙的是在比赛快结束的时候主办方对每个team的资源加了约束,我不能在全集上实现我的方案,最终还是没能更新结果。
小结一下这个比赛:
1。 内容很吸引人,但是做法却很简单粗暴。 图像什么的完全没有效果(不知道冠军队有没有用)。
2. 数据量很大,要对7.6W商品推荐前200个搭配候选项,大家都在全集(超过300W个商品)上筛选结果,光是item01-item02-feature这张表就有超过1T的大小。 所以比赛中期阿里云平台一度被选手们整奔溃了,后来主办方不得不对每个队伍资源加了限制。
3. 第二赛季完全在odps平台上操作。我是第一次使用odps,搭配本地环境花费了好大精力。 如果本地环境没搭配好,就不能提交mapreduce程序和udf程序,就只能靠sql脚本写,这样的得分最终会在30名左右。 所以我觉得,跑通了odps平台就赢了一半了。

以上就是我随手写的2015比赛之路历程。3次比赛,3个不同的平台(学术竞赛,kaggle,天池),3个不同的问题。 虽然后两个都是留着莫大的遗憾,也算是学到了不少东西。 眼下好好搞科研吧,希望以后再有时间,组个队搞搞吧。

时间: 2024-11-08 19:13:18

数据挖掘类竞赛经验总结与分享:人人都可以是赢家的相关文章

【知识分享-人人都能当管理】做好企业时间管理:累积铜板时间变黄金

做好企业时间管理:累积铜板时间变黄金 如何做好时间管理是上班族的一门大学问,但对企业主管而言,"零碎的时间"管理,是更重要的课题.因为在工作执行的过程中,主管最主要的工作,对内是分配.指挥.协调部门同仁达成任务:对外,又必须面对客户.供货商的种种需求,主管的时间会不断被干扰与压缩,甚至影响自身原本的任务. 因此如果你身为主管,学会不浪费时间这样的基本功是不足够的,进一步,还得学会如何将破碎不堪的时间"化零为整",创造出具体的时间运用绩效.    差旅是主管常见的时间

Python爬虫练习(拉勾网北京地区数据挖掘类职位所需技能统计)

这是我最近学习用Python做爬虫时的一个小练习,这段程序可以可以统计拉勾网北京地区的数据挖掘类职位所需的各项技能.程序未完成,还需要加工,目前职位的网址为手动添加,作为程序演示,后续会改为自动读取网址. 代码如下: 1 #encoding: utf-8 2 ''' 3 本段代码可以统计拉勾网北京地区的数据挖掘类职位所需的各项技能, 4 每个技能在每个统计职位中出现至少1次,则该技能统计次数加1(一 5 个职位中一个技能只统计1次),最后做出各技能被统计次数的条形图. 6 ''' 7 impor

对家用集成吊顶的安装的经验总结和分享

随着对生活的追求越来越高,大家越发要求美化自己的生活空间,特别有些房子的顶部有樑,不好看,因此吊顶就出现了,而社会的对吊顶的需要更是促进了吊顶行业的发展,集成吊顶的产生让我们自己也能安装吊顶,更大程度上满足了我们的生活需要.但很多人对集成吊顶安装方法不是很清楚,当然我自己也不知道,呵呵…… 不过没关系,我们内事问百度,百度就知道啦,我收集了这些资料,以后自己好用,也和大家分享下哦:集成吊顶是家居装修设计中一个能起到非常强的整洁美观效果的一个项目,集成吊顶能为家居空间提供一个多元化的设计效果,并且

分享《人人都是产品经理2.0:写给泛产品经理》高清中文PDF+苏杰(作者)

下载:https://pan.baidu.com/s/1LL0QffA_tF6znwrfvGyiuQ 更多分享:http://blog.51cto.com/14050756 <人人都是产品经理2.0:写给泛产品经理>高清中文PDF+苏杰(作者) 高清中文PDF,带书签目录,彩色配图,383页,文字能够复制粘贴. 两个版本.经典书籍. <人人都是产品经理2.0--写给泛产品经理>将从人开始,以人结束,中间说事,以一个产品从无到有的过程为框架--想清楚.做出来.推出去,外加一章综合案例

阿里云Quick BI——让人人都成为分析师

摘要: 在3月29日深圳云栖大会的数据分析与可视化专场中,阿里云产品专家潘炎峰(陌停)对大数据智能分析产品 Quick BI 进行了深入的剖析.大会现场的精彩分享也赢得观众们的一直认可和热烈的反响. Quick BI诞生于阿里巴巴集团自身对数据分析的需求过程. 在3月29日深圳云栖大会的数据分析与可视化专场中,阿里云产品专家潘炎峰(陌停)对大数据智能分析产品 Quick BI 进行了深入的剖析.大会现场的精彩分享也赢得观众们的一直认可和热烈的反响. Quick BI诞生于阿里巴巴集团自身对数据分

【总结整理】传统行业如何合理利用互联网思维----摘自《人人都是产品经理》

[天天问每周精选]第49期:传统行业如何合理利用互联网思维 人人都是产品经理社区 发布于 2018-10-08 08:03:46 举报 阅读数:1287 ??近年来互联网思维一词火爆,无论是互联网行业还是传统行业仿佛都把互联网思维挂在嘴边,用互联网思维改造传统行业似乎成了一个致胜的法宝,那么到底传统行业究竟该如何结合互联网思维呢? 问题清单: 药店门前放个体重秤有什么作用? 如何利用产品和运营思维,帮助菜市场猪肉小贩将生意从O2O平台重"抢"回来? 一个便利店如何提升利润? 一个人去吃

【转】测试,人人都是产品经理之测试产品的选择和创造

  序言:明天新的一年的的工作开始了,在晚上写这篇文章,也算是对自己一年工作的一个简单的总结以及对今年所想做的事情作为一个开端吧.这次回家,疯狂了一把,不管测试.不管自动化.也不管技术,只知道与朋友们欢畅,踏上回来的途中,却反射性的重新拿起了书.每个人也许想知道自己的价值在哪,无论在哪,我觉得每个人都是自己的产品经理,而定位自己的需求,寻找产品的价值都是一件很难的事情,首先知道自己要什么,再知道自己可以设计出来?最后还要经过反复的实践和测试,才能诞生出一个让自己感到稍微满意的产品,因为这些文章,

人人都是程序员

有一家饭店的大厨,烧得一手好菜,经过口碑相传,客人从五湖四海闻名而来.然而这对饭店的老板来说,并不单纯是一个好消息.因为客人不是奔着饭店,而是奔着大厨的手艺来的.老板必须想办法留住这位大厨,否则他一旦被别人挖走,饭店的生意就会一落千丈了.然而即便老板不惜血本保证了大厨的忠诚度,风险也依然存在: 大厨休息或请假的时候,菜品的口味就无法让顾客满意: 大厨只有一个,如果想在多个地方开分店,那口味也就不能保证了: 大厨再厉害,同时也只能炒一个菜,而顾客越来越多,输出总是供不应求: 大厨年纪大了总是要退休

NoSQL初探之人人都爱Redis:(1)Redis简介与简单安装

一.NoSQL的风生水起 1.1 后Web2.0时代的发展要求 随着互联网Web2.0网站的兴起,传统的关系数据库在应付Web2.0网站,特别是超大规模和高并发的SNS类型的Web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题: (1)对数据库高并发读写的需求 网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求.关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求