Kaggle DSB2019 58th place solution

2020/2/29(土)に開催した、Kaggle DSBコンペ振り返り会の発表資料です。
チーム：shirokane_friends
コンペURL：https://www.kaggle.com/c/data-science-bowl-2019/overview

Transcript

1. Kaggle DSBコンペ 58th place solution 2020/02/29 DSB 2019 振り返り会 チーム：Shirokane_friends
2. アジェンダ 2 時系列に沿って、チームの取り組みを紹介したいと思います 1. チーム紹介 2. 結果＆ソリューション 3. コンペ序盤（個人参加） 4. コンペ中盤（チーム結成） 5. コンペ終盤（アンサンブル） 6. コンペ振り返り
3. 1. チーム紹介
4. チーム名：shirokane_friends 4 つながり：同じ会社（ブレインパッド） nino_pira：下町データサイエンティスト(Kaggle 2回目) makotu ：Kaggle好きな先輩（Expert） Idem：画像に強いすごい人(Kaggle初参戦） しゃおろん：Kaggle好きな分析初心者（Contributor） 1. チーム紹介
5. 2. 結果＆ソリューション
6. Result 6 Public ：0.558 (77位) ↓ Private：0.550（58位）で 銀メダル ! 2. 結果＆ソリューション
7. Our solution 7 LightGBM×10のアンサンブル →NN系のモデルも試したが、アンサンブルが上手くいかなかった 2. ソリューション＆結果 Our approach Model LightGBM (10models ensemble) 5seed × 2 features Validation Stratified Group Kfold (k=5) Feature ユーザー行動を割合化した特徴量 ・プレイしたゲームセッションに占める各titleの割合 ・発生したイベントに占める、各event_code、event_idの割合 成績に関する特徴量 ・TitleごとのAccuracy（AssessmentとGameどちらも） ・直近にプレイしたGame と Assessmentの成績（偏差値） など Threshold 手動（CVが良い値で固定） ・trainの分布とはかけ離れる ・色んな分布の形が合ってよいと判断（APTOSコンペの知見） ▪概要
8. 3. コンペ序盤（個人参加）
9. ベースモデル作成（しゃおろん） 9 「地力をつける」を目標に、カーネルはなるべく見ずにベースモデルを作る →時間はかかったものの、public:0.52 まで上昇 【ベースモデル】 3. コンペ序盤（個人参加） My approach Model LightGBM (single) Validation GroupKfold (k=5) Feature ユーザー行動を割合化した特徴量がメイン ・プレイしたゲームセッションに占める各titleの割合 ・発生したイベントに占める、各event_codeの割合 ・成功失敗を表すevent_codeの比率を（3020 / 3010 など） Threshold 手動（CVが良い値で固定） →trainの分布とはかけ離れるが、色んな分布の形が合ってよいと判断（APTOSコンペの知 見）
10. 4. コンペ中盤（チーム結成）
11. しゃおろんpart（何も分からない） 11 • public：0.546 まで上げた後、停滞期に入る • CV上がる→LB下がるをひたすら繰り返す（30サブくらい） • かなり辛かった 4. コンペ中盤（チーム結成） 上手くいかなかったこと Model ハイパラ変更（カテゴリ指定、木の深さ変更） Validation StaratifiedGroupKfold →単体では上がらないが、seedアンサンブルで利用 Feature 特徴量選択 →feature Importance、類似特徴量の削除 特徴量追加 →成績の偏差値（履歴全部）、日時に関する特徴 など Threshold trainのヒストグラム寄せ Scipy.optimizeでの最適化
12. しゃおろんpart（ブレイクスルー） 12 成績の偏差値特徴量をラグ特徴量化してみる →public 0.558で大幅に上昇！（最終サブに使用） • CV大幅up→LB大幅down を繰り返していた特徴量 • ラグ特徴量（「過去1回」や「過去3回の平均」）とすることでLBも大幅up →trainとtestの履歴の長さが異なる問題に対処できたのでは 4. コンペ中盤（チーム結成） title 正解率 titleの 平均正解率 偏差値 （平均との差） Aさん Bird Measure 0.7 0.3 0.4 Bさん Mushroom Sorter 0.7 0.8 -0.1 Cさん Air Show 0.3 0.6 -0.3 ▪偏差値の計算方法
13. にのぴら part 13 4. コンペ中盤（チーム結成） 例の0.547kernelをベースに乱数で0.552を出す(チームマージ) 自作で試行錯誤していたがPBの誘惑に負け手を出す 乱数ガチャに勝利し、早々0.552が出る (当時約30位)(ただし、、、、) (後から見るとadversary validationした奴がメダル圏内だった、、、) hourは本当に効いていたのか？ LightGBMのimportanceは大きかったが、shap的には微妙 重要度の見方を学ぶ シンプルなLDA効かず悔しい チームマージして、title列などの任意列へのLDA実装を担当する さっぱり精度出ず、実装ミスなどへの疑心暗鬼。凹む。 上位陣に「任意の列 + (true or false)」を1列としLDAをしているチームも
14. Idem part 14 [KDD 2018]xDeepFM: Combining Explicit and Implicit Feature Interactions for Recommender Systems • DeepなFactorization Machineをいくつか試す • Click-through rate (CTR) predictionでユーザーと商品の交互作用を表現するために提 案されているモデル。 → 本コンペではInstallation_id（ごとの履歴）とtitleの交互作用を学習させた • アーキテクチャの変更によっても精度は向上したが、特徴量エンジニアリングの方が 効果は大きかった • アンサンブル時のモデルの多様性に期待できるので、時間に余裕あれば取り組むくらいにしたい XDeepFM 特徴量をグループごとに Embedding Embedding間の交互作用を 暗示的かつ明示的に学習 4. コンペ中盤（チーム結成）
15. Makotu part 15 4. コンペ中盤（チーム結成） • 参加したのが年末からでなかなか貢献できなかった… • カーネルをベースにいくつか特徴量を追加したくらい • Install_id毎にAssessの実施確率をモデリングして特徴量にした • 他にも色々作ったけど、多分これだけある程度効いてた （カーネルベースなので）Adjust_factorありでLB0.550くらい • Late joinでteamingをしてみた個人的感想 • 既にコンペに習熟しているメンバーと知識とスコアの差が大きく 「高スコアを出さないと…」というプレッシャーがかかりやすい。 • むやみに自分も高スコア出そうと頑張るより、明確に 貢献するポイントを絞った方が良いなと学んだ(反省） Ex. 気になる部分の可視化/基礎集計/stacking…
16. 5. コンペ終盤（アンサンブル）
17. アンサンブルで苦戦 17 スタッキングや重み付き平均を試すも、シングルモデルを超えられず • Testの予測分布がモデルごとに大きく違った • 学習時のmetricがモデルごとに違うから？（QWKとRMSE） • ajust_factorありとなしが混在しているから？ • 予測値のランク化を試すも上手くいかず 5. コンペ終盤（アンサンブル） Train Test ▪各モデルの予測値（計15モデル）
18. 6. コンペ振り返り
19. Trust CV is all you need 19 • 本コンペにおいては、「Trust CV」が正解だった（と思う） • 少なくともLBの信頼性は低い • 上位ソリューションの多くが Trust CV でモデルを改善している 6. コンペ振り返り 0.5 0.51 0.52 0.53 0.54 0.55 0.56 0.5 0.51 0.52 0.53 0.54 0.55 0.56 0.57 Private Public ▪PublicとPrivateの相関（過去100サブ）
20. なぜ Trust CV できなかったか 20 • 「CVの切り方にミスがない」という自信が持てなかった • リークがあるかもしれない • Trainに過学習しているだけかもしれない • ここまで極端にブレると思っていなかった • 劇的にスコアが下がったら、リークを疑ってしまった（0.54→0.52等） • 「1000サンプル」と「QWKのブレやすさ」を甘く見ていた • LeaderBoardが気になる • 順位が上がらないと、全く進んでいない感覚に陥る • どうしても目先の順位を上げたくなる 6. コンペ振り返り 【結論】 Trust CV できる人はすごい
21. カーネルは理解して使うことが大事 21 • 本コンペでは、Publicにoverfitした高スコアカーネルがあった • Shakeが起きた原因の1つになったのは間違いない • 鵜呑みにせずに、きちんと理解することの重要性を痛感 • 分からない内容はDiscussionに投稿してみるのもあり • 「ajust_factor(※)」について意見が分かれたので、投稿してみた • 「使わないほうが良い」という判断の助けになった 6. コンペ振り返り ▪とある高スコアカーネルのPublicとPrivate ※特徴量ごとにtrainとtestの平均の比(ajust_factor)を計 算し、testにajust_factorを掛ける処理のこと。 上記の高スコアカーネルで使われていた
22. 以上 ありがとうございました