コンテンツに移動
データ分析

Zeotap: BigQuery ML とベクトル検索が自社の AI モデル構築にどのように役立つか

2025年12月4日
Joe Malone

Product Manager, Google

Sathish KS

Chief Technology Officer, Zeotap

Try Gemini 3

Our most intelligent model is now available on Vertex AI and Gemini Enterprise

Try now

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

編集者注: この投稿は、色々な組織が Google Cloud 以外のクラウド データ プラットフォームではなく Google Cloud 独自のデータ サイエンス機能をどのように活用しているかを紹介するシリーズの一部です。Google Cloud のベクトル エンベディング生成と検索機能は、Google の高度な AI 研究を活用したエンドツーエンドのカスタマイズ可能なプラットフォームであるという点で際立っており、タスクに最適化されたエンベディング モデルやハイブリッド検索などの機能を提供し、セマンティック クエリとキーワードベースのクエリの両方に対して関連性の高い結果を提供します。


Zeotap の顧客インテリジェンス プラットフォーム(CIP)は、ブランドが顧客を理解し、行動を予測して、顧客エンゲージメントを向上させるのに役立ちます。Zeotap は Google Cloud と提携して、プライバシー、セキュリティ、コンプライアンスを提供する顧客データ プラットフォームを構築しています。BigQuery で構築された Zeotap CIP を使用すると、デジタル マーケターは AI/ML モデルを構築して使用し、顧客の行動を予測して顧客体験をパーソナライズできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_t03FFBt.max-1900x1900.png

Zeotap プラットフォームには、類似オーディエンスの拡張と呼ばれる顧客セグメンテーション機能が含まれています。類似オーディエンスとは、既存の価値の高い顧客ベースと類似した特性や行動を共有する、機械学習アルゴリズムによって特定された新規の見込み顧客のグループです。しかし、ファーストパーティ データがまばらであったり、不完全であったりすると、効果的な類似オーディエンスを作成することが難しくなり、広告アルゴリズムが、類似する新しい見込み顧客を見つけるために必要な、価値の高い顧客の重要な特性を正確に特定できなくなります。このような希少な機能のために、Zeotap は複数の ML 手法を使用しています。これらの手法では、Zeotap のマルチグラフ アルゴリズムと高品質のデータアセットを組み合わせて、CDP と類似モデルの間で顧客のオーディエンスをより正確に拡張します。

このブログでは、Zeotap が BigQuery ML やベクトル検索などの BigQuery を使用して、エンドツーエンドの類似ユーザーの問題を解決する方法について詳しく説明します。Google では実用的なアプローチを採用することで、複雑な最近傍探索問題を単純な内部結合問題に変換し、専用のベクトル データベースを使用せずに、費用、規模、パフォーマンスの課題を克服しました。ここではデータ準備からサービス提供までのワークフローの各ステップを分解し、その過程で BigQuery がどのように主要な課題に対処するかを説明します。ユーザー プロファイル データセットで大部分を占めるカーディナリティの低いカテゴリ列に対処する手法の一つとして、エンベディングを使用したジャカード類似度を紹介します。

フローの概要は次のとおりで、すべて BigQuery エコシステム内で行われます。注: このブログでは、カーディナリティの高い列のフローについては扱いません。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_viuso9A.max-1100x1100.png

ジャカード類似度

エンベディング空間で最も近いベクトルを返す他の類似性指標がいくつかある中で、Zeotap は、カーディナリティの低い特徴に適合する指標として、ジャカード類似性を好んでいます。これは、2 つの集合間の重複を測定するもので、簡単な式 (A B)/(AB) で表されます。ジャカード類似度は、「2 人のユーザーのいずれかに存在するすべての固有の属性のうち、共有されている属性の割合はどれくらいか?」という質問に答えるものです。少なくとも 1 つのエンティティに存在する特徴(バイナリ ベクトルの 1 など)のみを考慮し、両方に存在しない属性は無視します。

図式的に示すと次のようになります。

ユーザー

興味 / 関心

バイナリベクトル [映画、スポーツ、音楽、書籍、旅行]

X∩B

X とのジャカード類似度

X

[映画、スポーツ]

[1,1,0,0,0]

-

-

Y

[映画、スポーツ]

[1,1,0,0,0]

2

2/2

Z

[映画、スポーツ、音楽、書籍、旅行]

[1,1,1,1,1]

2

2/5

ジャカード類似度は、エンべディング空間の距離のみを測定する他の多くの複雑な距離指標や類似度インデックスよりもシンプルで説明しやすいため、優れています。まさにオッカムの剃刀です。

実装へのブループリント

ベクトル エンベディングの生成カーディナリティの低い特徴を選択したら、プリミティブ列と配列ベースの列に対して BigQuery のワンホット エンコーディング マルチホット エンコーディングを使用してベクトルを作成します。

ここでも、サンプル ベクトルテーブルを可視化するとわかりやすくなります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_HYyDAga.max-700x700.png

課題: BigQuery ベクトル検索では、ジャカード距離は直接サポートされていない

BigQuery ベクトル検索は、ユークリッドコサインドット積の 3 つの距離タイプをサポートしていますが、ジャカード距離はサポートしていません(少なくともネイティブには)。ただし、ジャカード距離(1 - ジャカード類似度)が次のようになるバイナリベクトルの選択を表すことができます。

Jd(A,B) = 1 - |A∩B|/|A∪B| = (|A∪B| - |A∩B|)/|A∪B|

ドット積のみを使用すると、次のように書き換えることができます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_6ZFqrE0.max-1100x1100.png

