Purpose
Two-tower retrieval is the workhorse first stage in large recommendation systems. One tower encodes the user or query. The other encodes the item. The score is usually a dot product. That sounds restrictive. It is restrictive. The reason people use it anyway is that the restriction buys a serving path that scales.
The Basic Form
Let be the user embedding and the item embedding. Retrieval uses
or a nearby similarity such as cosine similarity.
At training time, both towers are learned jointly from historical interactions. At serving time, item embeddings are precomputed and indexed. A request only has to:
- build the user embedding
- query an ANN index
- return the top items
That turns catalog-sized search into sublinear nearest-neighbor search.
flowchart TD subgraph UT["User tower (online)"] UF["User features<br/>history, queries, context"] --> UE["Encoder f"] UE --> UV["User embedding f(u)"] end subgraph IT["Item tower (offline)"] IF["Item features<br/>ID, metadata, content"] --> IE["Encoder g"] IE --> IV["Item embeddings g(i)"] end IV -->|precompute and index| ANN["ANN index"] UV -->|"dot product f(u)·g(i)"| ANN ANN --> K["Top-k candidates"] style UT fill:#e3f2fd,stroke:#1565c0 style IT fill:#e8f5e9,stroke:#2e7d32
Why It Became the Default
The main gain is decomposition. The user and item encoders can be evaluated separately. Since the item tower is offline, online retrieval costs almost nothing beyond user encoding and ANN lookup.
That is the key systems trade:
- richer cross-feature interactions are sacrificed
- catalog-scale retrieval becomes feasible
If the item tower had to read user features at scoring time, or the user tower had to read item features for every candidate, the whole trick would collapse.
Training
There are two common training views, and they are closer than they look.
Softmax View
The YouTube paper frames candidate generation as multiclass classification over the video vocabulary. The model predicts which next item the user will consume, usually with sampled softmax because the full catalog is too large.
Contrastive View
The same setup can be read as contrastive learning. Given a positive pair and sampled negatives , make the positive item’s dot product larger than the negatives’.
In both cases the model learns an embedding space where relevant items sit near the user vector.
Feature Design
The user tower often absorbs:
- recent interactions
- search queries
- demographics or locale
- device and temporal context
The item tower often absorbs:
- item ID
- metadata
- text
- image or audio features
- creator or taxonomy information
The tension is always the same. The more context you want in the score, the more pressure there is to break the tower decomposition. Once you break it too much, retrieval stops being cheap.
What It Gives Up
Two-tower models cannot express arbitrary user-item feature crosses at retrieval time. The score is bottlenecked through the embedding dimension and the similarity function. That means:
- memorized exception rules are hard
- calibration is usually poor
- business constraints are awkward to encode directly
- exposure balancing and multi-objective tradeoffs are usually deferred to later stages
This is why first-stage retrieval and final ranking are almost never the same model.
Hard Negatives Matter
A weak negative sampler teaches the model only coarse separation. The embeddings become good at telling a watched item from random catalog junk, while still failing to separate one plausible item from another plausible item.
The common fix is to train with harder negatives:
- in-batch negatives
- co-exposed but skipped items
- items retrieved by a previous model and rejected downstream
- semantically close items
Very hard negatives become false negatives
Items that are semantically close to the positive, or co-exposed and skipped, are often items the user would have liked if they had noticed them. Training against them as negatives pushes apart pairs that should stay close.
The downside is that very hard negatives can become false negatives. You can end up pushing apart items the user would have liked if they had seen them.
How It Fits the Pipeline
Two-tower retrieval is usually not asked to produce the final order. Its job is recall. A good retrieval stage finds most of the items the ranker would have wanted, while staying inside the latency budget.
That changes how you judge it. Absolute calibration barely matters here. Candidate recall, diversity of candidate sources, and tail coverage matter a lot more.
Executable Experiment
The companion notebook turns MovieLens 100K ratings into implicit positives, trains user and item towers with sampled negatives, and evaluates retrieval with Recall at . It also inspects nearest items in the learned embedding space.
When Not to Use It
Do not force a two-tower model into places where the business needs rich slate-level reasoning or precise feature interactions. If the catalog is small enough to score directly with a richer model, or if every decision depends on inventory, auction dynamics, or complex constraints, the tower decomposition may cost more than it saves.