Vertex AI Searchによる検索エンジンの構築

検索精度に関する課題

これまではキーワードベースのシンプルな検索エンジンを運用していましたが、主に以下の課題がありました。

• ゼロマッチの問題：
  • 意味が近いが漢字が異なるとゼロマッチ。
    • 例えば、「プレゼン」に対して「伝え方」を検索。
  • 表記揺れによるゼロマッチ。
    • 例えば、「itパスポート」に対して「ＩＴパスポート」を検索。
  • 入力ミスによるゼロマッチ。
    • 例えば、「減価償却」に対して「原価消却」を検索。
• 表示順番の不適切：
  • コースID順のため、必ずしも関心度が高いものが上位に出るわけではない。
• 複数キーワードの検索不可：
  • 複数キーワードがあっても、最初のものしか参照されない。

ユーザー体験への影響

これらの技術的な課題は、直接的にユーザー体験へ影響を与えていました：

• 適切なコンテンツが見つからないことによる学習機会の損失
• ユーザーがいつも同じようなキーワードやパターンでしか検索しない、多様性に欠ける状態

上記の課題を解決する方法として、今の時代であればベクトル検索が自然に想起されます。私たちはベクトル検索を中心にいくつかのソリューションを検討しました。複数のソリューションを検討しましたが、その中から代表的な3つを共有します。

1. Vertex AI Search
   • 概要
     • GCP（Google Cloud）が提供する、RAG、ドキュメント理解、ベクトル/ハイブリッド検索などを備えた企業向けAI検索プラットフォーム
   • 利点
     • ベクトル検索、ハイブリッド検索のサポート
     • 開発負担が低い
   • 課題
     • 細かなアルゴリズム制御や独自エンジンを使ったカスタマイズには制限あり
       • 例えば、ハイブリッド検索でのキーワード検索とセマンティック検索の間の重みは自動最適化されるため、カスタマイズできない
     • マネージドサービスゆえに、コストは自動スケールやストレージ・トークン量に比例し、用途によっては高くなる可能性がある
     • サービスに依存することで、他ベンダーへの移行が難しくなる可能性がある
2. Elasticsearch
   • 概要
     • GCP上で Elasticsearch を用い、自前でベクトル検索・ハイブリッド検索機能を構築するソリューション
   • 利点
     • 拡張性が高い
       • Embeddingモデルの選択自由
       • ランキングモデルのカスタマイズが可能
       • ハイブリッド検索において、キーワード検索とセマンティック検索の重み調整
       • 重視したいフィールドの重み付け
     • ハイブリッド検索が可能
   • 課題
     • インフラ構築・スケーリング・運用管理のためのコストが発生
3. BigQuery + Embedding
   • 概要
     • Embeddingモデルで生成したベクトルを BigQuery に保存し、SQL や Python/Dataflow で類似度検索や分析を行う方式
   • 方法
     • ベクトルをBigQueryに格納
     • ユークリッド距離やコサイン類似度をSQLで計算
     • PythonやDataflowで前処理や検索結果の強化
   • 利点
     • GCP上でサーバーレスにスケーラブルな構築が可能
     • BigQuery を中心にした既存データ活用が容易
     • SQLベースの開発で親和性が高い
   • 課題
     • ハイブリッド検索や高度な機能（ランキング改善・全文検索連携など）は自前で構築する必要があり、設計・開発負担が大きい
     • モニタリングや運用機構も自前で整備する必要があり、拡張性という点では運用負担に依存する形になる

各ソリューションの特徴をまとめると、以下の表になります。

開発エピソード①　データ前処理の工夫

検索エンジンのインプットとしてコース概要を検討しました。私たちのコース概要には、関連コースの紹介や、学びの意欲を引き出す表現、参考情報のURLなどが含まれています。人間が読むと確かに親しみやすいのですが、検索エンジンにとってはどうでしょうか。

実際には、ノイズ情報として認識され、検索精度に影響が出ます。

例えば、URLの中に偶然「ai」という文字列が含まれている場合があります。その結果、「ai」で検索すると本来AIとは関係のないコースまで結果に表示されてしまいます。ユーザーにとっては、理解しづらい結果になってしまいますね。

もう一つの例をご紹介します。コース概要の中には、講師プロフィールが含まれていることがあります。そこには、講師の経歴や専門分野といった情報が記載されています。これらは講師の専門性を伝える上で有益な情報ですが、検索精度に悪影響を及ぼすこともあります。

たとえば、以下の図に示すように、「クリティカル・シンキング」に関するコースの講師プロフィールに、「業務改革」や「人事組織変革」といったキーワードが含まれています。この状態で「業務改革」と検索すると、本来の意図とは異なるこのコースが、検索結果に表示される可能性があります。

そのため、コース概要をインプット情報から除外しました。代替として、コースの要約をAIで生成し、インプット情報として検索エンジンに投入しています。AIで生成したコース要約は親しみやすさがやや欠けますが、情報の網羅性という観点から、最終的に検索エンジンのインプットとして採用しました。 （AIでいかにコース要約を生成しているかは、また別途紹介させてください 🙇‍♂️）

開発エピソード②　検索DBのキープロパティの設定

検索DBのキープロパティ設定は忘れがちですが、設定することで検索エンジンの挙動が変わり、精度向上につながります。必ず対応してください。

GCP AI Applicationsのドキュメントにも記載があります。 https://cloud.google.com/generative-ai-app-builder/docs/provide-schema?hl=ja#example-schema

キープロパティは、検索エンジンに投入されたインプット情報の各列がどのような役割を持つかを明示するものです。今回の検索エンジン構築では、以下のようにキープロパティを設定することで、検索の質が向上しました。

• コースタイトルに name を設定
• コース要約に description を設定

一般的に、コースタイトルとコース要約では文字数が大きく異なります。コースタイトルが数十文字であるのに対し、コース要約はその数倍から数十倍の文字数になることがあります。name と description を設定することで、文字数の違いを検索エンジンに伝えます。これにより、検索エンジンはキーワード検索とセマンティック検索の重みや埋め込みモデルなどを調整し、精度向上を図っていると考えられます。 （設定によって挙動がどう変わるかは公式ドキュメントに明記されておらず、個人の推測です。誤りがあればご容赦ください）

開発エピソード③　検索DBの列名変更や列削除ができない

今回の開発で得られた教訓ですが、検索DBの列のリネームと削除はできません。開発時には、下記の点を念頭に置いて進めてください。

• スキーマ変更の制限：一度作成したデータストアの列名変更や削除は不可能
• 事前設計の重要性：スキーマ設計は慎重に行い、将来の拡張性も考慮する必要がある