Recommendation Ranking Models

A recommendation ranking model is the scoring model in a recommender serving path. In the Machine Learning Model Shapes map, it is a ranker: for one user request, it receives candidate items that earlier retrieval systems found, builds one feature row per (request, candidate) pair, and returns prediction scores that a feed, search, or related-item surface can use to order a response.

The serving vocabulary is: request, candidate set, candidate row, ranker output, response, and logged opportunity. Embedding-table training and GPU tensor exchange start after this serving path is clear.

One Request Path

This diagram follows one Home feed request from client input to ranked response. Retrieval produces the candidate set. Ranking spends more features and model compute on that bounded set.

The serving path has these objects:

Object	What it contains	Produced by
Request	user id, surface, device, country, session, privacy state, and current context	client and serving front end
Candidate set	candidate item ids and lightweight records	retrieval systems
Candidate row	one request joined with one candidate’s features	feature assembly layer
Ranker output	one or more scores for one candidate row	ranking model
Response	ordered items after policy, freshness, diversity, and layout constraints	feed composer

If retrieval returns 1,000 candidate Pins, the ranker usually scores 1,000 candidate rows as one batch. The model output is still per candidate:

request = {user_id: 42, surface: home, device: mobile}
candidates = [pin_77, pin_91, pin_123]
 
ranker outputs:
  pin_77  -> p(save)=0.18, p(hide)=0.02
  pin_91  -> p(save)=0.07, p(hide)=0.01
  pin_123 -> p(save)=0.11, p(hide)=0.04

The feed composer then combines model scores with product constraints. It may diversify creators, enforce policy eligibility, account for freshness, or choose a layout. The ranker scores candidates; it does not by itself decide the entire response.

Candidate Row Shape

One candidate row contains facts about the request, the candidate, and the current context. Some facts are ids that later become embedding lookups; others are measured or precomputed values.

Feature family	Example values	How the ranker sees it
Request facts	user_42, Home feed, mobile, country	ids, flags, or normalized values
Candidate facts	pin_77, creator id, topic ids, age	ids plus numeric features
Context facts	board_789, query text, recent saves	ids, sequences, or text-derived features
Upstream signals	retrieval source, quality score, policy flags	numeric values or categorical ids

Categorical Feature Embeddings in Recommender Systems explains one id-to-vector lookup. Multiple Embedding Tables in Recommender Rankers explains how a full candidate row fans out across several table families before the ranker has an assembled input tensor.

Retrieval Boundary

Retrieval is the upstream candidate-generation stage. Its job is recall under latency: find a bounded set of plausible items from a much larger inventory. Retrieval may use graph expansion, inverted indexes, approximate nearest-neighbor vector search, freshness pools, followed-entity expansion, or other low-latency sources.

Ranking is the downstream scoring stage. It receives candidate ids and candidate-side features from retrieval, joins them with request context, and computes prediction scores. The Pinterest scalability article concerns training a ranking model, so serving-time vector search belongs to retrieval unless a system deliberately reuses ranker representations inside a retrieval index.

Logged Opportunities

A logged opportunity is the serving record that later becomes a training example. The log needs enough context to reconstruct what the ranker scored and what happened afterward.

served candidate row:
  request_id: req_abc
  user_id: user_42
  candidate_id: pin_77
  context_board_id: board_789
  retrieval_source: related_board
  model_version: frm_2026_06_28
  position: 4
 
later labels:
  shown: true
  clicked: false
  saved: true
  hidden: false

Shown items can receive impression, click, save, hide, dwell, skip, or conversion labels. Retrieved-but-not-shown candidates can be used as sampled negatives only when the training pipeline knows how they were sampled. The logging policy defines the training data; it is not a cosmetic detail.

Where Training Begins

The serving path stops at candidate rows, scores, and logs. The training path follows the same row into lookup tables, model size, and distributed training:

Next question	Note
How does board_id=789 become a vector?	Categorical Feature Embeddings in Recommender Systems
How does one row gather from several tables?	Multiple Embedding Tables in Recommender Rankers
Why can lookup tables dominate model size?	Embedding-Heavy Models
Why do GPUs need to exchange rows during training?	Distributed Training for Embedding-Heavy Recommenders
What does near-linear training scalability mean?	Training Scalability for Distributed ML

Sources

• Pinterest Engineering - Achieving Near-Linear Training Scalability for Pinterest’s Foundation Models
• PyTorch - Linear
• PyTorch - MultiheadAttention

See also

• Categorical Feature Embeddings in Recommender Systems
• Multiple Embedding Tables in Recommender Rankers
• Embedding-Heavy Models
• Attention mechanism
• Introduction to Transformers
• Ad Serving Request Lifecycle