Google Retrieve-for-Train、複雑な検索推論をクリティカルパスから切り離す

Google Retrieve-for-Trainは、AI検索におけるコストの高い処理の一部をライブ推論からオフライン学習へ移し、ファンアウトの速度を12倍から20倍に高めたと報告している。このフレームワークが対象とするのは、最も近い単一の結果ではなく、有用な結果集合を必要とする検索だ。その中核にあるのは、コンパクトなモデルが複雑な検索行動を一度学習し、リクエストごとに長い推論トレースを生成せずに再現できるという考え方である。

Google Researchは、このフレームワークをICML 2026の論文として発表した後、2026年9月15日に紹介した。この研究は消費者向け検索製品を発表したものでも、Google Searchへの導入を告知したものでもない。ファッションコレクションや音楽プレイリストを用いた実験に支えられた、特化型検索システム向けの学習パイプラインを提案している。

この区別こそが本質的な緊張関係を生む。大規模言語モデルはニュアンス豊かなクエリ拡張を生成できるが、逐次生成にはレイテンシーと繰り返しの検索処理が伴う。従来の埋め込み検索はより高速に応答する一方、結果集合全体の多様性、網羅性、補完性ではなく、個々の一致を最適化しがちだ。Retrieve-for-Trainは、前者の計画品質をはるかに小さなデプロイメントモデルに保持しようとしている。

Google Retrieve-for-Trainはデプロイ前に検索行動をコンパイルする

重要なのは言語モデルを高速化することではない。ライブ検索経路から言語モデルを取り除くという判断だ。

多くの検索システムは、文書や製品を個別にランキングする。名前が指定された文書を探すように、ひとつの結果でリクエストを満たせる場合、この設計は有効だ。しかし、各要素が互いに補完し合う必要がある集合をリクエストが示唆する場合、その有用性は下がる。

たとえば、誰かがコマースカタログでキャンプ用品を検索するとする。関連性の高いテントが10件並んでも、結果集合としては不十分だ。有用な候補一覧には、シェルター、寝具、照明、調理用品など、異なるニーズが含まれるべきである。したがって、各アイテムの質は、隣に何が表示されるかにも部分的に左右される。

システムはしばしば、広範なリクエストを複数の狭いサブクエリに分割するクエリファンアウトでこの問題に対処する。言語モデルは「キャンプ用品」を、テント、寝袋、ポータブルストーブ、ヘッドランプを探す検索へ変換できる。各サブクエリが候補を取得し、システムがそれらを組み合わせる。

難しいのは、汎用言語モデルが特定カタログの構造を本質的に理解しているわけではない点だ。何も取得できないもっともらしい語句を生成したり、元のリクエストから逸脱したり、ほぼ同義の表現を繰り返したりする可能性がある。Googleは最後の失敗を「paraphrastic collapse」と呼ぶ。ボヘミアン風フェスティバル衣装について尋ねられたモデルは、ブーツ、かぎ針編みのドレス、フリンジジャケットをカバーせず、「ボヘミアン・フェスティバル・ファッション」のような表現を何通りも生成するかもしれない。

より慎重な推論はこうした失敗を減らせるが、逐次的なトークン生成と繰り返しのデータベース呼び出しを加える。自己回帰生成ではトークンをひとつずつ生成するため、基盤モデルが効率的に動作していてもレイテンシーの下限が生じる。

Google research postは、異なる役割分担を説明している。強化学習が有効なクエリ分解をオフラインで探索する。得られた行動は、複数の検索方向をまとめて生成するコンパクトな拡散検索器向けの合成学習データとなる。

このフレームワークは3段階で構成される。まず、ファンアウト言語モデルがタスク固有の報酬のもと、補完的な10個のサブクエリを生成するよう学習する。次に、学習済みモデルが人手ラベルなしでクエリとターゲット集合の例を生成する。最後に、5390万パラメータの拡散モデルが、クエリ埋め込みをターゲット埋め込みの集合へ直接写像することを学習する。

ライブトラフィックに応答する必要があるのは最終モデルだけだ。強化学習と言語生成は、レイテンシーを吸収でき、成功した行動を再利用できる学習段階にとどまる。

したがってGoogle Retrieve-for-Trainは、高コストな計算をどこで行うかを変える。計算自体をなくすわけではない。デプロイ前にコストを払い、その後の検索全体にわたって償却しようとする。

集合検索が異なる推論ボトルネックを生む理由

複雑な検索は、関連性が個々の結果ではなく集合全体に帰属する場合に難しくなる。

