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

Slide 1

Slide 1 text

人材領域での企業と求職者のマッチング最大化 RECRUIT TECH CONFERENCE 2025 Two-Towerモデルと近似最近傍探索による候補生成ロジック導入中間　康文株式会社リクルートデータ推進室若月　良平株式会社リクルートデータ推進室

Slide 2

Slide 2 text

目次 ● 自己紹介 ● 取り組みの背景・課題 ● 課題解決 - Two-Towerモデルと近似最近傍探索による候補生成ロジック導入 ● Two-Towerモデル ● 近似最近傍探索 ● 構成 ● 成果 ● 展開状況

Slide 3

Slide 3 text

自己紹介

Slide 4

Slide 4 text

中間康文アニメ・漫画・ゲーム・野球・釣り経歴 / Career 2021年にリクルートに新卒入社。 DSとして、HR領域の各プロダクトにおけるレコメンドシステムの改善に取り組む。 Two-Towerモデルと近似最近傍探索による候補生成ロジック導入の案件が、リクルートのナレッジ共有イベント（FORUM）に選出される。 Kaggle Grandmaster。趣味 / Hobbies プロダクト開発統括室データ推進室ＨＲ領域データソリューションユニットＨＲデータソリューション部中途データサイエンスグループ

Slide 5

Slide 5 text

若月良平ゲーム・散歩経歴 / Career 2018年にリクルートに新卒入社。内製ワークフローエンジンの開発 / HR領域の各プロダクトにおけるレコメンドシステムの改善などに取り組んできた。 Two-Towerモデルと近似最近傍探索による候補生成ロジック導入の案件が、リクルートのナレッジ共有イベント（FORUM）に選出される。 Kaggle Grandmaster。趣味 / Hobbies プロダクト開発統括室データ推進室データテクノロジーユニットアジリティテクノロジー部アジリティエンジニアリング１グループ

Slide 6

Slide 6 text

取り組みの背景・課題

Slide 7

Slide 7 text

HR領域のプロダクトにおけるレコメンド ● 求職者のレジュメや行動履歴に基づくレコメンド ● メールでのレコメンド、アプリでのリアルタイムなレコメンドなど、面は様々 ● レコメンド対象となる求職者と求人票のペアは、兆単位 ● 2-stageレコメンドを採用 2nd-stage 1st-stage Reranker 求職者求人票候補生成高精度の並び替え計算量の削減

Slide 8

Slide 8 text

課題：1st-stageの候補生成 ● レコメンド対象の増加が見込まれている中で、計算効率の改善が必須 ● 既存の候補生成は主にルールベース（ある属性が一致する等）が担っていた ○ 計算効率を改善しながら候補生成の精度を維持・改善することは難しい 1st-stage 求職者求人票候補生成計算量の削減

Slide 9

Slide 9 text

ルールベースによる候補生成 C 求職者が直近N日間に閲覧した求人票求職者が過去に閲覧した求人票の属性との完全一致 A or B A B A A

Slide 10

Slide 10 text

ルールベースによる候補生成：計算効率が悪い求職者 100万 ⇩ 1000万 100万求人票 ● 全ペアが計算対象なので計算効率が悪い ● レコメンド対象の増加に対してスケールさせにくい単純に計算量10倍にもなりえる

Slide 11

Slide 11 text

ルールベースによる候補生成：精度の維持・改善が困難 A A' A'' A A', A''も残したい ● 計算量を削減しながら精度を維持する => 困難 ● 計算量を一定に保ちながら精度を改善する => 困難 ● 例えば、完全一致条件だと属性の意味的な近さが考慮されない

Slide 12

Slide 12 text

ルールベースによる候補生成：精度の維持・改善が困難推薦候補 A 求職者が閲覧した求人票 A A A B A B B B B ● 完全一致条件だと微妙な行動を反映するのが難しい完全一致条件の問題 Aに興味があるはず Bはたまたまクリックしただけかも

Slide 13

Slide 13 text

課題解決案：ルールベースの精緻化？ ● ルールベースを精緻化することも可能だが…… ○ 定量的には、Recall, Precisionを改善 ● 微妙な類似度を捉えるには限界がある ● 効果的な計算量調節も困難

Slide 14

Slide 14 text

課題解決案：協調フィルタリング？協調フィルタリングは類似度を捉えられ、計算量を制御しやすい手法だが、コールドスタートの問題がある求職者\求人票 A B C D E X ◯ ◯ - ◯ - Y - - ◯ - ◯ Z ◯ ◯ ? ? ? 新規求職者W ? ? ? ? ? ◯ : 閲覧あり　? : 推測対象 XとZの類似性 → ?は◯と推測新規求職者W → 何もわからない

Slide 15

Slide 15 text

課題解決 Two-Towerモデルと近似最近傍探索による候補生成ロジック導入

Slide 16

