Kaggle Data Science Bowl 2019 上位解法まとめ

編集履歴

'20/01/28: 3rd solutionを追加

これはなに？

Kaggleで10/24-1/23に開催されたData Science Bowl 2019コンペの上位解法まとめです。
1/27時点で公開されている10位以内の解法をまとめてみました。
Shake-up/downの激しいコンペでしたが、上位入賞されている方の解法には学ぶところが多く、上位に入るべくして入った方が多い印象でした。
流し読みしてまとめたので、間違っているところとかお気づきの点あればご指摘ください。
金メダル圏内のものがあと4つぐらい公開されていたので後で足そうと思います。

1st

1st place solution

Stats

private 0.568 / public 0.563

要約

LightGBMのシングルモデル(!)
Foldごとにシードを変えた5Fold

詳細

Validation

LBが不安定なので見なかった
以下2つのValidationSetを利用した
1. GroupK CV (installation_id / 5x5Fold)
  - QWKが不安定だったので加重平均RMSEを採用した
  - weight: the weight is the sample prob for each sample (We use full data, for the test part, we calculate the expectation of the sample prob as weight). (Assessmentが何回あったか、の逆数を取っている？)
2. Nested CV
  - 上記CVは直感に反する結果が出ることがあった
  - そのため、手元でTrainを分割してチェックに使った
    - 疑似train: 全ログを使った1400ユーザー
    - 疑似test: ログを一部打ち切った2200ユーザー
  - これを50-100回行って、(testの評価の?)平均をValidationとして確認した

Feature Engineering

量

2万個ぐらい特徴量を作って、null importanceで500個まで削った

内容

同じAssessmentか、類似したゲームに関連する特徴量が非常に大切だった。 (基本的にゲーム内の順序をもとに、ゲームが どのAssessmentと似ているか をマッピングした。)
mean/sum/last/std/max/slope を true attempt, correct true, correct feedback に対して算出した。
ログデータを以下のように分割して特徴量を作った
1. 全履歴
2. 過去5/12/48時間
3. 前回のAssessmentから現在まで
Eventインターバル特徴量を作り、mean/lastをevent_idやevent_codeでグルーピングして算出した。
- いくつかのEventインターバル特徴量はかなり効いていた
Videoスキップ特徴量を作った
- clip eventインターバル / clip時間で算出
- clip時間はオーガナイザーが出してくれてたもの
event_id / event code組み合わせに対する特徴量
- event_code2030_misses_mean

Feature Selection

重複した特徴量の削除
Adversarial AUC が0.5になるように削除
null importance (TOP500に)

Model

testでaccuracy_groupがわかるものはtrainに使った
trainにはRMSEを使い、validationには加重平均RMSEを使った

Ensemble

行っていない
0.8xLightGBM+0.2xCatBoostのアンサンブルモデルはprivate0.570だったが最終サブには使っていない(手元のCVが悪かったから)

2nd

2nd place solution

Stats

private 0.563 / public 0.563

要約

LightGBM / CatBoost / NN のアンサンブル
基本的な特徴量に加え、経過によって減衰させた特徴量やword2vecを活用。
集約する前のログの各行を予測する特徴量も活用。

詳細

Validation

1ユーザーあたり1サンプルになるようにリサンプル
StratifiedGroupKFold, 5-fold

Feature Engineering

基本的な特徴量

session, world, types, title, event_id, event_code をワールド別や全体でカウント
sessionごとに半減して減衰させてカウント
経過日数で減衰させてカウント
num_correct, num_incorrect, accuracy, accuracy_groupに対して大量の統計値を算出
前回のAssessmentからの経過時間

Word2Vec

Assessmentまでのタイトルの履歴を文章とみなす → word2vecでタイトルをベクトル化 → 集計

Meta Features

ログデータの各行にAssessmentの評価を付与→予測→集約出典

Feature Selection

重複した特徴量の削除
相関が高い特徴量の削除
null importance (TOP300)

Model / Ensemble

アンサンブル: 0.5 x LightGBM + 0.2 x CatBoost + 0.3 x NN
各モデルは 5seed averaging

3rd

Discussion

