What's new

The Content Relevance: The Candidate Set Is Destiny - Part 2

S

Surya Kalipattapu

Guest

How retrieval silently determines what a ranker can ever choose​


Imagine hiring the world's best editor and asking her to choose the ten most important books for a reader—then giving her a cart filled only with airport thrillers.


Her ordering may be flawless. The recommendations will still be narrow.


This is the hidden reality of large-scale ranking systems. Product discussions tend to focus on the final score, but the final ranker sees only a tiny fraction of the available universe. Before it can be precise, the system must decide where to look.


That is retrieval.

From billions to hundreds.​


At the scale of a social or entertainment platform, scoring every available post, video, song, creator, or show with the most sophisticated model is computationally impossible. Production systems therefore use a funnel.


A simplified version looks like this:

  1. Eligibility removes items that cannot be shown because of policy, privacy, geography, age, language, availability, or prior exposure.
  2. Retrieval searches multiple sources and reduces millions or billions of items to thousands.
  3. Pre-ranking uses efficient models to remove weak candidates.
  4. Heavy ranking predicts multiple outcomes with richer user-item and contextual features.
  5. Reranking constructs the final slate, accounting for diversity, repetition, integrity, freshness, and other constraints.
  6. Presentation determines layout, position, explanation, and interaction design—which in turn affect the feedback the system observes.


The classic 2016 YouTube paper described a two-stage version: candidate generation followed by ranking. Instagram has publicly described a four-stage Explore funnel: retrieval, first-stage ranking, second-stage ranking, and final reranking. The details evolve, but the product law remains stable:

A ranker's theoretical ceiling is bounded by the recall and composition of its candidate set.

Retrieval is a portfolio.​


Good retrieval systems rarely rely on one source. They assemble a portfolio of candidate generators, each with a distinct thesis.


For a social or entertainment surface, sources might include:

  • Content from followed accounts or close relationships
  • Items similar to recent high-signal interactions
  • Long-term interest clusters
  • Fresh content from established creators
  • Fresh content from new creators
  • Locally or globally trending content
  • Collaborative signals from people with related behavior
  • Semantic matches based on text, audio, or visual understanding
  • Continuation items, such as the next episode or an unfinished video
  • Exploration pools deliberately chosen for uncertainty or novelty


Each source answers a different question. More from people you care about is not the same retrieval thesis as something unlike anything you have seen. A robust experience needs both memory and possibility.


This is why candidate-source allocation is a product decision. If 95 percent of the pool comes from similarity to recent consumption, a diversity rule in the final ten positions cannot create meaningful breadth. If new creators receive no retrieval budget, a fairness weight in the late-stage score may have nothing to act on. If a Stories tray pulls only from strongest historical relationships, it may fail to notice a newly important relationship.


The candidate mix defines the frontier of possible experiences.

Recall before precision.​


Ranking teams often celebrate a model that is more precise offline. But a better late-stage model can produce little user impact if the right items are absent upstream.


This suggests a more complete diagnostic sequence:

  1. Eligibility recall: Were valuable items incorrectly excluded?
  2. Source recall: Did at least one source retrieve the item?
  3. Merge health: Did source quotas or deduplication remove it?
  4. Pre-rank recall: Did the efficient model preserve items the heavy model would value?
  5. Rank quality: Did the final model order the survivors well?
  6. Slate quality: Did the collection work together?


Without this decomposition, teams can spend months tuning a late-stage objective while the real bottleneck sits in retrieval.


A useful practice is to measure oracle recall at every stage: among items that a stronger downstream model or later user behavior suggests were valuable, what fraction survived each funnel step? This reveals where the system loses potential value.

Retrieval has its own bias.​


Two-tower models made large-scale learned retrieval practical by separately encoding users and items into an embedding space, then using approximate nearest-neighbor search to find close matches. Their cacheability makes them efficient, and they remain foundational across the industry.


But efficiency creates constraints. Because user and item towers are computed independently, they cannot use the richest pairwise interaction features during retrieval. Similarity can also over-favor the already legible: content with abundant interactions, stable representations, and clear connections to known tastes.


This creates three common blind spots:

  • Freshness blindness: New items have little behavioral history.
  • Semantic blindness: Collaborative signals may miss why a new item is relevant.
  • Possibility blindness: Nearest neighbors are good at extending known taste, not discovering a taste the user has not expressed.


The answer is not to abandon embeddings. It is to diversify retrieval methods and preserve intentional uncertainty.

Retrieval is becoming a model, not a mesh.​


The architecture is now changing quickly. In 2026, Meta described SilverTorch, an “Index as Model” system that brings approximate-nearest-neighbor search, eligibility filtering, neural reranking, and multi-task scoring into one GPU-native model. Meta reported that the system could evaluate wider candidate pools and apply richer relevance logic earlier while remaining within a sub-100-millisecond retrieval budget.


The important product implication is larger than infrastructure efficiency.


Historically, retrieval was often treated as a coarse recall service: find broadly similar items fast, then let the real intelligence happen later. As retrieval becomes end-to-end learned, multi-task, and capable of neural reranking, it can express more of the product's value model earlier in the funnel.


That raises the ceiling—but also the responsibility. A more intelligent retriever can become a more powerful gatekeeper. Teams will need the same observability for retrieval-source composition, creator exposure, freshness, and integrity that they already expect from late-stage ranking.

The pre-ranker is a student with veto power.​


Large systems commonly use a lightweight model to imitate or distill the decisions of a heavier downstream model. Instagram's published Explore architecture, for example, describes a first-stage ranker trained to predict which media the second-stage model would place in its top results.


This is efficient, but it creates a subtle organizational risk: the cheaper student has veto power over the teacher. If the pre-ranker systematically drops a class of items, the heavy model never evaluates them.


That makes distillation parity an important product metric. Do errors vary by content format, language, creator maturity, topic, user activity level, or source? Aggregate recall can hide systematic starvation.


The best funnel is not the one that removes the most candidates fastest. It is the one that spends expensive attention on the candidates with the greatest plausible value while preserving enough uncertainty to learn.

Design retrieval like an investment portfolio.​


I find it useful to think of candidate sources as an attention portfolio:

  • Core holdings provide dependable relevance from relationships and known interests.
  • Growth holdings surface fresh content and evolving interests.
  • Exploration holdings test uncertain creators, topics, and formats.
  • Hedges preserve diversity, quality, and resilience when one signal or source becomes distorted.


This framing forces explicit choices. How much of the candidate pool should be stable versus exploratory? Which sources become correlated and therefore redundant? Which user cohorts receive too little discovery? Which creator groups have no path into the pool?


It also changes roadmap priorities. Improving a final ranker by a fraction may matter less than adding a retrieval source that opens an entirely new region of relevant inventory.

The first product decision happens before ranking.​


When a user says, “The algorithm never shows me anything new,” the failure may not be in ranking at all. The system may be faithfully ordering a candidate set that contains no real novelty.


When a creator says, “My posts never get a chance,” the issue may not be a low score. The posts may rarely enter competitive retrieval pools.


When a platform becomes repetitive, late-stage diversity rules are often treating the symptom. The upstream portfolio has already converged.


The final ranker decides who wins among the invited. Retrieval writes the guest list.


And in ranking systems, the guest list is destiny.
 

Thread statistics

Created
Surya Kalipattapu,
Replies
0
Views
3
Back
Top