Snap’s production generative retriever builds every item representation out of four fields: title, brand, category and image. Not one of them changes when the garment stops being sellable. EGR, posted to arXiv on 25 July and running live inside Snap’s Dynamic Product Ads, is the most detailed public account yet of an LLM doing candidate generation at consumer scale, and it carries an assumption apparel cannot make: that everything retrievable is still purchasable.

The paper’s central move is a retreat from the architecture the field has been calling generative retrieval. Most systems in this class quantise items into discrete semantic IDs and let the model emit those tokens directly, which is what people mean when they say the index has moved into the weights. EGR drops that layer. A single Qwen3-VL-Embedding 2B backbone encodes item metadata and user histories into one space, and the item side is written to an ordinary approximate-nearest-neighbour index. The trainable surface is about 41 million parameters, mostly LoRA matrices and a projection head, which tells you how much of this is a frozen general-purpose encoder and how little of it is anything learned about commerce. The catalogue stays outside the model, in a structure that can be rebuilt on a schedule — the opposite of the direction Meta and Shopee pointed when they retired the two-tower default.

Within four months, Snap published both an endorsement of semantic IDs and a system that declines to use them. In April the company documented running SIDs in production, a SIGIR paper reporting launches across multiple production models with positive metrics impact, framed in part as a fix for the rapid item-ID churn that Dynamic Product Ads produces. EGR, in July, itemises the same design’s costs instead: quantisation, mutable identifier vocabularies, token-to-item grounding, and the fact that “catalog updates require assigning identifiers to new or changed items.” Five authors appear on both papers. The two papers don’t agree on whether catalogue churn is a problem semantic IDs solved or one they created; what pushed the tidier architecture aside, on EGR’s own account, was not accuracy — it was complexity.

The word “availability” does not appear in the EGR paper, and neither do “inventory,” “in stock,” or “out of stock.”

That silence is correct for Snap and disqualifying for a retailer. Snap’s own Marketing API carries availability as a five-state catalogue field, alongside size and item_group_id, and treats all three as filter properties applied to a product search rather than as signals inside the retriever. The division of labour is sound when the miss is cheap: a retrieved-but-dead product costs an auction slot, and the auction has other bidders. On a retailer’s own site the same miss costs the session. The shopper who taps through and finds their size gone is not re-served by a competing bid. They leave.


The failure concentrates rather than scattering, which is the part the architecture makes worse as it improves. Over-retrieve-and-filter is the standard answer, and it works when unavailability is sparse and randomly distributed across the index. Apparel supplies neither condition. Stock depletes fastest where demand is highest, which is exactly where the ranker points, so the units that vanish first are the ones the system most wanted to show. And because EGR builds representations from title, brand, category and image, the sizes of one dress share every input and land as near neighbours by construction, which lets a top-K list run mostly unbuyable while still looking, to the retriever, like a strong result. A more precise retriever tightens that cluster.

The strongest objection is that retrieval was never supposed to know about stock. Snap held downstream ranking, auction, policy and rendering fixed across its A/B arms, which is the right experimental design and also the right production one, since constraints belong in the layer you can change without retraining a model. For the argument here to fail, one condition has to hold: the candidate set must arrive large enough, and varied enough, that removing unavailable items still leaves a slate worth showing. EGR does not report its production K, and it does not say whether size variants are collapsed before indexing. A merchant who can answer both questions for their own stack should take the objection seriously. Where the answer is a tight K over a variant-level feed, filtering does not rescue the slate — it empties it.

The architecture works where the corpus behaves, and there is production evidence for that. Alibaba’s Taobao and Tmall group reported that its generative recall channel accounts for 72.63% of purchases on TmallAPP, a share no experimental retrieval source reaches by accident. That system runs against a corpus its own authors describe as “massive and frequently updated,” and it was built with semantic cluster IDs and a reinforcement-learning stage specifically to survive that churn. If vendors keep reselling the Snap-style design to retailers as conversational discovery without shipping an availability path into the retrieval layer itself, the deployments that hold will be the ones that treated catalogue mutability as an architectural input rather than a downstream filter.

The choice facing a retailer buying this year is narrower than the vendor decks suggest. Generative retrieval is a real improvement in how a system finds things that resemble what someone wants, and Snap’s numbers are not decorative: a 2.91% conversion lift at that volume is a deployment, not a demo. What the architecture does not do, and does not claim to do, is know what can be sold. A merchant buying it as a discovery upgrade gets one. Buying it as a replacement for the availability logic already sitting in the old candidate-generation stack moves the catalogue into the model and leaves the stock outside it. The customer was shopping the stock.