CoGR trains two LLMs, one on queries and one on items, to emit small keyword sets that get matched through a standard inverted index. It alternates Group Relative Policy Optimization (GRPO) updates against the opposite side’s frozen index so both keyword spaces co-adapt, lifting retrieval F1 by 10.9% and 36.1% over the strongest baseline on two search datasets.
You run a product search or ads retrieval stack. A user query comes in, and the first-stage retriever picks a few hundred candidates from millions of items before ranking. That stage is usually BM25 over an inverted index, or a two-tower dense embedding model, and its misses can’t be fixed downstream.
A popular direction is to sprinkle an LLM on top: expand the query, rewrite it, or generate a pseudo-answer, then feed that to the existing retriever. DeepRetrieval is a representative example that trains the query rewriter with RL against retrieval metrics. The item side stays fixed. This paper argues that’s half the job: the item representations should learn too, and they should learn against what the query side is currently producing.
Both queries and items go through their own LLM that emits a compact keyword list. Retrieval is then plain keyword matching through an inverted index, ranked by BM25 over the generated tokens. No dense vectors, no learned scorer, no second retriever. The keywords are the index.
Training has two phases. Phase 1 is supervised fine-tuning that seeds an aligned vocabulary. For each item, the base LLM proposes candidate keywords. For each query, the authors pool the keywords of its known relevant items and take the most frequent ones as the query’s target. Both generators then SFT on these paired targets, which guarantees non-trivial overlap between relevant query-item pairs before RL starts.
Phase 2 is the interesting part. The two generators are trained alternately with Group Relative Policy Optimization (GRPO), each optimizing the same shared objective: retrieval F1 on the training queries. When training the query LLM, the item index is frozen; the query LLM samples several keyword sets per query, each set is scored by the F1 of the items it retrieves, and GRPO uses the within-group reward spread as advantage. Then roles flip.
The item-side reward is the subtle piece. You can’t score one item’s keywords with query-side F1 directly, because that F1 depends on every other item too. So they use a counterfactual reward: swap in the candidate keyword set for just this one item, hold the rest of the index fixed, and measure how total query-side F1 changes.
for round in range(R):
freeze(item_index)
for q in queries:
sets = query_llm.sample(q, n=8)
rewards = [f1(retrieve(s, item_index), rel(q)) for s in sets]
grpo_update(query_llm, sets, rewards)
rebuild(query_index, from=query_llm)
freeze(query_index)
for i in items:
sets = item_llm.sample(i, n=8)
rewards = [f1_delta_if_item_i_uses(s) for s in sets]
grpo_update(item_llm, sets, rewards)
rebuild(item_index, from=item_llm)
Computing that F1 delta naively means rebuilding the index per rollout. The paper avoids this by caching per-query true-positive counts and, for each rollout, only recomputing F1 for the queries whose retrieval set actually changes when item i’s keywords change.
The common pattern when adding LLMs to retrieval is to let the LLM improve the query side (rewrite, expand, generate keywords) and hand the result to a fixed downstream retriever. This paper argues the opposite. Query-side generation alone is undertrained: if the item vocabulary is frozen, the query LLM is optimizing against a target it can’t reshape, and vice versa. Both sides should be learned generators, co-adapting against each other’s current index under one shared retrieval objective. The evidence that isolates this is the ablation where the item side is frozen (marked with the dagger in their tables): CoGR with a frozen item side lands near DeepRetrieval, and only opens a real gap once both sides learn.
The load-bearing finding is the frozen-item ablation. CoGR-4B with the item side held fixed gets F1 0.2617 on the internal dataset; letting both sides co-evolve pushes it to 0.3963. On WANDS the frozen variant is 0.4662 vs 0.6819 for the full method. Same base model, same query-side training, the only difference is whether item keywords also learn. That gap is what the paper is really selling.
•
On the internal APP marketplace data, F1 0.3963 vs the best baseline ANCE with a Qwen3-4B backbone at 0.3575, roughly the 10.9% headline.
•
On WANDS, F1 0.6819 vs 0.5012 for the same strongest baseline, the 36.1% headline.
•
Ablations: replacing the counterfactual item reward with a symmetric “treat item as query” F1 (Transposed F1) drops F1 to 0.3743. Sharing one generator for both roles drops it to 0.3798. Skipping SFT drops it to 0.3751. All three still work, but the full recipe wins on each.
•
Training dynamics: validation F1 climbs from ~0.16 after SFT to ~0.40 after five alternating rounds, with the biggest jump in round one.
•
Vocabulary analysis: unigrams shrink from 37% to 13% of generated keywords, 3+ word phrases grow from 12% to 31%. Query-side and item-side vocab sizes converge after three or four rounds.
Reach for this if you already run a keyword-based first-stage retriever with an inverted index, especially in sponsored search or product search where advertisers or catalogs are indexed on tokens rather than dense vectors. The concrete migration path is: run one LLM offline over your item catalog to produce a keyword set per item, run a second LLM online over each user query to produce query keywords, and let your existing inverted index do the match. You keep your serving infrastructure. You just replace the humans (or heuristics) writing keywords with two trained generators, and you get an F1 objective you can actually optimize end to end.
The paper doesn’t say a code release is planned; the internal APP dataset is not public. WANDS is public and reproducible. If you want to try this yourself, the ingredients are all off-the-shelf: Qwen3-4B-Instruct as base, the verl framework for GRPO, 8 GPUs, and the F1 reward defined over your relevance labels. The efficient item-side reward (cached per-query counts, single index lookup per rollout) is described precisely enough in the appendix to reimplement.
When you glue an LLM onto retrieval, train both sides against each other, not just the query. A frozen document representation caps how much the query generator can learn, because it’s optimizing against a target it can’t influence. Alternating RL with each side frozen in turn keeps the loop stable and lets the two vocabularies converge on a shared, more specific keyword space.
•
Only two datasets, both with unusually dense relevance labels (~1000 relevant items per query on the internal set, ~200 on WANDS). Classic sparse-annotation IR benchmarks (MS MARCO, BEIR) are absent, and the authors explicitly say those don’t reflect their many-to-many target setting. Whether co-evolution helps when each query has 1-2 relevant docs is untested.
•
Training the item side requires knowing relevance labels over your full item universe, and rebuilding the item index after each round of GRPO. For a catalog of tens of millions of items, the reindexing cost and label coverage assumption are non-trivial engineering commitments the paper doesn’t quantify.
•
The final ranker is still just BM25 over generated keywords. The authors flag this as future work. If your production system already has a strong learned reranker, the marginal win from CoGR over a good dense retriever + reranker stack is not measured here.