初 Kaggle Microsoft Malware Predictionに参加しました
はじめに
- Microsoft Malware Predictionが終了
- 自分にとって初Kaggleだったが最後まで飽きることなく続けることができた
- 結果は(Pub:265位, Pri:673位)と奮いませんでしたが、学びが多かったのと身に着けるべき知識等がわかったので満足
- 次は CareerCon 2019 - Help Navigate Robots に参加予定
- ただのメモなのでご留意ください
自分の解法
ベースライン
- LightGBM. Baseline Model Using Sparse Matrix をベースモデルとして利用
- シンプルなコードながらシングルモデルでスコアも高かったため
- Train, Testの偏りを無くしたり、observationが少ないものをdropしたり、最後にOne Hot EncodingでSparceな行列を作ってLightGBMに突っ込んでいたりと、とても勉強になった
- このコードをforkして一行一行コードを確認して、どう改善していけばいいかアイディアを練った
- kaggleは一からコードを書くものなのか、それとも良さげなKernelをForkして自分なりに改変していくのかどっちがメジャーなんでしょう？
特徴量エンジニアリング
- とにかく自分が今まで経験した中でもデータが重かったので、取り回しだけでも大変だった
- 不要なカラム(skewed, missing等)の削除
- 似たような特徴量の削除
- Feature Importanceが高い特徴量の Interaction Feature なども追加したりした
- 公開カーネルを参考にして特徴量の追加 ms_malware_starteR
- Rだったので最初は無視していたが、参考にして特徴量を追加したら + 0.001ぐらい上がった
- こういう magic feature的なものはどう見つけるのか知りたい(センスや経験だと思うが)
- Target Mean Encodingを試したが、Pubilcのスコアはむしろ下がった(やり方が悪いのかも)
- 中盤くらいでもう何をしたらいいかアイディアが出なくなって手が動かなくなった
- これは経験と知識が全く足りないので、たくさんコンペ等に参加してノウハウをためていきたい
- 特徴量エンジニアリングはどのコンペでも使えるものと、ドメイン知識等が必要なものがあると思うので、とりあえず前者はマスターしたい
- バージョン系の特徴量にもっと注意を払うべきだった
ハイパーパラメータ チューニング
- 知識がなかったのでLightGBMのドキュメントを見ながら色々試してみただけ
- 自動最適化ツールが試せなかったので、次までにoptunaのチュートリアルでもいいのでやる
アンサンブル
- LightGBMと公開Kernelに自分で作成した特徴量を突っ込んだもののblendをしたりした
- 次はStackingも試したい
その他
- Kernelやdiscussionを読んで、分からなかった単語はググって Quizletという単語アプリに追加していって復習したりした
- 基本Kernelでやっていたが、メモリがどうしても足りない時があったので、GCEのプリエンティブ インスタンスを利用した
- Kernelのコードをコピって、GCEのファイルにペースとして python train.pyとかやっていたのでもっとスマートな方法を考えたい
- 試行錯誤した流れをメモ帳でもいいので書いておくようにする
- 同じ試行錯誤を何度かやっていた気がする。。。
- publicスコアの低めのkernelでも示唆を含んだものもあるので注意
- 今回のコンペはLightGBMばかりだったが、XGBoostがなかったのはなぜ？
- 一度XGBを使ったら学習が全く終わらなかったがなぜ？
上位入賞者の解法(随時追加予定)
6位 CPMP
本コンペの課題について
- train, public, privateの分布が明らかに違っている点
特徴量エンジニアリング
- バージョンに関する特徴量については integer encoding、sub featuresへの分解
- さらに LongYin によって提案されていたcounting features を使用
- target mean encoding、外部データからの日付を使用した、オリジナルデータまたは外部データなどに基づくさまざまな lag feature など探索をした
- これらはほとんど何もワークしていないようだった
Data processing
- データ（作成されたものも含む）は、train と test 間の分布差を減らすために処理
- オリジナルのデータを使用すると、Adversarial Validation で AUC 0.98を超える値が出ていたが、処理したデータでは AUC 0.7以下に抑えることができた
- 処train と test で頻度が非常に異なる値をマージ
- EngineVersionで例が以下の図
- 一つ目ぼ元のデータの train の頻度を赤で、test の頻度を青で示す
- 2番目の図は、処理後の値の頻度を示す
Cross Validation
- 私たちは層化5分割交差検証から始めましたが、これがあまり信頼できなかった
- 最終的に、5分割交差検証とさまざまな時間分割ベースのローカル validation を使用
- 3つすべての検証スキームとLBを使用して潜在的な feature をテストし、それらすべてを改善したもののみを受け入れた
- このテストに合格したものはほとんど何もない(以下で説明する1つの feature を除いて)
A magic feature
- magic featureは、同じEngineVersionにおけるMax AvSigVersion と AvSigVersionとの差
- この feature だけでプライベートLBスコアが0.02増加
Models
- LightGBM: pubLB 0.698
- Keras: pubLB 0.696
ML_Bearさん
特徴量エンジニアリング
- LBが完全時系列分断されている可能性があることを指摘しているKernelがあったため、特にバージョン系の特徴量の取扱に気をつけた
- AvSigVersionは日付に変換して日付として処理を行った
- ここは自分もやっていたがもう少し深掘りすべきだった
- 特徴量エンジニアリングは全部参考になるので勉強する
モデル
- LightGBMは特徴量180個くらい
- こんなに多いのは驚いた
その他
- データが重かったのでモデルを組んだり特徴量のテストをする時はデータを1/4程度にサンプリングして使ってました
- 自分はずっと全データでやっていたがサンプリングもありだなと思った
- とにかくデータが重かったので特徴量作成はBigQueryを主としていました。
- 自分もAthenaなりBigQueryなりを使えたらFeature Engineeringはだいぶ楽になりそう
