Retrieval and ranking pipelines

For an illustrative ten-million-video catalog, retrieve perhaps 1,000 candidates and rank them down to a display of 20. Those sizes are design assumptions to benchmark, not prescribed values. Retrieval prioritizes finding enough potentially useful items cheaply; ranking makes finer comparisons using richer user-item and context features.

Candidate sources can include embedding neighbors, subscriptions, recent interactions, and popular eligible content. Merge and deduplicate their outputs before expensive scoring. Multiple sources can improve coverage, but their quotas and score scales need a deliberate policy rather than accidental ordering.

Index preparation happens ahead of requests by training compatible representations, computing item vectors, and checking the resulting search index. When a request arrives, the serving path creates a query vector, retrieves candidates, obtains their features, and runs the ranker. Recording the model and index versions connects each response to the prepared artifacts that produced it.

New items need a route into the candidate pool before enough interaction history exists. Content features, creator metadata, or controlled exploration can help. New users may receive context-based or popular recommendations until enough history supports personalization. Evaluate these cases explicitly instead of hiding them in an average dominated by established users.

A final stage may enforce deduplication, creator limits, availability, safety policy, or a diversity objective. Some constraints also belong before retrieval or ranking to avoid wasting work on ineligible items. Access restrictions should be enforced as rules, not left to a relevance score.

Filtering after retrieval can shrink the candidate pool unevenly for different users. Track the number of eligible results at each stage and use an appropriate refill strategy. A top-20 endpoint that often returns three items has a coverage problem even if the three are highly ranked.

Measure candidate recall separately from ranking quality, and inspect the contribution of each retrieval source. If recall saturates well before the latency budget, a smaller pool may save cost. If relevant items are missing, a larger ranker will not solve the retrieval failure.

Tracing a failed recommendation through eligibility, retrieval, scoring, and filtering helps identify the stage responsible for the result. The same request trace can show where the system spends its time. We will use that view next to reason about latency, throughput, and the cost of returning useful predictions under load.