Slide 16 text

Two-Towerモデルの導入 ● ルールベースフィルターをTwo-Towerモデルに置き換える ● 計算効率の改善と候補生成の精度の改善どちらも狙う 1st-stage 求職者求人票候補生成ルールベースフィルター → Two-Towerモデル

Slide 17

Slide 17 text

Two-Towerモデル Embedding Encoder Feature ● ニューラルネットワークで求職者と求人票をベクトル化 ● それぞれ同じ空間に埋め込むことで、類似度を計算できる求職者求人票 Embedding Encoder Feature

Slide 18

Slide 18 text

近似最近傍探索求人票求職者 IT系 IT系に興味近似最近傍探索 ● 近似最近傍探索により各求職者に近い求人票を指定件数だけ高速に取得可能 Encoder Feature Embedding Embedding Encoder Feature

Slide 19

Slide 19 text

Two-Towerモデルの利点：機械学習モデルで改善しやすい過去実績データ & A AND B OR…… ● ルールベースを精緻化するには作り込みが必要 ● → 全て機械学習モデルに押し込める

Slide 20

Slide 20 text

Two-Towerモデルの利点：質的な改善 A' A'' A A A A A B A B 丁度良い点に求職者を配置求職者が閲覧した求人票 ● 完全一致の必要はない ● 求職者属性と求人票属性に応じた柔軟なフィルターを獲得 ● 細かいロジックをアドホックに実装する必要はない

Slide 21

Slide 21 text

Two-Towerモデルの利点：コールドスタートに対処属性A 属性B 属性C 求人票ID:123 (0.2, 0.1,...) (0.2, 0.1,...) ● 協調フィルタリングではコールドスタートの問題がある ● → 属性特徴量を使うことでコールドスタートに対処できる

Slide 22

Slide 22 text

近似最近傍探索の利点：計算効率の改善 ● ルールベースの全ペアの計算から、近似最近傍探索に変更 ○ 埋め込みベクトルを使ったインデックスの構築も必要だが、十分に高速 ● → 求職者数、求人票数に対してスケーラブルに求職者 100万 ⇩ 1000万 100万求人票求職者あたりに紐づける求人票数が固定であれば、計算量も固定

Slide 23

Slide 23 text

Two-Towerモデルと近似最近傍探索による候補生成 ● 整理すると、課題については以下のように解決できる ● 計算効率の改善 ○ 求職者と求人票をTwo-Towerモデルでembeddingに変換 ○ 近似最近傍探索により、各求職者に近い求人票を指定件数だけ取得 ○ 計算量をコントロールできる ● 精度の改善 ○ 計算効率を維持しながら、候補生成の精度を改善することができる ■ 特徴量を追加しても全体の計算効率はほとんど変わらない ■ 機械学習モデルで改善しやすく、質的な改善が見込める ■ コールドスタート問題にも対処

Slide 24

Slide 24 text

Two-Towerモデル

Slide 25

Slide 25 text

ネットワーク構造：概観 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 同カテゴリは共有求職者求人票

Slide 26

Slide 26 text

ネットワーク構造：コード例同カテゴリは共有各エンコーダー各Embedding 類似度

Slide 27

Slide 27 text

特徴量の例 ● 求職者の数値特徴量例 ○ 求職者の数値属性 ○ 行動した求人票の数値属性の集約 ○ 別の手法で作られた埋め込みベクトル ● 求職者のカテゴリ特徴量例 ○ 求職者のカテゴリ属性 ○ 行動した求人票のカテゴリ属性のTopN ● 求人票の数値特徴量例 ○ 求人票の数値属性 ○ 別の手法で作られた埋め込みベクトル ● 求人票のカテゴリ特徴量例 ○ 求人票のカテゴリ属性

Slide 28

Slide 28 text

特徴量の前処理 ● 数値特徴量 ○ np.log1pによる対数変換 ■ StandardScalerやRobustScalerよりも精度がよかったため ■ 総当たりで試してみて、一番精度が良いパターンを適用 ● カテゴリ特徴量 ○ カテゴリ値のエンコーディング ○ embeddingのサイズはカテゴリ値のユニーク数に応じて決定

Slide 29

Slide 29 text

求職者のTopNカテゴリ特徴量の扱い行動属性 ● 1,2,...,N番目に多く行動した求人票のカテゴリ属性の埋め込みベクトル ○ 各ベクトルの加重平均を取ったものをモデルに使用 Top1 Top2 Top3 w1 w2 w3 w1 0.5 w2 0.3 w3 0.2 重みも学習

Slide 30

Slide 30 text

モデル学習 https://storage.googleapis.com/pub-tools-public-publication-data/pdf/b9f4e78a8830fe5afcf2f0452862fb3c0d6584ea.pdf ● 対照学習（Contrastive Learning） ○ 行動が発生した求職者×求人票ペアのバッチを取得、バッチ内で負例作成

