Feature Placement Across the Funnel¶
Where do context and user history live — retrieval, ranking, or re-ranking? The premise "features are captured at a stage" is wrong. All feature types are available everywhere; what changes is how richly each stage can use them, dictated by compute budget and governed by the same separable-vs-joint line as the bi-encoder/cross-encoder split.
Rapid Recall
Features aren't captured at a stage — they're available everywhere; what changes is how richly each stage can combine them, governed by separable (retrieval) vs joint (ranking). Context enters the user tower at retrieval (shifts which region of item space you retrieve) but can only cross with items at ranking. User history sits on a spectrum: mean pooling → recency-weighted → target attention (DIN) → sequential models (SASRec/BERT4Rec). The placement rule is candidate-independence: candidate-independent encoders (SASRec produces a user vector without the candidate) can live in the retrieval tower; candidate-dependent ones (DIN target attention) must live in ranking because they need the candidate as input, breaking tower separability.
Fixing the premise
Features aren't "captured at a stage." All feature types are available everywhere; what changes is how RICHLY each stage can use them, dictated by compute budget. The governing line is always separable (retrieval) vs. joint (ranking) — the same bi-encoder/cross-encoder split.
§1 Context features (time, day, session length, weather, country)¶
These are user-side / request-side features — they describe this request, so they live wherever the user representation is built.
- At retrieval: fed into the user tower → a context-aware user vector. (This is why two-tower beat MF: MF's user vector was a static lookup that couldn't change with context; the user tower recomputes per request — 9am Monday mobile ≠ 11pm Saturday TV.) But context can only shift which region of item space you retrieve from — it can't form context×item crosses, because towers are separate.
- At ranking: fed into the joint model → now context crosses with items: "evening × Telugu-film," "raining × food-delivery." Only expressible here.
Answer to the confusion: context is used at retrieval (through the user tower) but its interactions with items are captured at ranking. Context lives in both, at escalating fidelity.
§2 User history representation — the spectrum¶
History is a user-side feature; structurally it lives in the user tower (retrieval) and user-side inputs (ranking). The interesting part is how it's encoded:
| Level | Method | Notes |
|---|---|---|
| 0 | Mean pooling | Average last N item embeddings. Order-blind blob (the baseline). |
| 1 | Recency-weighted pooling | Exponential decay; recent items weigh more. Cheap, still order-blind beyond weighting. |
| 2 | Target attention (DIN) | Weight history items by relevance to this candidate. User repr becomes candidate-dependent. |
| 3 | Sequential models (DIEN, SASRec, BERT4Rec) | Model history as an ordered sequence (GRU / transformer). Captures order, evolution, patterns. Literally next-token prediction over item IDs. |
The placement nuance (the deep point)
Candidate-independent history encoders (SASRec/BERT4Rec encoding history into a user vector without the candidate) → can live in the retrieval tower (still produce one vector before meeting items). Candidate-dependent encoders (DIN/DIEN target attention — history repr depends on which candidate) → must live in ranking (need the candidate as input, which breaks tower separability).
§3 The unifying principle¶
There are two feature families — query-side (user, context, history) and item-side. They live everywhere; what changes down the funnel is how they're allowed to combine:
- Retrieval: compress to one user + one item vector, meet at a dot product (separable, candidate-independent history).
- Ranking: all features in one joint model, interact freely (query×item crosses, candidate-aware attention).
- Re-ranking: features of the already-selected set (list-level relationships).
Interview questions¶
Q1: Why can context influence retrieval but not form context×item crosses there? Context enters the user tower and shifts the user vector (which region of item space you retrieve), but towers are separate and meet only at a dot product — so context can't interact with item features. Those crosses are only expressible in the joint ranking model.
Q2: Why can't DIN-style target attention live in the retrieval tower? It makes the user/history representation candidate-dependent (weights history by relevance to the specific candidate), which needs the candidate as input — breaking tower separability and precomputation. It must live in ranking.
Q3: What principle decides retrieval vs ranking for a history encoder? Candidate-independence. Candidate-independent encoders (produce a user vector without the candidate, e.g. SASRec) can live in the retrieval tower; candidate-dependent ones (DIN/DIEN) must live in ranking.