Netflix GenRec: How Netflix Taught an LLM to Recommend Movies

Netflix GenRec replaces Netflix's feature-engineered recommendation rankers with a large language model that reads raw member interaction histories, item metadata, and contextual signals as natural language prompts.

Instead of maintaining thousands of handcrafted features and bespoke model architectures across different surfaces, Netflix now passes verbalized interaction sequences into an LLM backbone with a custom catalog-aware scoring head, which turns the model's output into a score for every title in the catalog. The model then infers complex feature interactions and semantic relationships from the text itself.

To make an LLM work as a production ranker, Netflix GenRec post-trains a domain-adapted foundation model in two phases. Netflix structures member interaction logs into conversational user-assistant turns, optimizes the backbone with a combined ranking and language modeling objective, and scales the loss weights using long-term reward signals.

For online serving, GenRec skips slow autoregressive token generation entirely by running the model in prefill-only mode: the transformer reads the verbalized prompt in a single forward pass and produces a pooled context representation that scores the entire item catalog at once. Built this way, an LLM ranker beats Netflix's production ranker on accuracy while needing far less training data and far less operational machinery.

What was wrong with Netflix's old recommender?

Netflix's legacy recommendation architecture relied on thousands of hand-crafted dense and embedding features spanning user profiles, item catalogs, and interaction logs, and the production stack kept a whole web of specialized architectures alive to process them: Deep Learning Recommendation Model (DLRM) style feature interaction networks, two-tower models, custom attention blocks, and large multi-task setups.

All that fragmentation made every change slow and expensive. Onboarding a new content type (video games, podcasts, or live events) or adding a new product surface meant extensive manual feature engineering, architecture redesigns, pipeline modifications, and long experimentation cycles, and every new signal needed custom code to compute, store, and serve its features without data leakage.

Moving to one LLM backbone removes most of that structure. Instead of thousands of isolated pipelines, GenRec uses a shared language model and represents user history, item semantics, and request context directly as text. The transformer infers high-level feature interactions and temporal patterns from that verbalized input, so the complexity moves out of bespoke code pipelines and into managed prompt context. Note the verb: the complexity moves, and the context engineering section below shows where it lands.

Two training phases: from foundation LLM to ranker

Netflix GenRec is easy to confuse with the personalized recommendation foundation model Netflix described in March 2025, but the two are built differently. That earlier system worked directly on raw member logs, with BPE-style (byte-pair encoding) interaction tokenization, multi-token prediction objectives, sparse attention layers, and sliding window sampling over event sequences. GenRec, by contrast, is an LLM-backed ranker built by adapting a general-purpose text-based decoder-only transformer through a dedicated two-phase lifecycle.

Phase 1 adapts an open-source base LLM on proprietary Netflix corpora to produce a shared, Netflix-aware foundation model. Here the network learns Netflix catalog metadata, member behavior patterns, and domain language while keeping its general language and instruction-following skills. Because Phase 1 is about broad foundations, it runs at a lower update cadence and is less constrained by downstream serving costs.

Phase 2 is high-cadence post-training on recommendation-specific ranking data in a conversational user-assistant format. Raw member interaction logs (plays, view durations, thumbs up/down, watchlist additions, and abandons) are structured into single-turn or multi-turn conversations, where the user message carries verbalized context, profile information, user history, item metadata, and a task prompt, while the assistant message reflects what the member actually engaged with.

During Phase 2, the model is optimized with a joint training objective that combines a catalog-aware ranking loss (L_ranking), a language modeling loss (L_language), and auxiliary task losses (L_miscellaneous):

text

L = α · L_ranking + β · L_language + γ · L_miscellaneous
subject to  α + β + γ = 1,  α, β, γ ≥ 0

The ranking loss trains the scoring head to put high-value engagements at the top across the item catalog, while the language modeling loss preserves the backbone's textual capabilities, its natural language understanding, and its responsiveness to prompt-based recommendation steering. The miscellaneous term covers other objectives where applicable, and the hyperparameters α, β, γ are tuned through offline experiments. Keeping the language loss is the choice I find most telling, because without it nothing in training would protect the prompt-based steering that justifies an LLM backbone in the first place.

Context engineering replaces feature engineering

In an LLM-backed recommendation ranker, the prompt is the primary feature budget. Input verbalization turns raw interaction histories, item metadata (such as titles, genres, synopses, and release dates), and request-time context (such as device type, UI surface, locale, and time of day) into natural language. Because context length directly drives GPU memory use and inference latency, building the prompt takes deliberate context engineering to pack as much signal as possible into a strict token budget.

To manage token consumption without sacrificing ranking quality, GenRec applies four strategies. High-signal engagement events, such as long-duration plays and explicit thumbs-up feedback, are kept in full with detailed textual metadata, while low-signal or noisy events, such as quick hovers or brief plays below a defined duration threshold, are dropped from the prompt entirely. Repetitive actions, such as binge-watching several consecutive episodes of a series, are compressed into compact session summaries. And cold-start items or new catalog releases with little interaction history get selective elaboration, with expanded metadata descriptions to make up for the missing collaborative signal.

Prompt ordering is tied directly to the serving infrastructure. Netflix structures the prompt to maximize shared prefixes, so vLLM's automatic prefix caching can hash prefix token blocks and let incoming requests with identical prefixes reuse pre-computed KV-cache blocks (the attention keys and values already calculated for those tokens). The team also sweeps the number of retained historical events to find the "elbow point" where more history yields diminishing returns in offline Mean Reciprocal Rank (MRR, a score that rises the closer the title a member actually engages with sits to the top of the ranking), which buys the most accuracy for the smallest serving footprint. That is where the complexity from the old stack went: deciding which hovers to drop and where the elbow sits is still feature engineering, just written as prompt rules instead of pipeline code.

