【Kaggle】DSBコンペ 反省会 備忘録

DSBコンペ(DataScienceBowl 2019)の反省会を2/29 (土) に開催しました。
金メダルチームが3チームも参加するなど、非常に学びの多い会でした。
簡単ですが、備忘として記録を残しておきます。

shirokane_friends（58位）銀メダル

チームメンバー： しゃおろん、にのぴら、Idem、makotu

発表資料：Kaggle DSB2019 58th place solution

•  LightGBMのみ
  • NNとのアンサンブルは上手くいかなかった
    →metricなどモデルごとに違いすぎたことが原因？
• 一番効いた特徴量は、AssessmentとGameの成績を「偏差値化」したもの
  •  「ラグ特徴量」にしたら効いた
    • 偏差値にすることで難易度の差に依らない公平な評価ができる
    • ラグ特徴量化することで、trainとtestの履歴の多さの違いを吸収できる
• trust CV できなかったのが、スコアを伸ばせなかった要因
• カーネルは理解して使うことが大事
  • ajust_factor（各特徴量ごとにtrainとtestの平均を合わせる処理）は使わなくて良かった

私のチームです。
銀メダルを獲得できたのが嬉しい一方で、trust CV できずに実力不足を痛感するコンペでもありました。アンサンブルが上手くいかなかったのも悔やまれる部分で、QWKという指標の難しさを感じました。

akiraさん、yukiさん（837位）

akiraさん、yukiさん

• public 26位から大幅にshake downしてしまった
  • trust cv すべきと思いつつできなかった
  • ajust_factorを入れてしまった

• 有効だった特徴量＆取り組み
  • ステージを順番ごとにプレイしていたかどうか
    • ステージに番号を振っておいて、前後にプレイしたステージの番号同士で差をとる
    • 差が小さいほど、順番にプレイしていると言える
  • titleごとに番号を振っていって、その差分をとる
  • accuracy_groupではなく、accuracyをtargetとして回帰した
    • accuracy_groupだと、失敗が3回以上の場合が1つのaccuracy_groupに丸められてしまっている
• 上手くいかなかったこと
  • transformer
    • 入力ベクトルが違ったことが原因？

• • Assessment毎にモデル作成
    • データ量が減るからでは？

aryyyyyさん（51位）銀メダル

• kaggleの本格参戦 は初
• 個別にユーザーのログを追いかけて、特徴量作成の着想を得ていた
  • 実際にアプリをプレイしながら追体験した
  • 特定の箇所を連打している人など、ユーザーの変わった傾向などが見えてきた
    • 「この子の将来心配フラグ」として特徴量を作ったりもした
• とにかく大量の特徴量を作った
  • 10万くらい
  • 掛け合わせの特徴量も多い
•  効いた特徴量
  • world選択スピード
    • すぐ選ぶかどうかが賢さに直結しそう
  • 段階があるものについては、どこまでクリアしているかなど
  • install後に最初のタイトル
  • 時間帯を絞って特徴量の作成
    • 親と区別したかった
• 特徴量選択がとにかく上手くいかなかった
  • feature importance とか
  • 2000特徴量まで（どうにかして）削った
  • 2000特徴量をベースに、ランダムサンプリングを繰り返して一番いい特徴量のセットを使った（800,500,300）
• モデルはLightGBM、Xgboost、NN のアンサンブル
  • 重みは何となくで決めた
• 閾値はよくわからなかったので、2sub使った

初の本格参戦で銀メダルを獲るのがすごいですね。
ユーザーのログを個別に見るというのはやりたいと思ってもなかなかできないので、真似したいです。「絶対に上位に行く」という強い意志を感じました。

powellさん（246位）銅メダル

powellさん

•  勉強歴7カ月での挑戦で初メダル
  • 本格的に開始したのはコンペ一週間前
    • 起きてる時間を全て使った
• 公開カーネルに手を加える形で進めた
  • Convert to Regression をベースにした
  • 予測するAssessmentと同じWorldに関する特徴量を追加

• 閾値はtrainデータの割合を見て決めた
• publicが一番いいものと、ajust_factorを外したものを提出
• late sub で、private 0.554（銀メダル上位相当）まで上げることができた
  • optimizer rounderの利用
  • testデータの利用

Kaggler-jaフレンズ（15位）金メダル

発表：カレーさん

ソリューション：15th place solution

•  チームで役割を分担
  • カレーさんは特徴量作成以外のもろもろを担当していた（可視化とか）
• trainとtestの分布の違いに気を付けていた
  • testは初回のAssessmentを予測させる場合が多かった
  • 一定数以上のassessmentを切り捨ててvalidationを作った
    • testデータにないようなデータは使わない
• 回帰ではなく分類で解いたモデルが一番 publicが高かった
• サンプルごとのweightを設定することが大事だった
  • installation idごとのAssessmentの回数を逆数として重みづけする
    • Assessmentが3回なら、1/3
    • Assessmentが多いデータに過学習させたくない

sample weightを設定することは全く思いつかなかったので、すごく勉強になりました。
Assessmentの実施回数ごとに可視化するなど、色んな切り口でモデルの予測を確認していたのが印象的でした。改めて深くデータに向き合う重要性を感じました。

ほみちゅん さん

ほみちゅんさん

• Qiita記事に触発されて、1週間チャレンジ
  • shake down してメダル圏外だった
