Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
NLF 9th place solution
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
yuki
March 29, 2023
Technology
890
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
NLF 9th place solution
yuki
March 29, 2023
More Decks by yuki
See All by yuki
Claude Code の 地味に知られてなさそうな機能 7選
yururoi
0
10
yukiCup 2023 Summer 開催報告
yururoi
0
2.3k
ChatGPTでAutoML作ってみたかった
yururoi
0
1k
鳥蛙コンペ - Team Exodia
yururoi
3
800
Other Decks in Technology
See All in Technology
あけおめLINE 傾向とその対策
nasa9084
0
340
.NET WebAssemblyで実現するクライアントサイドAI推論:NuGetからViteまで、2つのエコシステムを繋ぐビルド戦略
yamachu
1
950
AIに会社の文脈を理解させる技術~上流工程・非エンジニアにも広げるハーネスエンジニアリング実践~
ochtum
0
130
AI感のないAWS構成図をAIエージェントに描かせたい!
sagochiko
2
440
【Findyテック文化祭ワークショップ】新卒エンジニア&採用担当と作る、 なりたい姿と今やるべき一歩
dip_tech
PRO
0
110
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
4
1.3k
Snowflake Horizon Catalog と Apache Iceberg で作る オープンなデータ基盤
kitagawaz
0
180
メルカリにおけるAI時代の高速プロトタイピング基盤「Arca」
ryotarai
15
12k
What the customer really needed
kawaguti
PRO
3
230
技術的負債から考える、AI時代のエンジニアリング投資 — ビズリーチの技術的負債と向き合った経験から、変更し続けられるソフトウェアを考える/ technical-debt-con2026
visional_engineering_and_design
4
3.9k
データ_AIの事業の勝敗をわけるもの
nek0128
1
480
営業オントロジーの作り方と、エージェントからの辿り方 ── ナレッジワークの現場から
kworkdev
PRO
0
110
Featured
See All Featured
Visualization
eitanlees
153
17k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
590
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
510
Become a Pro
speakerdeck
PRO
31
6.3k
Technical Leadership for Architectural Decision Making
baasie
3
580
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
250
KATA
mclloyd
PRO
35
16k
Everyday Curiosity
cassininazir
0
330
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
370
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.6k
Transcript
NFL コンペ 9th place solution
誰? 名前:yuki Twitter:@yuki93753711 趣味:kaggle バイク ステッカー配り 2
コンペ概要 NFLの試合の中で起こったプレイヤー同士の衝突、とプレイヤーと地面の衝突を予測する • 提供されていたデータ • 動画 • Endzone(ゴール側からの動画) • Sideline(サード側からの動画)
• All29(全体を俯瞰する動画) • ヘルメットのbboxデータ • Endzone、Sidelineはヘルメットのbboxを提供 • 昨年のwinner solutionで作ったデータ • Trackingデータ • 座標 • スピード • 加速度 • など • 評価指標 • Matthews Correlation Coefficient 3 Endzone All29
結果 チームで9位。ゴールドメダル獲得🎉 4
ソリューション (Overview) CV:0.791/Public:0.782/Private:0.775 5 ffmpeg YOLOv5 <Endzone> Efficientnet-b0 <Sideline> Efficientnet-b0
MLP 2nd stage channel 0 channel 2 channel 1 YOLOでプレイヤー領域をクロップ。 CNNの入力はプレイヤー画像のほかに、衝突を検出するプレイヤーの ヘルメットbboxと、全プレイヤーのヘルメットbboxのチャネルを追加。 ffmepgを使って 動画を各フレームの画像に変換 Endzone画像、Sideline画像をそれぞれEfficientnet に入力し、中間ベクトルを取得。中間ベクトルはセンサー データと結合したあとMLPに入力し衝突を予測。 Endzone、SidelineのEfficientnetの重みは共有。 動画データ センサーデータ trackingデータ NN 入力したフレームの予測だけでなく、 前後のフレームも予測するように学習。 前後のフレームの予測値は2nd stageで活用。 予測値 Feature Engineering Feature Engineering Resources: RTX3090*1、 RTX3080*1 (VRAMは8GB程度しか使わなかった) NN 次のような特徴量を作成 ・プレイヤー間の距離、プレイヤー同士が同じチームか、 スピードの差分、プレイヤーが向いている方向がどのくらい 近いか、プレイヤーの最大スピード、これらのshift徴量 (多くの特徴量を作ったが、効いたのは少なかった)
ソリューション(2nd stage) 6 LightGBM LightGBM LightGBM Moving Average seed値アンサンブル。(単純平均) 閾値が重要となるので、Seed値アンサンブルす
ることによってfoldごとのばらつきを均す狙いがあ る。 移動平均で平滑化。 移動平均のWindowはプレイ ヤー同士の衝突と地面との衝突 それぞれで探索 センサーデータ Feature Engineering NN予測値 LightGBM Simple Average 次のような特徴量を作成 ・プレイヤー間の距離 ・プレイヤー同士が同じチームか ・スピードの差分 ・NNの予測値 ・プレイヤーのスピード ・これらの履歴特徴量 Submission.csv 1st stageのCNNが2DCNNで時間方向の情報を扱えていないので、 LightGBMにshift特徴量を含めることで、時間軸の情報を補っている。 1st stage CV:0.769 -> 2nd stage CV:0.791
スコア推移 GBDT 特徴量エンジニアリングすれば するほど精度あがるので楽しい NN NNのnotebookが公開されて、 順位を落としたので着手 アンサンブル この頃から本当にやることがなくなる。 アンサンブル試すも精度改善は僅か
t-1からt+1を予測 極意本を読みマルチタスクを思い出す bbox channel追加 これを思いついた時は「天才か?」 と思ったけどみんなやってた YOLO ちょっと上のチーム名がちらつきYOLOを試す LGBM 2nd stage この頃時間を考慮したモデルを作れていないこと に課題を感じていたた。 LGBMにshift特徴量を使用
効かなかったものなど • 2.5DCNN • 多くのチームが採用していた。自分はうまく扱いきれず、2DCNNとほとんど精度が変わらず、 2.5DCNNは学習データ作成に時間がかかるため早々に切り捨てた • Tracking座標のマッピングデータ • プレイヤーの位置関係が重要ではと考えたが、これ単体では精度出なかった
• All29 • 人の検出などもうまくできず、使える形にできなかった。(他のチームもうまく活用できてなかった) • P2PとP2Gでモデルを分けた • ひょっとしたら効果あったかもしれないが、2モデルを作るのが大変で途中でやめた • 大きな画像、大きなモデル • 画像は128*128で十分だった • モデルもefficientnet-b0で十分だった • 1st stageで精度あがるが2nd stageでは精度よくなないということが続き苦しんだ • NNのテーブルデータは特徴量エンジニアリング頑張っても精度改善できなかった • PMIPで特徴量の寄与を確認して半分くらい削った 8
その他 • 高速化のために学習時画像は全部メモリに乗せた。推論時もメモリに乗る限り乗せた • Submit時にバグが混入することが度々ありデバッグに時間をとられた • CV改善してなくてもたまにsubmit • 学習notebookをほとんど修正なしでsubmitできるように修正 •
Localで作成したtestと推論時のtestが一致することを確認 • 最初からチーム組んでワイワイやりたかった! • ソロゴールドがかかっていたのでぎりぎりまでチーム組まなかった • 残り1週間でチームマージできることは意外と少ない。いくらチームメンバーからよい手法を教えてもらっても、モデルの構造を大きく変え るような実験を残り1週間でやるのは大変。アンサンブル+αぐらいが限界。アンサンブルのために急いで推論notebook高速化した • 過去のNFLコンペのソリューションあまり読まなかった。読めばよかった • みんなTSM使っててコンペ終わって「何それ?」ってなった 9