ビズリーチ求職者検索におけるPLMとLLMの活用 / Search Engineering MEET UP_2-1

2025年10月14日に開催された「検索エンジニアMeetUP #2 -ドメインにディープダイブするLLMと検索」の登壇資料です。
https://d-cube.connpass.com/event/367249/

▼関連資料
Qdrant を用いた検索改善施策の紹介
https://speakerdeck.com/visional_engineering_and_design/search-engineering-tech-talk-2024-summer

検索ランキングの比較のためにInterleavingの導入と評価をした際の工夫
https://engineering.visional.inc/blog/615/implement-interleaving-for-search-evaluation/

検索エンジニアが集う！「検索技術勉強会」レポート - Qdrant、Elasticsearch、Vespa 活用事例
https://engineering.visional.inc/blog/627/search-engineering-tech-talk-2024-summer/

DEIM2025 参加レポート
https://engineering.visional.inc/blog/653/deim2025-report/

Elasticsearch - 適切なOptimization Typeの選定と安全なクラスター分割
https://engineering.visional.inc/blog/617/elasticsearch-cluster-split/

-----
Visionalのエンジニアリングに関する最新情報はX、ブログで発信しています！📣

▼Visional Engineering Blog
https://engineering.visional.inc/blog/

▼VISIONAL ENGINEERING / X
https://twitter.com/VISIONAL_ENG

Transcript

1. ビズリーチ求職者検索におけるPLMとLLMの活用
 
 検索エンジニアMEET UP #2

2. 自己紹介
 プロダクト本部データプロダクト部 
 検索基盤グループ
 加藤 遼
 
 ビズリーチの求職者検索のグロースを 
 担当するチームで検索エンジニア 

3. チーム紹介
 ビズリーチプロダクトには検索チームが二つあり、検索機能のマイクロサービス化から検索インフラ構築、 ランキング改善、モデリングやR&Dまで広く取り組んでいる。

4. 株式会社ビズリーチ　ミッション
 キャリアに、選択肢と可能性を
 時代の変化により、市場の構造が複雑化し、価値観も多様化している。
 キャリア形成において重要なのは、
 自分の未来に自信を持てる「はたらく」を選択し、
 挑戦し続ける企業と繋がり、新たな活力を生み出すこと。
 私たちは世の中にたくさんの「選択肢と可能性」を提供し 、
 「はたらく」を変革していく。

5. プロダクト紹介
 採用プラットフォーム 
 人財活用プラットフォーム 
 この発表のスコープ
 後ほど発表

6. • Bizreachのドメインの説明 / 課題の共有 • PLM / LLM活用の考え方 • 事例紹介 • 今後の取り組み アジェンダ
7. 「ビズリーチ」のドメインと課題について

8. 採用プラットフォーム「ビズリーチ」におけるマッチング
 求人作成
 母集団
 形成
 スカウト
 送信
 返信 /
 書類通過
 スカウト
 受信/
 応募
 ログイン
 レジュメ
 登録
 面接
 採用決定
 企業
 (B側)
 求職者
 (C側)
 • 企業(B側)と求職者(C側)のマッチングは、双方向の行動から発生する。 
 ◦ 企業観点「企業からのスカウト送信に求職者から 返信があった」
 ◦ 求職者観点「求人への応募が 書類通過した」
 • 最終的に採用決定数を増やす 必要がある。
 

9. 本日のスコープ
 求人作成 母集団 形成 スカウト 送信 返信 / 書類通過 スカウト
 受信/
 応募
 ログイン
 レジュメ
 登録
 面接 採用決定 企業 (B側) 求職者
 (C側)
 • 企業(B側)と求職者(C側)のマッチングは、双方向の行動から発生する。 
 ◦ 企業観点「企業からのスカウト送信に求職者から 返信があった」
 ◦ 求職者観点「求人への応募が 書類通過した」
 • 最終的に採用決定数を増やす 必要がある。
 
 
 今日の話はこっち
10. • 企業の採用活動は複数のファネルがあり、先に進むほど該当人数が減っていく 
 • 全ファネルを同じ人が担当するわけではない 
 企業の採用活動
 ターゲティング
 リストアップ
 スクリーニング
 スカウト送信
 スカウト返信
 面接
 採用決定
 母集団形成
 スカウト活動
 面接~採用
 大きな壁
 該当人数

11. • 検索は母集団形成を担う重要な機能 
 • メインであるリストアップだけでなく、前後も含めた検索体験の向上が必須 
 
 求職者検索の位置付け
 要件定義
 検索条件作成
 検索
 評価
 ターゲティング
 スクリーニング
 リストアップ
 母集団形成

