DSB2019 1st place solution まとめ
はじめに
DSB2019の1st place solution をまとめました。
結論
- 基本はCVを信じられるように経験を積むのが重要なのかなと思った。
- CVの切り方に対する信用もそうだけど、単純に実装を信用できるかもあるから、パイプライン化というか定型化しちゃって、実装を信頼できるものを何個か作れば、もう少し考えることが減らせるのかなと思った。
以下、solution まとめ
1次ソース * 以下、拙訳ですので気になるところは1次ソースを見てね。
summary
- single lightgbm model (seed 5 fold average)
- privete qwk: 0.568, public qwk: 0.563
- cv weighted qwk 0.591, weighted rmse 1.009
validation
- LBとlocal CVが一致しなかったのでlocal CVを信じた。
- *とはいえ、LBも高いからなぁ
- local CV を安定させるために、いくつかためし、GroupK cv と Nested cvを試した。
group K cv
- groupをinstall_idとした、5 seed * 5-foldのgroup K Foldを用いた。
- *これは同じようなことをした。おそらく、validation dataはrandom sampling していると思うけど、install_idによって、historyの量が全然違うため、複数seedで平均を取るというのが効果的に思えた。
- *ちなみに、僕は学習もrandom samplingしてた(テスト時と同じように学習したほうがいいんじゃね?)のもあり、seed数は10~15くらいで試してた。
- qwk では、group K Foldにをしてもlocal cvが安定しなかったため、評価時にはqwkではなく、weighted rmseを用いた。
- *weightには、sample確率を用いたらしいが、そこがよくわからん。
- *commentを見ると、各installation_idにおいて、assesmentsの数が多いときのweightを小さくした感じみたい?
- *weightには、sample確率を用いたらしいが、そこがよくわからん。
nested cv
- group K cvでの信頼性が低いときに、nested cvでも再チェックした。
- localデータを用いて、train-test splitをsimulateした。
- *いまいち、ピンとこない、nested cvってそんなんだっけって感じ。(要確認)
Feature Engineering
ほとんどの時間をfeature engineeringに費やした。約20000featuresを生成し、null importance methodで500個選択した。
- *どうやったら、20000featuresも作れるのかよくわからんし、null importance methodもわからないので、後でちゃんと調べたい。
true attempts ratio, correct true ratio, correct feedback ratio等から、mean/sum/last/std/max/slopeといったものを生成した。
- 同じassessmentsや似たゲームはとても重要であった。
- 似たassessmentのゲームはmapした。
- *assesmentの値でゲームを分類(クラスタリング)して、ゲーム名の代わりにそれを使ったってことかな?
- 似たassessmentのゲームはmapした。
- 同じassessmentsや似たゲームはとても重要であった。
- history dataから異なった期間で、データを抽出した。
- device を share する場合もあるため、こうすることで違ったデータが得られる
- *異なった期間での抽出は思いついていたけど、deviceのshareの影響のことは考えてなかった。(cvが安定しなすぎて、それが落ち着かないといくらfeature増やしても...とも思っていたので、そこまでいかなかった。)
- device を share する場合もあるため、こうすることで違ったデータが得られる
- Event interval features (next event timestamps - current event timestamps)
- Event interval featureをevent idやevent codeでgroupbyしたもののmeanやlast
- *event interval featureみたいなものは作ったけど、groupbyはしなかった
- Event interval featureをevent idやevent codeでgroupbyしたもののmeanやlast
- video skip prop ratio
- *子供がvideoをスキップしたかどうかの指標らしい。確かに、ちゃんと見た子の方がやることわかっていてできそう。
- Event data feature
- event_codeやevent_idとのevent_dataの組み合わせfeature(eg. event_code2030_misses_mean)
- *trainとtestの分布が違うので、こういうfeature作るとoverfitするんじゃないかと思い、むしろこういった、featureは避けるようにしてたわ...,。
- *この考えがそもそも間違っているのか、local CVを信じると決めたからできるのか。
Feature selection
- Drop duplicate cols
- historyを除いた(?)adversarial validationによってリークがないことを確かめた。
- aucが0.5付近
- *自分がやった時は、0.6~0.7の間くらいだったんだけど...。
- *そもそもcvの中でってことかな?単純に何か間違っていたのかもしれない。
- null importance methodで500featureに絞った。
Model
DSB2019で惨敗した
はじめに
Kaggleはたまに参加していたけど、あまり本気でやったこともなかったので、ラスト1カ月からまじめにやってみた。
結論
色々ためしたが、何をやってもスコアが上がらず、惨敗した。
なぜだめだったか。
- CVの切り方が最後まで分からず、全くtrustCVにならなかった。
- trainとtestの分布が違う場合に、どう対応すればよいかわからなかった。
- FeatureEngineeringも色々ためしたけど、LB上でのスコアが上がらなかった。
- LBはあまり、信用できないだろうとも思っていたけど、自分のCVの切り方にも自信が持てなかった。
- 英語力が無く、間違って読み取ったり、理解に時間がかかったり等が根本原因としてありそう。
- 割と一から実装しているのでいろんなところで時間がかかってしまった。
よかったこと。
- 最終サブミットまで頑張った。
- 地味にいつも途中でやめてしまうので、一番良かったことかもしれない。
- 知ってはいるけど、試したことがなかった手法を色々試せた。
- target encoding, adversarial validation等
- やるかと思ってからの環境準備とかにいつも手間取るけど、割とスムーズに始められた。
- フォルダ構成とかが少しずつ良くなっている気がする。
- 手法の実装が比較的すぐできた。
- 「Kaggleに勝つ技術」のおかげだったりする。
今後について
- 上位陣の解法をちゃんとチェックしたい。
- パイプラインを少しずつ作っていきたい。
- 画像もやりたい。