検索精度を改善するための課題に対応
「COMPANY Bizmatch」では、生成AIを2つの方向性で利用している。1つはあらかじめ登録されている従業員データ（資格、免許、業務経験、研修受講歴、評価結果、キャリアプラン申告など）から、従業員それぞれの特徴をとらえた要約文を生成する。もう1つは検索文と、各社員の要約文とのマッチ度を判断し、判断理由となる文章も生成する。
当初のアーキテクチャは下図の通り。ユーザーからのリクエスト（左上）に対して、既存のタレントマネジメントステップの背後に追加された生成AI機能のアーキテクチャがある。
左側（Step Functions summarizer）が要約文作成だ。従業員データを取得し、LLMで要約文を作成し、作成した要約文をベクトルに変換してデータベースに保存する。右側が検索ロジックだ。検索文をベクトル変換し、データベースに対してベクトル検索を実施して1,000人程度に絞り、個別にマッチ度を判定。そして、マッチ理由をLLMで作成する。なお使用しているモデルはAmazon BedrockでのClaudeやCohereのエンベッドモデルとなる。
このアーキテクチャでベータ版までたどり着いたものの、実際のデータで使用してみると検索精度で課題に直面した。原因はいくつかあり、それぞれ対応することで改善していった。
1点目は数字の扱い。生成AIは数字の扱いが得意ではないため、「30代」のようなキーワードで検索しようとすると精度が低い。そこで数字で検索する時は生成AIやベクトル検索は使わず、従来のルールベースを使用する。
2点目は要約文を作成する段階で失われる情報があること。そこで経歴など要約しないカテゴリ（項目）を作成し、そのまま生成AIに渡す。
3点目は真逆の意味も引っかかってしまうこと。例えば「情報セキュリティに強い人」を検索しようとすると、ベクトル検索では「情報セキュリティに強い人」だけではなく「情報セキュリティに弱い人」も引っかかってしまうことがあった。そこで強みのベクトルだけ集めたカラムを作るなど、ベクトルを作る単位を変えた。
4点目は意図をうまく解釈できないこと。例えば「英語が得意な人」を検索したい場合、具体的にはTOEIC 700点以上の社員を拾いたいケースを想定する。しかし、ベクトル検索やLLMリランキングで該当者を絞り込んでいく段階で高い精度が出せず、該当者がこぼれ落ちてしまっていた。当初はベクトルを作る時の文章を短くする（チャンキング）とか、クエリ拡張やハイブリッド検索などを試したものの、「ベクトル検索に期待しすぎたところがありました」と吉田氏は言う。最終的にはベクトル検索（RAG）をやめて、すべてLLMで処理することに変えた。
検索精度を改善したら、次にコストと安定化の課題が浮上
検索精度は改善されたものの、生成AIへのリクエストが増えることにより、コストと安定化という新たな課題が生じた。
コストは比較した結果、当時（2025年1月）最安のGemini 1.5 Flashを選択した。状況が刻々と変わるので時期により他モデルが最適になる可能性もある。比較したのは提供元、価格、精度、同時実行数、加えて顧客のデータを使うためデータをモデル学習のために利用されるかどうかなどだ。
安定化は、生成AIモデルの呼び出しのクオーターを超えないようにコントロールするような対策を施した。大量の検索が同時発生すると処理があふれてしまうため、まずはキューイングして非同期処理したのと、（クオーターとなる）1分間に1,000件を効率的に扱えるように並列処理を組んだ。またエラーが生じた場合でもリトライできるようにした。
改善後のアーキテクチャは、検索実行部分がStep Functionsとして増えて、呼び出しているモデルがVertex AI Geminiとなっている。
吉田氏は「検索精度はある程度自信が持てる状態になりました。RAG（ベクトル検索）は高速に動作するので非常に便利ですが、要件次第で使うかどうかは判断が必要です」と指摘する。
