Ranking, Prediction, and Classification Pipelines

Many AI features never generate text. They score things: which posts to show first, whether a payment looks fraudulent, or how long a delivery will take. These ranking, prediction, and classification pipelines usually run on the request path while the user waits, so they must return results within tight deadlines, often tens to a few hundred milliseconds.

A pipeline meets these deadlines by turning request context and features into a score, a class label, or an ordered list. The decision layer differs by task: a feed ranker must find candidates before ordering them, while a fraud model emits a risk score that the product maps to allow, verify, or block.

In this lesson, we trace the ranking request path, decide when features and scores are computed, turn scores into decisions with thresholds, and operate the pipeline safely as models change.

The ranking request path

Consider a home feed that has about 150 ms to pick a few dozen posts from millions of candidates. Scoring every post with an expensive model would blow that budget, so the pipeline narrows the work in stages before expensive scoring begins.

Request context and candidate generation

The request context identifies the user, surface, device, locale, and session state. These fields shape what the user is eligible to see and which retrieval methods are likely to find relevant items.

Candidate generation keeps scoring within the deadline. Cheap signals such as recent follows, coarse embeddings, trending pools, or past engagement shrink millions of items to a few hundred. This stage aims for high recall, because the pipeline can rank only what it retrieves.

Next, eligibility checks apply hard constraints:

• Policy filters: Remove blocked creators, age-restricted items, and unsafe content.

• Availability filters: Drop deleted, expired, or region-unavailable items.

• Deduplication filters: Remove duplicate items, ...