Google CloudがAlloyDB AIのモデル更新準備を紹介、切り替え前の品質検証を支援

エンベディングモデル更新で生じる課題

エンベディングモデルを本番で更新するには、全データの再エンベディングやインデックスの再構築、クエリを止めないスキーマ移行の調整が伴います。移行で起こりうる主な課題は、以下の通りです。^[1]

再エンベディングでは通常、複雑なパイプラインの更新と、新旧モデルを一定期間並行稼働させる間のデュアルライトが必要です。クエリ側のベクトルと保存済みのベクトルは、検索品質の大きな低下を防ぐため、同じモデルへ同時に切り替える必要があります。

AlloyDB AIでできること

Model endpoint managementは、ファーストパーティやサードパーティ、セルフホストを含むエンベディングモデルへ、データベース内からアクセスする手段です。インデックスの同時作成や集合を返す関数（SRF）、列名の原子的な変更などPostgreSQLの標準機能は、ブルーグリーン型やカナリア型の切り替えに使えます。^[1]

図1　AlloyDB AIの関連機能（自動エンベディングはプレビュー版）

プレビュー版のAuto Embeddingsは、エンベディングを裏側で毎秒最大3000件生成し、元データの変更にも追従させる機能です。Google Cloudは、ScaNNインデックスの構築がオープンソースのHNSWより10倍速く、移行にかかる時間を大きく減らせるとしています。^[1][2]

AlloyDB AI移行例のトラフィック切替前手順

例の対象はecomm.product_reviewsテーブルで、ベクトルは768次元から3072次元に変わります。ステップ0では、google_ml_integration拡張機能の版が1.5.6以降（動作確認は1.6.1）であることと、モデルへの接続の確認が必要です。^[1]

図2　列の追加から切り替え前の検証までの手順

移行例は、切り替え前に検証するステップ4までです。インデックス構築と切り替え自体は、ステップ0〜4の段階に含まれていません。

事前確認では、vector拡張機能とalloydb_scann拡張機能も作成し、ai.embeddingの出力が3072次元になるかを確かめます。既存のAuto Embeddingsの設定は、ai.embedding_settings_viewで確認できます。

列の追加とエンベディングの初期化

ステップ1では、既定値がなくNULLを許す新しいvector列を追加します。この操作は行ごとの新しい版を作らずカタログ情報だけを更新するため、ほぼ瞬時に終わる処理です。

図3　ステップ1の列追加で確かめる点

ベクトル列のサイズは、エンベディングモデルが出力する次元数と一致させる必要があります。lock_timeoutを2秒にするのは排他ロックの待ちで本番の処理を妨げないためで、待ちが長引いて失敗した場合は再実行します。

ステップ2は、プレビュー版のAuto Embeddingsのai.initialize_embeddingsで新しい列のエンベディングを生成する段階です。実行するSQLは、以下の通りです。^[1][2]

CALL ai.initialize_embeddings(
    model_id => 'gemini-embedding-001',
    table_name => 'ecomm.product_reviews',
    content_column => 'review_text',
    embedding_column => 'new_embedding_col',
    batch_size => 50,
    incremental_refresh_mode => 'manual'
);

公式資料からの抜粋：How to upgrade embedding models in AlloyDB AI with zero downtime（Step-by-step migration walkthrough / Step 2: Initialize auto-embeddings and run backfill）。対象版・範囲：Google Cloudブログ（How to upgrade embedding models in AlloyDB AI with zero downtime）の手順。

上記のコードでは、model_idにgemini-embedding-001を、embedding_columnにnew_embedding_colを指定しています。incremental_refresh_modeを'manual'にしているのは、元のテーブルへの書き込みの性能を保つためです。

進捗確認とmanualモードの追い付き

AlloyDBは、自動エンベディングのジョブの状態や処理済みの行数、推定残り時間を追えるビューを備えています。進捗の照会は、別のセッションから実行する手順です。

図4　manualモードの移行例で使うビューと更新処理

