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
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
Search
Recruit
PRO
March 06, 2025
Technology
2
150
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
2025/2/20に開催したRecruit Tech Conference 2025の吉鷹の資料です
Recruit
PRO
March 06, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
問題解決に役立つ数理工学
recruitengineers
PRO
11
2.6k
Curiosity & Persistence
recruitengineers
PRO
2
170
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
370
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
150
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
200
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
250
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
0
180
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
5
130
技術的ミスと深堀り
recruitengineers
PRO
3
120
Other Decks in Technology
See All in Technology
MCP でモノが動くとおもしろい/It is interesting when things move with MCP
bitkey
3
600
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
310
WindowsでGenesisに挑戦した話
natsutan
0
120
MagicPodが描くAIエージェント戦略とソフトウェアテストの未来
magicpod
0
280
"発信文化"をどうやって計測する?技術広報のKPI探索記/How do we measure communication culture?
bitkey
4
340
非root化Androidスマホでも動く仮想マシンアプリを試してみた
arkw
0
130
Kaigi Effect 2025 #rubykaigi2025_after
sue445
0
170
雑に疎通確認だけしたい...せや!CloudShell使ったろ!
alchemy1115
0
240
AWSを利用する上で知っておきたい名前解決の話
nagisa53
6
850
水耕栽培に全部賭けろ
mutsumix
0
140
20250514 1Passwordを使い倒す道場 vol.1
east_takumi
0
140
猫でもわかるS3 Tables【Apache Iceberg編】
kentapapa
2
250
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1370
200k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Making the Leap to Tech Lead
cromwellryan
133
9.3k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2k
Building Applications with DynamoDB
mza
94
6.4k
Music & Morning Musume
bryan
47
6.5k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
BBQ
matthewcrist
88
9.6k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Become a Pro
speakerdeck
PRO
28
5.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
179
53k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.7k
Transcript
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 RECRUIT TECH CONFERENCE 2025 ビジネス編 吉鷹 伸太朗 株式会社リクルート プロダクトディベロップメント室 グループマネジャー
吉鷹 伸太朗 最近犬をお迎えして日々悪戦苦闘中 経歴 / Career 2019年にリクルートに新卒入社。 『ホットペッパーグルメ』や『じゃらん』のレコメンド 施策等を多数推進。 2024年より飲食データサイエンスGのグループマネ
ジャーに任用。 趣味 / Hobbies データ推進室 販促領域データソリューション3ユニット (飲食・ビューティー) 飲食・ビューティーデータソリューション部 飲食データサイエンスG
• ビジネス編 ◦ 『ホットペッパーグルメ』におけるレコメンド・検索施策がどのように 進展していったか? 本日お話しすること
『ホットペッパーグルメ』は、国内最大級の飲食店情 報サイト 毎日多くの飲食店利用ユーザーが訪問・利用している 弊グループでは、膨大な店舗とユーザーのデータを活 かして、『ホットペッパーグルメ』におけるレコメン ドと検索の改善を取り組んできた ホットペッパーグルメ
レコメンドと検索における課題 レコメンド • Impression量の少ない一部画面にのみレコメンドが存在していた • 既存レコメンドには以下のような課題が存在していた ◦ 高々日次バッチの事前推論のみ ◦ 機械学習アルゴリズムが非導入
検索 • ビジネス的なリスクが内包されるため検索システムへの介入には慎重だった • そのため、既存検索アルゴリズムのチューニングは停止しており、 古いまま運用されていた
データ施策導入の壁 レコメンドや検索等のデータ施策の導入や改善には3つの壁が存在した • データ施策の実績が少なく、データ組織への信頼残高が少なかった → 他施策との兼ね合いで優先度が下がりがち • 改修する際の関係部署が多く、前述の優先度もあり工数取得が難航 • 開発期間が長く、仮説検証の試行が回せない
工数取得が難航して、計画が進まない 開発期間が長く、なかなかABテストへ進めない
打ち手①:小さい成果から信頼を蓄積 2019年〜2021年 検索ワード入力画面でのレコメンド 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった
打ち手①:小さい成果から信頼を蓄積 2019年〜2021年 検索ワード入力画面でのレコメンド 2022年 アプリトップ下部でのレコメンド 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった
打ち手①:小さい成果から信頼を蓄積 2023年 アプリトップ画面の刷新 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった
打ち手①:小さい成果から信頼を蓄積 2023年 アプリトップ画面の刷新 2024年 検索アルゴリズム改善 (*SIGIR-AP 2024 ポスター発表より) 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった
打ち手①:小さい成果から信頼を蓄積 小さい画面でのレコメンドからはじめ、徐々に施策規模を拡張していった 当初 データ組織 2名 ↓ 小さなレコメンド施策1つ データ組織 20名以上 ↓
レコメンド施策複数 検索アルゴリズム サジェスト … 現在
打ち手②:密結合→疎結合なアーキテクチャへ 疎結合なアーキテクチャを採用することで関係部署/工数を減少 Storage 環境① API 環境② BATCH 組織A 組織B 組織C
データ組織
打ち手②:密結合→疎結合なアーキテクチャへ 疎結合なアーキテクチャを採用することで関係部署/工数を減少 Storage 環境① API 環境② BATCH 環境① API 環境②
BATCH API 組織A 組織B 組織C データ組織 組織A 組織B データ組織 データ組織
打ち手②:密結合→疎結合なアーキテクチャへ 疎結合なアーキテクチャを採用することで関係部署/工数を減少 Storage 環境① API 環境② BATCH 環境① API 環境②
BATCH API 組織A 組織B 組織C データ組織 組織A 組織B データ組織 データ組織 データ組織で APIを用意 → 組織Cの介 在が不要に
打ち手②:密結合→疎結合なアーキテクチャへ 疎結合なアーキテクチャを採用することで関係部署/工数を減少 Storage 環境① API 環境② BATCH 環境① API 環境②
BATCH API 組織A 組織B 組織C データ組織 組織A 組織B データ組織 データ組織 自由度をもたせた通信に設計 ↓ データ組織側の改修だけで一 定の試行が可能に データ組織で APIを用意 → 組織Cの介 在が不要に
打ち手③:開発方式/体制の変更 • ウォーターフォール開発 → アジャイル開発へ変更 • レコメンド/検索改善施策において、 一定のスコープ内でデータ組織の人員をPM/PLへ設定 柔軟な開発の実施が可能に →
仮説検証の試行が早く回せるように PO=Producer PM=DATA PL=DATA Team Team ⋯ 体制の一例 Team ⋯ ⋯
データ施策導入の壁が解消! レコメンドや検索等のデータ施策の導入や改善には3つの壁が存在した • データ施策の実績が少なく、データ組織への信頼残高が少なかった → 他施策との兼ね合いで優先度が下がりがち • 改修する際の関係部署が多く、前述の優先度もあり工数取得が難航 • 開発期間が長く、仮説検証の試行が回せない
小さい成果から信頼を蓄積 密結合→疎結合なアーキテクチャへ 開発方式/体制の変更 ✔ ✔ ✔
レコメンドと検索における課題も解消! レコメンド • Impression量の少ない一部画面にのみレコメンドが存在していた • 既存レコメンドには以下のような課題が存在していた ◦ 高々日次バッチの事前推論のみ ◦ 機械学習アルゴリズムが非導入
検索 • ビジネス的なリスクが内包されるため検索システムへの介入には慎重だった • そのため、既存検索アルゴリズムのチューニングは停止しており、 古いまま運用されていた APPのTOP画面に大きな枠を設置 ✔ オンライン推論の 機械学習アルゴリズムも導入 ✔ 検索アルゴリズムの改善も実施(後ほど詳述) ✔
『ホットペッパーグルメ』におけるレコメンドや検索等のデータ施策の導入や改 善は複数の要因によって進んでいなかった 以下の打ち手を実施することで、改善が進むようになった • 小さい成果から信頼を蓄積 • 密結合→疎結合なアーキテクチャへ • 開発方式/体制の変更 最初は非常に少ないメンバーでスタートでしたが、今では多くの仲間たちととも
に日々改善に取り組んでいます! 一緒に働いてくださる仲間も募集しています!! 興味があれば是非ご連絡ください!! まとめ