12. • 検索は採用フロー上やらなくてはいけないタスク 
 ◦ 検索結果は数百件くらいならすべて確認することもある 
 ◦ 検索はやってくれるが、検索 (採用活動)にかけられる時間が限られる 
 • 企業と求職者のマッチングの難易度が高い 
 ◦ 双方向の意思や志向を考慮したマッチングが必要 
 ◦ 検索条件に一致しているからといって、採用決定につながるとは限らない 
 ▪ 企業側のスキル面以外の条件にマッチしない、求職者側の希望と一致しない、 etc
 ◦ 人気の企業・求職者のみにマッチングが集中するのはプラットフォームとして不健全 
 • マッチング難易度が高い上に採用決定までのファネルが長いため、母集団という形で多めに集める (リスト アップする)必要がある
 ◦ 数件の正解ドキュメントを見つける検索と異なり、 high recallが求められる
 
 母集団形成における求職者検索の特徴

13. 母集団形成各ステップの課題 ターゲティング
 スクリーニング
 リストアップ
 • 適切なターゲットがわから ない
 • 市場感と離れた要求 
 • 求人で表現されない条件 
 • 検索条件の作成が難しい 
 • 検索する人とされる人の語 彙不一致
 • 検索する人にドメイン知識 が求められる
 • 評価が難しい
 • 1件1件確認する必要があ るため時間がかかる 
 • 面接してみないとわからな いことも多い
 例. RAGというものを自社で作りたい。 RAGの開 発運用経験があって、ベクトル DBの運用経験 あって、モデル開発できて、年収 600万くらい？
 カルチャーフィットしそうな人がいい 
 
 例. エンジニアをマネジメントできる人を探したい が、マネージャー、リーダー、 EM、エンジニアリン グマネージャー、…？？？
 会社によって役職名が違っていて、 レジュメでも 表記がバラバラ....
 例. 数百人のレジュメをみて、要件にマッチするか 判断しないといけない。大半の時間を結果の確 認に使っているので、条件変更など試行錯誤する 時間がない。
 具体例
14. PLM/LLMの活用

15. PLM/LLMの活用
 要件定義
 検索条件作成
 検索
 評価
 ターゲティング
 スクリーニング
 リストアップ
 課題の解決方法として、求職者検索における PLM/LLMの活用先は大きく3つ
 1. PLMによるRetrieverやRankerの品質向上 【プロダクトへの導入中】 
 2. LLMによる生成タスクでの効率化【一部プロダクトへの導入着手中】 
 3. 一連のフローの自動化 /AIエージェント化 【R&Dやプロトタイプ検証実施中】 
 
 PLM
 LLM
 LLM
 PLM/LLM

16. 現在の取り組み
 ターゲティング
 スクリーニング
 リストアップ
 • 適切なターゲットがわから ない
 • 市場感と離れた要求 
 • 求人で表現されない条件 
 • 検索条件の作成が難しい 
 • 検索する人とされる人の語 彙不一致
 • 検索する人にドメイン知識 が求められる
 • 評価が難しい
 • 1件1件確認する必要があ るため時間がかかる 
 • 面接してみないとわからな いことも多い
 現在の検索機能の改善の延長にあり、レバレッジの効く
 これらの課題の解決にフォーカスしている

17. リストアップとスクリーニングの改善 
 
 リストアップ: セマンティックな関連度で見つけるべき求職者を広くリストアップする 
 → PLMによるセマンティックサーチの導入 
 
 スクリーニング: レジュメ判定の確認負荷を下げて要件との適合性判定の負荷を下げる 
 → LLM as a judge
 現在の取り組み

18. 事例紹介1

19. • Recallを高める目的としてセマンティックサーチの導入 
 • SPLADEを採用
 
 
 
 事例1. セマンティックサーチの導入

20. • 特徴
 ◦ BERTを用いることで文脈に基づいた関連す る各トークンの重みを推定する 
 ◦ 最終的にBERTの語彙(Vocab)に対応した疎 (Sparse)なベクトルを生成する 
 ▪ 例. AI: 0.9, 機械学習: 0.5 , DeepLearning:0.8, 開発: 0.4
 • できること
 ◦ 転置indexを活用できる
 ◦ 単語の完全一致だけでなく、文脈に基づいて 関連する単語も出力される 
 
 
 
 SPLADE

21. 
 • 低latency
 ◦ DenseVectorの場合、数百万件以上のドキュメントを検索する際の latencyの懸念
 ◦ SparseVectorであれば転置インデックスが使える 
 ◦ ドキュメント側のみ拡張する方法 (SPLADE-Doc)もとれる
 • 解釈性
 ◦ サービス特性上なぜこの人が関連しているかの説明性も重要 
 ◦ DenseVectorだとなぜ関連しているのかわからない 
 ◦ LLMに説明させると、検索リクエスト数 x 表示件数(100件)の生成はコスト・latencyが懸念
 ◦ SparseVectorならmodelの出力トークンをタグのように扱い、検索結果に表示するなどの活用もで きる
 
 
 SPLADEの採用理由

