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
atmaCup#16 3rd place solution
Search
chimuichimu
January 19, 2024
Technology
600
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
atmaCup#16 3rd place solution
chimuichimu
January 19, 2024
More Decks by chimuichimu
See All by chimuichimu
書籍紹介:アジャイルなチームをつくる ふりかえりガイドブック
chimuichimu
0
160
朝 Kaggle のすすめ
chimuichimu
3
730
atmaCup#19 2nd Place Solution
chimuichimu
2
510
Wantedly Visit における相互推薦システムの活用事例
chimuichimu
1
400
データ駆動で実現する、人と企業のマッチング
chimuichimu
0
190
PydanticAI × Logfire ではじめる LLM エージェントのモニタリング
chimuichimu
3
1.6k
ウォンテッドリーの推薦システム開発を支える評価とデプロイの仕組み
chimuichimu
1
2k
進化計算ライブラリ DEAP の紹介
chimuichimu
2
380
Spotify Web API を使った分析で新しいお気に入りアーティストを発見する
chimuichimu
3
380
Other Decks in Technology
See All in Technology
[2026 Oracle Technical Deep Dive] AI時代のデータベース基盤をどう選ぶ? Exadata Database Serviceの選択肢と使い分け (2026年9月17日開催)
oracle4engineer
PRO
0
200
おそらく日本で唯一のDevRelインターン生として
husengs7
0
140
AI臭い文章とは何なのか
nasuvitz
38
78k
プラットフォームを「作る」、 チームに「入り込む」
sansantech
PRO
0
580
個別開発で終わらせない。 現場の課題をプロダクトの強さに変える StockmarkのFDE
ktkrhr
0
550
ビジネスを止めない技術的負債の返済のための戦略とその手法 - 技術的負債と向き合う / Complexity and Simplicity
soudai
PRO
3
500
AI 時代の Azure エンジニアリング ~ 私たちは何を磨き、何を任せるのか ~
chack411
1
390
Incremental HTTP
kazuho
5
2k
Argo CDとAtlantisで実現するインフラ管理のセルフサービス化──小規模SREチームで支えるプラットフォーム
cassius7
0
280
freeeらしさをAIとともに作る / Creating the freee Experience with AI
ymrl
0
120
2026-10-01_MagicPod_QAハーネスエンジニアリングとQA組織の未来像
ynisqa1988
1
460
OpenSharing について熱く語る〜AI アセットの共有について〜
kameitomohiro
0
150
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
28
2.9k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
260
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
560
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
710
How to Ace a Technical Interview
jacobian
280
24k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
470
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
290
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
A Soul's Torment
seathinner
8
3.7k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.4k
Transcript
atmaCup#16 3rd place solution Jan. 20 2024 #16 atmaCup 表彰式&振り返り会
Chiaki Ichimura
自己紹介 • 市村 千晃(@chimuichimu1) • 仕事 ◦ データ分析R&D@SIer ← 金融系SE@SIer
• 好きなもの ◦ 犬 ◦ サウナ ◦ ゲーム ◦ データ分析コンペ 2
解法サマリ • 候補生成→機械学習によるリランキングの2段階推薦 • 特にトレンドを考慮した候補や特徴量の作り込みが重要だった 候補生成 リランキング ~ 10K ~
40 10 yado.csv 3
候補生成ロジック • 色々試したが、シンプルなロジッ ク(セッションに出現した宿、人 気宿、アソシエーションルール) が強かった ロジック TOP_K MAP@10 セッションに出現した宿
all 0.295 人気宿(同じ sml_cd 内) 10 0.150 人気宿(同じ lrd_cd 内) 10 0.127 類似宿(sml_cdと宿の属性が一致) 100 0.064 アソシエーションルール(1-hop) all 0.219 アソシエーションルール(2-hop) 100 0.160 Implicit Matrix Factorization (IMF) 10 0.115 Bayesian Personalized Ranking (BPR) 10 0.104 Item2Vec(I2V) 5 0.142 候補生成 リランキング yado.csv 4
トレンドを考慮した候補生成 • 全期間で計算した候補だけでなく、各期間のみで計算した候補(+特徴量) を加えることで精度が改善 • 例:人気宿 ◦ 「全期間での人気宿」と「各期間(train or test)のログのみの人気宿」を候補に
◦ 「全期間での人気ランク」と「各期間(train or test)のみでの人気ランク」を特徴量に 候補生成 リランキング yado.csv 5
リランキング • LightGBM Rankerでモデリング • そのままだと負例が多いので、負例をダウンサンプリング ◦ 正例:負例 = 1:50 → 正例:負例
= 1:2 • 合計100程度の特徴量を作成 ◦ アイテム単位(基本属性、全期間に対する各期間の閲覧数割合、など) ◦ セッション単位(セッションの長さ、閲覧した宿の部屋数の統計、など) ◦ アイテム*セッション単位(セッション内で何回出現したか、何番目に出たか、など) ◦ 類似度特徴量(宿の属性、行列分解の埋め込みベクトルの距離、など) 候補生成 リランキング yado.csv 6
ablation study 条件 LB (MAP@10) LB (Rank) 最終sub 0.4458 3
without アンサンブル 0.4453 3 without アンサンブル、トレンドを考慮した候補と特徴量 0.4386 28 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量 0.4436 9 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量、機 械学習によるリランキング(*1) 0.4361 38 *1 : セッションに出現→アソシエーションルール→人気宿の順で候補を埋める単純なルールベース (工夫の余地はまだ全然ある) 7
ablation study 条件 LB (MAP@10) LB (Rank) 最終sub 0.4458 3
without アンサンブル 0.4453 3 without アンサンブル、トレンドを考慮した候補と特徴量 0.4386 28 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量 0.4436 9 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量、機 械学習によるリランキング(*1) 0.4361 38 アンサンブルの寄与はそこまで大きくない シングルモデルでも同等の順位のスコアが出せた *1 : セッションに出現→アソシエーションルール→人気宿の順で候補を埋める単純なルールベース (工夫の余地はまだ全然ある) 8
ablation study 条件 LB (MAP@10) LB (Rank) 最終sub 0.4458 3
without アンサンブル 0.4453 3 without アンサンブル、トレンドを考慮した候補と特徴量 0.4386 28 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量 0.4436 9 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量、機 械学習によるリランキング(*1) 0.4361 38 トレンドを考慮した候補と特徴量が 入賞圏にいくためには重要だった *1 : セッションに出現→アソシエーションルール→人気宿の順で候補を埋める単純なルールベース (工夫の余地はまだ全然ある) 9
ablation study 条件 LB (MAP@10) LB (Rank) 最終sub 0.4458 3
without アンサンブル 0.4453 3 without アンサンブル、トレンドを考慮した候補と特徴量 0.4386 28 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量 0.4436 9 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量、機 械学習によるリランキング(*1) 0.4361 38 セッション出現宿、人気宿、アソシエーションルールだけでも 10位以内に入れるスコアを出すことができた *1 : セッションに出現→アソシエーションルール→人気宿の順で候補を埋める単純なルールベース (工夫の余地はまだ全然ある) 10
*1 : セッションに出現→アソシエーションルール→人気宿の順で候補を埋める単純なルールベース (工夫の余地はまだ全然ある) ablation study 条件 LB (MAP@10) LB
(Rank) 最終sub 0.4458 3 without アンサンブル 0.4453 3 without アンサンブル、トレンドを考慮した候補と特徴量 0.4386 28 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量 0.4436 9 without アンサンブル、類似宿・IMF・BPR・I2Vの候補と特徴量、機 械学習によるリランキング(*1) 0.4361 38 機械学習によるリランキングによりスコアが大きく伸びた 11
ablation study まとめ • アンサンブルによる寄与はあまりなかった • トレンドを考慮した候補と特徴量が重要だった • シンプルな候補生成ロジックだけでも、10位以内に入る精度が出せた •
機械学習モデルのリランキングによりスコアが向上 12
反省点 • データの特性上、単純にRankerを作ると 「入力が同じだがラベルが違う」学習 データができてしまいがち • このラベルのノイズに対応できると優勝 スコアだった。コンペのユニークな点に 対応するスキルが足りなかった •
詳細は以下ディスカッション参照 ◦ https://www.guruguru.science/competitions/22/discussions/97f57d26-5c69- 4fcf-9cad-9240075f11a1/ ◦ https://www.guruguru.science/competitions/22/discussions/f1c6b804-6c60- 4987-8a6a-572052dc20a5/ 実力不足を痛感する筆者のツイート 13
実験管理 • 実験ログはNotionで管理 • 再現のしやすさのため、1実験ごと に1フォルダ作ってコードもデータ も全部そこに入れる Notionの実験ログのイメージ 14
まとめ • 解法 ◦ 候補生成→機械学習によるリランキングの2段階推薦 ◦ 特にトレンドを考慮した候補や特徴量の作り込みが重要だった • 全体を通じて ◦
シンプルな課題設定だが奥が深く、様々な工夫が活きる楽しいコンペだった ◦ 問題設定やデータの特性に対して対応する力が足りないことを自覚でき、参加してよかった 15