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 03, 2025
Technology
1
8
人材領域での企業と求職者のマッチング最大化
2025/2/20に開催したRecruit Tech Conference 2025の中間と若月の資料です
Recruit
PRO
March 03, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
4
18
技術的ミスと深堀り
recruitengineers
PRO
3
19
『ホットペッパーグルメ』における マルチプラットフォーム化の歩み
recruitengineers
PRO
2
10
『じゃらんnet』アプリ 改善活動の軌跡
recruitengineers
PRO
2
6
『スタディサプリ for SCHOOL』における Flutter導入とその成果
recruitengineers
PRO
2
9
よりよいビジネスの「実現」のために エンジニアリングを発揮する
recruitengineers
PRO
3
20
イテレーティブな開発で 不確実性を乗り越える
recruitengineers
PRO
3
7
株式会社リクルート 社内ISUCONの裏側
recruitengineers
PRO
1
13
エンジニア主導の企画立案を可能にする組織とは?
recruitengineers
PRO
1
22
Other Decks in Technology
See All in Technology
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
210
サイト信頼性エンジニアリングとAmazon Web Services / SRE and AWS
ymotongpoo
7
1.5k
AIエージェント時代のエンジニアになろう #jawsug #jawsdays2025 / 20250301 Agentic AI Engineering
yoshidashingo
8
3.6k
スキルだけでは満たせない、 “組織全体に”なじむオンボーディング/Onboarding that fits “throughout the organization” and cannot be satisfied by skills alone
bitkey
0
170
RayでPHPのデバッグをちょっと快適にする
muno92
PRO
0
190
RemoveだらけのPHPUnit 12に備えよう
cocoeyes02
0
280
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
82k
Goで作って学ぶWebSocket
ryuichi1208
3
2.7k
クラウド食堂とは?
hiyanger
0
110
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
10
3.7k
Raycast Favorites × Script Command で実現するお手軽情報チェック
smasato
1
140
Change Managerを活用して本番環境へのセキュアなGUIアクセスを統制する / Control Secure GUI Access to the Production Environment with Change Manager
yuj1osm
0
100
Featured
See All Featured
KATA
mclloyd
29
14k
GraphQLとの向き合い方2022年版
quramy
44
14k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
Site-Speed That Sticks
csswizardry
4
400
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Navigating Team Friction
lara
183
15k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Embracing the Ebb and Flow
colly
84
4.6k
Transcript
人材領域での企業と求職者のマッチング最大化 RECRUIT TECH CONFERENCE 2025 Two-Towerモデルと近似最近傍探索による候補生成ロジック導入 中間 康文 株式会社リクルート データ推進室 若月 良平
株式会社リクルート データ推進室
目次 • 自己紹介 • 取り組みの背景・課題 • 課題解決 - Two-Towerモデルと近似最近傍探索による候補生成ロジック導入 •
Two-Towerモデル • 近似最近傍探索 • 構成 • 成果 • 展開状況
自己紹介
中間 康文 アニメ・漫画・ゲーム・野球・釣り 経歴 / Career 2021年にリクルートに新卒入社。 DSとして、HR領域の各プロダクトにおける レコメンドシステムの改善に取り組む。 Two-Towerモデルと近似最近傍探索による候補生成
ロジック導入の案件が、リクルートのナレッジ共有 イベント(FORUM)に選出される。 Kaggle Grandmaster。 趣味 / Hobbies プロダクト開発統括室 データ推進室 HR領域データソリューションユニット HRデータソリューション部 中途データサイエンスグループ
若月 良平 ゲーム・散歩 経歴 / Career 2018年にリクルートに新卒入社。 内製ワークフローエンジンの開発 / HR領域の各
プロダクトにおけるレコメンドシステムの改善など に取り組んできた。 Two-Towerモデルと近似最近傍探索による候補生成 ロジック導入の案件が、リクルートのナレッジ共有 イベント(FORUM)に選出される。 Kaggle Grandmaster。 趣味 / Hobbies プロダクト開発統括室 データ推進室 データテクノロジーユニット アジリティテクノロジー部 アジリティエンジニアリング1グループ
取り組みの背景・課題
HR領域のプロダクトにおけるレコメンド • 求職者のレジュメや行動履歴に基づくレコメンド • メールでのレコメンド、アプリでのリアルタイムなレコ メンドなど、面は様々 • レコメンド対象となる求職者と求人票のペアは、兆単位 • 2-stageレコメンドを採用
2nd-stage 1st-stage Reranker 求職者 求人票 候補生成 高精度の並び替え 計算量の削減
課題:1st-stageの候補生成 • レコメンド対象の増加が見込まれている中で、計算効率の改善が必須 • 既存の候補生成は主にルールベース(ある属性が一致する等)が担っていた ◦ 計算効率を改善しながら候補生成の精度を維持・改善することは難しい 1st-stage 求職者 求人票
候補生成 計算量の削減
ルールベースによる候補生成 C 求職者が直近N日間に 閲覧した求人票 求職者が過去に閲覧した求人票の属性との完全一致 A or B A B
A A
ルールベースによる候補生成:計算効率が悪い 求職者 100万 ⇩ 1000万 100万 求人票 • 全ペアが計算対象なので計算効率が悪い •
レコメンド対象の増加に対してスケールさせにくい 単純に計算量10倍にもなりえる
ルールベースによる候補生成:精度の維持・改善が困難 A A' A'' A A', A''も残したい • 計算量を削減しながら精度を維持する =>
困難 • 計算量を一定に保ちながら精度を改善する => 困難 • 例えば、完全一致条件だと属性の意味的な近さが考慮されない
ルールベースによる候補生成:精度の維持・改善が困難 推薦候補 A 求職者が閲覧した求人票 A A A B A B
B B B • 完全一致条件だと微妙な行動を反映するのが難しい 完全一致条件の問題 Aに興味があるはず Bはたまたまクリックしただけかも
課題解決案:ルールベースの精緻化? • ルールベースを精緻化することも可能だが…… ◦ 定量的には、Recall, Precisionを改善 • 微妙な類似度を捉えるには限界がある • 効果的な計算量調節も困難
課題解決案:協調フィルタリング? 協調フィルタリングは類似度を捉えられ、計算量を制御しやすい手法だが、コー ルドスタートの問題がある 求職者\求人票 A B C D E X
◯ ◯ - ◯ - Y - - ◯ - ◯ Z ◯ ◯ ? ? ? 新規求職者W ? ? ? ? ? ◯ : 閲覧あり ? : 推測対象 XとZの類似性 → ?は◯と推測 新規求職者W → 何もわからない
課題解決 Two-Towerモデルと近似最近傍探索による候補生成ロジック導入
Two-Towerモデルの導入 • ルールベースフィルターをTwo-Towerモデルに置き換える • 計算効率の改善と候補生成の精度の改善どちらも狙う 1st-stage 求職者 求人票 候補生成 ルールベースフィルター
→ Two-Towerモデル
Two-Towerモデル Embedding Encoder Feature • ニューラルネットワークで求職者と求人票をベクトル化 • それぞれ同じ空間に埋め込むことで、類似度を計算できる 求職者 求人票
Embedding Encoder Feature
近似最近傍探索 求人票 求職者 IT系 IT系に興味 近似最近傍探索 • 近似最近傍探索により各求職者に近い求人票を指定件数だけ高速に取得可能 Encoder Feature
Embedding Embedding Encoder Feature
Two-Towerモデルの利点:機械学習モデルで改善しやすい 過去実績 データ & A AND B OR…… • ルールベースを精緻化するには作り込みが必要
• → 全て機械学習モデルに押し込める
Two-Towerモデルの利点:質的な改善 A' A'' A A A A A B A
B 丁度良い点に求職者を配置 求職者が閲覧した求人票 • 完全一致の必要はない • 求職者属性と求人票属性に応じた柔軟なフィルターを獲得 • 細かいロジックをアドホックに実装する必要はない
Two-Towerモデルの利点:コールドスタートに対処 属性A 属性B 属性C 求人票ID:123 (0.2, 0.1,...) (0.2, 0.1,...) •
協調フィルタリングではコールドスタートの問題がある • → 属性特徴量を使うことでコールドスタートに対処できる
近似最近傍探索の利点:計算効率の改善 • ルールベースの全ペアの計算から、近似最近傍探索に変更 ◦ 埋め込みベクトルを使ったインデックスの構築も必要だが、十分に高速 • → 求職者数、求人票数に対してスケーラブルに 求職者 100万
⇩ 1000万 100万 求人票 求職者あたりに紐づける求人票数 が固定であれば、計算量も固定
Two-Towerモデルと近似最近傍探索による候補生成 • 整理すると、課題については以下のように解決できる • 計算効率の改善 ◦ 求職者と求人票をTwo-Towerモデルでembeddingに変換 ◦ 近似最近傍探索により、各求職者に近い求人票を指定件数だけ取得 ◦
計算量をコントロールできる • 精度の改善 ◦ 計算効率を維持しながら、候補生成の精度を改善することができる ▪ 特徴量を追加しても全体の計算効率はほとんど変わらない ▪ 機械学習モデルで改善しやすく、質的な改善が見込める ▪ コールドスタート問題にも対処
Two-Towerモデル
ネットワーク構造:概観 Numerical FC Layer FC Layer FC Layer FC Layer
Embedding Categorical Embedding Layer Numerical FC Layer FC Layer FC Layer FC Layer Embedding Categorical Embedding Layer 同カテゴリ は共有 求職者 求人票
ネットワーク構造:コード例 同カテゴリは共有 各エンコーダー 各Embedding 類似度
特徴量の例 • 求職者の数値特徴量例 ◦ 求職者の数値属性 ◦ 行動した求人票の数値属性の 集約 ◦ 別の手法で作られた埋め込み
ベクトル • 求職者のカテゴリ特徴量例 ◦ 求職者のカテゴリ属性 ◦ 行動した求人票のカテゴリ属 性のTopN • 求人票の数値特徴量例 ◦ 求人票の数値属性 ◦ 別の手法で作られた埋め込み ベクトル • 求人票のカテゴリ特徴量例 ◦ 求人票のカテゴリ属性
特徴量の前処理 • 数値特徴量 ◦ np.log1pによる対数変換 ▪ StandardScalerやRobustScalerよりも精度がよかったため ▪ 総当たりで試してみて、一番精度が良いパターンを適用 •
カテゴリ特徴量 ◦ カテゴリ値のエンコーディング ◦ embeddingのサイズはカテゴリ値のユニーク数に応じて決定
求職者のTopNカテゴリ特徴量の扱い 行動属性 • 1,2,...,N番目に多く行動した求人票のカテゴリ属性の埋め込みベクトル ◦ 各ベクトルの加重平均を取ったものをモデルに使用 Top1 Top2 Top3 w1
w2 w3 w1 0.5 w2 0.3 w3 0.2 重みも学習
モデル学習 https://storage.googleapis.com/pub-tools-public-publication-data/pdf/b9f4e78a8830fe5afcf2f0452862fb3c0d6584ea.pdf • 対照学習(Contrastive Learning) ◦ 行動が発生した求職者×求人票ペアのバッチを取得、バッチ内で負例作成
モデル学習:細かい話 • バッチサイズ ◦ 2048などで学習 ◦ 総当たりで試してみて、一番精度が良いパターンを適用 • 学習環境 ◦
GPUの方が高速だがモデルが軽ければCPUで十分 • 対照学習のペア ◦ クリックや応募のペアを使用 ◦ 総当たりで試してみて、一番精度が良いパターンを適用
オフライン検証 1st-stageの候補生成の精度はRecallで評価 1. 学習データと評価データを用意 a. 行動が発生した求職者×求人票ペアのリスト b. 学習/評価は時系列の前後で分割 2. 学習データを使ってTwo-Towerモデルを学習
3. 評価データの全求職者と全求人票に対して埋め込みベクトルを計算 4. 近似最近傍探索で取得した求人票に対するRecallを計算 オフライン検証において、+5%以上の改善を確認
高速なモデル改善 config.yml • 特徴量の追加 • 特徴量の処理方法指定 • モデルのパラメータ指定 • 学習のパラメータ指定
根本的な変更以外は なるべくconfig.yml管理 • レコメンド対象の増加に向け短期でオンラインで結果を出したい ◦ 高速な実験サイクルを回しやすいスクリプト群 ◦ オフライン実験50回以上
近似最近傍探索
近似最近傍探索 • 大まかな手順 ◦ 全求人票の埋め込みベクトルを使ってインデックスを構築 ◦ 各求職者の埋め込みベクトルに近い求人票を取得 • 重要な指標 ◦
ビルド時間:インデックスを構築する時間 ◦ クエリ時間:1回の探索にかかる時間 ◦ リコール:最近傍探索の精度
近似最近傍探索アルゴリズムの例:HNSW • 実際にはどんな感じで近似最近傍探索をやっているか? ◦ 色々なアルゴリズムがある • HNSW ◦ グラフベースの近似最近傍探索アルゴリズムの一つ ◦
Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs ◦ https://arxiv.org/abs/1603.09320 Y. A. Malkov & D. A. Yashunin 2016
近似最近傍探索アルゴリズムの例:HNSW • 階層的なグラフ • 最下層は全ての点を含むとする • 目的の点に近い点を探索したい 第2階層 第1階層 第0階層
1. 最上層の点から出発 2. 目的の点にできるだけ近くなるよ うに階層内で移動 3. 下の階層に移動する 4. 2と3を繰り返せば良い
近似最近傍探索アルゴリズムの例:HNSW • グラフの構築(詳細は省く) ◦ 一点ずつ追加する ◦ 各点の高さはランダムに決定 ◦ 最上層のある点から出発し、 追加点に近くなるように移動
しつつ辺を張る • 計算量 ◦ ビルド:O(N log N) ◦ クエリ:O(log N) 第2階層 第1階層 第0階層
近似最近傍探索ライブラリ • 既存のライブラリを使用 ◦ 色々なライブラリのベンチマークが公開されている ◦ https://github.com/erikbern/ann-benchmarks • ビルド時間とクエリ時間が推論パイプラインに組み込む上で条件に合ったもの で、リコールが高いもの
◦ ScaNN ◦ hnswlib • 実データでは ◦ ビルド時間:~1分 ◦ クエリ時間:~1ミリ秒
近似最近傍探索:コード例 ライブラリで推奨され ているパラメーター 全求人票の埋め込みベクトル ある求職者の埋め込みベクトル
構成
前提 • メール配信用のレコメンド • 前日にバッチで全対象求職者に対する推薦リストを生成
構成(前) 学習バッチ LightGBM 求職者&求人票データ ルールベースフィルター+ LightGBM 送付 対象 LightGBM(2nd-stage)用 学習データ
構成(後) 学習バッチ LightGBM(2nd-stage)用 学習データ Two-Towerモデル用 学習データ LightGBM Two-Towerモデル 求職者&求人票データ+ 埋め込みベクトル
近似最近傍探索+ LightGBM 送付 対象 求職者&求人票データ
成果
成果 • 推論 ◦ レコメンド対象の増加に対応 ◦ 1st-stageのフィルター部分が約25倍高速化 ◦ 推論全体で約2倍高速化 •
KPI ◦ 閲覧数 +8.4% ◦ 応募数 +5.7%
展開状況
展開状況 • まずは、日次のバッチレコメンド(メールでのレコメンド)で導入 ◦ むしろ、速度が要求されるリアルタイムな基盤でこそ真価を発揮する • 現在ではリアルタイムなレコメンドにも導入済み • HR領域の各プロダクトに展開