Deep Learning for Recommendation Systems – Two-Tower, DLRM and Sequential Recommenders

Recommendation systems are among the highest-ROI ML applications: improving recommendation quality by 1% translates directly to hundreds of millions of dollars in additional revenue at YouTube, Netflix, Amazon, or Spotify. The evolution from collaborative filtering and matrix factorisation (covered in our Recommendation Systems guide) to deep learning architectures has been driven by the need to incorporate heterogeneous features, model sequential user behaviour, and scale to catalogs with hundreds of millions of items and user bases with billions of interactions per day. This guide covers the Two-Tower retrieval architecture, DLRM for ranking, sequential recommendation models (SASRec, BERT4Rec), multi-task learning for recommendation, and the production engineering challenges that distinguish industrial-scale recommenders from research prototypes.

Two-Tower Architecture for Scalable Candidate Retrieval

The recommendation pipeline at production scale is a two-stage funnel: retrieval (narrowing billions of items to thousands of candidates for a user) followed by ranking (scoring candidates to produce a final ranked list). The Two-Tower model is the standard retrieval architecture because it enables pre-computation: item tower embeddings can be computed offline for all items and indexed in a vector database; at serving time, only the user tower runs online (one forward pass), and ANN search retrieves the top-k candidates in <10ms. The user tower takes all user features as input — user ID embedding (from a lookup table), demographic features (age, country, device type), recent interaction history (average of recent item embeddings), and contextual features (time of day, session length) — and outputs a d-dimensional user representation. The item tower takes item ID embedding, content features (category, language, duration, tags), and popularity statistics and outputs a d-dimensional item representation. Training: for each (user, positive_item) pair in the training log, the model maximises the cosine similarity between user and positive item embeddings while minimising similarities to negatives. In-batch negatives (treating other items in the batch as negatives) are computationally efficient but introduce popularity bias; hard negative mining (sampling items the model currently ranks highly but that the user did not engage with) improves ranking quality at higher training cost. The connection to our vector databases guide is direct: the item embedding index is a vector database, and the Two-Tower serving pipeline is a real-world ANN search application at scale.

DLRM and Dense Ranking Models

DLRM (Naumov et al., Meta 2019) is the reference architecture for the dense ranking stage that scores the thousands of candidates retrieved by Two-Tower. Its design reflects the structure of tabular advertising data: many sparse categorical features (user ID, ad ID, advertiser ID, app category, device type — each requiring an embedding lookup in a separate table) combined with a smaller number of dense numerical features (user age, ad bid, historical CTR). DLRM processes these as follows: (1) Each categorical feature is looked up in its own embedding table, producing a d-dimensional embedding (d = 128 is typical); (2) Dense numerical features are projected to d dimensions by a bottom MLP; (3) All d-dimensional vectors (from embeddings and the bottom MLP) undergo pairwise dot-product interactions: f_ij = e_i · e_j for all pairs (i, j), producing C(K, 2) interaction scalars; (4) These interaction features are concatenated with the bottom MLP output and passed through a top MLP that outputs a click probability. The explicit dot-product interactions capture feature crosses that a standard MLP would need many layers and large width to learn implicitly — the connection to our feature engineering guide is direct: DLRM’s interaction layer is an automated feature crossing step analogous to polynomial feature engineering, but learned end-to-end. The embedding tables dominate DLRM’s parameter count: with 1000 categorical features each requiring a 100K × 128 embedding table, the total embedding parameters reach 12.8 billion — requiring distributed embedding tables sharded across multiple GPUs or servers.

Sequential Recommendation and Multi-Task Learning

Sequential recommendation models treat the user’s interaction history as a sequence of item IDs and model the sequence to predict the next item. SASRec (Kang & McAuley, 2018) applies a causally-masked Transformer — identical to the GPT architecture but operating on item ID sequences rather than word sequences — to the user’s last N interactions (N = 50 is typical), producing a representation that is used to score all candidate items via dot product with their embeddings. The causal masking ensures that the prediction at position t uses only items 1..t-1, preventing information leakage. BERT4Rec (Sun et al., 2019) applies bidirectional Transformer (BERT-style) with 15% random item masking — during training, masked item positions are predicted from their full context (past and future interactions), producing richer item representations than causal models. The connection to our Transformers guide is direct: SASRec is GPT applied to item sequences; BERT4Rec is BERT applied to item sequences — the same architecture, different masking strategy, different domain. Multi-task recommendation models (MMOE, PLE) train a single model to predict multiple engagement signals simultaneously (click, watch completion, share, subscribe) using shared-bottom representations and task-specific tower networks, improving generalisation by leveraging the correlation between related engagement signals and producing a multi-objective ranking signal that better captures user satisfaction than any single metric. The connection to our marketing analytics guide is direct: multi-task recommendation optimises a portfolio of engagement metrics that map to business objectives (reach, engagement, conversion) in exactly the way marketing attribution models allocate credit across the customer journey.

✦ SUMMARIZE THIS ARTICLE WITH AI

ChatGPT Perplexity Claude Grok

Matrix factorisation and collaborative filtering foundations are in our Recommendation Systems guide. Vector databases (FAISS, Pinecone, Qdrant) for ANN candidate retrieval are in our Vector Databases guide. Transformers (GPT architecture used in SASRec, BERT in BERT4Rec) are in our Transformers guide. Feature engineering for embedding feature crosses is in our Feature Engineering guide. GNN-based recommendation (PinSage) is in our Graph Attention Networks guide. Streaming ML for real-time feature updates in online recommenders is in our Streaming ML guide.