Most generative-retrieval papers quietly assume you’ll tear out your retrieval stack and rebuild around a new index. CoGR is interesting because it refuses to. It trains LLMs to emit compact keyword sets on both the query and item side, then matches them through a plain inverted index — the sparse infrastructure you already run.
- 🎯 Both sides generate, not just the query. The usual trick is LLM query expansion feeding a frozen retriever; CoGR trains query- and item-side generators together against the same query-to-item F1 objective.
- ⚡ Co-evolving RL with GRPO. After an SFT pass to align the keyword space, the two generators alternate — the item side earns a counterfactual reward measuring how much its keywords shifted query-side F1.
- 🔍 It stays on the inverted index. Keywords match through existing keyword-based retrieval, so this is additive to sparse and hybrid infra rather than a dense-vector migration.
- 📊 The numbers hold up. +10.9% F1 on their internal marketplace set and +36.1% on the public WANDS benchmark, over the strongest of ten sparse, dense, and generative baselines.
- 💡 Aligned vocabularies emerge. Query and item keyword spaces converge over training — which is the part I’d want to inspect first, because that same convergence is how you’d overfit a closed catalog.
The compatibility story is the real pitch. If you run hybrid search in production, a technique that upgrades the sparse leg without touching your index plumbing is a far easier sell than another embedding rebuild. The HF paper page has the training curves. So here’s my open question: how much of that 36% survives when the item universe churns daily instead of sitting still?