PLAsTiCC Astronomical Classification に参加した話

Copyright © DeNA Co.,Ltd. All Rights Reserved.
コンペ参加報告
田口直弥
PLAsTiCC Astronomical Classification

2
自己紹介
 田口直弥 (タグチナオヤ)
⁃ 18 新卒 (配属後８ヶ月経過)
⁃ Data Science group
⁃ Kaggle expert
 Strength finder
⁃ 回復志向が１番上
• 短所を伸ばし、長所には手をつけないという素養
• kaggler に多い『最上志向』と真逆だけど kaggle master になれるのか…?

3
概要
 PLAsTiCC Astronomical Classification とは
 タイムライン (説明の都合上、時系列が若干前後)
 上位陣の解法
 その他学んだこと
 まとめ

4
概要
 まとめ

5
PLAsTiCC Astronomical Classification とは
 背景
⁃ 2019 年に完成する超高性能天体望遠鏡の観測天体を 15 種類に分類
• LSST (Large Synoptic Survey Telescope) のシミュレーションデータ
• LSST の完成により飛躍的に観測天体数が増えることもあり、train と test で
データ数がかなり異なる (train : test = 7848 : 3492890)
• 未知の天体を発見するため、train に存在しないクラスが test に存在 (class 99)
https://www.kaggle.com/michaelapers/the-plasticc-astronomy-starter-kit

6
 ドメイン知識