従来のランキングは、関連性をクエリとアイテムの組の性質として扱う。各結果にスコアが与えられ、システムは候補をその順に並べる。この構造は、各学習例で有用な文書、画像、製品を特定できるため、成熟したlearning-to-rankパイプラインを支えている。

集合検索は異なる問いを投げかける。複数の結果が、多様性、網羅性、一貫性、補完性をまとめて表現しているかを判断しなければならない。こうした性質は非分解的であり、各アイテムを単独で採点してそのスコアを足し合わせるだけでは、常に算出できるとは限らない。

プレイリストは明快な例だ。各トラックが求められたムードに合っていても、リスト全体は依然として単調だったり、一貫性に欠けたりする可能性がある。コーディネートも同様だ。個々の衣服がテキスト上のテーマに合っていても、互いにちぐはぐだったり、必須カテゴリを満たせなかったりする。

また、正しいコレクションがひとつだけ存在することはほとんどない。同じリクエストを満たす異なるコーディネートは複数あり得る。この曖昧さは、記録された集合が完全な正解空間ではなく、受け入れ可能な答えのひとつにすぎないため、通常の教師あり学習を難しくする。

LLMは推論時にこうした関係を推論できる。観点を提案し、取得済みの候補を確認し、計画を修正して再検索できる。しかし、推論トークンやデータベースとのやり取りが増えるたびに、応答経路は長くなる。多数の候補分解をサンプリングし、最良のものを選ぶ手法は品質をさらに高められるが、そのコストは試行回数とともに上昇する。

R4T paperは、これを、より豊かな検索目的と限られた学習監督とのミスマッチとして位置付けている。強化学習は結果集合全体を対象とした報酬を最適化できるが、学習済み言語モデルを提供するには依然として高いコストがかかる。拡散検索器は複数の埋め込みを並列に生成できるが、学習には適切なターゲット集合が必要である。

Retrieve-for-Trainは、こうした不完全な解決策を結び付ける。言語モデルが有用な行動を発見し、拡散モデルがそこから得られる検索方向の分布を模倣するよう学習する。このアプローチは蒸留に似ているが、教師が単に従来型のラベルを生成するわけではない。教師はデータベースと相互作用し、明示的な集合レベルの目的を最大化する出力を探索する。

この設計は、推論負荷の高いAI検索アーキテクチャに疑問を投げかける。反復的な検索タスクに安定したコーパスと測定可能な目標があるなら、リクエストごとに精緻な分解を行うことは無駄になり得る。学習済みの専門モデルは、より低いレイテンシーと少ない提供リソースで、その行動を十分に再現できる可能性がある。

ただし、この問題意識がすべての領域に同じように当てはまるわけではない。オープンウェブ上の質問は、変化する情報、緩やかに定義された目的、そして新たな推論を要する可能性があるリクエストを含む。製品カタログ、メディアライブラリ、社内ナレッジコレクションは、より制御されたデータベースと、有用な網羅性のより明確な定義を提供する。

したがって、このフレームワークは特化型検索アーキテクチャとして理解するのが最も適切だ。固定コーパス上の反復的な検索パターンを対象とし、現在AI検索という広いラベルのもとに置かれているすべての活動を対象とするわけではない。

この仕組みは報酬を並列検索器へ変換する

Retrieve-for-Trainは強化学習をデータ生成器として用い、ライブ検索を非自己回帰型モデルに委ねる。

第1段階は、Gemma 3 4BまたはQwen3 4Bをベースとするファンアウト言語モデル、すなわちFOLMから始まる。各広範なプロンプトに対し、モデルは正確に10個のサブクエリを生成する。固定された検索器がそれらのサブクエリを対象データベースに対して実行し、学習システムが得られた集合を評価できるようにする。

オープンエンドの抽象的な検索に対して、Googleはgroundedness、diversity、alignmentという3つの報酬を組み合わせる。Groundednessは、実際のデータベースアイテムから大きく離れたサブクエリを抑制する。Alignmentは、拡張を元のリクエストと結び付けたままにする。Diversityは、サブクエリがコーパス内の意味的に異なる領域を探索することを促す。

多様性の要素では、コレクション全体の多様性を評価するために設計された類似性ベースの指標、Vendi Scoreが用いられる。元のVendi Score researchは、多様性を、選択した類似関数のもとでの実効的な異なる要素数として扱う。R4Tでは、密接に関連する言い換えのリストと、真に意味的な広がりを区別する助けとなる。

