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
3
190
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
2025/2/20に開催したRecruit Tech Conference 2025の吉鷹の資料です
Recruit
PRO
March 06, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
40
問題解決に役立つ数理工学
recruitengineers
PRO
11
2.8k
Curiosity & Persistence
recruitengineers
PRO
2
190
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
410
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
180
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
340
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
350
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
2
250
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
5
180
Other Decks in Technology
See All in Technology
米国国防総省のDevSecOpsライフサイクルをAWSのセキュリティサービスとOSSで実現
syoshie
2
830
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
4
1.4k
初めてのAzure FunctionsをClaude Codeで作ってみた / My first Azure Functions using Claude Code
hideakiaoyagi
1
190
ObsidianをMCP連携させてみる
ttnyt8701
2
140
標準技術と独自システムで作る「つらくない」SaaS アカウント管理 / Effortless SaaS Account Management with Standard Technologies & Custom Systems
yuyatakeyama
2
1.1k
20250625 Snowflake Summit 2025活用事例 レポート / Nowcast Snowflake Summit 2025 Case Study Report
kkuv
1
240
Amazon Bedrockで実現する 新たな学習体験
kzkmaeda
1
410
OAuth/OpenID Connectで実現するMCPのセキュアなアクセス管理
kuralab
5
890
Oracle Audit Vault and Database Firewall 20 概要
oracle4engineer
PRO
3
1.6k
BigQuery Remote FunctionでLooker Studioをインタラクティブ化
cuebic9bic
2
230
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
180
PostgreSQL 18 cancel request key長の変更とRailsへの関連
yahonda
0
110
Featured
See All Featured
It's Worth the Effort
3n
184
28k
RailsConf 2023
tenderlove
30
1.1k
Building a Modern Day E-commerce SEO Strategy
aleyda
41
7.3k
How STYLIGHT went responsive
nonsquared
100
5.6k
Unsuck your backbone
ammeep
671
58k
A better future with KSS
kneath
239
17k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Git: the NoSQL Database
bkeepers
PRO
430
65k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
790
Thoughts on Productivity
jonyablonski
69
4.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画面に大きな枠を設置 ✔ オンライン推論の 機械学習アルゴリズムも導入 ✔ 検索アルゴリズムの改善も実施(後ほど詳述) ✔
『ホットペッパーグルメ』におけるレコメンドや検索等のデータ施策の導入や改 善は複数の要因によって進んでいなかった 以下の打ち手を実施することで、改善が進むようになった • 小さい成果から信頼を蓄積 • 密結合→疎結合なアーキテクチャへ • 開発方式/体制の変更 最初は非常に少ないメンバーでスタートでしたが、今では多くの仲間たちととも
に日々改善に取り組んでいます! 一緒に働いてくださる仲間も募集しています!! 興味があれば是非ご連絡ください!! まとめ