コンテンツに移動
デベロッパー

Spanner の AI によるハイブリッド検索で検索エンジンをカスタマイズする

2025年1月16日
Chao Tian

Software Engineer, Spanner

Jagan R. Athreya

Group Product Manager, Spanner

※この投稿は米国時間 2024 年 12 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

検索は、オンライン ショッピングから重要な情報の検索まで、デジタル エコシステムでやり取りする方法の中核です。生成 AI が登場し、ユーザーの期待はかつてないほど高まっています。アプリケーションがユーザーの多様なニーズに応えるためには、クエリの形に関係なく、高速かつ正確で、コンテキストに応じた結果を提供する必要があります。次に例を示します。

  • オンラインの買い物客は、特定の「SummitEdge Pro」モデルと同じくらい簡単に「足首をサポートする防水のハイキング ブーツ」が見つかることを期待しています。

  • 法律専門家は、判例を正確に特定したり、さまざまな検索キーワードで微妙に意味合いの異なる法的概念を確認したりする必要があります。

  • 医師が重要な患者情報を検索する際には、正確さが求められます。「ペニシリンに対するアレルギー」を探す医師は、その情報が「薬物過敏症」と表示されていても、「ペシニリン」とスペルミスされていても、正確に記録を探し出さなければなりません。

実質的に無制限の拡張性を備えた、常時稼働している Google のマルチモデル データベースである Spanner は、AI によるハイブリッド検索機能でこれらの課題に対処します。Spanner により、デベロッパーは使い慣れた SQL インターフェースを使用して、ベクトル検索、全文検索、機械学習(ML)モデルの再ランキング機能を、運用データストアと直接統合された統一プラットフォームで組み合わせることができます。

この投稿では、Spanner を使用して e コマース マーケットプレイス用にオーダーメイドの検索エンジンを構築する方法をご紹介します。

Spanner でオーダーメイドの検索エンジンを構築する

他の多くの業界と同様、e コマースでは、単一の検索方法では不十分なことが多く、その結果、ユーザーに不満が出たり、情報が不完全になったり、収益が失われたりします。キーワード検索は精度に優れるものの、別の表現や自然言語を使用した検索の精度が課題となります。ベクトル検索はセマンティクスを捉えますが、特定の用語を見落とす可能性があります。両者の長所を組み合わせることで、組織はより効果的な検索エクスペリエンスを提供できるようになります。

仮想の e コマース マーケットプレイスである SpanMart では、ユーザーはキーワードや自然言語を使って商品を検索できます。同社の products テーブルは、次の 2 つの特別な列および関連するインデックスを含む複数の検索メソッドをサポートしています。

  • description_tokens : これは description の列をトークン化したバージョンで、テキストを個々の用語に分解します。この列の検索インデックスproducts_by_description)は全文検索を高速化し、情報検索での転置インデックスのような役割を担います。

  • embedding : 商品説明のベクトル表現を保存し、個々の単語ではなく、意味論的な意味を捉えます。類似した説明は「エンベディング空間」で近くにマッピングされます。これらのエンベディングは、Vertex AI Embeddings などのモデルを使用して生成されます。ベクトル インデックスproducts_by_embedding)は、効率的なセマンティック検索のために ScaNN ツリー構造を使用してこれらのエンベディングを整理します。

こちらに products テーブルとそのインデックスを Spanner で定義する方法を示します。

読み込んでいます...

これらのコンポーネントが揃うことで、SpanMart は以下が統合されたインテリジェントな検索パイプラインを構築できます。

  • ベクトル検索: 意味的な関連性

  • 全文検索: 正確なキーワードの一致

  • 結果の融合: 異なる取得方法からの結果を組み合わせる

  • ML モデルの再ランキング: 高度な結果の絞り込み

このパイプラインは、オペレーション データが保存されている Spanner 内のみで動作します。個別の検索エンジンやベクトル データベースとの統合を避けることで、Spanner は複数の技術スタック、複雑な ETL パイプライン、システム間通信のための複雑なアプリケーション ロジックを必要としません。これにより、アーキテクチャと運用上のオーバーヘッドを削減し、潜在的なパフォーマンスの非効率性を回避します。

