AI Engineer World's Fair 2025

One model to rule recommendations: Netflix's Big Bet

Yesu Feng22:28

Read the talk

One model to rule recommendations: Netflix's Big Bet

Netflix’s recommendation architecture centralizes learning from interaction histories, then reuses the resulting representations across ranking models, embedding stores and specialized applications.

From a talk by Yesu Feng

Before you start: Familiarity with embeddings, transformer hidden states and supervised learning losses will help with the model architecture and training examples.

A homepage is many recommendation problems

A Netflix homepage has to decide both which rows to show and which titles belong in each row. Its two-dimensional layout combines row ranking with item ranking: comedy and action rows sit alongside trending releases and Netflix-exclusive titles. A useful recommendation system must coordinate those choices, not simply produce one ordered list of movies.

Slide titled “Personalized 2D Page” with a Netflix page screenshot, a vertical Row ranking arrow and a horizontal Item Ranking arrow.Open full source frame
A personalized page combines row ranking with item ranking.

The variety extends beyond rows. Movies and TV shows share the content space with games and live streaming. Different pages impose different structures: the homepage, search and kids homepage serve distinct needs, while a mobile feed is linear rather than two-dimensional. Historically, these differences produced specialized models—some ranking videos, others ranking rows, some finding unwatched shows and others supporting titles a member was already watching. Their objectives differed, but much of their work overlapped.

0:320:42
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:32 · section reference included

Learn once from the same interaction facts

Independent models repeatedly transformed the same user interaction history into slightly different features. One might count actions; another count them within several time windows; another compute similarities between previously watched titles and a candidate title. A sequence model might instead consume a sequence of unique show IDs. Label engineering was duplicated too. The underlying facts were shared, but the derived features accumulated variations that made them difficult to maintain.

Expanding the business by building another model for every new use case made this maintenance problem an innovation problem. Some feature and label components were already shared, yet each new model still largely started from scratch. Yesu Feng places this situation around the beginning or middle of the pandemic, roughly four years before the talk. The architectural question became: could Netflix centralize the learning of user representations?

Netflix’s recommendation foundation model, abbreviated FM, rests on two hypotheses. First, scaling semi-supervised learning with a transformer should improve personalization, much as scaling improves language models. Second, integrating that shared model into downstream applications should spread improvements across recommendation surfaces. The intended benefit is both better learning and a reusable foundation for application development.

2:242:41
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:24 · section reference included

The token is an interaction event

The first design decision sits below the transformer: how to clean and tokenize interaction history. As in language modeling, choices at this layer propagate through the entire model. But the input unit is different. A language token can be represented by a vocabulary ID; a recommendation token represents a user interaction event with multiple fields. Reducing it to a title ID alone would discard information about the interaction itself.

Token granularity determines how much history fits into the context window. The slide maps raw interaction history to a shorter tokenized history, making that compression visible. Netflix iterated on the abstractions and interfaces around tokenization so it could adjust the representation to different applications. Pretraining and application-specific fine-tuning can therefore use slightly different tokenization rather than requiring one fixed treatment of every event.

Two rows of title artwork labeled raw interaction history and tokenized history, connected by dashed lines; action icons appear above the raw events.Open full source frame
Raw interaction history maps to a shorter tokenized history.
5:145:29
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:14 · section reference included

From event fields to stable user representations

The model proceeds through four layers: event representation, embedding and feature transformation, the transformer, and the training objective. At the input, Feng organizes the event fields around three questions:

QuestionInformation represented
When?Event time and its encoding
Where?Location, locale, country, device, page and row
What?Target title or entity, interaction type and duration

“Where” includes both physical context and the interface where the action occurred. “What” includes both the object and what the member did with it. These fields make an event richer than a title appearing in a sequence.

The embedding layer must decide which information to retain and combine learned ID embeddings with semantic content information. An ID embedding learned from interactions has a cold-start problem: a newly introduced title was absent during training, so its ID has no learned behavioral representation. Semantic information supplies a complementary description that does not depend solely on that title’s interaction history.

The transformer’s hidden-state output becomes the user representation. That changes the design question from merely predicting the next event to producing a useful, long-term representation of a member. A profile and its interaction history continually change, so stability matters alongside responsiveness.