Slide 31

Slide 31 text

モデル学習：細かい話 ● バッチサイズ ○ 2048などで学習 ○ 総当たりで試してみて、一番精度が良いパターンを適用 ● 学習環境 ○ GPUの方が高速だがモデルが軽ければCPUで十分 ● 対照学習のペア ○ クリックや応募のペアを使用 ○ 総当たりで試してみて、一番精度が良いパターンを適用

Slide 32

Slide 32 text

オフライン検証 1st-stageの候補生成の精度はRecallで評価 1. 学習データと評価データを用意 a. 行動が発生した求職者×求人票ペアのリスト b. 学習/評価は時系列の前後で分割 2. 学習データを使ってTwo-Towerモデルを学習 3. 評価データの全求職者と全求人票に対して埋め込みベクトルを計算 4. 近似最近傍探索で取得した求人票に対するRecallを計算オフライン検証において、+5%以上の改善を確認

Slide 33

Slide 33 text

高速なモデル改善 config.yml ● 特徴量の追加 ● 特徴量の処理方法指定 ● モデルのパラメータ指定 ● 学習のパラメータ指定根本的な変更以外はなるべくconfig.yml管理 ● レコメンド対象の増加に向け短期でオンラインで結果を出したい ○ 高速な実験サイクルを回しやすいスクリプト群 ○ オフライン実験50回以上

Slide 34

Slide 34 text

近似最近傍探索

Slide 35

Slide 35 text

近似最近傍探索 ● 大まかな手順 ○ 全求人票の埋め込みベクトルを使ってインデックスを構築 ○ 各求職者の埋め込みベクトルに近い求人票を取得 ● 重要な指標 ○ ビルド時間：インデックスを構築する時間 ○ クエリ時間：1回の探索にかかる時間 ○ リコール：最近傍探索の精度

Slide 36

Slide 36 text

近似最近傍探索アルゴリズムの例：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

Slide 37

Slide 37 text

近似最近傍探索アルゴリズムの例：HNSW ● 階層的なグラフ ● 最下層は全ての点を含むとする ● 目的の点に近い点を探索したい第2階層第1階層第0階層 1. 最上層の点から出発 2. 目的の点にできるだけ近くなるように階層内で移動 3. 下の階層に移動する 4. 2と3を繰り返せば良い

Slide 38

Slide 38 text

近似最近傍探索アルゴリズムの例：HNSW ● グラフの構築（詳細は省く） ○ 一点ずつ追加する ○ 各点の高さはランダムに決定 ○ 最上層のある点から出発し、追加点に近くなるように移動しつつ辺を張る ● 計算量 ○ ビルド：O(N log N) ○ クエリ：O(log N) 第2階層第1階層第0階層

Slide 39

Slide 39 text

近似最近傍探索ライブラリ ● 既存のライブラリを使用 ○ 色々なライブラリのベンチマークが公開されている ○ https://github.com/erikbern/ann-benchmarks ● ビルド時間とクエリ時間が推論パイプラインに組み込む上で条件に合ったもので、リコールが高いもの ○ ScaNN ○ hnswlib ● 実データでは ○ ビルド時間：~1分 ○ クエリ時間：~1ミリ秒

Slide 40

Slide 40 text

近似最近傍探索：コード例ライブラリで推奨されているパラメーター全求人票の埋め込みベクトルある求職者の埋め込みベクトル

Slide 41

Slide 41 text

構成

Slide 42

Slide 42 text

前提 ● メール配信用のレコメンド ● 前日にバッチで全対象求職者に対する推薦リストを生成

Slide 43

Slide 43 text

構成（前）学習バッチ LightGBM 求職者&求人票データルールベースフィルター+ LightGBM 送付対象 LightGBM(2nd-stage)用学習データ

Slide 44

Slide 44 text

構成（後）学習バッチ LightGBM(2nd-stage)用学習データ Two-Towerモデル用学習データ LightGBM Two-Towerモデル求職者&求人票データ+ 埋め込みベクトル近似最近傍探索+ LightGBM 送付対象求職者&求人票データ

Slide 45

Slide 45 text

成果

Slide 46

Slide 46 text

成果 ● 推論 ○ レコメンド対象の増加に対応 ○ 1st-stageのフィルター部分が約25倍高速化 ○ 推論全体で約2倍高速化 ● KPI ○ 閲覧数 +8.4% ○ 応募数 +5.7%

Slide 47

Slide 47 text

展開状況

Slide 48

Slide 48 text

展開状況 ● まずは、日次のバッチレコメンド（メールでのレコメンド）で導入 ○ むしろ、速度が要求されるリアルタイムな基盤でこそ真価を発揮する ● 現在ではリアルタイムなレコメンドにも導入済み ● HR領域の各プロダクトに展開