RESEARCH BRIEF / RECOMMENDER SYSTEMS / 10 MIN READ
Snap researchers describe how semantic IDs can make large recommendation systems more compact and better able to generalise—and why turning the idea into a production retrieval system requires solving codebook collapse, collisions, and misleading evaluation metrics.
The paper in five points
- A semantic ID represents an item with a short, ordered sequence of learned codes rather than one arbitrary identifier.
- Items with related meaning tend to share code prefixes, allowing models to share learning across similar and long-tail content.
- Snap uses semantic IDs both as extra ranking features and as targets for generative retrieval across ads, content, growth, search, and friend recommendations.
- Production use exposed two central problems: underused codebooks during training and multiple items resolving to the same ID.
- Online results show that semantic retrieval still needs conventional business-aware reranking; the code identifies a promising neighbourhood, not always the final item.
By the Smarter BI editorial team · Published 12 August 2026 · Based on research by Clark Mingxuan Ju, Tong Zhao, and colleagues at Snap Inc.
Why ordinary IDs become a bottleneck
Most industrial recommenders assign every user and item a unique “atomic” ID. The model learns an embedding for each ID from behavioural data: what people watched, bought, clicked, shared, or ignored. This is powerful because it captures collaborative patterns without requiring the ID itself to carry meaning.
At very large scale, that design creates three related problems. Embedding tables grow with every new entity. New items have little or no interaction history, creating a cold-start problem. Long-tail items receive relatively few training updates, while popular IDs become well trained. An atomic ID for a new video cannot tell the model that its subject, visual style, audio, or audience resembles existing videos.
Atomic IDs tell a model which item it saw. Semantic IDs also give it clues about what kind of item it saw.
Smarter BI interpretation
What is a semantic ID?
A semantic ID, or SID, is an ordered list of discrete codes generated from an item’s learned representation. Text, images, audio, transcripts, metadata, or collaborative signals are first encoded as dense vectors. A tokenizer then compresses those vectors into a short hierarchy of codebook selections.
Instead of representing an item only as something like video_847291, a system might represent it conceptually as [12, 47, 3]. The first code locates a broad semantic region; subsequent codes refine the location. Related items can share a prefix even when they have different exact sequences.
The paper describes this as a form of semantic hashing. Because each code is reused by many items, its embedding receives more training updates than a rare atomic ID would. The code space is also far smaller than a catalog-wide table containing a separately learned vector for every item.
| Atomic ID | Semantic ID | |
|---|---|---|
| Meaning | Arbitrary unique label | Learned hierarchical codes |
| Similarity | Not visible in the ID | Related entities may share prefixes |
| New items | Need a new table entry and interaction data | Can be encoded from available content or metadata |
| Parameter sharing | Primarily per entity | Across entities using the same codes |
| Uniqueness | One ID per item | Collisions are expected and must be resolved |
Two jobs inside Snapchat’s recommender stack
Snap reports using semantic IDs in two distinct ways.
1. An auxiliary feature for ranking
The lower-risk use is to add SIDs to existing ranking models. The ranker retains its established user, item, and context features but gains a compact semantic signal. Snap applied this pattern to ads, dynamic product ads, friend recommendations, and search.
For ads, text such as titles, brands, and categories was encoded and converted to SIDs. For fast-changing product catalogs, the same process gave new products useful representations despite rapid ID churn. In friend recommendation and search, Snap used GraphHash—a graph-derived form of SID—to compress more than 900 million raw user IDs into hierarchical structural communities.
2. A target for generative retrieval
The more ambitious use replaces atomic item IDs in a person’s behaviour sequence with semantic codes. A sequential model then predicts the SID sequence for likely next items. This changes retrieval from selecting among every catalog ID to generating a location in a learned semantic space.
That can reduce the output vocabulary and help the model generalise, but it creates a grounding problem: the generated SID must still resolve to real, eligible items. The semantic code is therefore a candidate generator, not a complete recommendation decision.
Challenge one: codebook collapse
Snap used residual-quantised variational autoencoders, or RQ-VAEs, to generate many of its SIDs. During training, the team found that the tokenizer could repeatedly choose a small number of codes while leaving most of the codebook effectively dead. If too many items occupy too few codes, the semantic hash loses the granularity needed to distinguish content.
The researchers report two remedies:
- Update the whole codebook. A straight-through estimator approximates gradients through the discrete assignment step, allowing training signals to reach more than only the selected centroids. On Snap’s internal data, this treatment improved SID uniqueness by 83.4% relative to the paper’s baseline.
- Fuse multiple embedding sources. Combining visual, textual, audio, transcript, and other representations creates a richer input space that requires broader codebook use. The paper reports additional uniqueness improvements from multimodal, audio, and transcript inputs.
This is an important engineering lesson: a semantic tokenizer is not automatically semantic or well distributed. Teams need diagnostics for code utilisation, collision rates, reconstruction, and downstream behaviour before trusting the identifiers it produces.
Challenge two: one code, many items
Collisions are partly intentional. Similar items may map to exactly the same SID because each codebook has much lower cardinality than the item catalog. But a product cannot display a semantic bucket—it has to choose specific items from that bucket.
Snap resolves this with a second-stage, domain-specific ranking step. Candidate items sharing an SID can be ordered using signals such as historical relevance, cumulative viewing, freshness, quality, safety, inventory, or other product rules. In the short-form video experiment, relevance-guided resolution materially outperformed random item selection.
The team also found that, under a fixed retrieval budget, fetching more items from a few highly ranked SIDs worked better than fetching a few items across many lower-ranked SIDs. In other words, retrieval depth beat semantic breadth in this setting.
What the reported results show
The paper reports positive offline results and production A/B tests across several Snapchat surfaces:
- Adding SIDs to ads rankers improved two reported AUC measures by 0.028% and 0.035%; the paper says a 0.01% gain is significant in that setting.
- For dynamic product ads, the reported offline improvement was 0.67% for add-to-cart prediction and 0.24% on average across prediction heads.
- GraphHash features produced positive online changes in friend and search systems, including relevance gains and reductions in negative friending actions.
- For generative short-video retrieval, expanding the input history from a baseline sequence length of 120 to 480 improved Recall@5 by 31.5% and NDCG@5 by 26.5% offline.
- With relevance-guided SID-to-item mapping, the online test reported increases of 0.57% in views, 2.54% in sends, 3.55% in reposts, and 4.39% in shares.
These percentages are reported by Snap and use different metrics, baselines, models, and experimental contexts; they should not be compared directly or treated as guaranteed gains elsewhere. The internal datasets and full production systems are not available for independent reproduction. The paper nevertheless provides useful evidence that the approach can survive beyond an academic benchmark.
The best-looking proxy was not the best objective
SID developers often measure uniqueness: the share of items assigned a distinct code sequence. Very low uniqueness is a warning that the tokenizer collapsed. It is tempting to keep maximising the number.
Snap’s experiment on the Amazon Beauty dataset found a non-linear relationship. Retrieval improved as uniqueness rose out of a collision-heavy range, then largely plateaued above roughly 70% in that experiment. Codebooks with 70.58%, 81.65%, 91.79%, and 92.95% uniqueness produced very similar Recall@10 values.
Uniqueness is a health check against collapse—not a substitute for measuring recommendation quality.
Practical implication of the paper’s evaluation
A perfectly unique code can recreate the weaknesses of an atomic identifier by sacrificing shared semantics. The useful objective is a balance: enough distinction to retrieve the right item, enough shared structure to transfer learning, and demonstrably better downstream outcomes.
What smaller teams should take from this
A proportionate adoption path
- Start with dense content embeddings and direct nearest-neighbour retrieval.
- Use stable database IDs as canonical identities; resolve current metadata at serving time.
- Add transparent eligibility, quality, freshness, diversity, and business rules after semantic retrieval.
- Measure relevance and catalog coverage against taxonomy, recency, and popularity baselines.
- Consider learned semantic IDs only when catalog scale, churn, memory, latency, or generative retrieval requirements justify the additional machinery.
Snap’s design addresses a catalog and traffic scale far beyond most publishers and mid-market businesses. A smaller archive usually does not need RQ-VAE training, generative retrieval, or learned codebooks. One embedding per item, cosine similarity, and deterministic reranking are easier to audit and may deliver most of the practical value.
The transferable pattern is the two-stage architecture: use semantic representation to find a relevant neighbourhood, then use explicit operational rules to select safe, timely, diverse, and strategically appropriate items. That principle applies whether the first-stage representation is a sophisticated SID or an ordinary embedding.
Our assessment
This is a concise industrial report rather than a complete recipe. Its value lies in the failure modes and design choices that papers focused only on benchmark accuracy can miss: dead codes, grounding collisions, retrieval-budget allocation, feature churn, and proxy metrics that stop correlating with real performance.
The central business lesson is not that every recommender needs semantic IDs. It is that identifiers are an architectural choice. Replacing arbitrary labels with shared semantic structure can improve generalisation and efficiency, but only when the organisation also builds the resolution logic, evaluation, infrastructure, and product controls required to turn semantic candidates into useful recommendations.
Source and editorial note
This article summarises Semantic IDs for Recommender Systems at Snapchat: Use Cases, Technical Challenges, and Design Choices by Clark Mingxuan Ju, Tong Zhao, Leonardo Neves, Liam Collins, Bhuvesh Kumar, Jiwen Ren, Lili Zhang, Wenfeng Zhuo, Vincent Zhang, Xiao Bai, Jinchao Li, Karthik Iyer, Zihao Fan, Yilun Xu, Yiwen Chen, Peicheng Yu, Manish Malik, and Neil Shah. The reviewed source is arXiv:2604.03949v1, submitted 5 April 2026. Snap’s implementation is available through the authors’ GRID repository. Reported internal results have not been independently reproduced by Smarter BI. Explanations, business implications, and the proportionate adoption path are our editorial interpretation.