There are several places to shape that representation. Outputs can be aggregated across sequence positions, across transformer layers, or adapted explicitly to a downstream objective through fine-tuning. These are consequential choices: the last hidden state is not the only possible interface between the shared model and an application. Feng identifies the aggregation and adaptation questions without prescribing one universal recipe.

7:087:23
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:08 · section reference included

Predict more than the next title

At the objective layer, the event’s multiple fields create multiple possible output sequences. Predicting the next entity ID resembles next-token prediction and can use softmax or sampled softmax. But a title is only one part of the next event. Other targets include the action type; entity metadata such as type, URL or language; action duration; device; and the time of the next play. The application determines which of these predictions is useful.

These fields can enter training in different ways:

  • Prediction targets: Use multitask learning with multiple heads or hierarchical predictions.
  • Loss weights: Give some events more influence than others.
  • Rewards: Use event-derived feedback to guide the desired behavior.
  • Loss masks: Restrict learning to a selected subset of events.

For example, the following Python function expresses the loss-weighting and masking option for a title-prediction head. next_title_logits contains predictions at each sequence position, next_title_ids contains the targets, and include_event selects the behavior category that should contribute. event_weights controls the contribution of included events.

python

import torch
import torch.nn.functional as F


def weighted_title_loss(
    next_title_logits: torch.Tensor,
    next_title_ids: torch.Tensor,
    include_event: torch.Tensor,
    event_weights: torch.Tensor,
) -> torch.Tensor:
    # logits: [batch, sequence, titles]
    # targets, mask, weights: [batch, sequence]
    per_event_loss = F.cross_entropy(
        next_title_logits.transpose(1, 2),
        next_title_ids,
        reduction="none",
    )
    weights = event_weights.to(per_event_loss.dtype)
    weights = weights * include_event.to(per_event_loss.dtype)
    denominator = weights.sum().clamp_min(
        torch.finfo(per_event_loss.dtype).eps
    )
    return (per_event_loss * weights).sum() / denominator

The distinction is useful: an event field need not become another thing to predict. It can instead specify which behavior the existing prediction objective should emphasize.

10:0010:10
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:00 · section reference included

Scale the learning, then account for serving

Feng reports continuing recommendation-quality gains over roughly two to two-and-a-half years as the model grew from a few million or order-ten-million parameters to order-one-billion parameters, with training data scaled alongside it. He does not give a named quality metric or numerical lift in the discussion. Netflix’s stopping point reflects recommendation systems’ strict latency and cost requirements: further growth would require distilling the larger model back into something suitable for serving, rather than assuming the largest trained model should answer every online request.

Three techniques borrowed from language modeling help make that learning more useful. The first is multi-token prediction. Feng points to DeepSeek as an example, without identifying a particular paper, and describes multi-head and multi-label implementations. The purpose is to make the model less focused on the immediately next action. Predicting farther ahead also addresses the time gap between training and serving and encourages learning about longer-term behavior and satisfaction.

Feng reports a notable metric improvement from multi-token prediction, without specifying the metric or magnitude. The second technique is multi-layer representation: layer-wise supervision, self-distillation and aggregation of outputs from multiple layers can help produce better, more stable user representations. This returns to the earlier question of which transformer outputs should become the shared representation.

The third technique is long-context handling. Feng lists truncated sliding windows, sparse attention, training on progressively longer sequences and parallelization strategies. These methods address the cost of learning from extended histories: the objective is to use more of the available behavior efficiently, rather than treating context length as an isolated model setting.

11:2611:36
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:26 · section reference included

Three ways applications consume the foundation model

Before the foundation model, the personalization stack contained many independently developed features and models, each serving one or more applications. The shared model consolidates much of the data and representation layer, including both user and content representations. Application models remain, but become thinner layers built on top of the shared learning. One foundation model does not mean one identical serving path for every application.

The first consumption pattern embeds the pretrained foundation model as a subgraph inside a downstream neural network. An application that already has a sequence-transformer tower can replace that component with the pretrained subgraph. Learned content embeddings can also become embedding lookup layers. This lets an application reuse the model within its own computation graph.

