人材領域での企業と求職者のマッチング最大化

2025/2/20に開催したRecruit Tech Conference 2025の中間と若月の資料です

Transcript

1. 人材領域での企業と求職者のマッチング最大化 RECRUIT TECH CONFERENCE 2025 Two-Towerモデルと近似最近傍探索による候補生成ロジック導入 中間　康文 株式会社リクルート データ推進室 若月　良平 株式会社リクルート データ推進室
2. 目次 • 自己紹介 • 取り組みの背景・課題 • 課題解決 - Two-Towerモデルと近似最近傍探索による候補生成ロジック導入 • Two-Towerモデル • 近似最近傍探索 • 構成 • 成果 • 展開状況
3. 自己紹介
4. 中間 康文 アニメ・漫画・ゲーム・野球・釣り 経歴 / Career 2021年にリクルートに新卒入社。 DSとして、HR領域の各プロダクトにおける レコメンドシステムの改善に取り組む。 Two-Towerモデルと近似最近傍探索による候補生成 ロジック導入の案件が、リクルートのナレッジ共有 イベント（FORUM）に選出される。 Kaggle Grandmaster。 趣味 / Hobbies プロダクト開発統括室 データ推進室 ＨＲ領域データソリューションユニット ＨＲデータソリューション部 中途データサイエンスグループ
5. 若月 良平 ゲーム・散歩 経歴 / Career 2018年にリクルートに新卒入社。 内製ワークフローエンジンの開発 / HR領域の各 プロダクトにおけるレコメンドシステムの改善など に取り組んできた。 Two-Towerモデルと近似最近傍探索による候補生成 ロジック導入の案件が、リクルートのナレッジ共有 イベント（FORUM）に選出される。 Kaggle Grandmaster。 趣味 / Hobbies プロダクト開発統括室 データ推進室 データテクノロジーユニット アジリティテクノロジー部 アジリティエンジニアリング１グループ
6. 取り組みの背景・課題
7. HR領域のプロダクトにおけるレコメンド • 求職者のレジュメや行動履歴に基づくレコメンド • メールでのレコメンド、アプリでのリアルタイムなレコ メンドなど、面は様々 • レコメンド対象となる求職者と求人票のペアは、兆単位 • 2-stageレコメンドを採用 2nd-stage 1st-stage Reranker 求職者 求人票 候補生成 高精度の並び替え 計算量の削減
8. 課題：1st-stageの候補生成 • レコメンド対象の増加が見込まれている中で、計算効率の改善が必須 • 既存の候補生成は主にルールベース（ある属性が一致する等）が担っていた ◦ 計算効率を改善しながら候補生成の精度を維持・改善することは難しい 1st-stage 求職者 求人票 候補生成 計算量の削減
9. ルールベースによる候補生成 C 求職者が直近N日間に 閲覧した求人票 求職者が過去に閲覧した求人票の属性との完全一致 A or B A B A A
10. ルールベースによる候補生成：計算効率が悪い 求職者 100万 ⇩ 1000万 100万 求人票 • 全ペアが計算対象なので計算効率が悪い • レコメンド対象の増加に対してスケールさせにくい 単純に計算量10倍にもなりえる
11. ルールベースによる候補生成：精度の維持・改善が困難 A A' A'' A A', A''も残したい • 計算量を削減しながら精度を維持する => 困難 • 計算量を一定に保ちながら精度を改善する => 困難 • 例えば、完全一致条件だと属性の意味的な近さが考慮されない
12. ルールベースによる候補生成：精度の維持・改善が困難 推薦候補 A 求職者が閲覧した求人票 A A A B A B B B B • 完全一致条件だと微妙な行動を反映するのが難しい 完全一致条件の問題 Aに興味があるはず Bはたまたまクリックしただけかも
13. 課題解決案：ルールベースの精緻化？ • ルールベースを精緻化することも可能だが…… ◦ 定量的には、Recall, Precisionを改善 • 微妙な類似度を捉えるには限界がある • 効果的な計算量調節も困難
14. 課題解決案：協調フィルタリング？ 協調フィルタリングは類似度を捉えられ、計算量を制御しやすい手法だが、コー ルドスタートの問題がある 求職者\求人票 A B C D E X ◯ ◯ - ◯ - Y - - ◯ - ◯ Z ◯ ◯ ? ? ? 新規求職者W ? ? ? ? ? ◯ : 閲覧あり 　? : 推測対象 XとZの類似性 → ?は◯と推測 新規求職者W → 何もわからない
15. 課題解決 Two-Towerモデルと近似最近傍探索による候補生成ロジック導入
16. Two-Towerモデルの導入 • ルールベースフィルターをTwo-Towerモデルに置き換える • 計算効率の改善と候補生成の精度の改善どちらも狙う 1st-stage 求職者 求人票 候補生成 ルールベースフィルター → Two-Towerモデル
17. Two-Towerモデル Embedding Encoder Feature • ニューラルネットワークで求職者と求人票をベクトル化 • それぞれ同じ空間に埋め込むことで、類似度を計算できる 求職者 求人票 Embedding Encoder Feature
18. 近似最近傍探索 求人票 求職者 IT系 IT系に興味 近似最近傍探索 • 近似最近傍探索により各求職者に近い求人票を指定件数だけ高速に取得可能 Encoder Feature Embedding Embedding Encoder Feature
19. Two-Towerモデルの利点：機械学習モデルで改善しやすい 過去実績 データ & A AND B OR…… • ルールベースを精緻化するには作り込みが必要 • → 全て機械学習モデルに押し込める
20. Two-Towerモデルの利点：質的な改善 A' A'' A A A A A B A B 丁度良い点に求職者を配置 求職者が閲覧した求人票 • 完全一致の必要はない • 求職者属性と求人票属性に応じた柔軟なフィルターを獲得 • 細かいロジックをアドホックに実装する必要はない
21. Two-Towerモデルの利点：コールドスタートに対処 属性A 属性B 属性C 求人票ID:123 (0.2, 0.1,...) (0.2, 0.1,...) • 協調フィルタリングではコールドスタートの問題がある • → 属性特徴量を使うことでコールドスタートに対処できる
22. 近似最近傍探索の利点：計算効率の改善 • ルールベースの全ペアの計算から、近似最近傍探索に変更 ◦ 埋め込みベクトルを使ったインデックスの構築も必要だが、十分に高速 • → 求職者数、求人票数に対してスケーラブルに 求職者 100万 ⇩ 1000万 100万 求人票 求職者あたりに紐づける求人票数 が固定であれば、計算量も固定
23. Two-Towerモデルと近似最近傍探索による候補生成 • 整理すると、課題については以下のように解決できる • 計算効率の改善 ◦ 求職者と求人票をTwo-Towerモデルでembeddingに変換 ◦ 近似最近傍探索により、各求職者に近い求人票を指定件数だけ取得 ◦ 計算量をコントロールできる • 精度の改善 ◦ 計算効率を維持しながら、候補生成の精度を改善することができる ▪ 特徴量を追加しても全体の計算効率はほとんど変わらない ▪ 機械学習モデルで改善しやすく、質的な改善が見込める ▪ コールドスタート問題にも対処
24. Two-Towerモデル
25. ネットワーク構造：概観 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 同カテゴリ は共有 求職者 求人票
26. ネットワーク構造：コード例 同カテゴリは共有 各エンコーダー 各Embedding 類似度
27. 特徴量の例 • 求職者の数値特徴量例 ◦ 求職者の数値属性 ◦ 行動した求人票の数値属性の 集約 ◦ 別の手法で作られた埋め込み ベクトル • 求職者のカテゴリ特徴量例 ◦ 求職者のカテゴリ属性 ◦ 行動した求人票のカテゴリ属 性のTopN • 求人票の数値特徴量例 ◦ 求人票の数値属性 ◦ 別の手法で作られた埋め込み ベクトル • 求人票のカテゴリ特徴量例 ◦ 求人票のカテゴリ属性
28. 特徴量の前処理 • 数値特徴量 ◦ np.log1pによる対数変換 ▪ StandardScalerやRobustScalerよりも精度がよかったため ▪ 総当たりで試してみて、一番精度が良いパターンを適用 • カテゴリ特徴量 ◦ カテゴリ値のエンコーディング ◦ embeddingのサイズはカテゴリ値のユニーク数に応じて決定
29. 求職者のTopNカテゴリ特徴量の扱い 行動属性 • 1,2,...,N番目に多く行動した求人票のカテゴリ属性の埋め込みベクトル ◦ 各ベクトルの加重平均を取ったものをモデルに使用 Top1 Top2 Top3 w1 w2 w3 w1 0.5 w2 0.3 w3 0.2 重みも学習
30. モデル学習 https://storage.googleapis.com/pub-tools-public-publication-data/pdf/b9f4e78a8830fe5afcf2f0452862fb3c0d6584ea.pdf • 対照学習（Contrastive Learning） ◦ 行動が発生した求職者×求人票ペアのバッチを取得、バッチ内で負例作成
31. モデル学習：細かい話 • バッチサイズ ◦ 2048などで学習 ◦ 総当たりで試してみて、一番精度が良いパターンを適用 • 学習環境 ◦ GPUの方が高速だがモデルが軽ければCPUで十分 • 対照学習のペア ◦ クリックや応募のペアを使用 ◦ 総当たりで試してみて、一番精度が良いパターンを適用
32. オフライン検証 1st-stageの候補生成の精度はRecallで評価 1. 学習データと評価データを用意 a. 行動が発生した求職者×求人票ペアのリスト b. 学習/評価は時系列の前後で分割 2. 学習データを使ってTwo-Towerモデルを学習 3. 評価データの全求職者と全求人票に対して埋め込みベクトルを計算 4. 近似最近傍探索で取得した求人票に対するRecallを計算 オフライン検証において、+5%以上の改善を確認
33. 高速なモデル改善 config.yml • 特徴量の追加 • 特徴量の処理方法指定 • モデルのパラメータ指定 • 学習のパラメータ指定 根本的な変更以外は なるべくconfig.yml管理 • レコメンド対象の増加に向け短期でオンラインで結果を出したい ◦ 高速な実験サイクルを回しやすいスクリプト群 ◦ オフライン実験50回以上
34. 近似最近傍探索
35. 近似最近傍探索 • 大まかな手順 ◦ 全求人票の埋め込みベクトルを使ってインデックスを構築 ◦ 各求職者の埋め込みベクトルに近い求人票を取得 • 重要な指標 ◦ ビルド時間：インデックスを構築する時間 ◦ クエリ時間：1回の探索にかかる時間 ◦ リコール：最近傍探索の精度
36. 近似最近傍探索アルゴリズムの例：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
37. 近似最近傍探索アルゴリズムの例：HNSW • 階層的なグラフ • 最下層は全ての点を含むとする • 目的の点に近い点を探索したい 第2階層 第1階層 第0階層 1. 最上層の点から出発 2. 目的の点にできるだけ近くなるよ うに階層内で移動 3. 下の階層に移動する 4. 2と3を繰り返せば良い
38. 近似最近傍探索アルゴリズムの例：HNSW • グラフの構築（詳細は省く） ◦ 一点ずつ追加する ◦ 各点の高さはランダムに決定 ◦ 最上層のある点から出発し、 追加点に近くなるように移動 しつつ辺を張る • 計算量 ◦ ビルド：O(N log N) ◦ クエリ：O(log N) 第2階層 第1階層 第0階層
39. 近似最近傍探索ライブラリ • 既存のライブラリを使用 ◦ 色々なライブラリのベンチマークが公開されている ◦ https://github.com/erikbern/ann-benchmarks • ビルド時間とクエリ時間が推論パイプラインに組み込む上で条件に合ったもの で、リコールが高いもの ◦ ScaNN ◦ hnswlib • 実データでは ◦ ビルド時間：~1分 ◦ クエリ時間：~1ミリ秒
40. 近似最近傍探索：コード例 ライブラリで推奨され ているパラメーター 全求人票の埋め込みベクトル ある求職者の埋め込みベクトル
41. 構成
42. 前提 • メール配信用のレコメンド • 前日にバッチで全対象求職者に対する推薦リストを生成
43. 構成（前） 学習バッチ LightGBM 求職者&求人票データ ルールベースフィルター+ LightGBM 送付 対象 LightGBM(2nd-stage)用 学習データ
44. 構成（後） 学習バッチ LightGBM(2nd-stage)用 学習データ Two-Towerモデル用 学習データ LightGBM Two-Towerモデル 求職者&求人票データ+ 埋め込みベクトル 近似最近傍探索+ LightGBM 送付 対象 求職者&求人票データ
45. 成果
46. 成果 • 推論 ◦ レコメンド対象の増加に対応 ◦ 1st-stageのフィルター部分が約25倍高速化 ◦ 推論全体で約2倍高速化 • KPI ◦ 閲覧数 +8.4% ◦ 応募数 +5.7%
47. 展開状況
48. 展開状況 • まずは、日次のバッチレコメンド（メールでのレコメンド）で導入 ◦ むしろ、速度が要求されるリアルタイムな基盤でこそ真価を発揮する • 現在ではリアルタイムなレコメンドにも導入済み • HR領域の各プロダクトに展開