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
atmaCup#16 3rd place solution
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
chimuichimu
January 19, 2024
Technology
580
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
140
朝 Kaggle のすすめ
chimuichimu
3
700
atmaCup#19 2nd Place Solution
chimuichimu
2
480
Wantedly Visit における相互推薦システムの活用事例
chimuichimu
1
380
データ駆動で実現する、人と企業のマッチング
chimuichimu
0
170
PydanticAI × Logfire ではじめる LLM エージェントのモニタリング
chimuichimu
3
1.5k
ウォンテッドリーの推薦システム開発を支える評価とデプロイの仕組み
chimuichimu
1
1.8k
進化計算ライブラリ DEAP の紹介
chimuichimu
2
360
Spotify Web API を使った分析で新しいお気に入りアーティストを発見する
chimuichimu
3
360
Other Decks in Technology
See All in Technology
SRE Lounge Hiroshimaへの招待
grimoh
0
590
Terraform共通モジュールをチーム横断で“変えられる”運用へ ― リリースと適用の分離
kekke_n
1
2.5k
AIと共生する開発者プラットフォーム:バクラクのモノレポ×マイクロサービス基盤
sakajunquality
2
3.2k
AIDLC_ヤフーショッピングの取り組み
lycorptech_jp
PRO
0
600
Amazon EVS で VCF 9.0 / 9.1 のサポート開始まとめ
mtoyoda
0
290
プロンプト_きのこカンファレンス2026_LT
yurufuwahealer
0
150
美しいコードを書くためにF#を学んでみた話
yud0uhu
1
400
依頼文化をやめる日 EM視点で語るPlatform EngineeringとInclusive SRE / Discussing Platform Engineering and Inclusive SRE from an EM's Perspective
shin1988
4
5k
【Claude Code】鹿野さんに聞く 私の推しの並行開発環境 大公開 / claude-code-parallel-2026-07-15
tonkotsuboy_com
9
4.4k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
事業価値を⽣み出すSREへ SREが担うべき意思決定の5層
kenta_hi
2
3.2k
グローバルチームと挑むプロダクト開発
sansantech
PRO
1
170
Featured
See All Featured
First, design no harm
axbom
PRO
2
1.2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
670
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
1
370
How GitHub (no longer) Works
holman
316
150k
ラッコキーワード サービス紹介資料
rakko
1
3.9M
The World Runs on Bad Software
bkeepers
PRO
72
12k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
970
Navigating Weather and Climate Data
rabernat
0
290
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
490
Docker and Python
trallard
47
3.9k
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.7k
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