Recommender Systems — Sr Staff edition

A course-level reference for the 2026 interview loop. Built for an experienced RecSys engineer who needs to articulate the field crisply enough to clear Pinterest / DoorDash / Reddit / TikTok / Snap / Anthropic / Databricks Sr Staff bars. The depth here is what you should be able to say out loud at a whiteboard, not what you read off a slide.

Part 1 — RecSys architecture

1.1 The canonical funnel

Every large-scale recommender — YouTube, Instagram, TikTok, Pinterest, DoorDash, Spotify, Reddit — has the same shape. You start with hundreds of millions to billions of candidate items and you have ~50–200ms end-to-end to return a sorted list of 10–50 to the user. You cannot run a deep model over 1B items per request, so you build a cascade of progressively more expensive models over progressively smaller candidate sets.

Latency budget — typical

1.2 Retrieval / candidate generation

Retrieval is responsible for recall. It does not need to score perfectly — it just needs to ensure the truly relevant items are among the ~10k passed to ranking. Modern systems run multiple retrieval sources in parallel and union them: collaborative, content, social, geo, freshness, exploration. Each source is allowed to be biased; the union is what matters.

Two-tower (DSSM)

The dominant architecture. A user encoder consumes user features (id embedding, recent history sequence, demographics, context) and produces a vector u ∈ ℝ^d. An item encoder consumes item features (id embedding, content embeddings, taxonomy) and produces v ∈ ℝ^d. Score = ⟨u, v⟩ (or cosine). Trained with sampled-softmax or in-batch negatives so item encoder can be precomputed offline and indexed in an ANN. Only the user tower runs at request time.

