Google CloudのRAGは「3層構造」だった — ベクトル検索・マネージドパイプライン・自律エージェントを使い分ける設計指針

9月2日、Abdul Salamが「The Three Tiers of Google Cloud RAG: Vector Search, RAG Engine, and Agent Retrieval」と題した記事を公開した。この記事では、Google CloudがVertex AIエコシステム内で提供するRAGの3つのアーキテクチャ層（Vector Search／RAG Engine／Agent Retrieval）の役割と使い分けについて詳しく紹介されている。

RAGは「クエリを受け取り、ベクトル検索でチャンクを取得し、LLMに渡す」という単一のパターンとして語られることが多い。しかし実際の本番システムでは、この抽象化はすぐに崩れる。数十億件の商品カタログを5ms以下で検索するビジュアル検索エンジンと、法律文書を解析するドキュメントインテリジェンスパイプラインと、複数の異種データストアを横断して自律的に検索判断するDevOpsエージェントでは、エンジニアリング要件がまったく異なるからだ。

Google CloudはこのスペクトルをVertex AI上で3層に整理している。

3層の全体像

層	サービス	抽象レベル
Level 1	Vertex AI Vector Search	インフラ層（生の数学）
Level 2	Vertex AI RAG Engine	マネージドミドルウェア層
Level 3	Vertex AI Agent Retrieval	自律推論層

Level 1: Vertex AI Vector Search — 「生のベクトル数学」

最も低レイヤーかつ最もパフォーマンスが要求される層がVertex AI Vector Search（旧Matching Engine）だ。Googleが自社のYouTube推薦やGoogle Play検索で実際に使用するScaNN（Scalable Nearest Neighbors）を基盤としている。

ScaNN 3段階パイプラインが速い理由

ナイーブな全探索ではなく、以下の3ステージで高速化している：

Tree-AH粗い分割（階層的IVFツリー）： ベクトル空間を数千のVoronoiクラスタに分割し、クエリ時には全体の5〜10%のリーフクラスタだけを探索する。残り90〜95%の候補をマイクロ秒単位で除外する。
ADC（非対称距離計算）+ SIMD ベクトルスキャン： アクティブクラスタ内のベクトルは量子化バイトコードとして保存され、AVX-512などのSIMD命令でCPUのL1/L2キャッシュ内を高速スキャンする。
完全精度での再ランキング（オプション）： 量子化スキャンで絞った上位候補（100〜500件）を32bit浮動小数点の非圧縮ベクトルで再評価し、精度を確保する。

この設計により、10億件超のベクトルを扱いながらP99レイテンシ10ms以下（典型的な構成では5ms以下）、95〜98%のリコールを実現する。また、Anisotropic Vector Quantizationによるキャッシュ効率の高い圧縮により、非圧縮グラフベースの代替手段と比べてインフラTCOを最大40%削減できる点も実用上の強みだ。

ポストフィルタリングではなく「探索中フィルタリング」

多くのベクトルDBが「検索後にフィルタ」する設計であるのに対し、Vector Searchはツリー探索中にブール条件（allow_list/deny_list）や数値条件（LESS_EQUAL、EQUALなど）を評価するIn-Traversal Constrained Filteringを採用している。ポストフィルタリングでは条件が厳しいと結果が0件になるリコール崩壊が起きやすいが、この設計でそれを回避できる。

以下は、Go SDKを使ったベクトル検索の実装例だ。768次元のクエリベクトルに対してカテゴリ・ブランド・価格・在庫状況の複合条件でフィルタリングしている：

req := &aiplatformpb.FindNeighborsRequest{
  IndexEndpoint:   indexEndpointPath,
  DeployedIndexId: deployedIndexID,
  Queries: []*aiplatformpb.FindNeighborsRequest_Query{
    {
      Datapoint: &aiplatformpb.IndexDatapoint{
        DatapointId:   "query_req_001",
        FeatureVector: queryVector,
        Restricts: []*aiplatformpb.IndexDatapoint_Restriction{
          {Namespace: "category", AllowList: []string{"electronics", "audio"}},
          {Namespace: "brand",    AllowList: []string{"sony", "bose"}},
        },
        NumericRestricts: []*aiplatformpb.IndexDatapoint_NumericRestriction{
          {Namespace: "price",    ValueFloat: 350.0, Op: LESS_EQUAL},
          {Namespace: "in_stock", ValueInt:   1,     Op: EQUAL},
        },
      },
      NeighborCount: 5,
    },
  },
}

想定ユースケースとして記事が挙げているのは以下の3つだ：

