Vertex AI Vector Search

解決する課題

• テキストや画像を埋め込み（ベクトル）にした後、似た意味のアイテムを高速に探したいが、総当たり比較では件数が増えると遅すぎる
• 生成 AI で自社ドキュメントを根拠に回答させたい（RAG）。質問に関連する文書チャンクを瞬時に取り出す土台が要る
• 推薦・類似画像検索・重複検出などで、数百万から数十億規模のベクトルに対し低レイテンシで近傍を返したい
• ベクトル検索基盤を自前で運用すると、インデックス構築・スケール・可用性の作り込みが重く、マネージドで任せたい

主要概念と用語

• Vector Search（ベクトル検索）: 埋め込みベクトルの近似最近傍探索を大規模・低レイテンシで提供するフルマネージドサービス。旧称は Matching Engine
• 埋め込み (Embedding): テキスト・画像などを意味を保った数値ベクトルに変換したもの。意味が近いものはベクトル空間でも近くに配置される
• 近似最近傍探索 (ANN): 全件を厳密に比較せず、許容できる精度で近い候補を高速に返す手法。総当たり（厳密 KNN）より桁違いに速い
• インデックス (Index): 検索対象ベクトル群から作る探索用データ構造。Google の ScaNN アルゴリズムをベースにする
• インデックスエンドポイント (Index Endpoint): インデックスをデプロイしてクエリを受け付ける配信先。検索リクエストはここへ送る
• 距離尺度 (Distance Measure): 近さの測り方。コサイン類似度・内積・ユークリッド距離などをインデックス作成時に選ぶ
• 更新方式: 全件を入れ替えるバッチ更新と、個別ベクトルを随時追加・更新するストリーム更新がある
• フィルタリング / 制限 (Restricts): ベクトルにラベルを付与し、検索時にカテゴリなどで候補を絞り込む機能
• 再現率 (Recall): 厳密な最近傍に対し、ANN がどれだけ正解を取りこぼさず返せたかの指標。速度と精度のトレードオフを表す

仕様・制限・クォータ

• インデックスはベクトルの次元数と距離尺度を作成時に固定する。埋め込みモデルの出力次元に合わせて設計する
• 更新はバッチ更新（Cloud Storage 上のデータから一括構築）とストリーム更新（個別ベクトルをほぼリアルタイムに反映）の二系統がある。要件に応じて選ぶ
• 検索精度と速度は ANN のパラメータ（探索する近傍の数など）で調整でき、再現率とレイテンシ・コストはトレードオフの関係になる
• 1 インデックスあたりのベクトル数・次元数・1 クエリで返せる近傍数（top-k）などに上限がある。具体的な上限値は変動するため公式ドキュメントとクォータ画面で確認する
• インデックスエンドポイントはマシンタイプとレプリカ数を指定してデプロイし、レプリカ数でスループットをスケールさせる
• 対応リージョンや上限は更新されるため、断定せず公式情報で都度確認する

内部の仕組み

Vector Search は、Google 社内の検索でも使われる ScaNN（Scalable Nearest Neighbors） をベースにした近似最近傍探索を提供します。検索対象のベクトル群からインデックスを構築すると、ベクトル空間が分割・量子化され、クエリベクトルに対して全件を見ずに近い候補だけを効率よく辿れる構造になります。これにより、数十億規模でも探索範囲を大きく絞り込み、低レイテンシで近傍を返せます。

運用面では、構築したインデックスをインデックスエンドポイントにデプロイします。クエリベクトルがエンドポイントに届くと、デプロイされたレプリカ群が近似探索を実行し、近い順に top-k のアイテム ID と距離を返します。本文や元データそのものは返さないため、ID を使って元のデータストア（データベースや Cloud Storage）から実体を引くのが基本の使い方です。データの追加・更新は、バッチ更新でまとめて作り直すか、ストリーム更新で個別ベクトルを随時反映します。

設計パターン / ベストプラクティス

• RAG のリトリーバル層に使う: 文書をチャンク分割して埋め込み、Vector Search で関連チャンクを取得し、その内容を Gemini などへ渡して回答を生成する
• ID 引きの設計を分ける: Vector Search は近傍の ID を返す役割に徹し、本文・メタデータは別のデータストアから取得する構成にする
• 更新頻度で方式を選ぶ: ほぼリアルタイムに反映したいならストリーム更新、定期的な一括入れ替えで足りるならバッチ更新
• フィルタで候補を絞る: カテゴリや権限などのラベルを付け、検索時の制限で対象を絞ると、精度とコストの両面で有利になる
• 再現率とコストを意図的に決める: 探索パラメータを調整し、ユースケースに必要十分な再現率に合わせてレイテンシとコストを最適化する

運用・監視

• Cloud Monitoring / Cloud Logging でクエリ数・レイテンシ・エラー率を監視し、エンドポイントの健全性を把握する
• レプリカ数とマシンタイプを負荷に合わせて調整し、スループットとコストのバランスを取る
• 検索品質はオフライン評価で再現率を測り、ANN パラメータの調整が効いているかを確認する
• 埋め込みモデルを更新したら、インデックスの作り直しと品質の再評価をセットで行う
• ストリーム更新を使う場合は、反映遅延と更新スループットの上限到達を監視し、必要に応じて設計を見直す

コスト

セキュリティ

• IAM でインデックス・エンドポイントへのアクセスを最小権限に分離する（AWS の IAM ロール相当）
• ワークロードにはサービスアカウントを割り当て、認証情報のハードコードを避ける
• 保存データは Google 管理鍵で既定暗号化され、要件に応じて CMEK（顧客管理鍵, Cloud KMS） を適用できる
• VPC Service Controls でデータ境界を作り、Private Service Connect / 限定公開アクセスで内部からのみエンドポイントに到達させる構成を取れる
• 検索対象に機微情報が含まれる場合、ラベルによるフィルタでユーザーの権限に応じた候補だけを返すなど、アクセス制御を検索層にも組み込む

関連サービス・比較

リトリーバル層の選択肢としては、フルマネージドのデータベースである AlloyDB / Cloud SQL に pgvector を組み合わせる方法もあります。小〜中規模で既存のリレーショナルデータと一緒に扱いたい場合は後者、超大規模・低レイテンシの専用検索が要る場合は Vector Search が向きます。

ハンズオン / CLI例

# 1) リージョンを指定して設定
gcloud config set ai/region asia-northeast1

# 2) Cloud Storage 上の埋め込みデータからインデックスを作成
#    （メタデータ JSON で次元数・距離尺度などを指定する）
gcloud ai indexes create \
  --display-name=my-index \
  --metadata-file=index_metadata.json \
  --region=asia-northeast1

# 3) インデックスエンドポイントを作成
gcloud ai index-endpoints create \
  --display-name=my-index-endpoint \
  --region=asia-northeast1

# 4) 作成したインデックスをエンドポイントにデプロイ
gcloud ai index-endpoints deploy-index INDEX_ENDPOINT_ID \
  --index=INDEX_ID \
  --deployed-index-id=my_deployed_index \
  --display-name=my-deploy \
  --region=asia-northeast1

# 5) エンドポイント一覧で確認
gcloud ai index-endpoints list --region=asia-northeast1