下の図は、Spanner でこれらコンポーネントがどのように連携しているかの概要を示しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Tailor_your_search_engine_with_AI-powered_.max-1700x1700.jpg

ベクトル検索と全文検索の機能を組み合わせる

ユーザーが SpanMart で商品を検索すると、システムはまずエンベディング モデルを使用してユーザーのクエリをその意味論的意味を捉えるベクトルに変換します。その後、SpanMart は次の 2 つのクエリを構築します。

近似最近傍(ANN)ベクトル検索:

読み込んでいます...

読み込んでいます...

これら 2 つのクエリは、異なるシナリオに適しており、互いに補完し合います。たとえば、ユーザーが「Supercar T-6468」のような特定の商品のモデル番号を検索する場合、全文検索クエリは正確なモデルを的確に見つけることができる一方で、ベクトル検索クエリは類似のアイテムを提案します。逆に、より複雑な自然言語によるクエリ、たとえば「論理的推論が好きだが、おもちゃは好まない 8 歳の子供へのギフト」の場合、全文検索では有用な結果を得るのに苦労する可能性があるものの、ベクトル検索ではおすすめ商品のリストを提示できます。両方のクエリを組み合わせることで、どちらのスタイルの検索でも確かな結果を得られるでしょう。

Reciprocal Rank FusionRRF

RRF は、複数の検索語句の結果を組み合わせるためのシンプルでありながら効果的な手法です。RRF は各レコードの関連性スコアを計算します。このスコアは、すべての結果セットでのレコードの位置に基づいて計算され、個々の検索で上位にランクされたレコードにより大きな重みが与えられます。この方法は、個々の検索の関連性スコアが異なるスペースで計算され、直接比較するのが難しい場合に特に有用です。RRF は、各結果セット内のスコアではなく、相対的なランキングに重点を置くことで、この問題に対処します。

こちらに、RRF がどのように機能するかを例で示します。

  • ランクの逆数を計算する: 各商品で、定数(例: 60)を加えた後のランクの逆数をとることにより、各結果セットのランクの逆数を計算します。この定数は、上位にランク付けされた商品が最終的なスコアを独占するのを防ぎ、下位にランク付けされた商品が効果的に貢献することを可能にします。たとえば、ある結果セットで 5 位にランク付けされた商品は、その結果セットでは 1/(5 + 60) = 1/65 のランクの逆数を持つことになります。

  • ランクの逆数を合計する: すべての結果セットのランキングの逆数を合計して、商品の最終的な RRF スコアを取得します。

RRF の数式は次のようになります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Equation.max-800x800.png

 – ここで

  • d は商品の説明です。

  • r はリトリーバーのセット(この場合、2 つの検索語句)です。

  • rankr (d) は、リトリーバー r の結果における商品説明 d のランクを表します。

  • k は定数を表します。

RRF Spanner SQL インターフェースに実装するのは比較的簡単です。その方法をご紹介します。

読み込んでいます...

