Modern feed ranking systems do not begin by scoring every available post, article, video, or recommendation in a platform’s inventory. At internet scale, that would be computationally impossible. Instead, they rely on a crucial upstream stage known as candidate generation.
Candidate generation is the mechanism that narrows a massive corpus of possible content into a much smaller, manageable set of items that a ranking model can evaluate in depth. In practical terms, it is the retrieval layer of the feed system. Its mission is simple in wording but difficult in execution: find the most promising items for a user, under strict latency constraints, from an ever-changing content universe.
This stage is foundational to the quality of the final feed. If candidate generation fails to retrieve relevant, diverse, fresh, and policy-compliant items, no downstream ranking model can fully recover. A ranking model can only reorder what it receives. It cannot rank content that was never retrieved.
In large-scale systems, candidate generation sits at the intersection of machine learning, distributed systems, information retrieval, user modeling, and product strategy. It must balance relevance with speed, exploration with precision, and personalization with operational efficiency.
This article explains how candidate generation works in feed ranking systems from an engineering and research perspective. It covers the purpose of retrieval, the major architectural patterns, common modeling approaches, infrastructure design, evaluation principles, and the trade-offs that define modern candidate generation pipelines.
Why Candidate Generation Exists
The central reason candidate generation exists is scale.
A major social, media, or content platform may have millions or billions of eligible items. Even a single user request can arrive in a context where thousands of new posts are being created every second, old items are decaying in relevance, and user intent is changing in real time.
A sophisticated ranker may use hundreds or thousands of features and complex neural architectures to estimate click probability, dwell time, satisfaction, retention impact, or long-term value. Applying such heavy computation to the entire corpus is not feasible within the latency budget of a feed request.
Candidate generation solves this by creating a recall-focused shortlist.
Its role is not to perfectly order content. Its role is to ensure that the downstream ranking stage receives a candidate set that contains enough high-quality possibilities to construct an excellent final feed.
This leads to an important conceptual distinction:
- Candidate generation optimizes for recall under speed constraints
- Ranking optimizes for precision under richer feature computation
That distinction shapes nearly every design decision in feed architecture.
The Position of Candidate Generation in the Feed Pipeline
A simplified feed ranking pipeline often looks like this:
- Eligibility filtering
- Candidate generation
- Feature enrichment
- Heavy ranking
- Re-ranking and constraints
- Final serving
Eligibility filtering removes content that should never be considered for a given request, such as blocked authors, exhausted inventory, policy-violating items, region-restricted content, or content the user already consumed.
Candidate generation then retrieves a few hundred or few thousand promising items from the remaining universe.
Feature enrichment adds contextual, user, content, graph, and behavioral signals.
The main ranking layer scores these candidates using more expressive models.
Finally, re-ranking may enforce diversity, freshness, creator fairness, session constraints, or business rules before the final feed is rendered.
In this architecture, candidate generation is the bridge between a massive content space and a tractable ranking problem.
The Core Objective: High Recall, Low Latency
The ideal candidate generator has two properties.
First, it achieves high recall. That means it successfully retrieves many of the items that a stronger downstream ranker would have considered top-quality for the user.
Second, it achieves this with low latency and reasonable infrastructure cost.
These goals are often in tension.
A broader retrieval strategy improves recall but increases response time, network traffic, and downstream ranking cost. A narrower strategy reduces latency but risks missing valuable content.
As a result, candidate generation is usually designed as a controlled compromise. Engineers define a candidate budget, latency budget, and retrieval composition strategy, then optimize the system within those boundaries.
Retrieval Sources: Where Candidates Come From
In most production feed systems, candidate generation does not rely on a single source. It is a multi-source retrieval system.
Different retrieval channels contribute candidates for different reasons:
1. Social Graph Retrieval
These candidates come from accounts, pages, creators, or communities the user follows or frequently interacts with.
This source tends to provide strong relevance because it reflects explicit or implicit affinity. It is often the backbone of follower-based feeds.
2. Content Similarity Retrieval
These candidates are retrieved because they are similar to content the user recently consumed, liked, watched, saved, or shared.
This channel captures evolving short-term interest and often powers recommendation-heavy feeds.
3. Collaborative Retrieval
These candidates come from patterns across users. If similar users engaged with certain items, those items may be promising for the current user.
This source is useful for discovery and can surface content outside the user’s immediate social graph.
4. Trending or Popularity Retrieval
These items are globally or locally popular, fast-rising, or high-velocity. They can improve freshness and exploration, especially when personalized signals are sparse.
5. Semantic or Topic-Based Retrieval
These candidates are associated with topics, intents, or latent concepts inferred from user behavior and content understanding.
This retrieval source is especially important when explicit graph signals are weak.
6. Heuristic or Rule-Based Retrieval
Some items are inserted through deterministic logic, such as recent posts from close connections, important updates, or content required for product goals.
Even advanced systems still use such channels because product requirements are rarely fully learned end-to-end.
A feed request may combine candidates from all these sources, each with its own budget and retrieval logic.
Two Major Paradigms: Retrieval by Rules and Retrieval by Learning
Candidate generation systems typically evolve through two broad paradigms.
Rule-Based Retrieval
Early or simpler systems often use hand-designed heuristics. For example:
- retrieve recent posts from followed accounts
- retrieve items with high interaction velocity
- retrieve similar posts based on metadata tags
- retrieve unseen items from preferred categories
This approach is interpretable and operationally simple. It can work surprisingly well when the content graph is small or the product is still maturing.
However, rule-based retrieval struggles with personalization depth, complex user intent, and scaling across many content types.
Learned Retrieval
Modern systems increasingly use machine learning models to retrieve candidates.
These models learn compact user and item representations and estimate which items are likely to matter for a specific user. Instead of relying only on surface heuristics, they learn from behavior patterns.
The most influential family here is the embedding-based retrieval model, especially the two-tower architecture.
Embedding-Based Candidate Generation
Embedding-based retrieval has become a dominant design in large-scale feed systems.
The idea is to map users and items into a shared vector space. In that space, a user vector should be close to items the user is likely to engage with, and far from irrelevant items.
User Tower
The user tower consumes features such as:
- long-term engagement history
- recent session actions
- followed entities
- device and locale
- time context
- topic preferences
- graph signals
It produces a dense user embedding.
Item Tower
The item tower consumes item features such as:
- text and metadata
- creator identity
- engagement priors
- media embeddings
- topic signals
- freshness information
It produces a dense item embedding.
At serving time, the system computes the user embedding and retrieves nearby item embeddings using approximate nearest neighbor search. This turns large-scale retrieval into a vector search problem.
This approach is powerful because it generalizes across sparse interactions and allows fast retrieval over enormous corpora.
Why Two-Tower Models Are Popular
Two-tower retrieval models are widely used because they separate user encoding from item encoding.
Item embeddings can be precomputed offline or updated incrementally. User embeddings can be computed online or refreshed frequently. This separation makes serving efficient.
The architecture also supports scalable indexing. Once item vectors are stored in an approximate nearest neighbor index, retrieval becomes much faster than exhaustive scoring.
Another advantage is extensibility. New content modalities such as image, video, audio, and text can be integrated into the item tower. Likewise, richer behavioral histories can improve the user tower.
However, these models also have limits. Dot-product similarity is efficient, but it is less expressive than a heavy ranker. That is why they are used for candidate generation rather than final ranking.
Approximate Nearest Neighbor Search
Because item catalogs are too large for brute-force vector comparisons, candidate generation systems typically rely on approximate nearest neighbor (ANN) search.
ANN methods trade exactness for speed. Instead of scanning every item, they search an optimized index structure that quickly returns vectors likely to be nearest to the query vector.
This matters because feed systems must respond within tight latency budgets, often in tens of milliseconds for retrieval stages.
ANN infrastructure becomes a core production component. Engineers must manage:
- index freshness
- memory usage
- sharding
- update frequency
- recall versus latency tuning
- embedding version compatibility
As the item corpus changes rapidly, keeping ANN indexes up to date becomes an engineering challenge in itself.
Candidate Generation Is Usually Multi-Stage
In practice, candidate generation is often not a single retrieval step but a multi-stage retrieval process.
A common design is:
- broad initial retrieval from multiple sources
- source-specific filtering and deduplication
- light scoring or pre-ranking
- budget allocation into a final candidate set
For example, the system may retrieve:
- 400 candidates from social graph sources
- 300 from embedding similarity
- 150 from trending content
- 100 from collaborative filtering
- 50 from exploration pools
It then merges, deduplicates, and lightly scores these items before handing them to the main ranker.
This structure helps balance personalization, freshness, and discovery.
Freshness and Time Sensitivity
Feed relevance is highly temporal.
A candidate that was attractive yesterday may no longer be appropriate now. User intent may also be session-dependent. A user browsing sports highlights after a live match may want very recent content, while the same user at another time may prefer evergreen analysis.
For this reason, candidate generation often incorporates freshness at multiple levels:
- time-decayed engagement priors
- recent interaction windows in the user representation
- freshness-constrained source budgets
- real-time event retrieval
- session-aware retrieval emphasis
Recency is especially important in social feeds, breaking news feeds, and short-form media platforms. If candidate generation underweights freshness, the feed can feel stale even if ranking quality appears high offline.
Diversity at the Retrieval Layer
A common misconception is that diversity should only be enforced after ranking. In reality, candidate generation itself must often contribute to diversity.
If retrieval returns a highly homogeneous set, downstream ranking has limited room to improve variety. For example, it may receive too many items from the same creator, topic, media type, or semantic cluster.
To reduce this risk, candidate generation may include:
- source quotas
- topic balancing
- creator caps
- semantic deduplication
- exploration channels
- cluster-aware retrieval
This is particularly important in systems where heavy personalization can collapse the candidate space around narrow patterns.
Filtering Before and After Retrieval
Candidate generation is tightly coupled with filtering.
Pre-Retrieval Filtering
Before retrieval, the system may exclude:
- blocked relationships
- policy-ineligible content
- already seen items
- regionally unavailable items
- exhausted sponsored inventory
- low-quality or unsafe content pools
Post-Retrieval Filtering
After retrieval, it may remove:
- near duplicates
- content failing freshness thresholds
- items violating session constraints
- repeated creators beyond allowed limits
- unsupported media for the current device or context
This means candidate generation is not just about finding relevant items. It is also about narrowing the search space responsibly and efficiently.
Real-Time Signals and Streaming Features
Modern feed systems increasingly incorporate real-time signals into candidate generation.
A user’s last few actions may significantly change the next best set of candidates. Similarly, an item’s sudden engagement spike may make it worth retrieving immediately.
To support this, production systems use streaming data pipelines for:
- recent clicks, likes, saves, watches, and skips
- session sequence updates
- creator posting activity
- item engagement velocity
- live trend detection
These pipelines allow candidate generation to adapt quickly, rather than relying only on slower batch updates.
The challenge is systems complexity. Real-time retrieval improves responsiveness but increases infrastructure demands, consistency concerns, and operational fragility.
How Candidate Generators Are Trained
Training a candidate generation model is usually framed as a retrieval or representation learning problem.
Positive examples often come from observed user-item interactions such as clicks, likes, long dwell, watch completion, or shares.
Negative examples may be sampled from:
- random items
- impression logs without engagement
- hard negatives from similar but unclicked items
- in-batch negatives during contrastive training
The objective is often to maximize similarity between users and positive items while separating them from negatives.
Training design matters greatly. Poor negative sampling can teach the model trivial distinctions instead of meaningful retrieval boundaries. Likewise, labels based only on clicks may overfit short-term engagement and miss long-term satisfaction.
Many advanced systems therefore use weighted labels, multi-task signals, or teacher-student setups aligned with downstream rankers.
Evaluation Metrics for Candidate Generation
Candidate generation is not evaluated the same way as final ranking.
Key retrieval-oriented metrics include:
Recall@K
Among the items a stronger ranker or ground-truth labels consider relevant, how many appear in the top K retrieved candidates?
Coverage
How broadly does the system retrieve across creators, topics, or item types?
Latency
How fast does retrieval run in production conditions?
Source Contribution
Which retrieval channels actually contribute items that survive downstream ranking?
Candidate Quality Funnel Metrics
How many retrieved items receive high downstream scores, impressions, engagement, or long-term satisfaction outcomes?
Offline evaluation is useful, but online experimentation is essential. Candidate generation affects the entire ranking stack, so its true value appears in end-to-end system behavior.
Common Failure Modes
Candidate generation can fail in several ways.
One failure mode is low recall, where relevant items are simply not retrieved.
Another is over-concentration, where the system retrieves too many similar items.
A third is staleness, where retrieval is too slow to reflect recent user behavior or fast-moving content.
There is also popularity bias, where popular items dominate the candidate pool and reduce discovery.
Cold-start is another classical problem. New users lack history, and new items lack engagement. Candidate generation must address both with side information, content understanding, heuristics, or exploration strategies.
Finally, misalignment can occur when retrieval optimizes one proxy while ranking optimizes another. If these layers are trained against inconsistent objectives, system quality degrades.
The Relationship Between Candidate Generation and Ranking
The strongest feed systems treat candidate generation and ranking as coordinated stages, not isolated components.
Candidate generation should retrieve candidates that are broad enough for ranking to select from, yet focused enough to preserve efficiency. Ranking should provide feedback about which candidate sources and retrieval strategies are actually useful.
In mature systems, engineers often analyze:
- which retrieval sources contribute to top-ranked impressions
- where recall losses occur
- whether certain user segments suffer from weak candidate pools
- how retrieval changes affect downstream model calibration
- whether diversity and exploration survive the ranking stage
This closed-loop analysis is essential because local improvements in retrieval metrics do not always produce global product gains.
The Future of Candidate Generation
Candidate generation is becoming more adaptive, multimodal, and context-aware.
As feed systems absorb richer content types and more complex objectives, retrieval layers are shifting from simple candidate recall engines to intelligent intent-sensitive selectors.
Emerging directions include:
- session-aware sequence retrieval
- multimodal embedding spaces
- graph-neural retrieval signals
- reinforcement-informed exploration
- long-term satisfaction-aware retrieval
- unified retrieval across feed, search, and recommendations
At the same time, infrastructure pressure continues to grow. Systems must retrieve better candidates from larger corpora with lower latency and stricter safety constraints.
This makes candidate generation one of the most strategically important layers in modern recommendation infrastructure.
Candidate generation is the hidden engine that makes feed ranking systems computationally viable and product-relevant at scale.
Its purpose is not to fully solve ranking, but to transform an impossibly large content universe into a high-quality, manageable candidate set for deeper evaluation. To do that well, it must combine retrieval science, machine learning, real-time systems, graph reasoning, filtering logic, and product-aware trade-offs.
The best candidate generation systems are fast, high-recall, freshness-aware, diversity-conscious, and tightly aligned with downstream ranking goals. They use multiple retrieval sources, increasingly rely on learned embeddings, and operate under demanding latency and infrastructure constraints.
In practical feed architecture, the quality of the final feed is often bounded by the quality of the candidate pool. A ranker can only choose from what it sees. For that reason, candidate generation is not a secondary optimization. It is a first-class design problem at the heart of every serious feed ranking system.