The Ranking Model
In one line: the ranker is the first stage that sees the user and the item together, and everything it can do that upstream stages cannot follows from that.
Cross features are the whole point
A two-tower retriever embeds the user and the item independently. That independence is what makes the item side precomputable and the index possible — and it means no feature can express a relationship between the two.
The ranker has no such constraint. It receives the pair and can compute features over both.
| Feature | Why only the ranker can compute it |
|---|---|
| Times this user bought from this seller | Needs both sides |
| Whether this item's category is in the user's top three | A join across user history and item metadata |
| Price relative to what this user usually pays | A ratio of a user statistic to an item attribute |
| Hours since this user last saw this exact item | Per-pair state |
| Match between the query and this item's title | The query is request-time; the item is precomputed |
That last row is the search version of the same point, and it is why a cross-encoder reranker exists in retrieval-augmented generation for exactly the same structural reason. A model that scores a pair can express interactions a model that scores each side alone never can.
The symmetry is the thing to remember: precomputability and interaction are mutually exclusive, which is exactly why there are two stages.
Three ways to define the objective
How you frame the learning problem changes what the model optimises, and the framings are genuinely different.
| Pointwise | Pairwise | Listwise | |
|---|---|---|---|
| Predicts | A score per item independently | Which of two items is better | The quality of a whole ordering |
| Loss | Regression or classification | Ranking-violation penalty | Optimises a ranking metric directly |
| Optimises | Calibrated absolute score | Relative order | Position-aware quality |
| Cost | Cheapest to train and serve | Pairs grow quadratically | Most complex |
| Use when | The score itself is used downstream | Only order matters | You care where in the list things land |
The "use when" row is the decision, and the pointwise case is more common in production than the literature suggests. If the score is multiplied by a bid, a margin, or a probability of conversion — as it is in ads and most commerce — you need a calibrated probability, not a relative ordering. A pairwise model that ranks perfectly and outputs uncalibrated scores is useless for expected-value arithmetic.
This is the calibration lesson from the foundations module arriving as an architecture decision: is the score's magnitude used anywhere, or only its order? If magnitude is used, pointwise with calibration. If only order, pairwise or listwise can do better.
Multi-objective is the normal case
Real rankers rarely predict one thing. A commerce ranker might predict click probability, conversion probability, expected margin and predicted return rate; a feed might predict click, dwell, share and hide.
Then something must combine them, and that something is a policy decision rather than a modelling one.
score = w1*P(click) + w2*P(convert)*margin - w3*P(return) - w4*P(hide)
Three things worth saying about that expression.
The weights are a business decision. They encode how much a conversion is worth relative to a complaint. Nobody can learn them from engagement data, because the data cannot tell you what the company values.
The heads should be calibrated. Adding a well-calibrated probability to a poorly-calibrated one produces a number with no meaning, and the miscalibrated head silently dominates.
Negative terms need care. P(hide) and P(return) are rare events, so their models are trained on imbalanced data — and, per the metrics chapter, rebalancing to handle that inflates their probabilities. An inflated negative term over-suppresses.
What the ranker should not do
Two things belong downstream, and putting them in the ranker is a common structural error.
Diversity. A ranker scores items independently, so it cannot express "this item is good but too similar to the one above it". Attempting it with features — penalising an item's own category popularity — approximates a set-level property with per-item information and works badly. Diversity is a re-ranking concern.
Hard business rules. "Never show out-of-stock", "this seller is suspended", "no alcohol to under-21s" are constraints, not preferences. Encoding them as a large negative weight makes them strong preferences that a high enough score can overcome. Constraints belong in a filter that cannot be outvoted.
That distinction — preferences go in the model, constraints go in a filter — is worth stating explicitly, because the failure mode is a policy violation caused by a sufficiently confident score.
Key takeaway
The ranker is the first stage to see user and item together, so cross features are what it exists for — precomputability and interaction are mutually exclusive, which is why there are two stages at all. Choose the objective by asking whether the score's magnitude is used downstream: pointwise and calibrated if it feeds expected-value arithmetic, pairwise or listwise if only order matters. Multi-objective is normal, its weights are a business decision no engagement data can reveal, and every head must be calibrated before summing. Keep diversity and hard constraints out of the ranker — a per-item scorer cannot express set-level properties, and a constraint encoded as a weight can be outvoted.
Next: the features, and the store that keeps training and serving honest.