Generative retrieval finally learns to play both sides

Retrieval is the first stage in every modern search or advertising system, selecting a candidate set from millions of items before ranking and auction take over. In recent years researchers have pushed LLMs into that pipeline — query expansion, data synthesis, retrieval-augmented training. Yet the generative side has almost always stayed on the query side only; final matching still hands off to a separate ranker. A new preprint, CoGR (arXiv:2609.00638), proposes breaking that asymmetry.

CoGR trains two separate generators, one for user queries and one for items — apps, in the tested case — each emitting a compact set of keywords. Those keywords are matched directly through an inverted index: no dense vectors, no separate ranker, no break with existing keyword-based infrastructure. That is the core difference: the generative representation becomes the retrieval representation itself, on both sides simultaneously.

The pipeline runs in two stages. First, SFT aligns the keyword spaces of the two generators. Then co-evolving RL takes over: in each round one side updates via GRPO against the frozen index of the other, then they swap. The reward function is identical — query-to-item retrieval F1 — but the item side receives a counterfactual marginal reward: the change in the other side's F1 caused by its own keywords. This forces both generators to converge on the same semantic space without collapsing.

Across ten baselines — sparse, dense, and generative — CoGR takes first place on both internal app-marketplace data and the public WANDS benchmark. Improvement over the strongest baseline stands at 10.9% on internal data and 36.1% on WANDS, both measured in F1. Additional analysis shows stable co-evolution and gradual convergence of the keyword spaces over training. The numbers are striking, but this is a preprint without peer review, open code, or downloadable weights, so treat the F1 gains as provisional until someone reproduces them.

What is missing: no open code, no model release. The paper does not specify base architecture, model size, training cost, or GRPO hyperparameters. It also does not say how many keywords each side emits on average, or how that affects inverted-index size in production. Without code or weights the community cannot verify whether co-evolution remains stable at real scale, or whether it only works on this particular dataset. For now it is an elegant idea with strong numbers; we will wait for the next version or an independent reproduction before calling it a paradigm shift.