2026-09-04·★ 会員·論文·19分で読めます

論文解説: It Takes Two to Match — 検索の「両側」をRLで共進化させるCoGR

検索の一段目を、クエリ側とアイテム側の2つのLLMに「キーワードを書かせる」ことで作り直す論文。両者を強化学習で交互に鍛えて語彙を歩み寄らせるCoGRを、前提知識ゼロから解説する。

#retrieval #generative-retrieval #grpo #reinforcement-learning #search

It Takes Two to Match: Co-Evolving Generative Retriever with Reinforcement Learning

一次資料 — この記事の根拠

論文の発表 2026-09-01→この解説の公開 2026-09-04同月

It Takes Two to Match: Co-Evolving Generative Retriever with Reinforcement LearningRunpeng Dai, Kaili Huang, Changsung Kang ほか · 2026-09-01 · v1arXiv:2609.00638論文ページ·PDF

原文の要旨（Abstract）を読む

Retrieval is the first stage of modern search and advertising systems, selecting a candidate set from a large item universe for downstream ranking and auction. Recent work increasingly leverages LLMs to improve retrieval through query expansion, data synthesis, and retrieval-feedback training. However, the generative component is typically used for query-side augmentation, while final matching is still delegated to a downstream retriever. We introduce CoGR, a retrieval framework that instead trains LLMs to directly construct retrieval representations on both query and item sides. Each generator produces a compact set of keywords, which are matched directly through an inverted index, preserving compatibility with existing keyword-based retrieval infrastructure. CoGR uses a two-stage training pipeline. Supervised fine-tuning first establishes an aligned keyword space, after which co-evolving reinforcement learning alternately optimizes the query- and item-side generators with GRPO against the opposite side's frozen index. Both sides optimize the same query-to-item retrieval $F_1$ objective: the query side receives retrieval $F_1$ directly, while the item side receives a counterfactual marginal reward measuring the change in query-side $F_1$ caused by its generated keywords. Across 10 representative sparse, dense, and generative baselines, CoGR achieves the best performance on both an internal APP Marketplace dataset and the public WANDS benchmark, improving $F_1$ over the strongest baseline by $10.9\%$ and $36.1\%$, respectively. Further analysis shows stable co-evolution and increasingly aligned query--item keyword spaces over training.

検索の一段目で落としたものは、二度と戻ってこない

今回読むのは "It Takes Two to Match: Co-Evolving Generative Retriever with Reinforcement Learning"（arXiv:2609.00638、Runpeng Dai・Kaili Huang・Changsung Kang・Ciya Liao、2026年9月1日公開）です。

論文の主張を先に要約します。検索や広告システムの第一段階であるリトリーバルは、巨大な商品集合から候補を絞り込む工程です。近年はLLMをクエリ拡張・データ合成・検索フィードバック学習に使う研究が増えましたが、生成部分はたいていクエリ側の水増しに使われるだけで、最終的な突き合わせは下流の別モデルに任されたままでした。本論文が提案する CoGR は、クエリ側とアイテム側の両方でLLMに検索用の表現そのもの＝コンパクトなキーワード集合を作らせ、転置インデックスで直接マッチさせます。学習は2段階で、まず教師ありファインチューニング（SFT）で両者の語彙をそろえ、その後の共進化型の強化学習が、相手側の凍結インデックスを相手にGRPOで交互に最適化します。両側とも目的関数は同じ「クエリ→アイテム検索の $F_1$ 」で、クエリ側は $F_1$ をそのまま、アイテム側は自分の生成したキーワードが引き起こした $F_1$ の変化量を反事実的な限界報酬として受け取ります。スパース・密・生成の代表的なベースライン10本と比較して、社内のAPPマーケットプレイス・データと公開ベンチマークWANDSの両方で最良、最強ベースラインに対して $F_1$ をそれぞれ $10.9\%$ 、 $36.1\%$ 改善した、というのが結論です（Abstract）。

なぜこの工程がそんなに重要なのか。論文は「この段階の誤りはほぼ取り返しがつかない」と書いています（§1）。ここで拾われなかったアイテムは、後段のランキングがどれだけ賢くても復活しません。逆に無関係なアイテムを大量に通せば、後段の負担が増えるだけです。広くすくいながら、正確に絞る——再現率と適合率のトレードオフそのものが、この一段目の宿題です。

比喩: 求人票と履歴書に、同じ言葉を書かせる

