AI Engineer World's Fair 2025
One model to rule recommendations: Netflix's Big Bet
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.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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:
| Question | Information 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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 pattern | What the application reuses |
|---|---|
| Subgraph integration | Pretrained computation and embedding lookups |
| Embedding store | Published member and content representations |
| Fine-tuning or distillation | An application-adapted model |
These interfaces preserve specialization while avoiding the need to relearn the entire representation independently for every surface.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Further reading
Original DeepSeek report describing its language-model architecture and multi-token prediction training objective.
Research on predicting several future tokens with independent output heads sharing a model trunk, cited by Netflix's companion article.
Read the transcript and explore slides
Loading transcript and slides…