AlloyDB AIのハイブリッド検索が更新、ベクトル検索と全文検索を1つのSQL関数で統合可能に

AlloyDB AIのハイブリッド検索でできること

今回の更新の中心は、ベクトル検索とFTSの結果をRRFで1つのSQL関数にまとめられることです。FTSには、単語の位置を保存するRUM拡張機能と、プレビューのBM25インデックスを使えます。^[1][2]

図1　AlloyDB AIのハイブリッド検索でできること

従来の多段階の処理では、ベクトル列またはベクトルインデックスで上位k件を検索してベクトルスコアを出し、FTSのクエリも別に実行していました。2つの結果セットの統合には複雑なSQLや独自コードが必要で、統合やスコア正規化、再ランキング用の別システムを保守することも多かったとされています。

FTSを別のシステムで行う場合、アプリケーションのメモリ上で文書IDのFULL OUTER JOINと正規化スコアの重み付き加算、並べ替えを行っていたとされます。Google Cloudによれば、この分散した方式は壊れやすいスコア計算やレイテンシの増加、高い運用負荷を招き、検索品質の維持もアプリケーションの専門知識に頼っていました。

Google Cloudによると、AlloyDB AIのネイティブな方式より前は、標準SQLでロジックをデータベース内に保つ堅牢なハイブリッド検索は困難でした。多段階の処理は2つのソースでも管理と保守が難しく、ソースを増やすと事実上スケールできなかったといいます。

hybrid_search()の仕組み

Reciprocal Rank Fusion（RRF）は、複数の検索結果リストを1つに統合する順位ベースのアルゴリズムで、壊れやすいスコア正規化の手順を不要にします。hybrid_search()関数は、ワークフロー全体を1つのクエリプランで実行し、オーバーヘッドを抑えてトランザクションの整合性の確保を助けます。^[1][3]

関数は動的SQLでコンポーネントごとに共通テーブル式（CTE）を作り、各CTEで順位を計算する仕組みです。次に、文書IDのFULL OUTER JOINで各CTEの順位を結合し、RRFの式で最終スコアを計算します。

図2　ai.hybrid_searchの処理

Google Cloudは、hybrid_search() UDFは外部ロジックが不要で、宣言的なSQL呼び出し1つで済むと評価しています。RRFは順位ベースで分布に依存せず正規化式の継続的な調整が不要とされ、関数は高性能なベクトル検索とFTSで包括的な検索関連性を出す設計です。

Google Cloudは手動SQLで再現した多段階の処理と比較し、UDFでは壊れやすいスコア計算とアプリケーション側の結合が不要になるとします。ネイティブのSQL関数へ移るとすぐに測定できる利点があり、1回のSQL呼び出しで運用とエンジニアリングのコストを大きく下げ、正確で高速な結果を一貫して返すといいます。

AlloyDB AIのハイブリッド検索の使い方

ハイブリッド検索は、テキスト検索インデックスを設定してベクトル検索インデックスを選び、作成後に各種クエリの例で始められます。AlloyDB内のテーブルで実行するには両方のインデックスが必要で、ベクトル検索にはScaNNアルゴリズムによる最近傍インデックスを使えます。^[1][3][4]

次のコードは、2つの検索要素を宣言的なJSON配列で渡し、ai.hybrid_searchを1回呼び出す例です。

SELECT id, score 
FROM ai.hybrid_search(
    search_inputs => ARRAY[
        -- Vector Component (Semantic) with dynamic embedding generation from natural language
        $json${
            "data_type": "vector",
            "limit": 10,
            "table_name": "documents",
            "key_column": "doc_id",
            "vec_column": "embedding",
            "distance_operator": "<=>",
            "query_vector": "ai.embedding('text-embedding-005', 'alloydb search')::vector"
        }$json$::jsonb,
        
        -- Text Component (Keyword)
        $json${
            "data_type": "text",
            "limit": 10,
            "table_name": "documents",
            "key_column": "doc_id",
            "text_column": "content",
            "query_text_input": "alloydb search"
        }$json$::jsonb
    ]
);

公式資料からの抜粋：AlloyDB: A unified database engine for hybrid search（Simplifying hybrid search architectures with AlloyDB / 1. The single source of truth）。対象版・範囲：AlloyDB AI（Google Cloudブログの発表内容）。

上記では、data_typeがvectorの要素が意味検索を、textの要素がキーワード検索を担います。query_vectorは、ai.embeddingとtext-embedding-005で自然言語からエンベディングを生成します。

図3　AlloyDB内のテーブルで始める準備

ai.hybrid_search関数は2つの要素に限らず、プレビューのexternal_search_fdwによる外部検索ソースにも対応し、その準備は別の手順です。Google Cloudは、外部の結果を直接統合し、大規模なテキストとベクトルの意味的な知見を組み合わせられるとします。^{[1][4][5][6][7]}

プレビューのSolrとの統合では、検索エントリに外部データテーブル名を指定し、weightでRRFへの貢献度を指定します。発表時点のランキングアルゴリズムはRRFで、Google Cloudは今後、ほかの統合・ランキングの選択肢を追加する意向です。

