株式会社ビズリーチで検索エンジニアをしている加藤です。
株式会社ビズリーチのオフィスで、オフラインイベント「検索エンジニアMeetUP #2 -ドメインにディープダイブするLLMと検索 -」を開催しました。本記事では、イベント開催の背景や目的、そして当日の様子をレポートします。
イベント開催の目的
LLM(大規模言語モデル)と検索技術の組み合わせは、検索領域においても注目されています。ただ、この領域は変化が非常に速く、確立されたベストプラクティスもまだない、まさに「試行錯誤の段階」です。 また、「検索」と一口に言っても、課題や最適なアプローチはドメイン(例えばEC、ニュース、あるいは私たちが取り組むHRなど)によって大きく異なります。汎用的な技術トレンドはあっても、それが自社のドメイン特有の課題にどう使えるのかは、各社が個別に検証しているのが現状だと思います。 結果として、この領域では「具体的なドメイン課題」に対するLLMの活用事例がまだ世の中に少なく、そうした知見を交換できる専門的な勉強会も不足している、と感じていたのが企画のきっかけです。 こうした背景から、「各社が持つリアルな知見をオープンに共有し、ドメインの壁を越えて議論を深める場がほしい」と考え、私たち自身が主催者となってコミュニティ全体に貢献できればと、今回のイベントを企画しました。
発表内容の簡単な紹介
当日は、私たち株式会社ビズリーチを含め、検索×LLMの領域に積極的に取り組んでいる3社が登壇しました。当社からは私が「ビズリーチ」について、石塚から「社内版ビズリーチ」について発表しました。
- 株式会社LayerX様
- ディップ株式会社様
- 株式会社ビズリーチ
ドメインやサービス特性が異なる3社ですが、セッションを通じて浮かび上がってきたのは、「LLMをいかに既存の検索システムと融合させ、制御し運用するか」という共通の課題意識でした。 ユーザー体験を向上させるために、事業課題に対してLLMをどう活用するのか、技術的な課題をどう解決したか、といった具体的な事例が共有されました。
- ディップ様の資料
- LayerX様の資料は非公開
セッション後の懇親会も大いに盛り上がり、登壇者と参加者が入り混じって、あちこちで議論の輪ができていました。検索へのLLM活用の実際がどうか、RAGやAIエージェントといった最新技術トレンドについて、白熱した議論が交わされていたのが印象的です。
自身の発表「ビズリーチ求職者検索におけるPLMとLLMの活用」について
私は「ビズリーチ求職者検索におけるPLMとLLMの活用」というタイトルで発表させていただきました。
この発表では、「ビズリーチ」を利用する企業の採用担当者向け機能である「求職者検索」にフォーカスし、私たちが直面している2つの主要な課題と、その解決アプローチについて話しました。 「ビズリーチ」の求職者検索は、一般的なWeb検索とは異なる特徴がいくつかあります。中でも大きいのは「High Recall(高い再現率)」、つまり「適合する可能性のある求職者を広く見つけ出すこと」が重要視されるという点です。
課題1:リストアップ(検索)における「語彙の壁」
一つ目の課題は、採用担当者と求職者の間で生じる「語彙の不一致」により、適切な求職者を見つけにくい「リストアップ」の課題です。 例えば、採用担当者が「PM」と検索した際に、職歴に「プロジェクトマネージャー」と記載している求職者がヒットしない、といったケースが起こりがちです。
従来のキーワードマッチングで、この「語彙の壁」を超えるのは簡単ではありません。採用担当者の方がキーワードを工夫して何度も検索し直す必要があり、それでも候補者を見つけられない、という体験を生んでいます。 「要件にマッチする可能性のある求職者を広く見つけ出すこと」が何より重要な求職者検索において、これは大きな問題です。
この課題へのアプローチとして、私たちはPLM(事前学習済み言語モデル)であるSPLADEを用いたセマンティックサーチを導入しました。 SPLADEは、検索クエリと文書から疎ベクトル(Sparse Vector)を生成するモデルです。密ベクトル(Dense Vector)を用いた手法と比較し、SPLADEは転置インデックスをそのまま利用できるため既存システムとの親和性が高く、低遅延(low latency)を維持しやすい利点があります。 また、ベクトル内のどの単語が関連性に寄与したかが分かりやすく、「解釈性」が高い点も選定の理由となりました。
発表では、汎用的なモデルをそのまま使うのではなく、HRドメイン(人材領域)のデータセットを用いてTokenizer(単語分割)から学習し直した、内製のSPLADEモデルについても触れました。 SPLADEのアーキテクチャと学習の工夫に関しては、後日改めて別の記事でご紹介する予定です。
課題2:スクリーニング(評価)における「確認負荷」
二つ目の課題は、リストアップされた数十件から数百件もの求職者を1件ずつ確認し、適合性を判断する「スクリーニング」の負荷が非常に高いことです。求職者の職歴は自由記述の非構造化データですから、その内容が募集要件と合致するかを短時間で判断するには、ドメイン知識とかなりの時間が必要になります。 しかも、前段のリストアップ(課題1)で可能性のある求職者を広く見つけられるようになるほど、今度はこの「スクリーニング負荷」がより大きな課題として顕在化してきます。
そこで、この課題に対する対応としてLLMに検索条件と求職者の適合性を判定させる「LLM as a judge」の取り組みを紹介しました。 これは、検索結果としてリストアップされた求職者をLLMに入力し、その適合性を評価させる試みです。 採用担当者が確認すべき求職者の優先順位付けを支援し確認負荷を軽減することで、リストアップから続くトータルな検索体験を改善することを目指しています。
発表では、LLMの評価が必ずしも人間の評価と一致しない点や、長いテキストを高評価しがちといったLLM特有の判定バイアスの調査についても、現在試みていることを共有しました。
当日の発表資料は、以下で公開しています。ご興味のある方はぜひご覧ください。
コミュニティへの貢献:SPLADEモデルのOSS公開
発表資料でも触れましたが、私たちは今後コミュニティへの貢献としてOSS活動も進めていきたいと考えています。 その第一歩として、我々が開発を進めているSPLADEに関するトレーニングのコードとモデルを公開しました。 ぜひ一度触ってみて、ご感想いただけると幸いです。
- GitHubリポジトリ: https://github.com/bizreach-inc/light-splade
- Hugging Faceモデル: https://huggingface.co/collections/bizreach-inc/splade-68edb5856c83a1ba7e37bb1a
おわりに
ご登壇いただいたLayerX様、ディップ様、そしてご参加いただいた皆様、誠にありがとうございました。皆様のおかげで、非常に有意義な時間となりました。 「#2」とあるように、今後も継続的に本テーマに関するイベントを企画していきたいと考えています。
最後に、我々検索基盤グループは、検索基盤となるインフラの構築から、ベクトル検索やランキング改善といった検索品質の改善、検索モデルの開発や研究開発といったことに今後も取り組んでいきます。 ご興味をお持ちいただけたら、ぜひカジュアル面談でお話ししましょう。