Rewarding long-term satisfaction, not just the next play

Train a ranker purely on raw interaction logs and it risks turning myopic, favoring immediate clicks, repetitive binge-watching, or globally popular content over long-term member discovery. To align recommendations with broader business objectives and member retention, GenRec builds multi-objective reward signals directly into training through a reward-weighted ranking loss, in which scalar loss weights scale each training example by its estimated value.

Those weights come from two categories of reward signals, produced by auxiliary reward models:

Long-term satisfaction proxies: Signals that estimate how strongly an immediate interaction correlates with long-term member retention, cross-catalog exploration, and sustained return behavior over time.
Behavior rebalancing: Reward adjustments that change exposure across content types (movies, series, games, live events, podcasts) and launch stages (new releases versus evergreen catalog titles) to better match business goals.

Instead of adopting a full reinforcement learning algorithm like Group Relative Policy Optimization (GRPO), GenRec sticks with this reward-weighted supervised loss, which gets effective behavioral alignment without the higher computational overhead and training instability of full reinforcement learning. For a ranker that is post-trained at high cadence, I think that is the right trade, since reward weighting changes the loss rather than adding a new training loop.

Ranking without generating text: the scoring head and prefill-only serving

Netflix GenRec ranks the full catalog without generating any text token by token during inference. The pipeline runs in three stages:

A verbalizer V maps interaction history H, catalog metadata M_i, and request context τ into an input text sequence x = V(H, {M_i | i ∈ C}, τ).
The decoder-only Transformer backbone processes x and extracts a pooled hidden state h at a designated token position, summarizing user context and preferences into a d-dimensional vector.
A catalog-aware scoring head φ combines h with learned d-dimensional item embeddings e_i to generate ranking scores s_i = φ(h, e_i) across all catalog items in a single forward pass.

To score candidate items efficiently, GenRec uses prefill-only inference, because standard autoregressive decoding (generating item titles token by token) is far too slow and expensive for high-throughput ranking over large candidate sets. In prefill-only mode, the LLM processes the input prompt once during the prefill pass, extracts the pooled state h, and evaluates the scoring head across candidate items simultaneously, so it never pays token generation latency or cost. Training has its own scaling problem: for very large catalogs a full softmax becomes compute-prohibitive, so GenRec applies sampled-softmax over candidate subsets, which keeps compute in check while maintaining ranking precision.

Serving runs on Netflix's internal LLM stack, built on vLLM. The system uses automatic prefix caching, which hashes shared prompt prefixes to reuse precomputed KV-cache blocks across incoming requests, and together with smaller or distilled backbone models this lets GenRec serve high-volume workloads within compute budgets. Of everything in the design, this is the part I'd copy first: an LLM that only reads and scores is a very different serving problem from an LLM that writes.

How much better is GenRec, really?

Offline, GenRec beats Netflix's mature production ranker while using far less data. On ranking metrics it achieves a +1.6% relative lift in MRR over the production baseline with ~40× fewer Phase-2 labeled training examples (and between 10–40× fewer across various configurations). The +1.6% looks modest, but it is measured against a mature system, and the label count is the number I'd pay more attention to. Ablation studies separate the contribution of each training phase: initializing from the Phase-1 Netflix-adapted foundation LLM gives a +10–20% MRR improvement over an off-the-shelf open-source base model, and Phase-2 post-training adds a further +35–50% MRR gain over a freshly trained Phase 1 backbone. Because Phase 1 updates less often, that gap widens to an ~80% relative gain after 2 weeks as the Phase 1 model goes stale against shifting content popularity trends.

The offline gains carried over to live traffic. In a large-scale online A/B test on batch-compute recommendation surfaces covering ~10% of Netflix traffic over 4 weeks, GenRec achieved statistically significant gains over the production baseline. In a low-data, low-signal configuration, the model yielded +0.115% on a short-term homepage engagement metric and a +0.006% relative lift on the long-term core metric, a gain that is statistically meaningful at Netflix scale. Next to the offline MRR figures those numbers look tiny, which is worth remembering before anyone quotes the +35–50% as if it were what members see: that figure compares Phase 2 against Phase 1, not GenRec against the production ranker.

GenRec also got much cheaper to serve as its prompts shrank. By applying context engineering to drop low-signal events, compress binge sessions, and tighten verbalized prompts, Netflix's engineers compacted input sequences from ~5,000 tokens down to ~1,700 tokens, reducing the context budget to roughly 1/3 of its original size. Because serving costs in prefill-only inference scale proportionally with prompt length, this token compaction cut serving cost to roughly 1/3 of the original with negligible loss in offline MRR.

What AI engineers can take from GenRec

The lesson I'd take from Netflix GenRec is narrower than "put an LLM in your recommender." Its accuracy and data-efficiency gains only fit a ranking budget because the model never generates text: one prefill pass through a single backbone, plus a catalog-aware scoring head, scores the whole catalog at once. If you build an LLM ranker, treat the prompt as your feature set, because the cut from ~5,000 to ~1,700 tokens is what brought serving cost down to a third, and deciding what stays in those tokens is the feature engineering you still have to do.