⁃ 赤方偏移 (↓ 以外にも原因はいくつか存在)
• 宇宙は常に膨張し続けており、天体間の距離も常に広がり続けている。よって
ドップラー効果により光が長波長 (赤) 方向に移動して観測される。
⁃ ２種類の赤方偏移計測法
• 分光的赤方偏移 (spec-z)
⁃ 非常に正確だが、計測コスト高
⁃ test のほとんどのデータで欠損
• 測光的赤方偏移 (photo-z)
⁃ 計測コスト低だが精度に難あり
⁃ 欠損無し
𝒗 = 𝑯 𝟎 𝑫 (Hubble's law)

7
 データ (２種類)
⁃ set metadata
• 各天体に付き１行 (座標系の features は使わなかったので入れてない)
• 天体に関するメタ情報
id
Deep drilling fields (観測点がいっぱい)
赤方偏移
Photo-z の err
宇宙のゴミ。塵の影響度
天体のクラス (trn only)天体までの距離

8
⁃ set data
• 各天体に付き複数行
• LSST による天体の観測記録 (観測時間はバラバラ)
どの波長帯の観測か
観測した光の大きさ
Flux の err
Detected == 1 だと基準値に比べて結構明るい
Modified Julian Date, 要は日付

9
⁃ プロットしてみると…？
活動銀河核…？
何かしらの超新星…？
太陽側 (昼に見える側) にいる
半年間は観測できない

10
 評価指標
⁃ weighted multi-class logarithmic loss
• クラス内天体数 𝑁𝑖 によらず、各クラスを天体数の面から平等に扱いたい
• 重要なクラスや難易度の高いクラスには重み付けをしたい
𝐿𝑜𝑔𝑙𝑜𝑠𝑠 = −
𝑖=1
𝑀
𝑤𝑖 𝑗=1
𝑁 𝑦𝑖𝑗
𝑁𝑖
⋅ ln 𝑝𝑖𝑗
𝑖=1
𝑀
𝑤𝑖
𝑀 : 全クラス数
𝑁 : 全天体数
𝑤𝑖 : class i の weight
𝑁𝑖 : class i の天体数
𝑦𝑖𝑗 : 天体 j が class i の場合 1, それ以外の場合 0
𝑝𝑖𝑗 : 天体 j が class i である確率

11
概要
 まとめ

12
コンペ最初期

13
コンペ最初期
 ハロウィン金圏チャレンジ -> 全員失敗
 overfit に苦しむ
⁃ object_id, spec-z を特徴に入れてた...

14
コンペ初期

15
コンペ初期
 Mamas 君がしばらくトップ
https://twitter.com/mamas16k/status/1048759834537947141

16
コンペ初期
 ひたすら特徴量エンジニアリング (↓ は終盤も含め作った特徴達)
⁃ flux の max や flux err の mean 等基本的な特徴
⁃ photo-z 等を使って補正した flux を使った特徴
⁃ detected (明るい部分) のみに絞った flux 系特徴
⁃ 平均 + (-) sigma 以上 (以下) のみに絞った flux 系特徴
⁃ 最大光度周り N 日のみに絞った flux 系特徴 (overfit)
⁃ mjd を x, flux を y としたグラフについての尖度・歪度
⁃ tsfresh 等周波数などを捉えるツールにより作成した特徴
⁃ 波長帯別・間の ↑ 特徴量の差・比
⁃ ↑特徴量に基づくいくつかのメタ特徴

17
コンペ初期
 効いた特徴達
⁃ detected == 1 の mjd の max-min-diff (from kernel)
• 単発系のイベントとそれ以外の区別に役立つ...？

18
コンペ初期
 効いた特徴達
⁃ photo-z 等を使って補正した flux の min, max-min-diff
• 例えば flux は距離の二乗をかけると実値に近づく (球の表面積、4𝜋𝑟2
)
⁃ 波長帯毎の detected 割合の分散

19
コンペ初期
 特徴選択
⁃ train が少ないこともあり、特徴選択をする必要あり
• 強い人々はだいたい 100 ~ 200 features
• LGBM ではそこまで変わらないが、NN ではかなり有効
⁃ 自動特徴選択手法の模索
• LGBM 5 fold cv の gain の変動係数 (std/mean) が小さい順
• LGBM の split と gain 正規化後の合計値の大きい順 (onodera san)
• LGBM の null importance (matsuken san)
⁃ target を shuffle して求めた importance と shuffle しない場合の
imporgance の乖離が少ないと意味のない feature とみなす手法

20
コンペ中期

21
コンペ中期
 チームマージ w/ onodera san, akiyama san, okumura san
⁃ Stardust Crusaders 誕生

22
コンペ中期
 Class 99 (test にしか無い天体)
⁃ Class 99 用手元評価手法発案 (akiyama san)
• CV (cross validation) において、ある１クラスの天体を全て欠損させて
class 99 用の手法を手元で試行錯誤
⁃ 色々試したがうまくいかず、Olivier の手法 (from kernel) 系を最後まで利用
⁃ 異常検知手法利用
• 1 class svm (matsuken san)
⁃ test より train のほうが異常値が
多くなってしまい、結局使わず…
𝑝99 =
𝑖
(1 − 𝑝𝑖)

23
コンペ中期
 NN 使用開始
⁃ MLP (kernel base)
• 構造 -> (n-features, 512, 512, 256, 128, 64, 14)
• BN, DO (0.5 とか大きめ)
⁃ RankGauss Scaler
• 特徴量を rank に置き換え、max で scaling, mean が 0 になるようシフト等
した後 erfinv にかける
• Standard scaler に比べて 1.XX 代で LB 0.1 良化
⁃ SGD (下の２設定が best)
• lr=0.6 , momentum=0.9, scheduler=*0.6/5iter
• lr=0.01, momentum=0.9, decay=1e-4, nesterov=True
⁃ ELU

24
コンペ中期
 Band feature-wise 1D-CNN (1 channel)
⁃ passband 毎の feature に関しては 1D-CNN で関係性を抽出
⁃ 若干のスコアアップがあったが overfit がひどく、また重いので結局使わず...
band-i-flux-mean
b0 b1 b2 b3 b4 b5 b0 b1 b2
band-i-flux-max
b0 b1 b2 b3 b4 b5 b0 b1 b2 …
…
1D-CNN 1D-CNN
… … …… …
non-band-wise features
…
concat
Dense layers
output

25
コンペ中期
 SE (Squeeze-and-Excitation) Block の応用 (matsuken san)
⁃ 元々は channel への重み付けを学習
⁃ CNN でない NN においては各要素に対して sigmoid をかけてゲート
を表現
https://arxiv.org/pdf/1709.01507.pdf

26
コンペ終盤

27
コンペ終盤
 チームマージ w/ matsuken san
⁃ Stardust Crusaders★ミ誕生 (写真はチーム名変更前)

28
コンペ終盤
 超新星の template fit (okumura san)
⁃ 各クラスの代表的な形である template をいくつかの parameter を動かし
て各天体に fit させ、その parameter を特徴に使用
⁃ 上位チームはほとんどやっていたが、template から自作したのは
うちだけ...？
• 他チームが利用していた外部ライブラリは速度や今回のデータとの親和性を懸念して
利用しなかった

29
コンペ終盤
 その他 okumura san 系特徴 (結構効いた)
⁃ Flux の min ~ max の範囲を10等分し、その区間をまたぐ回数をカウント
⁃ detected = 1 の左 (右) 端とそれぞれに最も近い右 (左) 側の
detected = 0 との mjd の差
• 下図の用に、超新星が半年区間によって欠損したか否かを判断可能
この区間

30
コンペ終盤
 Post processing (onodera san)
⁃ 天の川銀河内外でのクラス分け
• train においてあるクラス群は天の川銀河内のみに、それら以外のクラス群は
天の川銀河外のみに存在
• 予測値も天の川銀河内外の天体で存在し得ないクラスを 0 埋め -> 0.02 程良化
⁃ 謎 weight
• Validation 予測値において、各クラスに固定の重みをかけて予測値を最適化し、
同様の重みを test の予測値にもかける
• 重みは勾配降下法で算出
𝑝′𝑖𝑗 = 𝑊𝑖 ⋅ 𝑝𝑖𝑗

31
コンペ終盤
 目的関数
⁃ 評価関数を直接目的関数にするのが一般的
⁃ 弊チームでは通常の logloss で求めた 𝑞𝑖𝑗 に重みをかける最適化も利用
• 評価関数において 𝑦𝑖𝑗 を 𝑞𝑖𝑗 に置き換えれば交差エントロピーの最小化により
下式のようにすれば良いことがわかる
• test における 𝑁𝑖 は予測値から算出
𝐿𝑜𝑔𝑙𝑜𝑠𝑠 = −
𝑖=1
𝑀
𝑤𝑖 𝑗=1
𝑁 𝑦𝑖𝑗
𝑁𝑖
⋅ ln 𝑝𝑖𝑗
𝑖=1
𝑀
𝑤𝑖
参考 : https://ja.wikipedia.org/wiki/%E4%BA%A4%E5%B7%AE%E3%82%A8%E3%83%B3%E3%83%88%E3%83%AD%E3%83%94%E3%83%BC
𝑝𝑖𝑗 =
𝑤𝑖
𝑁𝑖
⋅ 𝑞𝑖𝑗

32
コンペ終盤
 ３層 bi-LSTM (enc-dec model) auto encoder を使った欠損補完 (1/2)
⁃ pivot_table し、flux を５日毎にリサンプリング
⁃ err 考慮した目的関数設計
⁃ 欠損箇所は masking してロスをかけない
https://arxiv.org/abs/1711.10609

33
コンペ終盤
 ３層 bi-LSTM (enc-dec model) auto encoder を使った欠損補完 (2/2)
⁃ 見た目結構うまくいったように見えるが、エンコードされた情報および補完後の
flux から作った特徴のどちらもがスコアに寄与せず

34
コンペ終盤
 アンサンブル
⁃ akiyama san, onodera san, matsuken san, taguchi の
lgbm, nn (seed avg 後) を weight 0.125 ずつで単純平均
最終日の submit 戦略 (朝日が...)

35
コンペ終了

36
コンペ終了
 結果
⁃ 金圏届かず…

37
コンペ終了
 結果
⁃ Kaggle expert へ

38
概要
 まとめ

39
上位陣の解法
 1st place solution (Kyle Boone, ガチ astro 勢)
⁃ Gaussian Process により欠損補完後、できたデータを test に似せるよう
いい感じに欠損させて data augmentation (7,848 -> 271,148)
⁃ Single LGBM でぶっちぎりの１位

40
上位陣の解法
 その他上位陣がやっていること
⁃ 時系列系 NN での直接学習 (pretrained by AE)
⁃ sncosmo 等既存のライブラリを使った template fitting
⁃ Pseudo Labelling
• うまく使えば結構効くが、スコア向上が無いチームもまぁまぁ存在
⁃ Class 99 の probing
⁃ Flux の補正
• Bayesian approach, k correction
⁃ spec-z の予測補完

41
概要
 まとめ

42
特徴管理について
 ひとまとまりの特徴群毎に管理するのが良い
⁃ ex) detected_feats.py -> detected_feats.pkl.gz
⁃ 意味的に理解しやすく、管理する特徴群数も手頃な数で済む
⁃ 各特徴名に特徴群名 (と実験 ID) を prefix として入れると管理が楽
⁃ 特徴群内の特徴は都度再作成することになるので、あまりにデータが
重いコンペだとそれに応じた対応が必要

