• Core tension: catalog is huge (billions), but you show ~10, and the best ranking model is too slow to run on every item.
• Example: 5 ms/item × 100M items = hours per request. User needs ~100 ms.
• Fix: a cascade. Cheap-and-broad first, expensive-and-precise last. Each stage cuts the set and has its own compute budget.

1. Candidate Generation (Retrieval): cut billions → thousands. Cheap, runs on all items, optimize recall. Often several sources in parallel. Tools: Two-Tower Model + Approximate Nearest Neighbor (ANN), Collaborative Filtering.
2. Ranking: thousands → tens. Heavy model, rich features, optimize precision at top. See Learning to Rank.
3. Re-ranking / policy: tens → ~10. Fix what a per-item score misses: diversity, freshness, dedup, business rules (ads).

Key intuition: recall early, precision late

• False negative in stage 1 is fatal: a missed good item can never be shown downstream.
• False positive in stage 1 is cheap: ranking will demote the junk.
• Precision must wait: stage 1 runs on the whole corpus, so it must be cheap and coarse, and coarse models can't be precise. You earn a precise model only after the set is small.

Search vs RecSys

• Same funnel. Only stage 1's trigger differs: search retrieves by a query, RecSys retrieves by user profile / history / context. Stages 2-3 are shared.

References