Snaps produktiver generativer Retriever baut jede Artikeldarstellung aus vier Feldern auf: Titel, Marke, Kategorie und Bild. Keines davon ändert sich, wenn ein Artikel nicht mehr verkäuflich ist. EGR, am 25. Juli auf arXiv veröffentlicht und live im Einsatz in Snaps Dynamic Product Ads, ist bislang die detaillierteste öffentliche Beschreibung eines LLM, das Candidate Generation im Konsumentenmaßstab betreibt – und es trägt eine Annahme in sich, die Bekleidung nicht treffen kann: dass alles, was auffindbar ist, auch käuflich ist.

Der zentrale Schachzug des Papers ist ein Rückzug von der Architektur, die das Feld bislang als generative Retrieval bezeichnet hat. Die meisten Systeme dieser Klasse quantisieren Artikel in diskrete semantische IDs und lassen das Modell diese Tokens direkt ausgeben – genau das meinen Leute, wenn sie sagen, der Index sei in die Gewichte gewandert. EGR verzichtet auf diese Schicht. Ein einzelnes Qwen3-VL-Embedding-2B-Backbone kodiert Artikel-Metadaten und Nutzerhistorien in einen gemeinsamen Raum, und die Artikelseite wird in einen gewöhnlichen Approximate-Nearest-Neighbour-Index geschrieben. Die trainierbare Fläche umfasst rund 41 Millionen Parameter, größtenteils LoRA-Matrizen und ein Projektionskopf – was zeigt, wie viel davon ein eingefrorener Allzweck-Encoder ist und wie wenig tatsächlich über Handel gelernt wurde. Der Katalog bleibt außerhalb des Modells, in einer Struktur, die nach Zeitplan neu aufgebaut werden kann – das Gegenteil der Richtung, in die Meta und Shopee zeigten, als sie den Two-Tower-Standard in dieser Woche ablösten.

Innerhalb von vier Monaten veröffentlichte Snap sowohl eine Bestätigung für semantische IDs als auch ein System, das sie ablehnt. Im April dokumentierte das Unternehmen den Produktionseinsatz von SIDs, ein SIGIR-Paper, das über Launches in mehreren Produktionsmodellen mit positivem Metrikeffekt berichtete und dies teilweise als Lösung für die rasche Fluktuation der Artikel-IDs darstellte, die Dynamic Product Ads erzeugt. EGR im Juli listet stattdessen die Kosten desselben Designs auf: Quantisierung, veränderliche Identifier-Vokabulare, Token-zu-Artikel-Grounding und die Tatsache, dass “Katalog-Updates die Zuweisung von Identifiern für neue oder geänderte Artikel erfordern”. Fünf Autoren erscheinen auf beiden Papers. Die beiden Papers sind sich nicht einig darüber, ob Katalog-Fluktuation ein Problem ist, das semantische IDs gelöst haben, oder eines, das sie erst geschaffen haben. Was die schlankere Architektur nach EGRs eigener Darstellung verdrängte, war nicht Genauigkeit – es war Komplexität.

Das Wort “Availability” taucht im EGR-Paper nicht auf, ebenso wenig “Inventory”, “in stock” oder “out of stock”.

Dieses Schweigen ist für Snap richtig und für einen Händler disqualifizierend. Snaps eigene Marketing API führt Availability als Katalogfeld mit fünf Zuständen, neben Größe und item_group_id, und behandelt alle drei als Filtereigenschaften einer Produktsuche – nicht als Signale innerhalb des Retrievers. Diese Arbeitsteilung ist sinnvoll, wenn der Fehltreffer billig ist: Ein abgerufenes, aber totes Produkt kostet einen Auktionsplatz, und die Auktion hat andere Bieter. Auf der eigenen Website eines Händlers kostet derselbe Fehltreffer die gesamte Session. Der Käufer, der durchklickt und seine Größe nicht mehr vorfindet, wird nicht von einem konkurrierenden Gebot ersetzt. Er geht.


