embedding table
**Embedding Tables in Deep Recommendation Systems** are the **large lookup tables that map sparse categorical features (user IDs, item IDs, categories) into dense vector representations** — forming the core component of modern recommendation systems where billions of user-item interactions are modeled through learned embeddings that capture latent preferences, accounting for the majority of model parameters and memory in production systems at companies like Meta, Google, and Netflix.
**Why Embeddings for Recommendations?**
- Users and items are categorical: User #12345, Movie #67890.
- One-hot encoding: Vectors of millions of dimensions → impractical.
- Embedding: Map each entity to a dense vector (d=64-256) → captures latent features.
- Similar users/items → similar embeddings → enables generalization.
**Architecture of Deep Recommendation Models**
```
User Features: Item Features:
user_id → Embedding(1M, 128) item_id → Embedding(10M, 128)
age → Dense category → Embedding(1K, 32)
gender → Embedding(3, 8) price → Dense
↓ ↓
Concat user features Concat item features
↓ ↓
User Tower (MLP) Item Tower (MLP)
↓ ↓
User Embedding (128) Item Embedding (128)
↓
Dot Product → Score
```
**Major Recommendation Architectures**
| Model | Developer | Key Innovation |
|-------|----------|---------------|
| DLRM | Meta | Embedding + MLP + feature interactions |
| Wide & Deep | Google | Wide (memorization) + Deep (generalization) |
| DCN v2 | Google | Cross network for explicit feature interactions |
| Two-Tower | Google/YouTube | Separate user/item towers for efficient retrieval |
| DIN (Deep Interest Network) | Alibaba | Attention over user behavior history |
| SASRec | Sequential | Transformer for sequential recommendation |
**Embedding Table Scale**
| Company | Embedding Tables | Total Size |
|---------|-----------------|------------|
| Meta (DLRM) | ~100 tables | Terabytes |
| Google (Search/Ads) | Thousands of features | Terabytes |
| Typical e-commerce | 10-50 tables | Gigabytes |
- Embedding tables dominate model size: >99% of DLRM parameters are in embeddings.
- Cannot fit on single GPU → need distributed embedding (embedding sharding across GPUs/hosts).
**Embedding Training Challenges**
| Challenge | Problem | Solution |
|-----------|---------|----------|
| Memory | Billion-entry tables don't fit in GPU | Distributed tables, CPU embedding |
| Sparsity | Most embeddings accessed rarely | Frequency-based caching, mixed precision |
| Cold start | New users/items have no embedding | Feature-based fallback, content embedding |
| Update frequency | User preferences change | Online learning, periodic retraining |
**Two-Tower Model for Retrieval**
- **Offline**: Compute item embeddings for all items → store in vector index (FAISS/ScaNN).
- **Online**: Compute user embedding from request features → ANN search for top-K items.
- Latency: < 10 ms for retrieval over millions of items.
- Separation enables pre-computation of item tower → very efficient serving.
Embedding-based deep recommendation systems are **the technology powering the personalization infrastructure of the modern internet** — from social media feeds to e-commerce product recommendations to ad targeting, these systems process billions of daily interactions through learned embeddings that capture the complex, evolving preferences of hundreds of millions of users.