Kaggle LEAP Competition Solution解説&振り返り

Kaggleで行われたLEAP - Atmospheric Physics using AI (ClimSim)において3位に入賞したpaoによるコンペのSolution解説及び振り返り資料です。
こちらの資料は下記のイベントにて発表された資料です。
https://abeja-innovation-meetup.connpass.com/event/326148/

Transcript

1. Pao Kaggle LEAP Competition Solution解説
2. • pao @pppaaaooo ＠名古屋 • ABEJA CTO室 データサイエンティスト ◦ 2024/06 マネージャーらプレイヤーに • コンペ周り ◦ Kaggle Grandｍaster ◦ atmaCup 1st x 3 ◦ Kaggledays world championship 1st • 特技：短期間コンペ、⿇雀 ⾃⼰紹介 2
3. • ホスト: LEAP ◦ the Learning the Earth with Artificial Intelligence and Physics ◦ ⽶国国⽴科学財団 (NSF) の科学技術センター • 天候シミュレーションの結果を機械学習で予測する ◦ シミュレーターの計算コストが⾼すぎるので軽量版としてMLを使う • タスク：特定地点の複数⾼度の情報から、20分後の天候変化を予測 • 周囲の情報や時系列情報は与えられない。（使っちゃダメ） LEAPコンペについて 3
4. • 説明変数 ◦ Seq変数(60⾼度) ▪ 気温、湿度、雲の⽔分量 / 氷分量、⾵(東⻄、南北⽅向それぞれ) 、オゾン/メタン等の 含有量 ◦ Scaler変数 ▪ 地表気圧、太陽放射、表⾯フラックス、表⾯応⼒、アルベドなど • ⽬的変数 ◦ Seq変数 (60⾼度) ※20分後の変化量 ▪ 気温、湿度、雲の⽔分量 / 氷分量、⾵(東⻄、南北⽅向それぞれ) ◦ Scaler変数 ▪ 地表⾯での熱反射関連のフラックス(6種類)、降⾬率、降雪率 データカラム 4 ※計368個 全て連続値（回帰問題）
5. データカラム補⾜ 5 温度 ⽐湿 雲中の⽔分量 雲中の氷の量 東⻄⽅向の⾵ 南北⽅向の⾵ … ⾼さlevel 0 state_t_0 state_q0001_0 state_q0002_0 state_q0003_0 state_u_0 state_v_0 … ⾼さlevel 1 state_t_1 state_q0001_1 state_q0002_1 state_q0003_1 state_u_1 state_v_1 … … … … … … … … ⾼さlevel 59 state_t_59 state_q0001_59 state_q0002_59 state_q0003_59 state_u_59 state_v_59 … ⾼さlevel 59 ⾼さlevel 0
6. • train: 約1000万件、 test: 62.5万件 ◦ Public 20%, Private 80% • さらにtrain⾃体も元データのサブサンプル • 元データはhuggingface上で約5000万件 • 更に⾼解像度なデータもhuggingfaceに存在 ◦ 恐ろしくて触っていない データ量 6
7. カラムごとの決定係数（R2スコア）の平均 予測値を⼤きく外すと、とんでもないマイナススコアが出る 評価指標 7 最初にサブミットしたときのスコア
8. コンペ初期時点での考え 8 • データ量が多い, Targetカラム多い, ⽋損無し, 時系列要素あり → 勾配ブースティングよりNN • ⾼さ毎の説明変数‧⽬的変数 →シーケンシャルなNN系（1d CNN, LSTM, Transformer）で良さそう • 各地点での1レコード1予測 (周囲の情報や時系列情報使えない) →出来ることは割と限られている
9. 少し触って感じたこと 9 • 数値の桁数の扱いが⾯倒 ◦ 1e-40とかの値がある。float32で読み込むと正確さが失われる ◦ ⼀度1e+30をかけて処理をして最後に1e-30をかけるとかが必要 • ドメイン知識がなさすぎる！ ◦ →アルベド？フラックス？絶対湿度/相対湿度/⽐湿? • CVとLBの相関は綺麗に取れている
10. とりあえず買って流し読み 10 天気予報の難しさが分かった、なんとなくの関係性は分かった、面白かった しかしコンペそのものにはほぼ役に立たなかった....（後述）
11. 1. CNN + LSTMでベースライン作成 2. ⾊々調整しながら20位くらいに到達。ここでk_matさんとチームマージ 3. k_matさんが20%のデータで今の順位ということが判明。全データ使うと⾦圏に！ 4. Camaroさんも合流し、情報交換しながら⼆⼈でk_matさんを追いかける 5. 私の後処理でミスが判明。直したら⼀気にスコア伸びる！アンサンブルで⾦圏。 6. 終盤に⼊り、5倍ある全データの学習に⼿を出す。どのチームもこのへんで伸びだす。 7. 全データ学習でCamaroさんモデルが急激に伸びる（最終Camaroさんだけで5位相当） コンペ中の流れ（ざっくり） 11
12. 結果！ 12
13. • 特徴量 ◦ 相対湿度（相対湿度 = ⽔蒸気圧 / 飽和⽔蒸気圧） ◦ 全特徴量の⾼さ⽅向の⼀次微分(diff)、⼆次微分(diffのdiff) ▪ ⊿state_t = state_t(n) - state_t(n-1) • 学習 ◦ Huber Loss, AdamW ◦ Cosine annealing 1e-3 → 1e-5, 10 epoch ◦ ⾼さ⽅向のTargetのdiffも補助ロスとして予測 • モデル ◦ CNN+Transformer + LSTM （詳細は次ページ） コンペ解法（paoパート） 13
14. コンペ解法（paoパート）モデル詳細 14 ×4 • Feature Scale ◦ 各特徴量に対してax + bで変換 ◦ aとbは学習可能パラメーター ◦ カラムごとの正規化で⾼さ間でスケー ルが変わったものをモデルで修正して 欲しい気持ち • Other features proj ◦ scaler特徴量を⾼さ毎に異なるLinear 層で変換 ◦ 地表⾯からの⾼さによって影響変わる 部分を学習してほしい気持ち
15. 最近流⾏りのSqueeze former Conv層とMulti-head-attention層を組み合わせた Sqeezeformer Blockを繰り返している 元々⾳声認識⽤のモデルだが、シーケンス系のデータ でよく使われている Stanford Ribonanza RNA Folding: 2nd, 3rd Google - American Sign Language Fingerspelling Recognition: 1st HMS - Harmful Brain Activity Classification: 3rd 参考: SqueezeFormer 15 Squeezeformer: An Efficient Transformer for Automatic Speech Recognition https://arxiv.org/abs/2206.00888
16. • ドメイン特徴量いろいろ（流体⼒学の知識とかもあって強かった） • 複数の正規化⼿法を組み合わせ • モデルは、FiLM ConvのUnet • ScalerのTargetはUnetのbottomで予測 • 予測のHeadを種類毎に分ける（温度系、⽔蒸気系、⾵系） • ⽔蒸気系のTargetが(-Input / 1200) になるデータが⾒られた ◦ Targetが、(-Input / 1200)になるかどうかをHeadで予測。確度が⾼い ものは(-Input / 1200)を利⽤ チームメイトのモデル（k_matさん） 16
17. • 特徴量はK_matさんベース • ⾼さ⽅向のTargetのdiffも補助ロス • モデルは、Transformer onlyとTransformer + CNN • TransformerはCLIPのencoderを利⽤ • Transformer + CNNは、(Conv1d x 3 + TransformerLayer)の繰り返し • 全データ学習で、このTransformerが激強 チームメイトのモデル（Camaroさん） 17
18. • 元の値から作った特徴とNNの予測値を特徴量として、LightGBMで学習 • ptend_q0001, q0002, q0003の⼀部のカラムに適⽤ • 気温と雲中の⽔‧氷の関係を正しく学習させ直したい気持ち • 少しだけ改善（ 0.0004） • 時間的に、Camaroさんモデルにしか適⽤できなかった 2nd Stage on Camaro model 18
19. 最終パイプライン 19
20. • Kaggleデータのみだと、ドメイン特徴量が強かったが全データだと効果 が少なめだった • 全データになると、Transformerモデルが急激に強くなった チームのモデルとデータ量 20 • データ量が少ないうちは、明⽰的に作った特徴量が効いていたが、データ量が増 えるにつれ、モデル側で暗黙的に学習できるようになった • 全データになるとTransformerなどのモデルの表現⼒の⾼さが重要だった？
21. • ⾃分のソリューションを⾒返すと、「あれ？こんなけだっけ？」となる （⼤した独⾃性はない） • 今回のコンペの特性的に、独⾃性‧アイデアというより、NN細部の チューニング⼒や経験、実験数が⼤事だった気がする ◦ 上位チームはどこも経験豊富なチームが多い ◦ 優勝した⽅は直近の類似コンペにめっちゃ出ててノウハウが溜まっている⽅ • 計算リソースも重要だが、いかに効率的に実験を回せるかも⼤事 • ソリューションだけ読んでも「へぇ〜」ってなりがちなコンペ ソリューションを振り返ると... 21
22. • Model: Squeeze former • Loss: MAE • Auxiliary loss: 時間と場所をサブタスクで予測 • Confidence head ◦ 誤差の範囲を複数binに分ける ◦ そのうちどれに⼊るかを予測して、cross entropy loss • データのSoft clipping • 3つの正規化を全て結合 ◦ （カラム単位の標準化, カラム種別単位の標準化, 対数化） • 過去コンペのSolutionめっちゃ研究してる 1st ソリューション 22
23. • Model: LSTM baseで⾊々 ◦ residualなLSTM ◦ LSTM with cnn, mamba, transformerなど • Loss: smoothl1 loss • Auxiliary diff loss: level間の差をサブタスク（私と同じ） • LR scheduler: CosineAnealingWithRestarts(2cycle) • TargetをGroupに分けて、最後にGroup毎にfinetuning ◦ Group毎に1epoch最後に回す 2ndソリューション 23
24. • Model: ◦ Convnext, transformer ◦ 1D Unet-based model ◦ LSTM • Loss: smoothl1 loss • 学習率のスケジューラ調整がシビアだった • 特徴量: 相対湿度、特徴量の⼀次‧⼆次微分、q0002 / (q0002 + q0003)、 (q0002 + q0003)、q0002/q0003が0の場所を⽰すembedding等 • アンサンブル: 1d CNNでのStacking 4thソリューション 24
25. • 全データflattenにしてMLPしてからLSTM (5th) • clipや⼀部の期間のデータで最初学習してから全データ学習(11th) • TransformerにBEiT-v2ブロックを追加(9th) • 予測headの前にfno1d (Fourier Neural Operator )レイヤーを追加(9th) • Confidence-Aware MSE Loss (10th) ◦ This idea was variant of the @ryomak 's previously shared solution[2]. • Drop hard example (10th) その他Solution抜粋 25
26. • モデルはLSTM, Transformer, CNN様々 ◦ どのモデルでもちゃんと育てれば戦えた？ ◦ ただ1位が使ってるようにSqueezeFormer(transformer)は強かった？ ◦ ⼤量のデータを学習できる表現⼒があればよい？ • LossをMSEではなくMAEやSmoothL1, Huberに変えるのは⼤事だった • 特徴量や補助ロスなど学習の⼯夫の積み重ねはありそう • ActivationはGELUが多め • どのチームもモデルの学習に複数⽇かかるくらい回してる... Solutionの全体傾向 26
27. LEAPコンペのリーク問題について 27 • 元々ホストより、周囲の情報や時系列情報は与えられず、1レコードごと の学習‧予測をしてほしいという旨があった • データから位置情報‧時系列情報を復元できることが判明 ◦ →復元できないように、Testデータを⼊れ替え。コンペ2週間延⻑. • 終了直前、別⽅法で位置情報‧時系列情報を復元できることが判明 ◦ ディスカッションが⼤荒れ☔ • 再延⻑の案などもあったが、上位のソリューションで使っていないか？を ホストがチェックする（使ったら失格）形で幕を閉じる
28. LEAPコンペのリーク問題について2 28 • 最終どのチームもリークは使っていないとは思う ◦ Master/GMも多く失格になる/信頼を失うリスク‧デメリットが⼤きすぎる ◦ Prize以外はチェックは⼊らないので可能性はゼロではない • 揉めポイント ◦ ホストが「1レコードごとの学習‧予測をしてほしい」と⾔いつつ、終了直前まで 禁⽌するルールが明⽰されなかった。 ◦ 競技上の解釈を参加者に求められ、チームによって違う解釈、参加者同⼠での意⾒ 対⽴が発⽣してしまった（リークのあった過去コンペでもある話）
29. • データセットのサイズで、改善策が効くかどうかが変わりうる ◦ ⼩さいので試して良ければ⼤きいデータ...だけではない ◦ 早めに⼤きいデータも試しておいたほうが良い • Web Dataset便利 ◦ ⼤規模データでは幅広く使える • 過去コンペからのSolution理解は学習（改めて） • どこがコンペのポイントかの⾒極め重要（改めて） ◦ 今回はドメイン知識と思いつつ、いかにモデルの表現⼒⾼められるかが重要だった ◦ それはたまたまとも⾔えるし、ここを探し当てられるかが勝つための肝 ◦ ドメイン知識はほぼ役⽴たず... その他コンペでの学び 29
30. 30 以上です！ ありがとうございました！