A funnel at billion-item scale
Explore is one of Instagram's largest recommendation surfaces, serving hundreds of millions of people daily. Ranking content from a pool of billions of candidates in real time calls for a multi-stage funnel. Explore now follows four distinct stages — retrieval, first-stage ranking, second-stage ranking, and final reranking — each with its own models and objectives.
Throughout these stages, the system leans heavily on caching and pre-computation. That lets engineers run heavier models at every step, learn behavior from data, and cut reliance on hand-tuned heuristics.
Retrieval: narrowing billions to hundreds
Retrieval finds content likely to rank highly later in the funnel, giving the system an approximation before any expensive scoring. In practice, multiple retrieval sources each pull a few hundred relevant items from the wider media pool, and those lists are merged before ranking.
Sources may be heuristic or ML-based, real-time or pre-generated. Real-time sources capture the freshest interactions, while pre-generated sources reflect long-term interests and can be built offline during off-peak hours. Mixing these source types with tunable weights lets the system cover different user communities. Pre-generated candidates — locally popular media, for instance — are produced when load is low, holding down peak-hour cost.
Two Tower neural networks for retrieval
Two Tower NNs are central to retrieval at this scale. Earlier ML retrieval used Word2Vec to produce user and media embeddings purely from IDs. The Two Tower extension keeps Word2Vec's practical benefits but accepts arbitrary user and item features and learns multiple objectives simultaneously.
The architecture works like this:
- Two separate neural networks sit side by side, one consuming user features, the other consuming item features.
- Each block outputs an embedding for its entity.
- Training predicts engagement signals — likes, for example — as a similarity score between the two embeddings.
- After training, content embeddings close to a given user's embedding become ranking candidates.
Because the towers are independent, item embeddings can be generated daily through an offline job. Those vectors go into a service supporting approximate nearest neighbor (ANN) search such as FAISS or HNSW, so lookups don't scan the full corpus. User embeddings are produced at request time from the freshest user-side features. Well-known interaction signals can't be fed to this model, though — they'd tie the representation to a specific user-item pair and break caching. That tradeoff is what enables fast, cacheable inference.
Retrieval from interaction history
A second retrieval path starts from the item side. Given the items a user recently liked, saved, or shared, the system fetches similar items via their embeddings and merges the lists. That yields candidates reflecting the user's current and recent interests.
Interactive-history retrieval gives operators finer control over the online tradeoff between engagement types than user-embedding lookup does. But candidate quality hinges on choosing the right history items — a random click history quickly floods results with low-value content. Rule-based filters remove poor candidates (e.g., reported posts, objectionable imagery) before this retrieval path runs.
Ranking: two stages, complementary models
A full ranking of thousands of candidates with a heavyweight model isn't feasible under latency constraints. Explore thus splits ranking in two: a lightweight first-stage ranker scores all candidates from retrieval, and a heavier second-stage model takes the top ~100. The two-stage split raises the total candidate count while keeping quality high.
Both stages use neural networks. Those models support continual training, re-fine-tuning as often as hourly as new interaction data arrives, which matters in an environment where behaviors shift quickly. Neural nets also handle categorical features well by learning embeddings for them.
First stage: distilling the second stage
The first-stage ranker is — again — a Two Tower model, chosen for its cacheable embeddings. Its training objective sets it apart from the retrieval stage: it learns to predict which items land in the top K of the second-stage output, effectively distilling the larger model into a light, fast scorer.
Second stage: multi-task scoring
The second-stage ranker is a multi-task, multi-label (MTML) neural network. It predicts probabilities for different engagement events like click, like, and "see less." This model consumes the strongest signals — user-item interaction features — something tower-based models cannot do without losing caching advantages.
Serving the MTML model during peak hours can stress capacity, so recommendations for some users are precomputed in off-peak time, protecting availability for every Explore visitor.
A final ordering score combines these probabilities into what the team calls the value model:
Expected Value = W_click * P(click) + W_like * P(like) – W_see_less * P(see less) + etc.
Weights (W_click, W_like, etc.) let operators trade off online engagement signals. A larger W_like, for instance, pushes more likeable content up. The end goal of tuning is maximizing policy goals without hurting other metrics.
Reranking: constraints on top of scores
A pure score sort isn't always the right final output. Final reranking lets the system enforce integrity constraints — downranking or dropping harmful content — and diversity rules like avoiding long runs from a single author. These business-rule filters provide additional control over final results and help online engagement metrics.
Parameter tuning
Hundreds of parameters shape this pipeline, such as VM weights and per-source fetch counts. Good online outcomes pair with disciplined tuning. Explore uses two approaches:
Online Bayesian optimization
Bayesian optimization (BO) tunes parameters live. It needs only the set of parameters, the goal metric, and threshold constraints on other metrics; the optimizer finds the rest. The tradeoff is convergence time — often over a month, especially when many low-sensitivity metrics are in play.
Offline tuning
With sufficient historical data, engineers can learn a function mapping offline metric changes to expected online metric outcomes. Then parameter candidates can be tested offline using BO to explore the space efficiently, translating into projected online gains in hours rather than weeks. This is only as good as the correlation between offline and online behavior, but where that assumption holds it speeds the loop dramatically.
Keeping up with a maturing system
The pipeline described above is an ongoing effort, and the increasing complexity of the ranking systems will continue to introduce new obstacles around maintainability and feedback loops. To handle these, we will keep refining existing models and adding new ranking models and retrieval sources. At the same time, we’re exploring ways to merge our retrieval approaches into a smaller set of highly configurable ML algorithms.