AlloyDB AIの関連拡張のプレビューと対応版

BM25インデックスは、pg_textsearch拡張機能を通じてCloudSQLとAlloyDBにプレビューとして導入されました。external_search_fdw拡張機能のバージョン1.0も、プレビューの段階です。^[1][2][4]

プレビューのpg_textsearch拡張機能は、PostgreSQL 17または18のAlloyDBでのみサポートされます。RUM拡張機能は、PostgreSQL 17以前のAlloyDBが対象です。^[2][8]

図4　検索関連機能の提供状態と対象版

プレビューのElasticsearch、Solr、OpenSearchとの統合で外部データを照会するには、プライマリAlloyDBインスタンスでアウトバウンド接続を有効にします。クラスタの認証情報はSecret Managerに保存し、AlloyDBサービスアカウントにシークレットの読み取り権限を与えます。^[5][6][7]

これらの統合はPostgreSQLのメジャーバージョンが対象なら使え、Solrとの統合は17以降が対象です。接続や認証情報などの事前条件を満たしたうえで、external_search_fdw拡張機能を有効にし、外部データサーバーとユーザーマッピング、外部テーブルを作成します。

AlloyDB AIのハイブリッド検索のFTS選定

低レイテンシならRUM拡張機能、キーワードスコアの精度ならプレビューのBM25インデックスが推奨とされ、両者の対応版が重なるのはPostgreSQL 17です。Google Cloudは、低レイテンシな内部FTSにはRUM拡張機能、拡張性のある専用バックエンドには外部検索の経路を示し、ワークロードやデータ量、既存基盤で選べるとします。^[1][2][8]

FTSインデックスの選択

標準のPostgreSQL GINは単語の位置情報を保存せず、関連性ランキングやフレーズ検索で内容を再分析する高コストなテーブルスキャンが必要です。関連性ランキングは単語の近接度と出現頻度からスコアを計算する処理、フレーズ検索は正確な語順を見つける検索です。

Google Cloudは、RUM拡張機能がScaNNなどのベクトル検索を補完し、GINは潜在的なレイテンシのためリアルタイムのハイブリッド検索に向きにくいとします。Google Cloudによれば、RUM拡張機能はGINを基にしたインデックスアクセス方式で、こうした課題を直接解決するものです。

RUM拡張機能は単語の位置をインデックス内に保存し、ランキングやフレーズ一致を主にインデックス内で処理して、高コストなヒープスキャンを避ける方式です。これにより関連性ランキングは大幅に速くなり、フレーズ検索と近接検索も効率化するといいます。

図5　GINとRUM拡張機能の違い

Google Cloudは、RUM拡張機能をランキング中心や同時実行の多い検索アプリに適した選択肢と評価する一方、インデックス構築は遅く、ディスク使用量も大きくなります。BEIR Natural Questionsベンチマークのテストでは、FTS単体とFTSを含むハイブリッド検索の両方で、GINより性能が向上しました。

プレビューのBM25インデックスは、単語の頻度の飽和と文書長の正規化を考慮するTF-IDFを使ったランキング方式です。Google Cloudは、キーワード検索の精度と品質が大幅に高まり、外部の検索エンジンや複雑な独自のスコアリングなしで優れたランキング精度を得られるとします。

プレビューのBM25インデックスで関連性ランキングに使うのは、<@>演算子です。RUM拡張機能の検索とランキングには<=>演算子を使い、この演算子はハイブリッド検索のSQL呼び出しでも使えます。

-- Install pg_textsearch extension
CREATE EXTENSION pg_textsearch;

-- Create the native BM25 index on the content column
CREATE INDEX idx_docs_bm25 
ON cymbal_products 
USING bm25 (product_description) 
WITH (text_config='english');

-- Full text search query
SELECT product_name, product_description <@> 'cherry tree' AS bm25_score 
FROM cymbal_products
ORDER BY bm25_score 
LIMIT 5;

公式資料からの抜粋：AlloyDB: A unified database engine for hybrid search（Introducing BM25 Index: The modern ranking standard）。対象版・範囲：プレビュー（Google Cloudブログの発表内容）。

外部検索クラスタの活用

プレビューのexternal_search_fdw拡張機能は、各統合の条件下でElasticsearch、OpenSearch、Solrの外部クラスタを全文検索できます。Google Cloudは、専用の検索クラスタの規模やランキングアルゴリズム、豊富な機能を、AlloyDB環境から離れずに活用できるとしました。^[1][4][5][6]

Google Cloudによれば、external_search_fdw拡張機能では標準のPostgreSQLのSQLで外部データの操作や結合、結果の統合ができます。高度なFTSクエリの表現力は失わず、既存の検索基盤のままAlloyDB AIの簡素化されたハイブリッド構成の利点を得られるとされます。

図6　Google Cloudが示す外部検索の利点

編集部の整理では、まずPostgreSQL版と統合の前提条件を確かめ、低レイテンシ重視ならRUM拡張機能、キーワード精度重視ならプレビューのBM25インデックスが候補です。既存の専用検索クラスタを生かすなら、プレビューのexternal_search_fdw拡張機能を検討します。