これらの目的は相互に制約し合う。Groundednessだけでは、たまたまデータベース座標の近くに位置する無意味なテキストを報いる可能性がある。Alignmentを加えると、モデルは元のクエリを安全だが反復的に言い換える方向へ傾くことがある。Diversityは、異なる検索方向に報酬を与えることで、この安易な収束を防ぐ。

Googleは、soft proximal policy optimization正則化を伴うgroup relative policy optimizationを用いる。GRPOは同じプロンプトに対して複数のサンプリング出力を比較し、それらの相対報酬からアドバンテージを導出する。より広範なGRPO methodは、別個の価値モデルなしで言語モデルの方策を最適化する手法として注目を集めた。

Retrieve-for-Trainでは、モデルがデータベース固有のファンアウトを探索する際、正則化が急激な方策変更を抑える。結果として得られる言語モデルは強力な検索分解を生成できるが、Googleはこれを理想的な提供コンポーネントとは見なしていない。

第2段階では、そのモデルを固定し、監督データを合成するために使用する。元のクエリごとに、学習プロセスは報酬によって形づくられたファンアウトを収集し、それらをターゲットテンソルへ変換する。各行は、取得されたコンテンツ埋め込みまたは最適化されたサブクエリ埋め込みを通じた検索方向を表す。

この合成データセットは、目的を学習例へ移し替える。研究者が強化学習を「objective transducer」と表現する理由はそこにある。報酬は望ましい行動を数学的に定義し、成功した軌跡はその定義を小型モデルに適した学習ペアへ変換する。

最終段階では、拡散検索器を学習させる。拡散モデルは、反復的なノイズ除去を通じてノイズから構造化データを復元することを学習する。ここでの出力は画像やテキストの一節ではない。データベース内の関連領域を指し示す埋め込みの集合である。

推論時、モデルはひとつのクエリ埋め込みを受け取り、ターゲット方向をまとめて生成する。近傍探索はそれらの方向を実際のデータベースコンテンツに対応付ける。この処理は非自己回帰型であるため、10個のテキストサブクエリをトークンごとに書き出す必要がない。

この仕組みは手法の限界も説明する。デプロイされたモデルは、特定のデータベース、埋め込み空間、報酬に対して学習した行動を内部化する。カタログの変更、新たな目的、多様性の定義変更には、監督データの更新と再学習が必要になる可能性がある。レイテンシーはクリティカルパスから移るが、適応は学習と運用の問題になる。

高速化の根拠はより限定的である

Googleは大幅な効率向上を報告しているが、その根拠は本番環境での検証ではなく、依然として研究ベンチマークにとどまる。

実験では、2つの検索レジームを対象とした。オープンエンドの抽象検索では、唯一の正解がない結果セットを評価する。弱教師ありの構成的検索では、参照セットを有効な実現例の一つとして用いつつ、他のコレクションもクエリを満たし得ることを認める。

マルチモーダル評価では、研究者らはユーザーがキュレーションしたコーディネートを含む大規模なファッションデータセットと、専門家が作成した音楽プレイリストのプロプライエタリなデータセットを使用した。ファッション検索には、CLIPベースの画像・テキストエンコーダーを用いた。音楽検索には、音楽音声と自然言語による説明を対応付けるMuLan埋め込みを使用した。

比較には、fan-outを使わない従来型検索、ゼロショットの言語モデル拡張、複数の候補を生成してからより強い出力を残すBest-of-Nアプローチが含まれた。ゼロショットシステムでは、Gemini 2.5 Flash、Gemma 3 4B、またはQwen3 4Bを用いてクエリを拡張した。

Googleによると、強化学習で訓練した言語モデルと蒸留された拡散モデルはいずれも、評価対象のベースラインを上回る検索品質を示した。論文では、R4Tはオープンエンドおよび弱教師ありのタスク全体で競争力を維持しながら、より多様で、根拠に基づき、整合性の高いセットを生成したとしている。

主要な結果はレイテンシーに関するものだ。Googleによると、5,390万パラメータの拡散リトリーバーは、自己回帰型の代替手法より12〜20倍高速に動作した。報告されたスケーリング比較では、大規模なコンテキストバッチ下で自己回帰型fan-outは50秒近くに達した。拡散実装は1秒未満から数秒の範囲にとどまった。

これらの数値は、この仕組みが意図する利点を裏付けている。複数の埋め込みをまとめて生成することで、増え続けるテキストのサブクエリ群を作る際の線形的なトークン生成コストを回避できる。この手法では、同じドメイン固有の振る舞いを再発見するよう言語モデルに繰り返し求める必要もない。

