Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PLAsTiCC 3rd Place Solution
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Nomi
July 13, 2019
Technology
18k
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
PLAsTiCC 3rd Place Solution
Kaggle Tokyo Meetup #6の発表資料です。
https://connpass.com/event/132935/
Nomi
July 13, 2019
Other Decks in Technology
See All in Technology
AWS Security Hub CSPMの成功・失敗体験
cmusudakeisuke
0
540
アジャイルな経理と Claude Code と経営の未来
kawaguti
PRO
3
190
AI 不只幫你寫 Code: 當專案從 300 暴增到 1500, 我們如何撐住 DevOps
appleboy
0
220
從開發到部署全都交給 AI:實作 AI 驅動的自動化流程
appleboy
0
160
クレデンシャル流出 ― 攻撃 3 時間 vs 復旧 10 時間。この非対称性にどう備えるか
kazzpapa3
3
560
4人目のSREはAgent
tanimuyk
0
130
LayerX コーポレートエンジニアリング室におけるサプライチェーンセキュリティへの取り組み / Supply Chain Security at LayerX Corporate Engineering
yuyatakeyama
3
830
事業会社における 機械学習・推薦システム技術の活用事例と必要な能力 / ml-recsys-in-layerx-wantedly-2026
yuya4
0
160
元銀行員がAIだけでアプリを量産!「バイブコーディング実演セミナー 」
tatsuya1970
0
110
Microsoft のサポートとフィードバック総まとめ
murachiakira
PRO
0
110
2026-06-24_人とAIの責務分離に基づく開発プロセスの提案.pdf
takahiromatsui
0
120
AI時代のコスト管理を考えよう〜明日から使える実践AWSノウハウ~
yoshimi0227
0
860
Featured
See All Featured
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
160
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
210
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
5
1.1k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.5k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
420
Mobile First: as difficult as doing things right
swwweet
225
10k
The SEO identity crisis: Don't let AI make you average
varn
0
500
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.5k
Scaling GitHub
holman
464
140k
Transcript
PLAsTiCC Astronomical Classification 3rd Place Solution 2019/7/13 Kaggle Tokyo Meetup
#6 Nomi (nyanp) Team: Major Tom
自己紹介 ⦁ Nomi ( : nyanp) ⦁ Software Engineer @
大阪 ⦁ Kaggle : 2018/3~ ⦁ 深層学習FrameworkのAuthor (tiny-dnn, 2012~) ⦁ 特徴量エンジニアリングが好き
コンペの背景と概要
LSST ⦁ 2020年~運用開始の大型望遠鏡 ⦁ 従来を遥かに超える規模の全天観測 ◦ 3200メガピクセルの撮像素子 ◦ 10年で60PBのデータ収集 ◦
370億個の天体を観測 https://www.lsst.org/about
LSSTミッションの狙い ⦁ ダークマター、ダークエネルギーの解明 ⦁ 地球に衝突する危険がある小惑星の発見 ⦁ 銀河系の構造の理解 ⦁ 超新星などの突発天体・変動天体の観測 ◦
明るさが変動する星や銀河などの天体のこと ◦ 今回のPLAsTiCCが対象とする天体
Astronomical Classification ⦁ これまで人類が発見した超新星:約1万 ⦁ LSSTが10年間に観測する超新星: 約1000万 ◦ 人類が今まで見つけてきた超新星の総数を3日で超える ◦
機械学習による自動検出・分類はほぼ必須!
2 Data Processing Challenges in LSST ⦁ 突発天体の早期検出 ◦ イベントが終わる前に検出し、後続の観測機器で詳細にスペクトルな
どを観測したい ⦁ 突発天体・変動天体の自動分類 ◦ どの観測機器のキャパシティよりも速いペースで天体を検出し続ける ので、LSST自身でも天体の分類を行う必要がある ◦ PLAsTiCCはこちらのタスク
コンペ概要 ⦁ 観測データ(Light Curve)から天体を特定する多クラス分類 ◦ 全14種のクラス+Test Dataにのみ存在するClass 99 ◦ シミュレーションデータ
クラス分布は偏りが大きめ。一番少な いクラスでは30個しかラベル付き データがない
評価指標: Weighted Multi-Class Log Loss w: class iの重み (1 or
2) N: class iのデータ数 ⦁ Minority Classほど1データの重みが大きい ◦ GBDTの学習時にはsample_weight等の調整が必要
データセット概要 (1/2) ⦁ meta data: 天体ごとに1行 緯度経度 観測モード (0/1) 距離(赤方偏移)とその誤差
※speczはTestではほとんどが欠損 光の吸収効果
データセット概要 (2/2) ⦁ Light Curve: 6つの波長域での時系列観測データ ◦ 約3年間のWindowのどこかで天体が検出されている 時刻 波長域(1~6)
見かけの明るさとその誤差 (定常状態からの差分) S/N比が一定以上か
Light Curve ⦁ 天体が太陽側に隠れる時期は欠測する ⦁ 遠方の観測データほどfluxが小さく、ノイズも多い(右) https://www.kaggle.com/mithrillion/all-classes-light-curve-characteristics-updated
データセットの特徴 ⦁ Training 8,000件 vs Test 3,500,000件 ⦁ Test Dataは遠方の観測データ多め
⦁ Test Dataにしか無い未知天体“Class 99” ◦ 実際は特定の天体ではなく、いくつかの天体のミックス Training = 既存観測データ、Test = LSST、という問題設定
上位入賞への鍵 ⦁ 超新星以外は比較的容易に区別できた。時系列データから、どんな特徴 量/モデルで超新星のパターンを見分けるかがポイントだった。 ◦ 上位陣のアプローチは大きく3つ ▪ Gaussian Process ▪
NN (LSTM / RNN / 1D-CNN) ▪ Template Fit ⦁ Class 99をどう扱うのかもスコアを大きく左右した。 ◦ ただしPublic Kernel相当の手法でも金メダルまでは行けた
上位入賞への鍵 ホストがDiscussionに投稿した情報も有用だった。特にLSST Science Bookに は本コンペを戦う上での知見が詰まっていた。 https://www.lsst.org/scientists/scibook 突発天体の分類は光度と減衰時間が重要 (8-6) SALT-2 TemplateでSNIaとそれ以外の超新星を区別できる
(Fig11.5) クラスごとの距離分布 (Fig 11.7), 予想観測数 (Table 8.2)で、どのクラスが何か大体わかる
3rd Place Solution
The Team “Major Tom” yuval NN担当 TrackML 7th / Jigsaw(‘19)
暫定9th つよい。 mamas nyanp リーダー&Catboost担当 TalkingData 5th / Santander(‘19) 9th つよい。 LGBM&ドメイン知識担当 ニャンピョウ みんなKaggle歴は浅め (当時Expert x1, Contributor x2)
Solution Pipeline Yuval Features x 4 Nyanp Features x 581
Mamas Features x 2K 1DCNN (4 Fold) LB: 0.86854 1DCNN (4 Fold) LB: 0.85209 1DCNN (4 Fold) LB: 0.86854 LightGBM (Gal + Ex-Gal) x4 LB: 0.86542 (20th place) CatBoost (Gal + Ex-Gal1 + Ex-Gal2) x7 LB 0.82955 (13th place) Per-Class Ensemble LB: 0.75876 (5th place) Final Sub LB:0.70016 (3rd place) Class99 Postproc Avg. CNN LB: 0.81019 (8th place) Top 16 Top 16 ※LB and rank is based on private dataset
Key points ⦁ 1D CNN ⦁ Template Fit & ドメイン知識由来の特徴量
⦁ 2種類のPseudo-Labeling ⦁ LB ProbingによるClass 99推定
Key points ⦁ 1D CNN ⦁ Template Fit & ドメイン知識由来の特徴量
⦁ 2種類のPseudo-Labeling ⦁ LB ProbingによるClass 99推定
1D CNN (yuval) ⦁ 3種類の前処理を行い、128固定長 x18chに加工→1DCNNに入力 元の信号を線形補間 detected=1の系列のみ 残してから線形補間 最近傍の有効データ
との時間差 元データ 6ch
Architecture Input 1D Conv (k=8) +BN, LeakyReLu, Dropout 128 128
18 256 256 1D Conv (k=5) +BN, LeakyReLu, Dropout 128 256 1D Conv (k=3) +BN, LeakyReLu 128 256 Global- Max Pooling 256 14 Dense Dense Dense Dense 32 16 Input (Meta) 6 Galactic- Switch Input (hostgal_photoz) 14 1 photoz>0かどうかで 無関係なクラス側の 出力をマスク 時系列データを 長さ128 x 18chに加工 メタデータ側の特徴量 Light curveは 時間方向のシフトに対して invariant
CNN学習 ⦁ 学習時に以下のAugmentation ◦ ランダムに線形補間前の元データを削除 ◦ flux_errに基づいたランダムノイズ ◦ Cyclic Shift
◦ Skew : 各chをランダムに1+Δ倍 ⦁ Feature Engineering無しのSingle ModelでPrivate 22位 ◦ 仮にclass99 probeと合わせれば、特徴量無しでも金メダル相当
Key points ⦁ 1D CNN ⦁ Template Fit & ドメイン知識由来の特徴量
⦁ 2種類のPseudo-Labeling ⦁ LB ProbingによるClass 99推定
Template Fitting ⦁ 超新星の光量変化をモデル化した Templateが色々ある ◦ 例: SALT-2 ⦁ 観測データに当てはめた時のパラ
メータを特徴量に使う ◦ sncosmo等のパッケージが使える
Template Fitting is Slow... ⦁ 大体手元で1データ0.8秒くらい ◦ テストデータは3.5M rows ->
30日くらいかかる ◦ コア数を増やしてもスケールしない
Template Fitting is Slow... ⦁ 大体手元で1データ0.8秒くらい ◦ テストデータは3.5M rows ->
30日くらいかかる ◦ コア数を増やしてもスケールしない ⦁ 解法:インスタンスを30個立てて30倍速
さまざまなTemplate ⦁ 超新星のテンプレートにも色々ある ◦ 超新星の種類毎に異なるテンプレート ◦ 一部の参加者が使っていたSALT-2はClass90 (SNIa)向け ◦ sncosmoで試せるものだけで数十個
https://sncosmo.readthedocs.io/en/v1.5.x/source-list.html
さまざまなTemplate ⦁ 解法:全部試す ◦ CVでスコア上昇したものだけTest Dataを作ったので、実質は30インス タンス×15周ほど ▪ Final Modelには7種分のテンプレートを採用
▪ LGBMで~0.06の改善 (Golden feature of our solution)
Preemptible Instance牧場の一日 Terminated Terminated
結局60頭まで増えた $ $
その他の特徴量(1) - 光度(luminosity) ⦁ LSSTが観測する見かけの明るさ(flux):遠方ほど暗い ⦁ 天体そのものの光度は重要な特徴量 ◦ 距離とfluxから光度に変換するのが有効 luminosity
~ (max(flux) - min(flux)) * luminosity_distance ** 2
その他の特徴量(2) - TimeScale ⦁ 超新星は種類によって減光の時間スケールが違うので、それを 捕まえたい ◦ detected = 1の持続時間
◦ max(flux) - N% fluxの減衰時間/立ち上がり時間 ◦ fluxと時間の差をとり、arctanで角度に変換→集約 mjd 0 2 3 5 flux 10 15 23 32 mjd_diff 2 1 2 flux_diff 5 8 9
その他の特徴量(3) - Gaussian Process ⦁ Gaussian Processでフィッティングし、長さ100x6chの予測値 をそのまま特徴量に使う ◦ ライブラリはGPyを使用
◦ こちらもやっぱり~30日かかる ▪ mamasさんが30インスタンス使ってがんばっていた ⦁ 既にTemplate, CNNが出来た後だったのでLBの増分は少な かったが、diversityには効いた?
その他の特徴量(4) - tsfresh, feets ⦁ 時系列データの特徴抽出を専門にしたライブラリがあるので、 それらも活用 ◦ https://github.com/blue-yonder/tsfresh ◦
https://github.com/carpyncho/feets ⦁ 劇的に効いたものはないが、baselineとしては有用だった ◦ fft-coefficient, auto-correlation, skew, slope…
Key points ⦁ 1D CNN ⦁ Template Fit & ドメイン知識由来の特徴量
⦁ 2種類のPseudo-Labeling ⦁ LB ProbingによるClass 99推定
Class 90/42 Pseudo-Labeling (LGBM) ⦁ Class 90, 42 (SNla, SNll)に絞って実施
◦ Class 99に似たクラスでPLをやるとスコアを落とすので注意 ◦ LightGBMで~0.03くらい効いた 元データの1~10倍くら いの量のPseudo Label を加えるのがベストだっ た 左はx軸をPLの閾値、右はpseudo/real labelの比率で同じデータをプロット
Adversarial Pseudo Labeling (Cat / NN) ⦁ CatBoostで予測値が高く、かつTraining Dataに似ているサン プルを使ってTraining
⦁ 特にNNモデルでスコア向上 (~0.01)
Per-Class Weighting Ensemble クラス毎に異なる重みでアンサンブル。重みはoof predictionの 精度で決めた。スコアを~0.006ほど改善。
Key points ⦁ 1D CNN ⦁ Template Fit & ドメイン知識由来の特徴量
⦁ 2種類のPseudo-Labeling ⦁ LB ProbingによるClass 99推定
Class 99 ⦁ OCSVMのような通常の異常検知は上手く行かない ⦁ Public Kernelでのアプローチ preds_99 = np.ones(preds_.shape[0])
for i in range(preds_.shape[1]): preds_99 *= (1 - preds_[:, i]) →他のどのクラスとも似ていないときにスコアが上がる
Class 99 ⦁ 疑問:Class 99はどんな天体なのか? ◦ 候補1:あまり見つかっていないタイプの超新星 ◦ 候補2:AGNやマイクロレンズなど、それ以外の天体 ⦁
Class 99が何であるにせよ、どのクラスからも均等に遠い、と いうことはないはず
Class 99 ⦁ 疑問:Class 99はどんな天体なのか? ◦ 候補1:あまり見つかっていないタイプの超新星 ◦ 候補2:AGNやマイクロレンズなど、それ以外の天体 ⦁
Class 99が何であるにせよ、どのクラスからも均等に遠い、と いうことはないはず ⦁ じゃあクラスごとに異なる重みを付けてみたら? Kiを下げる =P(ci)が高いときのペナルティを弱める =Class99とciが似ていると扱う
LB Probing on Class 99 weighting ⦁ まずはClass 90の係数を2乗に →
スコア改善 ◦ 少なくともClass 90(SNIa)とは似ていなさそう ◦ 手ごたえを得たので、これ以降LB Probingに専念 元々SNIaは他と区別がつ きやすい超新星のため、ド メイン知識から考えても妥 当な結果。 当時の気持ち
LB Probing on Class 99 weighting ⦁ 超新星を中心に係数を調整し、以下の解に到達 ◦ Class
42や52, 62 (いずれも超新星)と良く似ている ◦ これだとPrivate 4th相当
最終形態 P(c99) *= (1-P(ci))**niの形を少し単純化し、コンペ最終日に以下 の式に到達 Probingによる利得は~0.06程度だった (Private 5th → 3rd)
None
振り返り ⦁ 3人の役割分担がうまく機能した。モデルの方向性が3者3様 で、アンサンブルの利得が大きかった ◦ yuval: 特徴量を作らずにCNNを作り込む ◦ mamas: 大量のhand-crafted特徴+CatBoost
◦ nyanp: template量産、ドメイン知識側で攻める ⦁ 最終1wをProbingに専念する判断が結果的に良かった
おわり / Any Questions? 本日のハイライト: Appendix(質問あれば): 他の上位解法 / GBDTモデリング /
CatBoostがなぜ強かった? / Feature Importance / Class99 の正体
以下補足
上位陣の解法 - 1st Place (Kyle) ⦁ Train Dataを遠方にシフトさせるAugmentation ◦ 発想は自然だが実際やるには要ドメイン知識
⦁ Gaussian Processでデータを補間し、その波形の上で 集約やTimeScaleなどの特徴量を作る Code: https://github.com/kboone/avocado/blob/master/avocado/plasticc.py Discussion: https://www.kaggle.com/c/PLAsTiCC-2018/discussion/75033#latest-457546
上位陣の解法 - 2nd Place (Silogram & Mike) ⦁ Class99を抜くと1位 ⦁
NNがとても強かった ◦ シンプルなBidirectional GRU ◦ 距離で割って波形を平準化 ◦ コードが綺麗なので読もう Code: https://www.kaggle.com/zerrxy/plasticc-rnn Discussion: https://www.kaggle.com/c/PLAsTiCC-2018/discussion/75059#latest-462457
モデリングの基礎部分 (GBDT Part) ⦁ 銀河系内モデルと銀河系外モデルに分割 ◦ 特定の列の値が0かどうかで完全に識別可能なため ◦ CatBoostでは、銀河系外モデルを2種類作っていた ▪
hostgal_speczを特徴量に含めたモデルとそうでないモデル ⦁ ValidationはN-Fold Stratified CV ◦ CVで効いた特徴量だけTest Dataの分を作り、時間短縮 ⦁ Metricに合わせてsample_weightを重み付け ⦁ CatBoostではアンサンブル時に異なる特徴量のサブセットで モデルを学習
Hyperparameter (CatBoost) { 'Learning_rate':0.1, 'depth': 3, 'loss_function': 'MultiClass', 'colsample_bylevel': 0.7
}
Hyperparameter (LightGBM) { 'objective': 'multiclass', 'metric': 'multi_logloss', 'learning_rate': 0.1, 'max_depth':
3, 'subsample': .9, 'colsample_bytree': .9, 'reg_alpha': 0, 'reg_lambda': 3, 'min_split_gain': 0, 'min_child_weight': 10, 'min_data_in_leaf': 1, 'n_estimators': 10000, 'max_bin': 128, 'bagging_fraction': 0.66, }
Why CatBoost worked well? CatBoostはカテゴリ変数の扱いが特徴的だが、今回のデータにはそれが生きるよ うな変数は存在しなかった。 仮説: depth=2~3が最適なことから分かるように、今回はGBDTで容易にoverfitするデー タだった。CatBoostの以下の機構がoverfitを抑制したのではないか。 ⦁
Symmetric Tree ⦁ Ordered Boosting
Ordered Boosting ⦁ (ざっくり言うと)t番目のデータに対する残差を計算する際に、t-1番目までの データで学習したモデルを使う ◦ CatBoostがカテゴリ変数のEncodingでやっていることに似ている ◦ サンプルが少ない(~数K)ときに過学習を防ぐ効果が高い https://papers.nips.cc/paper/7898-catboost-unbiased-boosting-with-categorical-features
7に対する残差を、1~6で学習したモデルの予測値 M6(x7)で求める。StackingのときにLeakを防ぐために oofを使うのと似た気持ち? データを間引く(右→左)ほど、Ordered Boostingによる改善幅が大きい
簡単な実験 ⦁ CatBoostはOrdered Boostingと、通常のBoostingを選択できる ⦁ 上記2つ+似たハイパラのLGBMで、CVと混合行列を確かめてみる CatBoost { 'learning_rate': 0.1,
'max_depth': 3, 'objective': 'multiclass', 'metric': 'multi_logloss', 'max_bin': 128, 'reg_lambda': 3, 'bagging_fraction': 0.66, 'colsample_bytree': 0.7, 'min_data_in_leaf': 1 } { 'Learning_rate':0.1, 'depth': 3, 'loss_function': 'MultiClass', 'colsample_bylevel': 0.7, #'boosting_type': 'Plain', } LightGBM boosting_typeを指定しない場合はデフォルトで Ordered Boostingが使われる。
実験結果 モデル Weighted LogLoss (10 Fold CV) CatBoost + Ordered
Boosting 0.6286 CatBoost + Plain Boosting 0.6647 LightGBM 0.6480 ⦁ 確かにOrdered BoostingによってCVが大きく改善 ⦁ この実験設定では、CatBoostがLightGBMよりも良かった ◦ 使う特徴量によっては逆になることもあるよう(相性?) LBは計算が間に合いませんでした。ごめんなさい … ※特徴量は200個、Extra-Galactic側の9クラスのみモデリング
CatBoost /w Ordered Boosting Confusion Matrix CatBoost /w Plain Boosting
特に難しいClass42/52あたりの精度がOrdered Boostingによって改善している。
mamas先生からのコメント
Feature Importance (CatBoost / ExtraGalactic)
Feature Importance (LightGBM / ExtraGalactic)
Class 99の正体 5つの天体のミックス(99%以上はILOTかCaRT) 超新星の一種(想定どおり!) これだけ銀河系内の object (数は非常に少ない) https://arxiv.org/pdf/1903.11756.pdf
Our solution code yuval https://www.kaggle.com/yuval6967/3rd-place-cnn mamas https://github.com/takashioya/plasticc nyanp https://github.com/nyanp/kaggle-PLASTiCC