5-fold TRANSFORMER Model(Single Model)
private LB 0.562 / public LB 0.576
韓国の旧正月で忙しいからまた書くわ、とのことです。

('20/01/28追記: 書いてくださったので追記しました)

3rd solution - single TRANSFORMER model

前置き(意訳)

DNNで問題を解くのが好きだからなるべく多くの問題をDNNで解いている
データそのものの理解よりはデータの構造に着目し、なるべく情報の欠損がないようにモデルに入力するよう心がけている。
言い換えると、特徴量エンジニアリングよりもデータにより良くフィットするNNのネットワークデザインの発見により注力している。

詳細

注目すべき点

位置関係の情報はCVを下げたので、BERT/ALBERT/GPT2といったposition-embeddingを使うものは精度が良くなかった。
そのため、position-embeddingを使わないTransformerモデルを組んだ

Pre-processing

game_sessionごとにevent_code/event_id/accuracy/max_roundなどのカウントを集計
game_sessionを単語に見立ててシーケンスとしてモデルに入力する

Model

100 sessionを入れた (短いシーケンスはPADで埋めた)
embeddingの作り方
- Categorical変数: ['title', 'type', 'world']
  - 個別にembed→concat→nn.linearで次元削減
- 連続値の変数: ['event_count', 'game_time', 'max_game_time'] (+accuracy/max_round?)
  - np.log1pで正規化→nn.linearで直接embed
params
- optimizer: AdamW
- schedular: WarmupLinearSchedule
- learning_rate: 1e-04
- dropout: 0.2
- number of layers : 2
- embedding_size: 100
- hidden_size: 500

f:id:naotaka1128:20200129003840p:plain 出典

Loss function

accuracy_groupの定義を以下のように再構成した

new_accuracy_group = 3 * num_correct - num_incorrect
(num_incorrect: contrained not to exceed 2)
(new_accuracy_group >= 0 の制約も入れてる、はず…？)

[num_correct, num_incorrect] をターゲットとして、mseをmodified_lossとして扱った。
accuracy_group もtargetに入れて、最終的に以下のようにしてaccuracy_groupの予測とした

new_accuracy_group = 3 * num_correct_pred - num_incorrect_pred
final_accuracy_group = (accuracy_group_pred + new_accuracy_group) / 2

Data Augumentation

多く(30以上)のゲームセッションがあるユーザーのセッションをランダム除去した
- Train: 古い順に最大50%をランダム除去
- Test: 同60%をランダム除去

Data Augumentation (pre-train用)

Game typeのセッションからpre-train用の学習データを生成した
- Gameセッションのcorrectからnum_correct/num_incorrect/accuraby_group(のようなもの)を作ってデータを増幅
- 41,194のデータをtrainに加えることが出来た
- 学習方法
  - pre-train: original label + 上記の学習データ
  - fine-tuning: original labelのみ

4th

Stats

private 0.561 / public 0.572 (NNのブレンド)
private 0.560 / public 0.566 (3階建てStacking)

詳細

Validation

色々頑張ったけどうまく行かなかったからごく普通にやった

(installation_idのGroupKですらなかった)

Feature Engineering

testでaccuracy_groupがわかるものはtrainに使った
- 決定木系にいれると悪化したので使わなかった
いくつかのClipやタイトルは非常に重要だった
EventシーケンスのTfIDFを活用
- 各event_idをtitle + event_code + correct_flag + incorrect_flagに変換 → ユーザーのシーケンスを文章とみなす → TfIDF
- Assessment, タイトル, Assessmentの評価, だけにTfIDF使っても効かなかった
NNにはNNに適した特徴量を出すように心がけた
- タイトルのembedding (7次元)
- タイトルの正解/不正解数およびその比率
- タイトル開始時間からの経過時間(秒)
- 以前のタイトルの正解/不正解数およびその比率

Model / Ensemble

3階建てStacking (NNブレンドよりも弱かった)
1. RNNx3, lgbm, catboost
  - ダブルクロスバリデーション (5x5)
2. MLP(x100 starts averaging), Lightgbm(x100 seed averaging)
3. Ridge
全てのモデルは回帰で学習させた
code(NN)

7th

7th Place Solution

Stats

Private 0.559 / Public 0.559 / CV 0.575

要約

特徴量エンジニアリングが肝だった。最後は51特徴量を使った。(150個から削った)
0.3 LGB, 0.3 CATB, 0.4 NN のアンサンブルだった
20Foldのバギングを全モデルに適用し、NNはさらに3seed averagingを行った
testでaccuracy_groupがわかるものはtrainに使った
Validationではテストセットの構造を考慮して、各ユーザーから1Assessmentをランダム抽出した。

8th

8th place solution

Stats

Private 0.558 / Public 0.556

要約

シンプルな3層MLP(256x256x256)

詳細

Validation

5 GroupKFold
inversely weighted oof qwk をウォッチしていた
- discussionに書いた、らしい、

Feature Engineering

Preprocess
- Log transform → std transform
- fillna with zeros
- NaNだったことを示す新たな特徴量を追加
2サブのうち片方はtestでaccuracy_groupがわかるものをtrainに使った
- 使ったサブ: 0.559 private
- 使わなかったサブ: 0.552 private
主要な特徴量 (8thより上位にあったものは省く)
- titleのdurationが16分より長いものはクリップし、フラグを立てた。
  - 子どもたちが16分連続で同じタイトルをやってるのは考えづらい
- titleの平均ミスをround_durationで割ったもの
- リピート特徴量

Feature Selection

null importance
- 1100特徴量を作って216個を選んだ

Model

シンプルな3層MLP(256x256x256) x 9models(seed違いだけ?)
- 各層でBatch Normalization / Dropout 0.3
- 3xleaky Relu + 1linear
- ecpochは63/65/68と僅かに変えた
- Optimizer: Adam / BatchSize: 128
- learning_rate: 0.0003 w/cyclic decay
  - cyclic decay: コードが共有されている
accuracy_groupに加えて、3 x sqrt(accuracy)も目的関数として利用
- 離散値より多くの情報をモデルが学習できるように
- だが、あまり大きな影響はなかったとのこと
アンサンブル
- 9models x 2outputs = 18prediction のブレンディング
code

その他

thresholdは25回回してCVが一番良かったものを選んだ
trainのtarget分布に合わせるよりも最適化したほうが良かった

9th

9st place solution

Stats

要約

ほぼaggregation特徴量で特徴量エンジニアリング
いくつかの多様なモデルを作ってStacking
巨大なランダムサーチによるしきい値探索

詳細

Model

Stacking が非常に効いた
- LightGBM x 7 + NN x 1 → Ridge
LightGBM
- gbdt/goss/dart
- targetをいくつか利用した
  - accuracy_group
  - accuracy
  - accuracy_group > 2
  - accuracy_group > 1
  - accuracy_group > 0

Threshold tuning

公開KernelのOptimizedRounderは初期値に依存し、局所最適解に陥る挙動が多かった。
そのため、truncateしたtrainをランダムサーチするようにした。

10th

10th place solution

詳細

Validation

StratifiedKFold 10fold
各installation_idから1サンプルづつ(?)ランダム抽出
各Foldで51validation setsを利用
- 1つはearly_stopingに
- 残り50個でqwkの平均を取ってvalidation score算出する

Feature Engineering

3000-5000個ぐらい作って300個を利用した
magic featureはなかったと思う
主要な特徴量 (10thより上位にあったものは省く)
- 正規化したaccuracy系特徴量
  - タイトルごとに難易度が違うのでaccuracy系特徴量を正規化したものも利用した
  - 例: (Accuracy - Accuracy_mean_per_title) / Feature_std_per_title
- タイトルごとに特徴量を作った
  - 例: target_distances length in Air Show
  - 多すぎて10タイトル分作って挫折した

Feature Selection

LightGBMのfeature_importanceを元に300個を選んだ
各Foldで50個のデータセットを作り、5iterationごとにLightGBMのinit_modelパラメーターを使ってデータセットを変えた。(よくわからなかった…)

Model

LightGBM x 6seed averaging
feature_fractionは1.0にした
- タイトルごとに平均正答率が違うので全ての木で使うのが良かったのだろう

Threshold

local CV が最大化するしきい値を固定しこれをprivateでも利用した