43
実験管理について
 実験情報管理
⁃ 実験 ID で管理
• コードを実験 ID を引数に取らないと回らないように作ってしまうのもあり…？
⁃ 実験概要は spreadsheet 等で管理
• 個人的には server 上で完結したいので ~.md の表とかが良さそうだと
• 比較対象を明記
⁃ 実験詳細は実験 ID を入れた log file で管理
 コード管理
⁃ 実験毎にファイルを分ける
• 管理コスト、過去をたどるコストが低い
⁃ git で管理
• 実験毎にブランチを切る…？ただ管理コストがちょっと高い
きれいなやり方でやるよりも、管理コスト等を考慮して
実現・運用可能なやり方とるべき

44
概要
 まとめ

45
まとめ・感想
 チームマージは計画的に
⁃ コンペの内容話せて良いけど、submission 数が限定されるので時期は
考えるべき
 時間の余裕と心の余裕確保大事
⁃ AE やったんだから時系列モデルでの予測できたはず…
 ドキュメントちゃんと読むの大事
⁃ pandas, lightgbm 周りで知らないことによる損失が多すぎた…
 コンペを走る土台固めに時間を使うの大事
⁃ 実験管理、特徴管理法は意識して作って行かないと非効率的
⁃ 不都合があれば都度変更を加えて行き、これによりどんどん洗練されていく
勝ちたかった…

PLAsTiCC Astronomical Classification に参加した話

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

PLAsTiCC Astronomical Classification に参加した話

Notes de l'éditeur