manualモードの移行例では、最初のバックフィルが完了した後に、実行中に変更された行のエンベディングをai.refresh_embeddingsで任意に再生成できます。Google Cloudは、最新の変更を反映し続けるため、この更新をpg_cronや外部のスケジューラーで定期的に実行するよう勧めています。

切り替え前の品質検証

ステップ4では、トラフィックの切り替え前にエンベディングの欠けと正しさを確かめます。対象は、google_ml_track_stale_embedding = 'false'の行です。

図5　ステップ4の検証クエリで確かめる値

欠けの確認は、google_ml_track_stale_embedding = 'false'の行でnew_embedding_colのNULLがほぼ0件かを数える処理です。距離の確認は、同じ条件の無作為な20行でgemini-embedding-001を再度呼び出し、新しい列との最大距離が0に近いかを見ます。

前回のai.refresh_embeddings以降に変更のない行に絞るのは、結果の偏りを防ぐためです。追跡用の列名が検証クエリと違い、google_ml_track_stale_embedding_2などの場合は、クエリの修正が必要です。

図6　ステップ4の検証対象の条件

近傍結果の重なりと本番前の試験

Google Cloudの社内比較では、text-embedding-005とgemini-embedding-001の上位10件の近傍結果の重なりは31%にとどまりました。Google Cloudは、この変化を3072次元モデルの意味の忠実度の高さの表れとしています。

図7　2つのモデルの社内比較結果

recall@10の新しい結果はアプリの前提に影響しうるため、本番トラフィックの切替前に見本のgolden queriesでのオフライン試験が必要です。新モデルでのアプリのロジック検証も行います。

AlloyDB AIの機能ごとの利用条件

ai.initialize_embeddingsを使う自動ベクトル エンベディングは、確認日時点でプレビュー版です。機能ごとに確かめる主な条件は、以下の通りです。^[2]

出典：^[1][2][3]

プレビュー版の自動ベクトル エンベディングでは、使用するモデルの割り当てが足りないと、処理が遅くなったり失敗したりする可能性があります。Geminiエンベディングモデルのシリーズの上限は、プロジェクトごとに毎分5,000,000トークンです。

図8　プレビュー版の自動エンベディングの割り当て

エンベディング移行で指定する設定の選び方

エンベディング移行で選ぶ設定には、incremental_refresh_modeとmax_parallel_requestsがあります。どちらも、更新時やバックフィル中の書き込みに影響する設定です。^[1]

増分更新モードの選び方

incremental_refresh_modeは、元データの変更をエンベディングへ反映する方式を決める設定です。transactionalは変更時にすぐ更新する分だけ書き込みが遅くなり、manualは変更行を追跡してai.refresh_embeddingsで後から再生成する方式です。

図9　増分更新モードの違い

Google Cloudは、変更頻度が低く整合性を保ちたい場合はtransactional、変更頻度が高く更新間隔までのずれを許容できる場合はmanualを勧めています。transactionalを選ぶ場合は、テーブルに対するオーナーロールが必要な点もプレビュー版での確認事項です。^[1][2]

Auto Embeddingsの並列度

バックフィル中、Auto Embeddingsはbatch_size × max_parallel_requestsの単位で行を並列処理します。同時の更新や削除は、バッチのコミットを待つ必要があります。

図10　10,000行のテーブルでの測定値（秒）

書き込みの多いトランザクションテーブルで書き込み側の最長の待ちを抑える場合は、バックフィルのセッション中にmax_parallel_requestsを下げることが可能です。設定例の値は、google_ml_integration.max_parallel_requestsを20にするものです。

Google Cloudの10,000行のテーブルでの測定では、既定値400を20にすると、並行する書き込みの最長の待ちは5.1秒から0.39秒に縮みました。一方、バックフィル全体の所要時間は5.2秒から7.6秒に延びたため、書き込み待ちの上限を優先して値を下げる場合は全体が延びることも見込んでおくとよいでしょう。