• 公開カーネルをベースに特徴量の追加
• adversarial validationのモデルが、サブしていないけど銀メダル圏内だった
• 本業で関わっている中国のビジネスモデルとKaggleの共通点についての発表
  • パクリ経済システム
  • Kaggleも公開カーネルを借りる（パクる）だけでは生き残れない

まさか中国の文化の話を反省会の場で聞くとは思いませんでした(笑)
今回のコンペは特にパクリに危険が潜んでいたコンペだったなと思います。

TNTさん（217位） 銅メダル

TNTさん

• public 980位からの大幅shake up
• 正解数を予測するモデルと不正解数を予測するモデルをそれぞれ作った
  • それらを元にaccuracyを算出して、QWKの最適化
• チーム募集スレッドの投稿を参考に、特徴量を作成した
  • 各自のアプローチを書いていることがあるので参考になる

• 公開カーネルにあるtrainデータを削る処理を外すと、精度が上がった
  • train_labelsにはないが、trainにはassessmentが存在するinstallation_idがあった？

俵さん（198位）銅メダル

俵さん

• public 701位からの大幅shake up
• ログデータを勉強したいと思って始めた
  • カーネルとディスカッションはあまり見なかった
• LightGBMのシングルモデル
• QWKは閾値調整に苦しんだ人が多いはず
  • late subで検証してみた
• 計量経済学の分野で使われている順序ロジットモデルを使ってみた
  • lgbmのcusom loss に自作したものを入れる
  • 0.5,1.5,2.5 という理想的なしきい値で切った場合のスコアは大幅に上がった
  • QWKの最適化をした場合は、CVは上がったがPrivateは同じ

Fusion（2位）金メダル＆入賞

発表：yabeaさん

ソリューション：2nd place solution

• meta featureが一番効いた
  • private 0.543 → 0.563くらい上がった
    • 最低でも0.01は上がった
  • publicには効かなかった
  • 各ゲームが、どれくらい成績に影響するかを特徴量化したかった
  • Eloコンペでsenkinさんの同様の特徴量を作成しており、参考にした
• meta featureはtitleごとに作成した
  • 数学が得意でも国語は得意ではないというように、問題によって性質が違うはずなので、分けたかった
• title について word2vecをした
  • min とかmaxとか色々計算した
  • 大きく効いたわけではないかも
• 特徴量は1600くらい使った
• 特徴量選択が効いた
  • null importanceで300個まで削った

yukkeさん（565位）

yukkeさん

• 1000位くらいから shake up
• チームメンバー 5人いたが、モチベdownなどで実質1人で取り組んでいた
• カーネルは見たが、そのままコピーしたわけではない
• ajust_factorは特徴量削除だけに使った
• train全データでの学習を試した
  • APTOSコンペの知見
  • privateにはそこまで効いてなかった
• Kaggle ってすごい人ばかりなんだろうなと思っていたら、汚いコードもあってびっくりした
• RFECV & 100特徴量が、銀メダル圏内だった
  • 過学習する要因となった特徴量が、大幅に削除することでなくなったのでは？
• 1位の人は、列や行の順番をrandamizeしており、参考にしたいと感じた

paoさん（10位）金メダル

paoさん

発表資料：DSB2019 10th Solutionの一部とShakeについて

• public 183位からのshake up
• truncated CVを使った
  • 1個が安定しないので、50個作っていた
• 成績の偏差値にして特徴量にした
  • センター試験のニュースで思いついた
• 累積系は入れず、比率系特徴量だけを作るようにしていた
  • 履歴の長さに影響されないように
• feature fraction 1.0 がよかった
  • title(予想対象のAssessmentの種類)列が落ちることを避けたかった
• test データを学習に利用した
• public LB がどこまで信用できるのかをひたすら考えた
  • シミュレーションしまくった
  • trainから1000件のランダムサンプリングしたときのブレ
  • これだけシミュレーションしたから、trust CV できた
• shake にはいろんな要因がある
  • publicへoverfitした公開カーネルがある
    • 今回のコンペはまさにこれ
    • 公開カーネルは、どうしてもoverfitしたものが増えがち
  • ぶれやすい評価指標
    • 仕方ない
  • overfit した特徴量を作ってしまう
• shakeに備えて気を付けるべきこと
  • ハイスコアカーネルは、解釈できる部分だけに利用する
  • LBを気にしてサブミットし続けない
    • 解釈できないけどスコアが上がった場合は特に危険
  • 仮説ベースで特徴量を作る
• 最初に自分の信じる指標を決める
  • 最初に決めないと、途中で変えることは難しい
• trust CV or trust LB の2択ではなく、どちらも使う
• malware以降、shakeについてめちゃくちゃ気を付けるようになった
  • shake down の数だけ強くなれる

shakeの神 paoさんによるshake論は学ぶことが多すぎました。。
「最初に信頼できる指標を作る」という大事さはbestfitting氏も言及しているように重要なことは分かっていながら、自チームはできませんでした。
paoさんのように「徹底的に考える」姿勢が足りなかったことが要因だと思うので、肝に銘じたいと思います。

まとめ

参加者全員発表というスタイルで3時間という長丁場でしたが、笑いあり学びありであっという間でした。
反省会後の交流会もKaggle談義で盛り上がり、幸せな1日でした。
参加者の皆様、ありがとうございました！