Candidate Generation

No production recommender scores its whole catalogue when you open the app. The very first thing it does is throw almost all of it away, and candidate generation is the stage that decides what survives.

How the shortlist is built
Rather than one clever retriever, real systems run several cheap ones in parallel and union their outputs. Each contributes a few hundred items, and a few thousand in total go forward to be ranked:

Embedding retrieval — an approximate nearest-neighbour lookup against a two-tower item index, which covers broad personalised taste.
Item-item neighbours — co-visitation or co-purchase lists for the items touched in the last few minutes, which is what makes a session feel responsive.
Pools — trending, newly added, and locally popular items, which give fresh content a route in before any model has learned about it.
Rules — continue-watching, same creator, previously saved; cheap, explainable, and often the highest-converting source of all.

Optimised for recall, not precision
This stage is judged on whether the good item is somewhere in the shortlist, not on where it sits. Precision is the ranking stage's job, which is why candidate generation can afford approximate indexes, stale-by-an-hour embeddings and crude heuristics. It spends most of the request's latency budget on one index lookup and leaves the expensive feature fetching and scoring to a set small enough to afford it.

Why it matters
The recall of this stage is a hard ceiling on the entire system: an item no retriever emits cannot be ranked, however good the ranker is. That makes its failures quiet and expensive — a stale index renders new items invisible and looks exactly like item cold start, and a retrieval source that breaks in production costs quality without producing a single error. Measuring recall per source, not just end-to-end click-through, is what surfaces both.

Candidate generation is the first stage of a staged recommender: it narrows a catalogue of millions down to a few hundred or few thousand plausible items, cheaply enough to fit the serving latency budget, so a heavier ranking model only ever scores that shortlist. It is usually served by approximate nearest-neighbour lookup over learned embeddings, or by simple co-occurrence rules. Recall is what matters here — anything this stage drops can never be recommended, however good the ranker is.

Imagine a bookshop with ten million titles and an assistant who has one minute to suggest something you will like. They cannot read every blurb, so they first wheel round a trolley and sweep in maybe two hundred books that look roughly right — recent crime novels, say, because that is what you have been buying. Only then do they look closely and pick the best three.

Candidate generation is that trolley-filling step inside recommendation software. It is deliberately quick and rough, built to cut millions of options down to a shortlist in a few thousandths of a second. The careful comparison happens afterwards. Its one job is to make sure nothing good gets left off the trolley.