Ranking Stage

By the time the ranking stage runs, the hard problem of scale has already been solved. Candidate generation has cut a catalogue of millions down to a few hundred items. The ranking stage is what happens next: score those survivors precisely, with the expensive model you could never have run over the whole catalogue, and put them in order.

Why it is a separate stage
Retrieval optimises recall under a brutal latency budget, so it uses cheap representations — a dot product between a user and an item embedding, served from an approximate nearest-neighbour index. Ranking optimises precision over a small set, which buys room for features retrieval cannot afford: cross features between user and item, real-time context, dozens of counters and sequence features. A few hundred candidates times a heavy model fits the budget; a few million does not.

What it typically runs

• Gradient-boosted trees such as an XGBoost or LambdaMART ranker over dense tabular features.
• Deep CTR models — DLRM, DeepFM, DIN — which learn feature interactions and attend over a user's history.
• Multi-objective heads predicting click, dwell time, completion and conversion separately, then combining them into one score.

Where it sits in the pipeline
Ranking is accountable for the ordering a user sees, but it is not the final word — a re-ranking pass usually follows to enforce diversity, business rules and calibration. Its two standing weaknesses are inherited: it can only order what retrieval handed it, so recall lost upstream is unrecoverable, and it trains on logged impressions it produced itself, which is why position-bias correction and off-policy evaluation belong here rather than as an afterthought.