キーワード検索は、求人マッチングに似ています。企業は求人票に「求めるスキル」を書き、応募者は履歴書に「持っているスキル」を書く。両者に同じ単語が出てくればマッチ成立です。

ところが現実には、企業が「フロントエンド」と書き、応募者が「React」と書く。中身は合っているのに、単語が一致しないので出会えません。

従来の改善策は「応募者の履歴書はそのままに、求人票の言葉だけを増やす」ものでした。CoGRの発想は、求人票と履歴書の両方を書き直させることです。しかも一度きりではなく、「この書き方だと何件マッチしたか」の結果を見ながら、交互に何度も書き直させます。タイトルの It Takes Two（マッチには二人要る）はここを指しています。

これまでのやり方と、この論文がずらした点

論文が整理する既存路線は3つです（§1・§5）。

スパース（語彙）検索: BM25 のように、実際に出てくる単語と転置インデックスで突き合わせる。広告の入札のようにキーワードを直接買う世界では今も主役ですが、語彙が一致しないと深い意味の関係を捉えきれない。
密（dense）検索: クエリとアイテムを同じ連続ベクトル空間に写して、ベクトルの近さで探す。DPR や ANCE が代表。
生成検索: アイテムの識別子を自己回帰的に生成する。DSI や RIPOR など。ただし識別子の設計に強く依存し、デコードのスケーラビリティと汎化に課題が残る。

そこにLLMが加わり、クエリ拡張・疑似文書生成、さらには下流retrieverの結果を報酬にしてLLMを学習する手法（DeepRetrieval など）が出てきました。しかし論文が指摘するのは、そのほとんどが片側（たいていクエリ側）しか学習していないという点です（§1）。CoGRはここを「両側とも学習し、生成されたキーワードをそのまま検索表現＝インデックスにする」へ変えました。副次的な利点として、出力がキーワードなので既存のキーワードベース検索基盤にそのまま載る、と主張しています。

密検索がどう違うのかは、実際に触ると腑に落ちます。次の図は、文書ベクトルの海にクエリを落として上位を見るものです。キーワード検索が「単語が一致したか／しないか」の0か1であるのに対し、密検索は距離という連続値で順位が決まる、という対比を掴んでください。

FIG 1密検索は「近さ」で順位が決まる。CoGRはこの連続値ではなく、生成した単語の一致で候補を作る

仕組み① マッチングは「集合の重なり」だけ

まず、学習の話に入る前に検索そのものの定義を押さえます。クエリ側の生成器 $G^q$ とアイテム側の生成器 $G^i$ が、それぞれキーワード集合 $S_q = G^q(q)$ 、 $S_i = G^i(i)$ を出します。検索結果は次で定義されます（§2.1）。

I_{\mathrm{ret}}(q)=\{\, i : (S_q \cup \{q\}) \cap (S_i \cup \{i\}) \neq \varnothing \,\}

(1)

言い換えると、「クエリ自身とその生成キーワードを合わせた袋」と「アイテム自身とその生成キーワードを合わせた袋」に共通の要素が1つでもあれば候補に入れる、それだけです。 $\cap$ は共通部分、 $\varnothing$ は空集合なので、「共通部分が空でない」＝「1個以上かぶっている」という意味になります。

これでは候補の順位が付かないので、論文は各側のキーワード集合を単語の袋（bag of words）とみなし、BM25スコアで並べ替えます（§2.1）。つまり CoGR の新しさは「候補をどう作るか」であって、ランキング関数自体は古典的なままです。

ここで一つ、直感の補助線を引いておきます。密検索が使う「近さ」は内積で測られ、向きがそろうほど大きくなります。キーワード一致はこれを0/1に量子化したもの、と考えると両者の関係が見えます。

FIG 2密検索の類似度は連続的に変わる。キーワード一致はこれを「重なった/重ならない」に潰した極端な場合と見なせる

埋め込みの側から検索を眺めた話は埋め込み(Embedding)を1から理解する、検索と生成をつなぐ全体像はRAGの基礎で扱っています。

論文解説: It Takes Two to Match — 検索の「両側」をRLで共進化させるCoGR

検索の一段目で落としたものは、二度と戻ってこない

比喩: 求人票と履歴書に、同じ言葉を書かせる

これまでのやり方と、この論文がずらした点

仕組み① マッチングは「集合の重なり」だけ

ここから先は会員限定です

参考文献

コメント