ただし、ベンチマークの範囲は重要だ。2つのドメインだけでは、企業文書、科学文献、ウェブ検索、法的ディスカバリー、急速に変化するコマース在庫全体における一般的な性能を確立できない。ファッションと音楽はいずれもコレクションレベルで意味のある構造を持つため、多様性と一貫性を評価するには有利なテストとなる。

音楽データセットはプロプライエタリであり、独立した検証や再現を制限する。また、論文はユーザー満足度、コンバージョン、検索離脱、エンドツーエンドのインフラコストではなく、オフライン検索指標を評価している。埋め込み、近傍探索、フィルタリング、再ランキングがデプロイ時のレイテンシーを支配する場合、より高速なfan-outコンポーネントが検索システム全体を自動的に高速化するわけではない。

Googleは本番展開を発表していない。ライブトラフィック、敵対的な挙動、保守頻度、コーパス変更後の性能についても報告していない。したがって、この結果が示すのは、推論時の推論を普遍的に置き換えるものではなく、選定された実験条件下での実現可能性である。

報酬設計も別の不確実性をもたらす。数理的な目的関数は精密だが、その精密さが人間の好みを捉える保証にはならない。多様性は関連性と衝突し得る。根拠性は、よく知られたカタログ領域を優遇する可能性がある。整合性は、曖昧な要求の有用な解釈を抑制するおそれがある。

このアプローチは、教師モデルと埋め込み基盤の弱点も引き継ぎ得る。言語モデルが有効な側面を見落とせば、合成データセットはそれを表現しない可能性がある。埋め込みモデルが無関係な項目同士を近くに配置すれば、拡散リトリーバーはその歪んだ幾何構造の中で学習する。

したがって、Google Retrieve-for-Trainはシステムパターンの証拠として評価すべきだ。高価な最適化は、より安価な専門モデルのための教師信号を生成できる。報告された速度上の優位性は実験内では信頼できる一方、本番での価値はなお検証されていない。

Retrieve-for-Trainが一般化した場合に圧力を受けるのは誰か

このフレームワークは、あらゆる検索分解タスクで汎用LLMをデフォルトの実行時手段として扱うチームに挑戦を突きつける。

最も直接的な比較は、Googleと別の企業の比較ではない。推論時の推論と、訓練時のコンパイルとの比較だ。どちらの経路も、言語モデル、強化学習、埋め込み、再ランキングを利用できる。違いは、システムが最も高価な探索をいつ行うかにある。

推論時の推論は柔軟性を維持する。異例のプロンプト、新しい文書、変化する制約、訓練中に表現されなかった要求に反応できる。開発者は、専門モデルを再訓練せずにプロンプトや推論ループを変更することも可能だ。

この柔軟性には、繰り返し発生するコストがある。各リクエストで比較的大きなモデルを呼び出し、一連のトークンを生成する。複数ステップの検索では、ツール呼び出し、検索ラウンド、選択パスが追加されることがある。提供コストは、トラフィック、出力長、探索する分岐数に応じて増加する。

訓練時のコンパイルは、このトレードオフを逆転させる。リリース前に報酬最適化、合成データ生成、モデル訓練のコストを支払う。デプロイされたモデルは、その後、制約されたタスクをより効率的に処理する。リクエストが反復的で、目的が安定し、低レイテンシーが重要な場合、この設計は魅力的になる。

コマース検索チームは、このパターンを用いて、重複する商品ではなく補完的なバンドルを検索できる。ストリーミングサービスは、多様なプレイリストや視聴候補を作成できる。エンタープライズアプリケーションは、同じ事実のコピーを多数返すのではなく、プロジェクトの複数の側面をカバーする文書コレクションを検索できる。

同じ考え方は、個人ナレッジシステムにも影響を与え得る。広範な要求では、会議、文書、保存したウェブページからのノートを組み合わせて、ひとつの質問に答える必要がある場合がある。検索可能なナレッジベースを構築するチームも、関連性と網羅性のバランスを取るという同様の課題に直面する。

しかし、社内ナレッジは頻繁に変化し、構造の均一でない資料を含む。コンパイル済みリトリーバーには、信頼できる更新手順と、古い埋め込みに対する保護策が必要になる。分解が新しく追加された情報に依存する質問では、推論時の推論がなお価値を持ち得る。

Best-of-N手法も依然として重要だ。難しい要求にはより多くの計算を割り当て、定型的な要求にはより単純な検索を使える。ハイブリッドシステムでは、一般的なクエリをコンパクトなリトリーバーへ振り分け、曖昧または高価値な検索にはLLMを確保できる。