22. • japanese-splade-v2のような公開されている日本語汎用 SPLADEモデルもあるが、HRドメインに特化した ものが必要
 • ビズリーチのもつ自社ドメインデータを使って、 HRドメイン特化SPLADEモデルを内製
 ◦ BERTのtokenizerのトレーニングから自分たちで実施 
 ◦ cc100_ja, jawiki, 自社ドメインデータを使って事前学習、 FineTuning
 • SPLADE++(v2bis)をベースにtraining codeを実装
 ◦ cross encoderを使って蒸留を実施 
 ◦ 公開されているNaverの実装は商用利用に制限あるため、独自に実装 
 • ビズリーチの場合関連度が多段階あるため Training時にいくつか工夫あり 
 ◦ 詳細は別の機会に発表します 
 
 ドメインへの適応

23. input text: "TypeScriptでフロント開発をリード "
 hotchpotch/japanese-splade-v2
 output: {'フロント': 2.1314, 'リード': 1.2783, '##cript': 1.1884, '開発': 1.0119, '##ript': 0.7186, 'プログラミング': 0.6975, 'リーダー': 0.672, 'タイプ': 0.6496, '##ype': 0.4726, '種類': 0.3594, '##プト': 0.3038, '担当': 0.1076, '##s': 0.0795, 'すすめ': 0.0769, 'スクリ': 0.0731, '作者': 0.0595, '方法': 0.054, '牽引': 0.0477, '前': 0.0463, 'テキスト': 0.0449, '作り': 0.041}
 
 HR domain splade
 output: {'リード': 1.8745, '開発': 1.6846, 'PHP': 1.623, 'Java': 1.6137, 'React': 1.5227, 'TypeScript': 1.4965, 'JavaScript': 1.3349, 'フロント': 1.223, 'AWS': 1.0509, 'QA': 0.9529, 'Python': 0.897, 'プロダクト': 0.81, 'バック': 0.81, 'SEO': 0.192, 'パブリック': 0.1785, 'Flutter': 0.1351, '技術': 0.1228, 'コンテ ンツ': 0.0145}
 
 
 サブワード少なく、レジュメや検索でよく使われるような単語 (例. プログラミング言語)が出力されている
 既存日本語SPLADEモデルとの違い: tokenize

24. • CPU利用 / 推論スピードを早くするために小型のモデルを作成 
 ◦ hotchpotch/japanese-splade-v2: 136M
 ◦ HR domain splade: 30M
 • 実際の検索ログを使った定量テストで 同等~少しよい程度の性能を実現
 • ドメインデータを使って FineTuningすることで小型でも性能を担保可能 
 
 既存日本語SPLADEモデルとの違い: model size

25. 事例紹介2

26. スクリーニングの効率化のために LLMによる判定(LLM as a judge)を導入
 
 狙い
 • ユーザーの(心理的)負担軽減
 ◦ 基準を満たしているかわからない状態で数百件のドキュメントをみる → 一定の品質を担保した状態 で確認
 • リストアップの件数を増やせる 
 ◦ セマンティックサーチ導入などで recallを増やすと、合わせて関連度の低いレジュメも増える 
 ◦ LLMによるスクリーニングでノイズ排除することで件数を増やしやすくなる 
 
 
 
 事例2. LLMによるスクリーニング

27. • ユーザーの高評価と完全一致はしない 
 ◦ PoCの段階ではLLMの高評価をすべてを人間が高評価判定していない 
 • LLMの判定バイアス
 ◦ 先行研究でLLMによるjudgeでさまざまなバイアスがかかることがわかっている 
 ▪ 長いドキュメント、語彙一致、 LLMが生成したドキュメントは高評価しやすいなど 
 ◦ ビズリーチではLLMによるレジュメの自動作成機能もあるため検証予定 
 
 
 
 
 
 事例2. LLMによるスクリーニングの課題
 https://www.bizreach.co.jp/pressroom/pressrelease/2023/070601.ht ml

28. 今後の取り組み

29. • 何よりも大事なのは、地道な検索精度の改善 ◦ 精度改善やランキング改善 ◦ 評価の仕組み改善 • LLM活用範囲を増やす ◦ QueryUnderstandingなど検索フォローの強化 /パーソナライズ • 新しい検索体験の創出に向けた R&D/検証 ◦ AIエージェント化 /AIエージェントと人の作業の体験の探索 • 研究やOSS等の外部への貢献 今後の取り組み
30. SPLADEモデルとトレーニングコードを公開 
 
 github
 • https://github.com/bizreach-inc/light-splade
 
 model
 • 28M
 ◦ https://huggingface.co/bizreach-inc/light-splade-japanese-28M
 • 56M
 ◦ https://huggingface.co/bizreach-inc/light-splade-japanese-56M
 
 告知: OSSを公開しました

31. 基盤構築から精度改善、リサーチャーまで広く検索エンジニア募集中！ 
 
 
 
 
 
 興味持っていただけたら、ぜひカジュアル面談で話しましょう！！ 
 カジュアル面談フォームはこちら →
 https://hrmos.co/pages/hrmos/jobs/3100100100963
 
 
 we are hiring

32. ご清聴ありがとうございました！
 Xアカウント
 求人
 エンジニア
 最新情報
 検索エンジニア
 募集中
 @VISIONAL_ENG
 検索基盤エンジニア /ビズリーチプロダ クト