Der Fehler konzentriert sich, statt sich zu verteilen, und genau das macht die Architektur schlimmer, je besser sie wird. Over-retrieve-and-filter ist die Standardantwort, und sie funktioniert, wenn Nichtverfügbarkeit selten und zufällig über den Index verteilt ist. Bekleidung erfüllt keine der beiden Bedingungen. Der Bestand schrumpft dort am schnellsten, wo die Nachfrage am höchsten ist – genau dorthin, wo der Ranker zeigt –, sodass die zuerst verschwindenden Einheiten genau jene sind, die das System am liebsten zeigen wollte. Und weil EGR Darstellungen aus Titel, Marke, Kategorie und Bild aufbaut, teilen sich die Größen ein und desselben Kleides jeden Input und landen konstruktionsbedingt als nächste Nachbarn – wodurch eine Top-K-Liste größtenteils unkäuflich sein kann und dem Retriever dennoch wie ein starkes Ergebnis erscheint. Ein präziserer Retriever zieht diesen Cluster nur noch enger.

Der stärkste Einwand lautet, dass Retrieval nie etwas über Lagerbestände wissen sollte. Snap hielt nachgelagertes Ranking, Auktion, Policy und Rendering über seine A/B-Arme hinweg konstant – experimentell die richtige Entscheidung und auch produktionsseitig die richtige, denn Constraints gehören in die Schicht, die man ohne Neutraining ändern kann. Damit das hier vorgebrachte Argument scheitert, muss eine Bedingung erfüllt sein: Das Kandidaten-Set muss groß genug und vielfältig genug ankommen, dass nach Entfernen der nicht verfügbaren Artikel noch eine vorzeigbare Auswahl übrig bleibt. EGR berichtet weder sein produktives K, noch sagt es, ob Größenvarianten vor der Indexierung zusammengefasst werden. Ein Händler, der beide Fragen für den eigenen Stack beantworten kann, sollte den Einwand ernst nehmen. Wo die Antwort ein enges K über einem Feed auf Variantenebene ist, rettet Filtern die Auswahl nicht – es leert sie.

Die Architektur funktioniert dort, wo sich der Korpus entsprechend verhält, und dafür gibt es Produktionsbelege. Die Taobao- und Tmall-Gruppe von Alibaba berichtete, dass ihr generativer Recall-Kanal für 72,63 % der Käufe auf TmallAPP verantwortlich ist – ein Anteil, den keine experimentelle Retrieval-Quelle zufällig erreicht. Dieses System läuft gegen einen Korpus, den die eigenen Autoren als “massiv und häufig aktualisiert” beschreiben, und es wurde mit semantischen Cluster-IDs und einer Reinforcement-Learning-Stufe gezielt gebaut, um diese Fluktuation zu überstehen. Wenn Anbieter das Snap-artige Design weiterhin an Händler als konversationelle Entdeckung verkaufen, ohne einen Availability-Pfad in die Retrieval-Schicht selbst einzubauen, werden jene Deployments Bestand haben, die Katalog-Veränderlichkeit als architektonischen Input behandelt haben – nicht als nachgelagerten Filter.

Die Entscheidung, vor der ein Händler in diesem Jahr beim Kauf steht, ist enger gefasst, als es die Anbieter-Präsentationen suggerieren. Generatives Retrieval ist eine echte Verbesserung darin, wie ein System Dinge findet, die dem ähneln, was jemand sucht, und Snaps Zahlen sind nicht bloß Dekoration: eine Conversion-Steigerung von 2,91 % bei diesem Volumen ist ein Deployment, keine Demo. Was die Architektur nicht leistet und auch nicht zu leisten behauptet, ist zu wissen, was verkauft werden kann. Ein Händler, der sie als Discovery-Upgrade kauft, bekommt genau das. Wer sie als Ersatz für die Availability-Logik kauft, die bereits im alten Candidate-Generation-Stack sitzt, verschiebt den Katalog ins Modell und lässt den Bestand draußen. Der Kunde wollte im Bestand einkaufen.