従来の密ベクトル検索には、もう一つの利点がある。単純さだ。ユーザーの大半が既知の一つの項目を探しているなら、セットレベルの最適化は不要な複雑さを加える。すべての検索バーに、一貫した候補群を構築するモデルが必要なわけではない。

したがって最も強い示唆は、アーキテクチャ上の選択性にある。汎用モデルは探索し、訓練のための振る舞いを生成できるため、有用な教師となる。ただし、予測可能なすべてのリクエストを処理するうえで自動的に最良のコンポーネントとなるわけではない。

R4Tが一般化するなら、開発者はより明確な構築対提供の問いに直面する。どの推論をライブで残すべきか、どの振る舞いを蒸留できるか、専門モデルをどれほどの頻度で更新すべきかを決めなければならない。この判断は、レイテンシー、インフラコスト、適応性、評価に影響する。

こうした観点から説明すると、Retrieve-for-Trainは単一の検索アルゴリズムというより、デプロイの原則である。必要なときに高価なモデルで振る舞いを発見する。成功した振る舞いをデータに保持する。許容できる品質を維持できる最小のモデルで提供する。

Google Retrieve-for-Trainの後に注目すべき点

次の試験は、報告された品質と速度が、2つのキュレーションされた研究環境の外でも維持されるかどうかだ。

最初のシグナルは、公開データセットでの独立した再現である。研究者は、記録されたハードウェア、バッチサイズ、エンドツーエンドの計測を用いて、検索性能の向上と12〜20倍というレイテンシーの主張の両方を再現する必要がある。ショッピング、文書検索、レコメンデーションにまたがる公開結果は、Googleの主張を強化するだろう。

再現では、各段階の価値も分離すべきだ。有用な比較では、リトリーバーと埋め込み基盤を一定に保ち、改善のどれだけが強化学習、合成教師信号、拡散ベース生成によるものかを測定する。この分離がなければ、チームはパイプライン全体が運用上の複雑さを正当化するか判断できない。

2つ目のシグナルは、変化するデータベースからの証拠だ。現在の枠組みは、報酬最適化と合成の間、コーパスが固定されていることを前提としている。現実のカタログでは、商品が追加され、在庫が削除され、メタデータが変わり、新しいカテゴリが生まれる。従業員がノート、レポート、会議記録を作成するため、エンタープライズリポジトリはさらに速く変化する。

今後の研究では、コーパスのドリフト後に品質がどのように低下するか、更新にどれだけのデータや計算が必要かを報告すべきである。増分更新は、この手法をより実用的にする。頻繁な完全再訓練は、特に小規模な検索事業者にとって、コスト面の優位性を弱めるだろう。

3つ目のシグナルは、ユーザー中心の指標を備えた本番デプロイだ。オフラインの多様性と再現率だけでは、人々が結果を有用と感じるかは分からない。ライブ評価では、成功したセッション、再検索、離脱、候補群全体の有用性を測定すべきだ。

失敗時の対応も開示すべきである。コンパクトなリトリーバーには、未知の要求を認識するための仕組みが必要だ。不確実なクエリをLLMまたは従来の検索パイプラインに振り分ければ品質を守れる可能性があるが、そのフォールバックはレイテンシーとコストの計算を変える。

研究チーム自身も、R4Tを完全な解決策ではなく初期段階の一歩として説明している。この慎重さは、入手可能な証拠に合致する。この手法は実際のシステム課題に対する一貫した答えを提示しているが、その効率性の向上が適応性の低下を上回る場面はまだ確立されていない。

Google AIの検索研究を評価する開発者は、実務的な問いを投げかけるべきだ。自らのワークロードには、推論を事前にコンパイルするのに十分な、反復的で測定可能な構造があるだろうか。答えがイエスなら、Retrieve-for-Trainは試すべき具体的なアーキテクチャを提供する。そうでなければ、ライブ推論またはハイブリッド設計のほうが引き続き適した選択肢かもしれない。

R4Tが標準コンポーネントにならなかったとしても、より広い教訓には注目する価値がある。AIシステムは、ユーザーごとに高価な推論行為をすべて繰り返す必要はない。安定した目的を表現、評価、訓練データへの変換ができるなら、推論はより小さく、より高速になり得る。

公開再現、コーパス更新の結果、ライブ製品指標に注目したい。これらのシグナルを合わせることで、Google Retrieve-for-Trainが特化型ベンチマークでの成功にとどまるのか、複雑なAI検索のための持続的なモデルとなるのかが明らかになる。