Why two-tower wins for retrieval but not for ranking: a dot product cannot model feature crosses across user × item (e.g. "user from SF × restaurant in SF" gets the same score as "user from SF × restaurant in NYC" if those interaction features aren't in the encoders). For retrieval, this is acceptable because ranking will fix it. For ranking, it's a dealbreaker.

Negative sampling — the central question of two-tower training

• In-batch negatives. For each positive (u, v⁺), use other items in the batch as negatives. Cheap, but biased toward popular items (because popular items appear more often as positives, so they appear more often as negatives, and the gradient pushes them down). YouTube's seminal paper corrects with logQ subtraction: subtract log(sample frequency) from logits.
• Mixed negatives. Add uniform random negatives (from full corpus) to in-batch — fixes the popularity bias.
• Hard negatives. Mine items the model currently scores high but are not positives. Greatly improves discrimination but can collapse if hard negatives are actually mislabeled positives ("false negatives"). Common recipe: top-100 from a previous-version model, then sample 1–5 per positive.
• Cross-batch negatives. Maintain a queue of recent batch embeddings (MoCo-style) for larger negative pools without OOM.

Item-to-item collaborative filtering

Classical: build a co-occurrence matrix from sessions, normalize (cosine, Jaccard, or PMI), and serve "items frequently watched after X." Old but still extremely strong for fresh sessions and cold users where you have one anchor item. Amazon's "customers who bought this also bought" was item-item CF. Today usually combined with neural retrieval, not replaced.

Matrix factorization (ALS)

Decompose user–item interaction matrix R ≈ U V^T. Implicit-feedback ALS treats observed interactions as confidence-weighted positives, all others as low-confidence zeros. Closed-form per-user/per-item updates make it embarrassingly parallelizable on Spark. Limitation: shallow, no side features (without extensions like LightFM).

Graph-based retrieval — PinSAGE, GraphSAGE, LightGCN

Treat the user–item bipartite graph (and optionally item–item co-engagement graph) as the substrate. Aggregate features from a node's neighborhood with learned weights. PinSAGE scaled this to ~3B node graphs at Pinterest by sampling neighborhoods with random walks. LightGCN strips out non-linearities and feature transforms — just iterative neighborhood averaging — and matches/exceeds heavier GCNs on retrieval benchmarks because in collab-filtering the embedding propagation is what matters, not the MLP.

Sequential models for retrieval — SASRec, BERT4Rec

Treat a user's interaction history as a sequence and use a transformer to predict the next item. SASRec uses causal attention (predict next from prefix); BERT4Rec uses bidirectional masked-item modeling. The "user representation" is the encoder output at the last position. The item embeddings are the input/output embedding table. Retrieval = top-K of W_item^T · h_last.

Generative retrieval — TIGER, RecGPT

The newest paradigm. Items are tokenized into semantic IDs (a short tuple of discrete codes from an RQ-VAE trained on item content embeddings), then a transformer is trained to autoregressively generate the semantic ID of the next item. Retrieval becomes beam search. Strengths: generalizes to cold items (because the semantic ID is content-derived), shares parameters across items, can scale with model size. Weaknesses: beam search is slower than ANN; semantic IDs need re-training as the corpus drifts.

Mixed retrieval — the production pattern

No top-tier system uses one retrieval source. A typical Sr Staff answer:

• Two-tower neural retrieval (~3000 candidates) — captures personalization
• Item-item / "more like this" from current session anchor (~1000) — captures intent
• Trending / freshness pool (~500) — captures discovery
• Social: items engaged by friends in last 24h (~500) — captures network
• Geo / context: nearby restaurants, local creators (~500)
• Exploration source: random sample from underexposed long-tail (~200) — combats popularity feedback loops

Total ~5–10k candidates after dedup, all hydrated and passed to ranking. The diversity of sources is itself a debias mechanism — if your only retrieval is two-tower, popularity bias compounds.

1.3 ANN serving

Once you have item embeddings indexed, retrieval is "given query vector q, return top-K nearest neighbors by inner product or cosine." Exact NN is O(N·d) per query — for N=100M, d=128, that's 12.8B FLOPs per request. Approximate methods get you 100–1000x speedup with <1% recall loss.

HNSW (Hierarchical Navigable Small World)

A multi-layer proximity graph. Top layers are sparse (long-range links); bottom layer contains all points. Search starts at the top entry point, greedily descends by following edges to the closest neighbor of the query, then drops to the next layer. At the bottom layer, performs a beam search of width efSearch.

Key parameters and how they trade off:

• M — max edges per node. Higher M ⇒ better recall but more memory (each node stores ~M neighbor IDs per layer it appears in). Typical 16–48.
• efConstruction — beam width during index build. Higher ⇒ better graph quality, slower build. Typical 100–400.
• efSearch — beam width at query time. Higher ⇒ better recall, slower query. Tunable per query, often the production knob.
• Memory: ~(d × 4 bytes + M × 8 bytes × levels) per item. For N=100M, d=128, M=32: ~75 GB. Doesn't fit on one box → shard or use IVF-PQ.

IVF-PQ (Inverted File + Product Quantization)

Two-stage lossy compression:

1. IVF (coarse). Cluster all vectors into nlist centroids (k-means). At query time, find the nprobe nearest centroids and only search items in those Voronoi cells.
2. PQ (fine). Split each d-dim vector into m sub-vectors, run k-means with K=256 on each sub-space. Each item is now stored as m bytes (one cluster ID per sub-space). Distances are computed via precomputed lookup tables — extremely cache-friendly.

HNSW vs IVF-PQ — when to pick which

Other notable systems

• ScaNN (Google). Anisotropic vector quantization — quantizes to minimize loss in inner product direction specifically (instead of L2). Often best recall/latency tradeoff at moderate scale. Used in Vertex Matching Engine.
• Faiss (Meta). Library, not a service. Provides HNSW, IVF, IVF-PQ, OPQ, GPU implementations. Standard backend.
• Vespa (Yahoo / Verizon). Production search+ranking platform. HNSW + tensor evaluation in the same query — supports retrieval, filtering, and small ranking models in one engine. Used at Spotify, Tumblr, Yahoo.
• Vald, Milvus, Weaviate, Qdrant. Open-source vector DBs. Mostly HNSW under the hood, differentiated on operability, filtering, and hybrid search.
• DiskANN (Microsoft). SSD-resident graph index. Trick: store full vectors on SSD, compressed (PQ) vectors in RAM for routing. Lets you serve 1B+ vectors from a single machine with ~5–10 ms latency.

Filtering / hybrid search — the painful problem

Real recsys queries always have filters: "in stock," "shippable to my zip," "not blocked by user," "language=en." How to combine filters with ANN is non-obvious:

• Pre-filter: filter the corpus to candidates that match, then ANN. Correct but slow if filter selectivity is low (e.g. "in stock" matches 99% of items — you've done nothing) or very high (almost no candidates remain — exact NN is fine).
• Post-filter: ANN over everything, then drop disqualified items from the top-K. Fast but you may return fewer than K, or even 0.
• In-graph filtering (HNSW with attribute predicates): during graph traversal, skip neighbors that don't satisfy the predicate. Most modern systems (Vespa, Milvus, Qdrant) implement this. Caveat: if filter is very selective, the graph becomes disconnected and recall collapses → fall back to exact for those queries.
• Multi-index: partition the corpus by attribute (e.g. one index per country) and query the relevant index. Best when filter cardinality is small.

1.4 Ranking

The ranking stage scores each candidate from retrieval. Unlike retrieval, ranking can use rich user×item interaction features and deep architectures because the candidate set is small (~hundreds to a few thousand). Sr Staff interviews go deep here — be ready to defend choices about loss, architecture, multi-task structure, and calibration.

Loss formulations

• Pointwise (binary cross-entropy). For each (u, i) example with label y ∈ {0,1}, predict p(click). Easy to train, easy to calibrate (probability is meaningful), but doesn't directly optimize ranking — two items both with p=0.3 are "tied" even if one is better.
• Pairwise (BPR, RankNet). Sample pairs (i⁺, i⁻) and train so score(u, i⁺) > score(u, i⁻). Optimizes order, but loses absolute calibration. BPR-MF is the classic implicit-feedback baseline.
• Listwise (LambdaMART, ListNet, NeuralNDCG). Loss is a function of the entire ranked list. LambdaMART (gradient-boosted trees with lambda gradients from NDCG swap deltas) is still the workhorse for search/ads ranking — top-of-leaderboard on classical learning-to-rank tasks.

In practice, a Sr Staff answer is: pointwise BCE for the underlying probability heads (with calibration) plus a pairwise auxiliary loss when the metric you care about is ordering and your data is heavily implicit. For multi-task (CTR, like, share, completion), pointwise BCE per task with shared bottom is the baseline.

Deep ranking architectures

Wide & Deep (Google, 2016). Linear/cross-feature "wide" arm + DNN "deep" arm. Wide handles memorization (specific user×item co-occurrence indicators); deep handles generalization (embedding lookups + MLP). Still a useful mental model for "what features go where."

DeepFM, DCN, DCN-v2. Add explicit cross-feature layers. DCN-v2's cross network multiplies embeddings layer-by-layer to learn polynomial interactions of arbitrary degree, with cost roughly linear in feature count. Outperforms vanilla MLP because MLPs are surprisingly bad at learning multiplicative feature interactions.

AutoInt. Multi-head self-attention over feature embeddings to learn arbitrary interactions automatically. Heavier than DCN; sometimes wins, sometimes doesn't.

DLRM (Meta, 2019). The reference Meta architecture for years. Sparse features (id-types) → embedding tables; dense features → bottom MLP; pairwise dot products of all (sparse_emb, dense_proj) pairs → top MLP → logits. The dot-product interaction is the inductive bias that captures "this user × this item × this context."

Multi-task learning — Shared Bottom, MMoE, CGC/PLE

Real systems optimize multiple objectives jointly: click, like, share, watch-time, complete, follow, hide. Three architectures dominate:

• Shared Bottom. One MLP "trunk," then per-task heads. Simple, parameter-efficient. Fails when tasks conflict — gradients average out and no task wins.
• MMoE (Multi-gate Mixture of Experts). N expert MLPs share the input. Each task has its own gating network producing weights over experts. Tasks can specialize on different experts; shared experts capture common structure. Originated at Google for YouTube ranking.
• PLE / CGC (Tencent). Adds task-specific experts that only their own task can use, plus shared experts. Cleaner separation, better when tasks really do conflict (e.g. "share" and "long-watch" pull in different directions).

Why MMoE outperforms shared-bottom (the interview answer)

In shared-bottom, all tasks must compromise on a single trunk representation. If two tasks have negatively correlated labels (e.g. "fast click" vs "long watch"), their gradients destructively interfere and the trunk learns a weak average. In MMoE, each task routes to a different mixture of experts; the negative correlation can be expressed as the two tasks attending to different experts, and gradients no longer fight at the parameter level. Empirically this shows up most strongly when tasks have different positive rates (e.g. click 5% vs share 0.1%) and different feature dependencies — exactly the regime feed ranking lives in.

Multi-objective combination

You have p(click), p(like), p(share), p(complete), p(follow). What do you optimize? Three approaches:

• Linear scalarization. Score = Σ w_k · f(p_k). Weights are tuned via A/B test guidance from product (e.g. "increase shares 5% without losing CTR"). f might be log or identity. The interview-correct phrasing: "weights are not learned end-to-end — they're a product artifact, set by leadership in service of the ecosystem KPI."
• Pareto frontier. Treat as multi-objective optimization, find Pareto-optimal weight vectors. Useful for offline analysis but practical systems still ship a single weight vector.
• Constrained optimization. Maximize one (e.g. watch time) subject to others ≥ baseline. Dual / Lagrangian methods. More principled but harder to operate.

Calibration

Critical when scores feed into auctions (ads), bid shading, or business rules expecting probabilities. Multi-task models are systematically miscalibrated because:

• Logging policy biases — items shown more often have more training data and shrink toward base rate; rare items inflate.
• Negative downsampling during training breaks the link between predicted probability and true probability (need to back out: p_true = p_pred / (p_pred + (1 − p_pred) / r) where r is sample rate).
• Multi-task gradients pull each head toward an "average" calibration.

Common fixes: Platt scaling (logistic regression on top of logits, fit on holdout), isotonic regression (non-parametric monotonic mapping, more flexible but needs more data), temperature scaling (one scalar T fit to minimize NLL — under-fits but stable). For multi-task, calibrate each head separately, then combine. Track ECE (Expected Calibration Error) and reliability diagrams in dashboards.

1.5 Sequence-aware ranking

The single biggest accuracy lift in modern recsys, beyond going deep, has been treating user history as a sequence with attention rather than a bag of average-pooled embeddings. Below are the canonical models.

DIN — Deep Interest Network (Alibaba, 2018)

Idea: not all of a user's history is relevant to the current candidate. For a candidate i, compute attention weights over the user's past items based on similarity to i, then weighted-sum the past item embeddings into a "user-interest-given-i" vector. This is essentially target attention. Solved a real production problem at Alibaba where users with broad interests had their representation diluted.

DIEN — Deep Interest Evolution Network

Adds a GRU over the history to model temporal evolution of interests, then attention-weighted by relevance to candidate. Handles "user moved from electronics to home goods last week" gracefully.

BST — Behavior Sequence Transformer (Alibaba, 2019)

Replaces the GRU with a transformer encoder over the recent history. By 2019 this was the dominant architecture for sequence-aware ranking.

SASRec, BERT4Rec

These started as retrieval models but their hidden states make great sequence features for the ranker too. The pattern: pretrain SASRec on next-item prediction, then use the encoder output at last position as a frozen or fine-tuned input to the deep ranker.

HSTU — Hierarchical Sequential Transduction Unit (Meta, 2024)

Meta's new flagship architecture, replacing DLRM at Reels/IG ranking. Reframes recommendation as generative sequence modeling: tokens are user actions (impression, click, like, etc.) plus item IDs, the model learns to predict next-token. A single HSTU does both retrieval and ranking in one pass. Key tricks: (a) custom attention with relative positional encoding tuned for action sequences; (b) handles million-scale token vocabularies via sharded embeddings; (c) exhibits scaling laws — bigger HSTU keeps winning. The 2024 paper showed it strictly outperformed DLRM at the same FLOP budget at Meta scale.

LLM-augmented (ReLLA, P5, M6-Rec)

Use a pretrained LLM to encode item text/metadata and inject those embeddings into the ranker, or use the LLM directly as a reranker over the top-K. P5 reformulated all recommendation tasks as text-to-text; M6-Rec scaled this at Alibaba. Status in 2026: helpful for cold-start and content-rich domains (news, e-commerce), still too slow for top-of-funnel ranking at feed scale.

1.6 Generative recommendation

The frontier topic any 2026 Sr Staff loop will probe.

TIGER (Rajput et al., 2023)

Pipeline:

1. Train a content encoder (text + image) to produce item embeddings.
2. Train an RQ-VAE (Residual Quantized VAE) to compress each item embedding into a tuple of L codes (typically L=4, each code from a vocab of K=256). This is the item's semantic ID — semantically similar items share prefix codes.
3. Train a vanilla transformer to autoregressively predict the next item's semantic ID given the user's history of semantic IDs.
4. At serving, beam-search the top-K most likely semantic IDs and look them up.

Why it matters: (a) generalizes to new items (their semantic ID is computable from content with no training data), (b) the model size scales independently of corpus size (no embedding table per item), (c) beam-search controls retrieval and ranking jointly.

HSTU (Meta, 2024)

Different flavor of generative — keeps id-based item tokens but uses a custom transformer to do retrieval + ranking jointly. Trained on user action sequences with next-action prediction. Production-deployed at Meta at large scale; the 2024 paper showed clear scaling-law behavior in industrial recsys for the first time.

RecGPT framing

The umbrella name for "treat the user history as a token sequence and use an LLM-style decoder to generate next item." TIGER, HSTU, and various academic systems all fall under this. The Sr Staff framing: "we are converging recommendation, search, and conversational interfaces into one autoregressive system because semantic IDs let us share parameters across tasks and items, and because scaling laws are starting to apply."

Pros and cons vs traditional retrieval+ranking

Part 2 — Eval, calibration, debiasing

2.1 Offline evaluation

The classical metrics

• HitRate@K — fraction of test users for whom the held-out item is in the top-K. Coarse but interpretable.
• Recall@K — for tests with multiple held-out items, the fraction of them that appear in top-K. The retrieval-stage metric.
• Precision@K — fraction of top-K that are positives. Less common in implicit feedback.
• MRR (Mean Reciprocal Rank) — 1 / rank of first relevant item, averaged over users.
• NDCG@K — discounts gain by log of position. The standard ranking metric. Sensitive to relevance labels at top positions.
• AUC — pointwise probability of ranking a positive above a random negative. Useful for binary classifier sanity, but a 0.01 AUC lift can correspond to massive online lift or none at all because AUC is an average over all (pos, neg) pairs while you only show top-K.

AUC vs NDCG — when each matters

AUC is position-insensitive: it asks "given any random pos and any random neg, is pos ranked higher?" NDCG is position-sensitive: lifts at rank 1 matter much more than lifts at rank 50. For a two-tower retrieval model, AUC is fine — you only care that positives are roughly above negatives. For a feed ranker where users see 10 items, NDCG@10 (or even NDCG@3) is what predicts online wins. Sr Staff phrasing: "AUC for retrieval, top-heavy metrics for ranking, and never trust AUC alone for the final ranker."

The offline–online correlation problem

The biggest hard-earned lesson in industrial recsys: offline metrics often do not correlate with online A/B test outcomes. Reasons:

• Selection bias. Logged data came from an old policy. New model is evaluated on items the old policy showed — it never sees the items it would now surface.
• Feedback loops. Offline you predict on historical context; online your predictions change future logs.
• Position bias. Logged labels are confounded with where they were shown.
• Multi-task interactions. A model that improves p(click) AUC may push down p(complete), and the linear combination loses.
• Distribution shift. Model trained on last month, served this month.

Counterfactual / IPS / DR estimators

For more honest offline eval, weight each logged event by 1/p_logging(action), where p_logging is the (logged or estimated) probability that the old policy showed this item to this user. This is the Inverse Propensity Score estimator. It's unbiased but has high variance when propensities are small. Doubly Robust (DR) combines IPS with a reward model: if either the propensity model or the reward model is correct, the estimator is unbiased. Production teams run replay eval (using IPS/DR) alongside traditional offline metrics, and trust the agreement.

2.2 Online evaluation

A/B test fundamentals

Sample size: n ≈ 16 σ² / Δ², for detecting a relative effect Δ at 80% power, 5% significance, two-sided. For typical CTR (5%) and a 1% relative MDE (so absolute Δ = 0.0005), n is in the tens of millions per arm. For low-traffic surfaces, this means month-long tests or no test at all. Sr Staff candidates should know:

• Randomization unit. User-level (default), session-level (for short-lived effects), cluster-level (for network effects).
• Triggered analysis. Only analyze users who actually hit the treatment surface, not all users in the bucket. Reduces variance.
• Multiple comparisons. If you're tracking 50 metrics, expect 2–3 false-positive movements. Pre-register the primary metric.
• Novelty effects. First week of a new model often inflated by curiosity. Run for ≥ 14 days.
• Network effects. If your treatment changes what creators see (e.g. ranking changes affect creator behavior), randomization unit must be a connected component, not a user.

CUPED variance reduction

Subtract a regression-predicted "expected metric value" (from pre-experiment user features) from the observed metric. The residual has lower variance, so you detect smaller effects with the same n. Conceptually: control for "this user was always going to click a lot." Reduces required sample size by 30–60% in most consumer experiments. Microsoft / Booking.com / Netflix all use it.

Interleaving

Instead of A/B (different users see A or B), each user sees a result list interleaved from both rankers (Team Draft Interleaving, Probabilistic Interleaving). Counts wins per ranker. Detects ranking improvements with ~10x less traffic than A/B because variance from "different users" is removed. Microsoft Bing's standard pre-A/B gating tool.

Multi-armed bandits

For exploration / cold-start / many-arm comparison:

• ε-greedy. Pick best arm with prob 1−ε, random arm with prob ε. Trivial; surprisingly hard to beat in practice.
• Thompson sampling. Maintain Bayesian posterior over each arm's reward; sample one parameter per arm per draw; pick the arm with the highest sampled value. Naturally allocates traffic proportional to posterior probability of being best.
• UCB (Upper Confidence Bound). Pick arm with highest mean + √(2 log t / n_arm). Provably good regret bound, but tuning the constant matters.
• Contextual bandits (LinUCB, neural bandits). Reward depends on context (user features). Foundation for personalized exploration.

Bandits in production usually serve either (a) cold-start exposure for new content, or (b) hyperparameter tuning across model variants. Pure bandit-driven feed ranking is rare — bandits don't naturally compose with the cascade.

Long-term metrics

The hardest, most Sr-Staff topic. Short-term CTR may go up while 30-day retention goes down (the "engagement bait" failure mode). Real production teams maintain:

• 30/60/90-day retention
• L7/L28 active days
• Diversity / novelty (e.g. categorical entropy of items shown)
• Creator-side health (creator earnings distribution, cold creator survival)
• Reported satisfaction (star surveys)
• Hide / mute / report rates

The operationalized answer: any launch must move the primary metric without significantly hurting any guardrail. Long-term metrics are tracked in holdback experiments (5% of users on baseline indefinitely) so you can attribute multi-month effects.

2.3 Bias and fairness

Position bias

Items at the top of a list get clicked more regardless of relevance. If you train naively on click logs, your model learns "be like the previous model" rather than relevance. Two correction families:

• Examination hypothesis. Click = examine × relevant. Estimate p(examine | position) from a randomized "swap" experiment, then weight click loss by 1/p(examine).
• PAL (Position-Aware Learning). At training, add position as a feature into a separate "bias" head that is summed with the relevance head. At serving, fix position to a constant (e.g. position 1 or "no position"). Trick: the model learns to put position-dependent variance into the bias head, leaving a clean relevance head for serving. Used at Huawei / Pinterest.

Selection / exposure bias

Items never shown have no labels. Naive training converges to "show items the previous model would've shown." Mitigations: random exploration traffic (e.g. 1% of impressions are random), counterfactual reasoning (IPS), and explicit exploration sources in retrieval.

Popularity bias and item cold start

Popular items appear in training data far more often, both as positives and (via in-batch sampling) as negatives. The negative effect typically dominates and you under-rank popular items unless you correct. YouTube's logQ subtraction (subtract log of sampling probability from logits during training) corrects in-batch negatives. For cold items, hybrid retrieval (content tower) and explicit cold-item exploration boost are standard.

Calibrated logging

The single highest-leverage practice for honest training: log the propensity that the action was taken. If your serving system did Thompson sampling or stochastic rerank, log the probability. This lets you train with IPS or DR estimators, run honest counterfactual eval, and avoid the offline-online correlation collapse. Most teams ship deterministic ranking by default, then quietly add ε-randomization just to enable better training data.

Fairness — not just bias

Beyond position bias, "fairness" in recsys typically means: equal exposure across creator groups, demographic parity, or specific KPIs for protected categories. Common interventions: post-rank reordering to satisfy exposure constraints (Polyak / Lagrangian), in-training fairness regularizers, or pipeline-level changes (e.g. "ensure ≥ 30% of impressions go to creators with < 10k followers"). Be ready to discuss tradeoffs with primary metric.

Part 3 — Embedding tables at scale

The number-one infra problem in industrial recsys. A modern ranker has tens of billions of parameters, ~95% of which are in sparse embedding tables (user IDs, item IDs, creator IDs, all the cross IDs). A single user-id embedding table at Meta or YouTube can be ~100B rows × 128 dim × 4 bytes = ~50 TB. No single GPU has that memory.

Sharding strategies

• Table-wise. Each whole table on one GPU. Simple, but balance is poor (some tables are huge, some small).
• Row-wise. Hash row IDs across GPUs; each GPU holds a slice of rows from each table. Best for one giant table.
• Column-wise. Each GPU holds all rows for a contiguous slice of columns. Useful when row count is moderate but dim is huge.
• Grid (table×row). Combination of the above; most flexible. TorchRec uses a planner (heuristic or ILP) that chooses the best sharding strategy per table given hardware.

Communication: all-to-all

For each minibatch, each GPU has some subset of needed embedding rows; the rest are on other GPUs. The pattern is:

1. Forward all-to-all: each GPU sends "I need rows X, Y, Z from you" and receives back the embedding rows.
2. Compute.
3. Backward all-to-all: gradients flow the other way to update embeddings.

This is the hot loop of training. NVLink/IB bandwidth here is what limits throughput in production.

Compression and capacity tricks

• Hash trick. Map id → hash(id) % B for some bucket count B < cardinality. Loses some uniqueness; reduces memory by orders of magnitude. Used heavily for low-importance categorical features.
• Quantization. Store embeddings in int8 or fp8 instead of fp32. ~4x memory reduction with negligible accuracy loss for ranking. FBGEMM provides fused int8 lookup kernels.
• Mixed precision. Frequent items in fp16/bf16, infrequent in int8. Even fancier: differential dim — popular items get bigger embeddings.
• Composite embeddings. emb(id) = f(coarse_emb(hash1(id)), fine_emb(hash2(id))). Multi-resolution; reduces collision impact.
• UVM (Unified Virtual Memory). Embedding table lives in CPU host memory; GPU pages it in on demand via NVLink/PCIe. The hot rows naturally end up cached on GPU.
• Hot embedding cache. A small explicit GPU cache for top-N most accessed rows (popular items, popular users), backed by a slower CPU-resident store.

Training challenges specific to embeddings

• Skewed access (Zipf). 1% of items get 50% of impressions. The hot rows get massive gradient updates, the cold rows almost none. Need rowwise-adaptive optimizers (RowwiseAdagrad) that maintain per-row state.
• Optimizer state size. Adam doubles or triples table memory (m and v per row). Often forced to use Adagrad / RowwiseAdagrad to keep state small.
• Gradient staleness. In async training, gradients computed against an old version of an embedding row are applied to a newer version. Hot rows are updated by many workers per step.
• Rebalancing. Hot tables become bottlenecks; periodic re-sharding (TorchRec's planner) is run during long training.

Stack landscape

• TorchRec (Meta). PyTorch-native, supports table-wise / row-wise / column-wise sharding, FBGEMM kernels for fast embedding ops, integrates with FSDP for the dense parts. Production at Meta.
• HugeCTR (NVIDIA). CUDA-native, optimized for NVLink/IB. Marketed for ads/recsys at NVIDIA-stack shops.
• Merlin (NVIDIA). The umbrella ecosystem (HugeCTR + NVTabular + Triton-based serving).
• Persia (Bytedance). Heterogeneous training — embeddings on CPU parameter servers, dense on GPU workers. Predecessor pattern.

Part 4 — Six worked ML system designs

Each at the depth a Sr Staff loop expects. The goal isn't to memorize architectures — it's to know which knobs you would turn and why. For every problem, walk the same template: clarifying Qs → scale → data → features → arch → training infra → serving infra → eval → monitoring → gotchas → "if I had more time."

Part 5 — RecSys + LLM convergence (the 2025–2026 frontier)

The most asked-about topic in 2026 Sr Staff loops. Be opinionated. Below: how LLMs are actually used in production recsys, and where they aren't yet.

LLMs as feature extractors

The most boring and most useful pattern. For any item with text (titles, descriptions, reviews, transcripts, captions), pre-compute LLM embeddings (OpenAI text-embedding-3, Cohere, in-house Llama-style encoder). These plug into ranking models as a continuous feature. Wins:

• Dramatic cold-item improvement — content embeddings exist before any interaction.
• Cross-lingual transfer (multilingual encoders).
• Subtle topical similarity beyond what tag systems capture.

This is in production at virtually every modern recsys team. Cost is dominated by one-time embedding compute, refreshed only for changed items.

LLMs as rerankers

Take the top-50 from your traditional ranker, send to an LLM with a prompt like "User has been browsing {history}. Rank these items by relevance: {items}." Used in:

• Search result reranking (Bing, You.com).
• E-commerce product reranking for high-intent queries.
• News reranking with personalized briefs.

Tradeoff: latency. A GPT-4-class call adds 500ms+. Production deployments use distilled smaller models, batch reranking offline for "warm" content, or only invoke LLM rerank for high-value queries (high commercial intent, low-latency tolerance).

Generative recommendation (autoregressive item generation)

TIGER, HSTU, and the broader RecGPT framing — covered in Part 1.6. The future direction. As of 2026, HSTU is in production at Meta scale; most other "generative recsys" are research or small/medium scale.

Conversational recommendation

"Recommend me a sci-fi movie like Arrival but happier." A user expresses preferences in language; an agent translates into retrieval, ranks, presents, and refines based on follow-up. Hot research area, increasingly shipping in product (Amazon Rufus, Klarna, Shopify, Google's product search). Architecture pattern:

• LLM extracts query into structured filters + free-text intent.
• Hybrid retrieval (BM25 + semantic + filtered).
• LLM-style rerank with chain-of-thought rationale.
• Multi-turn refinement: each user reply updates the latent intent state.

Personalized agents (multi-step research / shopping)

"I want to switch from gas to induction stove — what should I buy?" The agent reads product specs, reads reviews, does spec comparisons, answers tradeoffs, narrows to recommendations, possibly checks out. This is recsys + tool use + reasoning. Companies betting here: Anthropic (computer-use agents), Amazon, Klarna, Perplexity. Recsys engineer's role: design how recommendations are surfaced inside an agent loop, how to ground in user history without violating privacy, and how to attribute conversion.

World models for simulation-based eval

The dream: rather than running an A/B test for 14 days, simulate the new ranker against a learned model of user behavior to predict the outcome offline. Active research area (Meta, Google, academia). Risk: the world model itself is just a learned predictor and can suffer from distribution shift. Promising for narrowing the candidate set of A/B tests, not for replacing them.

Part 6 — Common interview questions, with Sr Staff answers