つまり、ドット積を使用してジャッカード距離を求めることができます。BigQuery のすぐに使える LP_NORM 関数は、 マンハッタン ノルムを計算するのに便利です。バイナリベクトルのマンハッタン ノルムは、ベクトルとベクトル自身のドット積だからです。つまり、マンハッタン ノルム関数を使用することで、BigQuery でサポートされている「ドット積」検索を使用して計算できる方法で、ジャカード距離をサポートできることがわかりました。

ベクトル インデックスの構築

次に、ベクトル インデックスを構築する必要がありました。BigQuery は、IVF(Inverted File Index)と TREE_AH(Tree with Asymmetric Hashing)の 2 つの主要なベクトル インデックス タイプをサポートしており、それぞれ異なるシナリオに合わせて調整されています。TREE_AH ベクトル インデックス タイプは、 Google の ScaNN アルゴリズムをベースに、ツリーのような構造と非対称ハッシュ(AH)を組み合わせています。このアルゴリズムは、さまざまな ANN ベンチマークで優れたパフォーマンスを発揮しています。また、このユースケースは大規模なバッチクエリ(数十万から数百万のユーザーなど)を対象としていたため、他のベクトル データベースと比較して、レイテンシと費用を削減できました。

類似配信

検索を最適化するベクトル インデックスができたところで、私たちは「BigQuery の VECTOR_SEARCH 関数を使用して直接検索を実行すべきか?」と自問しました。このアプローチを基本テーブルに対して採用したところ、1 社のクライアントだけで 1 億 1,800 万ものユーザー エンコード ベクトルが生成されました。さらに、最も重要なこととして、この計算ではデカルト積が必要となるため、インメモリ データサイズがすぐに非常に大きく複雑になりました。すべてのお客様にスケーリングできる戦略を考案する必要がありました。

希少特徴戦略

シンプルながら非常に効果的な戦略は、偏在するユーザーの特徴を検索することを避けることです。2 段階の希少特徴プロセスでは、「遍在する」特徴を特定し、次に、より希少な特徴または判別力のある特徴を少なくとも 1 つ持つユーザーを含む、シグナルが豊富なテーブルを作成します。すぐに、検索スペースを最大 78% 削減できました。BigQuery の VECTOR_SEARCH では、事前フィルタリング を使用してこれを行うことができます。事前フィルタリングでは、サブクエリを使用して検索スペースを動的に縮小します。ただし、サブクエリは従来の結合にすることはできません。そこで、「フラグ」列を導入し、それをインデックスの一部にします。注: 列がインデックスに保存されていない場合、VECTOR_SEARCH の WHERE 句は事後フィルタを実行します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_zdPwyaH.max-900x900.jpg

BQUI またはシステム テーブルを使用して、ベクトルがクエリの高速化に使用されているかどうかを確認する

バッチ戦略

ベクトル検索では、クエリユーザー(N、ターゲットとするユーザー)とベースユーザー(M、ユーザープール全体、この場合は 1 億 1,800 万人)を比較します。複雑さは(M × N)で増加するため、大規模な検索はリソースを大量に消費します。これを取り扱うために、N クエリのユーザーにバッチを適用し、これらをグループごと(例: バッチあたり 500,000)に処理し、M はベースセット全体としました。このアプローチにより、計算負荷が軽減され、各クエリユーザーの上位 100 人の類似ユーザーを効率的にマッチングできるようになりました。 次に、グリッド検索を使用して、大規模な要件に最適なバッチサイズを決定しました。

まとめ

Google Cloud とのパートナーシップにより、デジタル マーケターは AI/ML モデルを構築して使用し、顧客セグメンテーションとパーソナライズされたエクスペリエンスを実現して、コンバージョン率の向上と顧客獲得費用の削減を推進できます。BigQuery ベクトル検索ではジャカード距離が直接サポートされていないという課題に対処するため、ドット積とマンハッタン ノルムを使用しました。BigQuery ML とベクトル サービスを活用したこの実用的なアプローチにより、1 つの SQL スクリプトだけでカスタムの類似ユーザー モデルを作成し、専用のベクトル データベースを使用せずに費用、規模、パフォーマンスの課題を克服できました。

BigQuery ML とベクトル サービスを、堅牢なサーバーレス アーキテクチャと組み合わせて使用することで、個々の顧客のドメインとニーズに対応するカスタムの類似ユーザー モデルをリリースできました。Zeotap と Google Cloud は、マーケターがどこでもリーチを拡大できるよう支援するパートナーシップを期待しています。

ISV とデータ プロバイダにとっての Built with BigQuery のメリット

Built with BigQuery は、BioCorteX などの企業による、Google のデータクラウドを活用した革新的なアプリケーション構築のお役に立ちます。参加企業には以下のメリットがあります。

  • 専任のエキスパートから、重要なユースケース、アーキテクチャ パターン、ベスト プラクティスに関するインサイトを得ることによって、プロダクトの設計とアーキテクチャの構築を加速できます。

  • 共同マーケティング プログラムを利用して、認知度の向上、需要の創出、導入の拡大を図り、より大きな成功を実現できます。

BigQuery は、Google Cloud のオープンかつ安全でサステナブルなプラットフォームに統合された、パワフルでスケーラビリティの高いエージェント時代の統合データクラウドのメリットを ISV に提供します。Built with BigQuery の詳細については、こちらをクリックしてください。

-Google、プロダクト マネージャー、Joe Malone 

-Zeotap、最高技術責任者、Sathish KS 氏 

投稿先