大規模ECビジュアル検索： 2億以上のSKUで50,000+ QPSのトラフィックスパイクを処理しつつ、<10ms P99 SLAで在庫・価格・配送エリアの複合フィルタをかける
推薦ファネルの候補生成： YouTube・Google Playのような多段ファネルで、数億件から〜500件を3ms以下で絞り込むL1取得
リアルタイム金融詐欺検知： GNNとオートエンコーダで生成したトランザクション行動ベクトルを既知の不正クラスタと比較し、20ms以内に不正判定

Level 2: Vertex AI RAG Engine — 「定型ボイラープレートを捨てる」

Vector Searchは「生の数学」を提供するが、その上にRAGパイプラインを構築するにはPDFテキスト抽出・意味的チャンキング・埋め込み生成・ベクトルインデックス管理・再ランキングといった大量のボイラープレートが必要になる。Vertex AI RAG Engineはこの運用負担をAPIで丸ごと引き受けるマネージドレイヤーだ。

主な機能：

RagCorpusマネージドコーパス： Cloud StorageやGoogle Drive上のドキュメントを自動インデックス管理
レイアウト認識チャンキング： 表・見出し・文書階層を尊重したインテリジェントな分割（固定文字数スライスではない）
ハイブリッド検索 + セマンティック再ランキング： 密ベクトル検索とスパース語彙検索を組み合わせ、Googleのsemantic-ranker-512でスコア付け
Geminiグラウンディングと引用： GroundingChunkとGroundingSupportメタデータを返し、フロントエンドでインライン引用の表示とソース検証が可能

ベンダーロックインを避ける「プラグイン式ベクトルDB」

従来のマネージドRAGプラットフォームの課題として記事が強調するのが、プロプライエタリなベクトルストアへのベンダーロックインだ。Vertex AI RAG EngineはRagCorpusのプロビジョニング時に、物理的なベクトルストレージの選択を開発者に委ねる設計を取っている。既存のベクトルインフラやマルチクラウド環境を持つ組織にとって、データの重複コストを避けられる点は実践的なメリットだ。

Level 3: Vertex AI Agent Retrieval — 「AIが検索を自律判断する」

最上位層のAgent Retrievalは、3層のなかで最も抽象度が高く、検索そのものをモデルの推論ループに組み込む点が他の2層と根本的に異なる。

Level 1・2では、エンジニアが「何を検索するか」「いつ検索するか」を事前にコードで定義する。対してAgent Retrievalでは、Geminiの認知推論ループ（ReAct / Plan-and-Solve）に検索ツールを直接統合し、何を・いつ・どのように検索するかをモデル自身が動的に判断する。オーケストレーションにはGoogle Agent Development Kit（Google ADK）を使用する。

典型的なフローは次のようになる。ユーザーの複合的な質問を受けたエージェントが、まず社内ドキュメントコーパス（RAG Engine経由）を検索して関連規定を取得し、次に構造化データベースにSQLクエリを発行して数値データを補完し、さらに不足情報があればライブAPIを呼び出す——というマルチホップの検索シーケンスをモデル自身が組み立てる。記事が示すユースケースは以下の3つだ：

DevOpsインシデント対応エージェント： 障害アラートを受けてRunbook・ログ・過去インシデントチケットを横断検索し、根本原因の仮説と対処手順を自律的にまとめる
法律・コンプライアンス調査： 条文データベース・判例コーパス・社内ポリシー文書を順次参照し、複数法域にまたがる規制適合性を多段推論で評価する
エンタープライズ知識アシスタント： HR・財務・技術文書など部門をまたぐ異種コーパスを統一インターフェースで検索し、回答の根拠ソースを引用付きで提示する

Level 2との最大の違いは、検索の「決定権」の所在だ。RAG Engineはパイプラインが固定されており、クエリが来れば必ず同じ手順で検索する。Agent Retrievalはモデルが状況を判断して検索をスキップしたり、追加の検索ラウンドを自発的に発行したりできる。この柔軟性の代償として、推論コストとレイテンシはLevel 1・2より大きくなる点は考慮が必要だ。

どの層を選ぶべきか

記事の核心は「3層を理解し使い分けること」だ。要約すると：

sub-10msの超低レイテンシ、十億規模のスケール、カスタムフィルタリングが必要 → Vector Search
ドキュメントパイプラインを素早く構築したい、Geminiグラウンディングが必要 → RAG Engine
複数データソースを横断する自律的なエージェント → Agent Retrieval

これらは排他的ではなく、RAG EngineがVector Searchをバックエンドに使うなど、層をまたいだ構成も可能だ。

詳細はThe Three Tiers of Google Cloud RAG: Vector Search, RAG Engine, and Agent Retrievalを参照していただきたい。