The second pattern publishes content, entity and member embeddings to a centralized embedding store. Downstream consumers retrieve representations rather than integrating the foundation model itself. Member embeddings introduce two operational decisions: how frequently to refresh them and how to keep them stable. The store also broadens access beyond recommendation models, allowing analysts and data scientists to consume embeddings directly.

The third pattern extracts the model and fine-tunes it for a specific application. Where online latency is especially strict, distillation can produce a smaller serving model.

Consumption patternWhat the application reuses
Subgraph integrationPretrained computation and embedding lookups
Embedding storePublished member and content representations
Fine-tuning or distillationAn application-adapted model

These interfaces preserve specialization while avoiding the need to relearn the entire representation independently for every surface.

13:5114:03
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:51 · section reference included

Measure adoption separately from experiment wins

Feng describes application adoption and A/B-test wins accumulated over the preceding year and a half. His chart separates two quantities: blue bars count applications incorporating the foundation model; green bars count A/B-test wins. One application can produce multiple winning experiments, so those bars are not interchangeable measures of adoption. The discussion supplies no exact counts, effect sizes or experimental conditions.

Feng regards the combination of recommendation gains and infrastructure consolidation as validation of the original bet. Scaling improves the shared model, while centralizing learning makes its benefits available to multiple applications. The development benefit is concrete: a new application can fine-tune the foundation model to launch its first experience instead of assembling a full model from scratch.

16:0916:20
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

16:09 · section reference included

Represent heterogeneous entities and generate collections

At the time of the talk, the next directions extend both what the model represents and how applications adapt it:

  • Universal entity representations: Explore semantic IDs and related approaches so a shared representation can cover increasingly heterogeneous content types.
  • Generative collection retrieval: Generate a collection rather than recommend only an individual video. Multi-step decoding creates opportunities to incorporate business rules and diversity during generation.
  • Prompt tuning: Train soft tokens that can be swapped at inference time to change the foundation model’s behavior, enabling faster adaptation.

Feng presents these as research directions. In particular, soft-token prompt tuning is a promising approach the team is exploring, distinct from the deployed subgraph, embedding-store and fine-tuning consumption patterns.

Current Directions slide lists universal representation for heterogeneous entities, generative retrieval for entity collection recommendation, and faster adaptation through prompt tuning.Open full source frame
Current directions include universal representations, collection retrieval and prompt tuning.
17:1917:34
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

17:19 · section reference included

What transfers beyond the recommendation surface?

The audience first pushes the idea of shared preferences beyond entertainment recommendations, asking whether they might reveal purchasing choices or political opinions—even predict the next US president. After requesting clarification, Feng gives a narrower answer: Netflix is expanding across entity types and moving toward capturing tastes both on and off its platform. He does not confirm the speculative political-prediction capability.

A subsequent question asks where graph models and reinforcement learning fit, and whether they improve performance. Feng explains that a dedicated graph-model team works on a knowledge graph covering the entertainment ecosystem, including content both on and off Netflix. Embeddings from those graph models provide semantic information for cold start—the semantic complement to learned title IDs described earlier.

Reinforcement learning connects to collection generation. Feedback from user actions is sparse, but those rewards can guide how an entire collection is generated. Feng identifies this use for reward signals without giving a quantitative accuracy or performance improvement.

18:3618:56
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

18:36 · section reference included

Embeddings flow through the model—but not every source is integrated

The next question makes the embedding flow explicit. The unified model exposes its learned embeddings as features for downstream models, while also consuming upstream representations such as graph neural network embeddings. Centralized learning therefore sits between existing sources of semantic information and the applications that need personalized representations.

The final question asks how deeply the model reads the video itself: does it rely on interactions and metadata, or use individual frames and short clips? Feng says another Netflix content group already has relevant embeddings, but granular clip- or view-level representations have not yet been incorporated into this model. He expects movement in that direction. The boundary is practical: having an embedding somewhere in the organization is different from integrating it into the shared recommendation representation.

21:0621:13
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

21:06 · section reference included

Resources

Transcript download
Read the transcript and explore slides

Loading transcript and slides…