s****h 发帖数: 3979 | 1 今天无意在kaggle上发现了这道题,要预测CTR rate:
https://www.kaggle.com/c/avazu-ctr-prediction
不利的一点是这题已经出来两个多月,还有2周就截止了。
有趣的是这题变量很多,啥machine learning的tool都可以随便试,所以目前已经提交
答案的队居然有1400+,估计都是啥顺手的toolbox都拿来试一试。
论坛上看到很多人说直接用Vowpal Wabbit,还没tuning呢,结果就接近目前排名最高的
team了。
大家有兴趣的一起看看?分享一下思路?
evaluation is based on Logarithmic Loss.
觉得不合理啊,实际应用中应该用number of correct prediction吧。
下午比较空,就下载了数据,load进hive,先算了算group by各个变量的CTR。
我目前的思路比较too simple too naive。就是每个变量替换成该group by变量的CTR
,然后general linear regression试试看效果如何。 |
G****o 发帖数: 229 | 2 数据量不小,处理起来比较花时间
如果感兴趣可以一起解决一下那个 driver-telematics-analysis。
每个单独的数据都比较小,而且截止日期还比较长。坏处是目前第一个成绩非常好。
有兴趣站内联系吧 |
s****h 发帖数: 3979 | 3 论坛里这个人一个多月前贴出的code,号称没怎么做tuning,已经可以达到0.402
现在的领先者也不过是0.38
主要code如下:
https://github.com/mkneierV/kaggle_avazu_benchmark/blob/master/run_model.py
就做了两步
1.feature hash
2.logistic regression |
s********n 发帖数: 80 | 4 嗯,我一开始也看了,现在也在做。
Google有篇2013年的文章就是用logistic regression来做CTR的,Kaggle的论坛里面有
人把对应的Python code贴出来了。
Facebook在2014年也有篇文章,是先做GBM,然后用GBM生成的tree来做logistic
regression,号称要比直接做logistic Regression要好。
py
【在 s****h 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 论坛里这个人一个多月前贴出的code,号称没怎么做tuning,已经可以达到0.402 : 现在的领先者也不过是0.38 : 主要code如下: : https://github.com/mkneierV/kaggle_avazu_benchmark/blob/master/run_model.py : 就做了两步 : 1.feature hash : 2.logistic regression
|
k*******6 发帖数: 103 | 5 看起来接近,0.402 已经排名1000开外了。。。
py
【在 s****h 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 论坛里这个人一个多月前贴出的code,号称没怎么做tuning,已经可以达到0.402 : 现在的领先者也不过是0.38 : 主要code如下: : https://github.com/mkneierV/kaggle_avazu_benchmark/blob/master/run_model.py : 就做了两步 : 1.feature hash : 2.logistic regression
|
s****h 发帖数: 3979 | 6 接触这题之前,我都不知道啥是feature hash. 现在也不理解为啥结果这么好?
觉得这个feature hash有点too good了。比起啥random forest,SVM强太多了。
那位解释一下?
另外一个问题:
某个特定的device_id (或者app_id, 或者device_id & appid的组合)占了总数据的10
%的话。
单独预测这个device_id的数据,会不会比和其他device_id的数据mix起来一起预测结
果更好?
开始贴这题,是因为看到一个直接OTTB的model结果就这么好,估计有办法improve
1. intraday pattern, 每个小时的CTR rate会有不同 (其实区别不大),估计很多
team也考虑到了;
2. 某天(1022)的数据和其他9天有些不同;
3. 误以为相同device_id&app_id, CTR for the first impression 会比average of
other impressions 大。
后来才发现,其实,app_id根本不是同一个content,device_id也不是同一个user
end device。(见我上面的问题)
不过,我ran a query,结果是,对于count ( # of impressions) group by
device_id & app_id 小的情况,
CTR for the first impression 会比average of other impressions 大,虽然
不是大很多,但也足够明显了。
而这点区别,feature hash + GLR是不会利用上的。
|
i**********a 发帖数: 149 | 7 我也关注了这个contest,我是用random forest作的,除了把hour分出来,没有任何
tune和feature engineering, LB score是0.409。据说predict成constant都有0.43
正准备试下logistic regression, 然后加一些interaction的feature
10
【在 s****h 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 接触这题之前,我都不知道啥是feature hash. 现在也不理解为啥结果这么好? : 觉得这个feature hash有点too good了。比起啥random forest,SVM强太多了。 : 那位解释一下? : 另外一个问题: : 某个特定的device_id (或者app_id, 或者device_id & appid的组合)占了总数据的10 : %的话。 : 单独预测这个device_id的数据,会不会比和其他device_id的数据mix起来一起预测结 : 果更好? : 开始贴这题,是因为看到一个直接OTTB的model结果就这么好,估计有办法improve : 1. intraday pattern, 每个小时的CTR rate会有不同 (其实区别不大),估计很多
|
c***z 发帖数: 6348 | 8 没有看错的话,feature hash增加的是速度,而不是精度吧
而且matrix也不解决sparsity的问题,不如用set
个人觉得问题的关键是click是rare event,所以相应的要采用resample + weighted
cost function (对于RF,就是balanced+weighted RF)
这里的精度是AUC还是F1 score? |
i**********a 发帖数: 149 | 9 大牛说的没错,feature hash只是另一种代替one hot encode的model categorical
variable的方法,好像跟SGD常用。会不会提高精度很难说,貌似很多时候精度跟
implementation也很相关。
kaggle论坛里面贴出来的方法就是online的train了一个logistic regression model,
用了feature hash。直接run那个code我得到了leadboard score 0.398,用了feature
之间的interaction反而降低了score,0.409
这里的score是logloss, 不是AUC和F1
【在 c***z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 没有看错的话,feature hash增加的是速度,而不是精度吧 : 而且matrix也不解决sparsity的问题,不如用set : 个人觉得问题的关键是click是rare event,所以相应的要采用resample + weighted : cost function (对于RF,就是balanced+weighted RF) : 这里的精度是AUC还是F1 score?
|
c***z 发帖数: 6348 | 10 谢谢科普logloss,受教了:)
feature
【在 i**********a 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 大牛说的没错,feature hash只是另一种代替one hot encode的model categorical : variable的方法,好像跟SGD常用。会不会提高精度很难说,貌似很多时候精度跟 : implementation也很相关。 : kaggle论坛里面贴出来的方法就是online的train了一个logistic regression model, : 用了feature hash。直接run那个code我得到了leadboard score 0.398,用了feature : 之间的interaction反而降低了score,0.409 : 这里的score是logloss, 不是AUC和F1
|
|
|
s****h 发帖数: 3979 | 11 借这个楼问个random forest的问题:
random forest都是直接在feature space上做?
还是会先假设features独立;根据某个feature A的数据分布,投射到某种更接近均匀
分布的feature A'上,用A'替换A? |
i**********a 发帖数: 149 | 12 是的。没有假设feature独立
什么方法会需要假设假设feature独立,然后坐作变换啊?
【在 s****h 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 借这个楼问个random forest的问题: : random forest都是直接在feature space上做? : 还是会先假设features独立;根据某个feature A的数据分布,投射到某种更接近均匀 : 分布的feature A'上,用A'替换A?
|
s****h 发帖数: 3979 | 13 哦,假设features独立是我随口说的。说错了。
其实decision tree based 算法,是不是都无所谓feature之间关系怎么样?
Random forest就是怕有些feature太相关,所以才用树的一部分,而不直接用tree
bagging.
个人觉得这种算法都只能算是无可奈何的办法。和KNN差不多。
很多方法都希望变换之后的新features独立吧。
native bayes假设features独立,有些改进型就要做变换。 |
c***z 发帖数: 6348 | 14 个人理解,tree的优点之一就是不用考虑interaction terms/correlation between
terms,
在recursively partition的时候自动包括进去了 |
y******g 发帖数: 26 | 15 这个我当时做了,最后是80多名,LB score 0.389,第一名是0.377,0.01的差距其实
相当远,因为用sklearn里面的SGD都有办法达到0.39X
排名前面的主要用的都是FTRL和FM(都是logistic regression的变形),他们表现好
的原因在于数据的稀疏性(全都是多level的离散变量)
直接加入所有interaction会使结果变差,而有选择性的加入会大大提高精确度,同时
对于用户的ip地址要做一个处理,比如访问次数低于10次的作为“rare”
还需要feature engineering,比如要判定该用户使用的是电脑还是手机,比如判定出
某个用户过去总共有多少次点了多少次没点。里面的data全都是加密过的,但通过一些
手段可以得出这些信息 |
s****h 发帖数: 3979 | 16 你后面说的我也考虑到了。
需要根据deviceid / ip 访问的次数,判断到底是个人用户(次数低)还是网络设备
(次数高)
个人用户有些不同的pattern。
感觉data scientist现在很容易做,因为很多open source的工具,很方便。
要做好,就需要很多business analysis的技巧,也就是所谓的domain knowledge。
然后就是需要爱动脑筋,做中小学数学竞赛题那种脑筋。估计这里很多人这方面都有比
较强的背景。
【在 y******g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这个我当时做了,最后是80多名,LB score 0.389,第一名是0.377,0.01的差距其实 : 相当远,因为用sklearn里面的SGD都有办法达到0.39X : 排名前面的主要用的都是FTRL和FM(都是logistic regression的变形),他们表现好 : 的原因在于数据的稀疏性(全都是多level的离散变量) : 直接加入所有interaction会使结果变差,而有选择性的加入会大大提高精确度,同时 : 对于用户的ip地址要做一个处理,比如访问次数低于10次的作为“rare” : 还需要feature engineering,比如要判定该用户使用的是电脑还是手机,比如判定出 : 某个用户过去总共有多少次点了多少次没点。里面的data全都是加密过的,但通过一些 : 手段可以得出这些信息
|
O*********y 发帖数: 923 | 17
random forest 就是因为选取部分feature而进一步降低correlation吧
【在 c***z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 个人理解,tree的优点之一就是不用考虑interaction terms/correlation between : terms, : 在recursively partition的时候自动包括进去了
|
s****h 发帖数: 3979 | 18 今天无意在kaggle上发现了这道题,要预测CTR rate:
https://www.kaggle.com/c/avazu-ctr-prediction
不利的一点是这题已经出来两个多月,还有2周就截止了。
有趣的是这题变量很多,啥machine learning的tool都可以随便试,所以目前已经提交
答案的队居然有1400+,估计都是啥顺手的toolbox都拿来试一试。
论坛上看到很多人说直接用Vowpal Wabbit,还没tuning呢,结果就接近目前排名最高的
team了。
大家有兴趣的一起看看?分享一下思路?
evaluation is based on Logarithmic Loss.
觉得不合理啊,实际应用中应该用number of correct prediction吧。
下午比较空,就下载了数据,load进hive,先算了算group by各个变量的CTR。
我目前的思路比较too simple too naive。就是每个变量替换成该group by变量的CTR
,然后general linear regression试试看效果如何。 |
G****o 发帖数: 229 | 19 数据量不小,处理起来比较花时间
如果感兴趣可以一起解决一下那个 driver-telematics-analysis。
每个单独的数据都比较小,而且截止日期还比较长。坏处是目前第一个成绩非常好。
有兴趣站内联系吧 |
s****h 发帖数: 3979 | 20 论坛里这个人一个多月前贴出的code,号称没怎么做tuning,已经可以达到0.402
现在的领先者也不过是0.38
主要code如下:
https://github.com/mkneierV/kaggle_avazu_benchmark/blob/master/run_model.py
就做了两步
1.feature hash
2.logistic regression |
|
|
s********n 发帖数: 80 | 21 嗯,我一开始也看了,现在也在做。
Google有篇2013年的文章就是用logistic regression来做CTR的,Kaggle的论坛里面有
人把对应的Python code贴出来了。
Facebook在2014年也有篇文章,是先做GBM,然后用GBM生成的tree来做logistic
regression,号称要比直接做logistic Regression要好。
py
【在 s****h 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 论坛里这个人一个多月前贴出的code,号称没怎么做tuning,已经可以达到0.402 : 现在的领先者也不过是0.38 : 主要code如下: : https://github.com/mkneierV/kaggle_avazu_benchmark/blob/master/run_model.py : 就做了两步 : 1.feature hash : 2.logistic regression
|
k*******6 发帖数: 103 | 22 看起来接近,0.402 已经排名1000开外了。。。
py
【在 s****h 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 论坛里这个人一个多月前贴出的code,号称没怎么做tuning,已经可以达到0.402 : 现在的领先者也不过是0.38 : 主要code如下: : https://github.com/mkneierV/kaggle_avazu_benchmark/blob/master/run_model.py : 就做了两步 : 1.feature hash : 2.logistic regression
|
s****h 发帖数: 3979 | 23 接触这题之前,我都不知道啥是feature hash. 现在也不理解为啥结果这么好?
觉得这个feature hash有点too good了。比起啥random forest,SVM强太多了。
那位解释一下?
另外一个问题:
某个特定的device_id (或者app_id, 或者device_id & appid的组合)占了总数据的10
%的话。
单独预测这个device_id的数据,会不会比和其他device_id的数据mix起来一起预测结
果更好?
开始贴这题,是因为看到一个直接OTTB的model结果就这么好,估计有办法improve
1. intraday pattern, 每个小时的CTR rate会有不同 (其实区别不大),估计很多
team也考虑到了;
2. 某天(1022)的数据和其他9天有些不同;
3. 误以为相同device_id&app_id, CTR for the first impression 会比average of
other impressions 大。
后来才发现,其实,app_id根本不是同一个content,device_id也不是同一个user
end device。(见我上面的问题)
不过,我ran a query,结果是,对于count ( # of impressions) group by
device_id & app_id 小的情况,
CTR for the first impression 会比average of other impressions 大,虽然
不是大很多,但也足够明显了。
而这点区别,feature hash + GLR是不会利用上的。
|
i**********a 发帖数: 149 | 24 我也关注了这个contest,我是用random forest作的,除了把hour分出来,没有任何
tune和feature engineering, LB score是0.409。据说predict成constant都有0.43
正准备试下logistic regression, 然后加一些interaction的feature
10
【在 s****h 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 接触这题之前,我都不知道啥是feature hash. 现在也不理解为啥结果这么好? : 觉得这个feature hash有点too good了。比起啥random forest,SVM强太多了。 : 那位解释一下? : 另外一个问题: : 某个特定的device_id (或者app_id, 或者device_id & appid的组合)占了总数据的10 : %的话。 : 单独预测这个device_id的数据,会不会比和其他device_id的数据mix起来一起预测结 : 果更好? : 开始贴这题,是因为看到一个直接OTTB的model结果就这么好,估计有办法improve : 1. intraday pattern, 每个小时的CTR rate会有不同 (其实区别不大),估计很多
|
c***z 发帖数: 6348 | 25 没有看错的话,feature hash增加的是速度,而不是精度吧
而且matrix也不解决sparsity的问题,不如用set
个人觉得问题的关键是click是rare event,所以相应的要采用resample + weighted
cost function (对于RF,就是balanced+weighted RF)
这里的精度是AUC还是F1 score? |
i**********a 发帖数: 149 | 26 大牛说的没错,feature hash只是另一种代替one hot encode的model categorical
variable的方法,好像跟SGD常用。会不会提高精度很难说,貌似很多时候精度跟
implementation也很相关。
kaggle论坛里面贴出来的方法就是online的train了一个logistic regression model,
用了feature hash。直接run那个code我得到了leadboard score 0.398,用了feature
之间的interaction反而降低了score,0.409
这里的score是logloss, 不是AUC和F1
【在 c***z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 没有看错的话,feature hash增加的是速度,而不是精度吧 : 而且matrix也不解决sparsity的问题,不如用set : 个人觉得问题的关键是click是rare event,所以相应的要采用resample + weighted : cost function (对于RF,就是balanced+weighted RF) : 这里的精度是AUC还是F1 score?
|
c***z 发帖数: 6348 | 27 谢谢科普logloss,受教了:)
feature
【在 i**********a 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 大牛说的没错,feature hash只是另一种代替one hot encode的model categorical : variable的方法,好像跟SGD常用。会不会提高精度很难说,貌似很多时候精度跟 : implementation也很相关。 : kaggle论坛里面贴出来的方法就是online的train了一个logistic regression model, : 用了feature hash。直接run那个code我得到了leadboard score 0.398,用了feature : 之间的interaction反而降低了score,0.409 : 这里的score是logloss, 不是AUC和F1
|
s****h 发帖数: 3979 | 28 借这个楼问个random forest的问题:
random forest都是直接在feature space上做?
还是会先假设features独立;根据某个feature A的数据分布,投射到某种更接近均匀
分布的feature A'上,用A'替换A? |
i**********a 发帖数: 149 | 29 是的。没有假设feature独立
什么方法会需要假设假设feature独立,然后坐作变换啊?
【在 s****h 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 借这个楼问个random forest的问题: : random forest都是直接在feature space上做? : 还是会先假设features独立;根据某个feature A的数据分布,投射到某种更接近均匀 : 分布的feature A'上,用A'替换A?
|
s****h 发帖数: 3979 | 30 哦,假设features独立是我随口说的。说错了。
其实decision tree based 算法,是不是都无所谓feature之间关系怎么样?
Random forest就是怕有些feature太相关,所以才用树的一部分,而不直接用tree
bagging.
个人觉得这种算法都只能算是无可奈何的办法。和KNN差不多。
很多方法都希望变换之后的新features独立吧。
native bayes假设features独立,有些改进型就要做变换。 |
|
|
c***z 发帖数: 6348 | 31 个人理解,tree的优点之一就是不用考虑interaction terms/correlation between
terms,
在recursively partition的时候自动包括进去了 |
y******g 发帖数: 26 | 32 这个我当时做了,最后是80多名,LB score 0.389,第一名是0.377,0.01的差距其实
相当远,因为用sklearn里面的SGD都有办法达到0.39X
排名前面的主要用的都是FTRL和FM(都是logistic regression的变形),他们表现好
的原因在于数据的稀疏性(全都是多level的离散变量)
直接加入所有interaction会使结果变差,而有选择性的加入会大大提高精确度,同时
对于用户的ip地址要做一个处理,比如访问次数低于10次的作为“rare”
还需要feature engineering,比如要判定该用户使用的是电脑还是手机,比如判定出
某个用户过去总共有多少次点了多少次没点。里面的data全都是加密过的,但通过一些
手段可以得出这些信息 |
s****h 发帖数: 3979 | 33 你后面说的我也考虑到了。
需要根据deviceid / ip 访问的次数,判断到底是个人用户(次数低)还是网络设备
(次数高)
个人用户有些不同的pattern。
感觉data scientist现在很容易做,因为很多open source的工具,很方便。
要做好,就需要很多business analysis的技巧,也就是所谓的domain knowledge。
然后就是需要爱动脑筋,做中小学数学竞赛题那种脑筋。估计这里很多人这方面都有比
较强的背景。
【在 y******g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这个我当时做了,最后是80多名,LB score 0.389,第一名是0.377,0.01的差距其实 : 相当远,因为用sklearn里面的SGD都有办法达到0.39X : 排名前面的主要用的都是FTRL和FM(都是logistic regression的变形),他们表现好 : 的原因在于数据的稀疏性(全都是多level的离散变量) : 直接加入所有interaction会使结果变差,而有选择性的加入会大大提高精确度,同时 : 对于用户的ip地址要做一个处理,比如访问次数低于10次的作为“rare” : 还需要feature engineering,比如要判定该用户使用的是电脑还是手机,比如判定出 : 某个用户过去总共有多少次点了多少次没点。里面的data全都是加密过的,但通过一些 : 手段可以得出这些信息
|
O*********y 发帖数: 923 | 34
random forest 就是因为选取部分feature而进一步降低correlation吧
【在 c***z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 个人理解,tree的优点之一就是不用考虑interaction terms/correlation between : terms, : 在recursively partition的时候自动包括进去了
|