説明:

  • 共通テーブル式(CTE: これらは WITH 句で、このクエリでは読みやすさを向上させるために使用されています。ただし、現在の制限により、クエリ オプティマイザーのデフォルトが全文検索をサポートしていない古いバージョンになる可能性があります。現時点では、クエリは @{optimizer_version=7} ヒントを使用して、オプティマイザーのより新しいバージョンの使用を促します。 

  • ANN CTE: これは前の ANN クエリと同じですが、少し便利な点があります。結果で各商品にランクが割り当てられます。Spanner はランクを割り当てる直接的な方法をサポートしていませんが、対処方法があります。結果を構造体の配列に変換することで、配列内の各要素のオフセットをランクとして使用できます。配列のオフセットはゼロから始まるため、オフセット + 1 で実際のランクを表します。これは純粋に SQL 言語による回避策であり、パフォーマンスには影響しません。クエリ プランナーは、配列変換を効果的に最適化し、結果セットの各行にオフセットを直接割り当てます。

  • FTS CTE: 同様に、この部分は前の全文検索クエリを反映しており、配列のオフセットを使ってランクが割り当てられます。

  • 組み合わせとランキング: 両方の CTE の結果は統合され商品 id でグループ化されます。各商品の rrf_score を計算し、上位 50 商品を選びます。

RRF は効果的な手法ですが、Spanner の汎用性の高い SQL インターフェースにより、アプリケーション デベロッパーは他のさまざまな結果融合の方法を検討して実装できます。たとえば、デベロッパーは異なる検索でスコアを共通の範囲に正規化し、加重合計を使用してそれらを結合し、各検索方法に異なる重要度を割り当てることができます。この柔軟性により、検索エクスペリエンスをきめ細かく制御でき、デベロッパーは特定のアプリケーション要件に合わせて検索エクスペリエンスを調整できます。

ML モデルによる検索結果の再ランク付け

ML モデルベースの再ランキングは、検索結果を絞り込んでユーザーに改善された結果を提供する優れた方法です。前述したように、ベクトル検索、全文検索、またはこれらを組み合わせた方法を使用してリトリーブした初期候補の絞り込まれたセットに、高度であるものの計算費用が高額なモデルを適用します。計算費用が高いため、ML モデルベースの再ランキングは、最初のリトリーブが結果セットを少数の有望な候補に絞ってから適用されます。

Spanner Vertex AI とのインテグレーションにより、ML モデルベースの再ランキングを Spanner 内で直接実行することが可能になります。Vertex AI エンドポイントにデプロイされたモデルを使用できます。これには、Vertex AI Model Garden から入手可能なモデルも含まれます。モデルのデプロイが完了したら、Spanner で対応する reranker MODEL を作成できます。

読み込んでいます...

この例では、SpanMart は再ランキングに Cross-Encoder モデルを採用しています。このモデルは 2 つのテキスト入力(text text_pair)を受け取り、この 2 つのテキストがどの程度一致しているかを示す関連性 score を出力します。エンベディング モデルを使用して各テキストを固定次元空間に個別にマッピングしてから類似度を測定するベクトル検索とは異なり、Cross-Encoder 2 つのテキストを一緒に評価します。これにより、Cross-Encoder は、「論理的推論が好きだが、おもちゃは好まない 8 歳の子供へのギフト」といった複雑なクエリで、より豊富なコンテキスト情報と意味的なニュアンスを捉えることができます。より高度なセットアップでは、reranker は、商品レビュー、プロモーション、閲覧および購入履歴のようなユーザー固有のデータなど追加のシグナルを組み込んだカスタム トレーニング モデルを活用し、さらに包括的な検索エクスペリエンスを提供できます。

このモデルを Spanner で定義したら、次のクエリを使用して、最初の検索結果に再ランキングを追加できます。

読み込んでいます...

説明:

  • ANNFTSRRF CTE: これらはそれぞれ、以前に定義した近似最近傍、全文検索、Reciprocal Rank Fusion クエリと同じです。

  • ML.PREDICT Ranking: このステップでは、reranker モデルを RRF の結果から text として各商品説明に適用し、検索語句を text_pair として適用します。モデルは各商品に関連性 score を割り当てます。その後、これらのスコアで商品が並べ替えられ、上位 10 位が選ばれます。

使ってみる

この投稿では、Spanner で全文検索とベクトル検索を組み合わせる 1 つのアプローチを示しましたが、デベロッパーはベクトル検索で全文検索結果を絞り込んだり、カスタマイズされた融合メソッドで複数の検索結果を組み合わせたりするなど、他のアプローチについても検討することをおすすめします。

Spanner の詳細情報を確認し、今すぐお試しください。その他の情報については、以下をご覧ください。

SQL を使用した ML 予測の生成での Spanner Vertex AI インテグレーションの概要およびチュートリアル

ー Spanner、ソフトウェア エンジニア Chao Tian

ー Spanner、グループ プロダクト マネージャー Jagan R. Athreya

投稿先