Netflix/Large Language Models

3 posts

netflix4 min readCurated summary

GenRec: Towards LLM-Native Recommendation at Netflix

GenRec is Netflix’s LLM-backed recommendation ranker, designed to reduce dependence on thousands of hand-engineered features. It verbalizes user history, item metadata, and context, then post-trains a Netflix-adapted foundation model for catalog-aware ranking and long-term member value. In large-scale A/B testing, it reportedly improved both short- and long-term metrics while using far fewer labeled examples and input signals than an established production ranker. ## Motivation for an LLM-Native Recommender - Netflix’s existing recommendation stack supports many content types and product surfaces but is costly to extend. - New use cases can require substantial feature engineering, architectural changes, infrastructure work, and experimentation. - LLMs offer: - Shared semantic representations for users, items, and interactions - Natural-language steering through prompts - Rich understanding of content and user histories - General-purpose LLMs are not production-ready on their own because they may: - Over-recommend globally popular titles - Hallucinate items outside the catalog - Ignore business constraints - Provide limited personalization ## Ranking Problem and Long-Term Utility - GenRec ranks the full Netflix catalog, or a provided candidate set. - It uses the user, interaction history, current context, and time to produce a personalized ranking. - The optimization target is expected long-term member utility—a proxy for satisfaction and retention—rather than only immediate clicks or plays. ## Two-Phase Training ### Netflix-Adapted Foundation Model - Netflix first adapts an open-source LLM using proprietary Netflix data. - The model learns: - Netflix content and metadata - Member behavior and preference patterns - General language understanding and generation - This relatively stable foundation can support multiple Netflix applications. ### GenRec Post-Training - A second training phase specializes the foundation model for recommendation. - It focuses on ranking quality, steering, reward alignment, and serving-cost constraints. - This phase is refreshed more frequently to reflect new content and changing member preferences. ## Interaction Data as Conversations - Hundreds of billions of events—including views, play duration, feedback, add-to-list actions, and abandons—are converted into single- or multi-turn recommender conversations. - Each user message includes verbalized: - Context and profile - Interaction history - Item metadata - The recommendation task - Assistant messages represent actual member behavior, such as titles played, viewing duration, or feedback. - During inference, GenRec uses the verbalized request and a catalog-aware scoring head; it does not generate conversational responses. - The conversational format mainly supports language-model training and comprehension of rich textual inputs. ## Context Engineering Instead of Feature Engineering - GenRec represents histories and context as natural language rather than relying primarily on dense, manually designed features. - The token budget becomes the new feature budget, so histories are selectively compressed: - Retain detailed, high-signal events such as long plays and thumbs-up - Remove low-signal events such as brief plays and hovers - Summarize repetitive behavior such as binge-watching - Add detail for important or cold-start items, including new releases - Recent and high-value interactions receive priority, while older information is compressed or dropped. - Prompt structure is also optimized for shared prefixes and prefix caching, reducing serving costs. ## Ranking, Language, and Reward Objectives - GenRec combines several training objectives: - **Catalog-aware ranking:** Uses high-value engagements as positive labels, applies denoising and thresholds, and trains the model with cross-entropy over the catalog or candidate set. - **Language modeling:** Preserves understanding of natural-language histories and metadata and supports potential future features such as recommendation explanations. - **Reward-weighted alignment:** Incorporates business requirements and longer-term satisfaction into training. - Reward signals can help balance content categories such as movies, series, games, live content, and podcasts instead of optimizing only immediate engagement. ## Serving and Results - GenRec runs in prefill-only mode on Netflix’s LLM serving infrastructure, avoiding the cost of decoding generated text. - A catalog-aware scoring head converts the model’s representations into item rankings. - Compared with a mature production ranker, GenRec achieved statistically significant improvements in short- and long-term online metrics. - It did so with a small fraction of the labeled data and input signals used by the existing system. GenRec suggests that recommendation systems can shift from extensive manual feature construction toward careful context engineering, LLM post-training, and reward alignment. The approach is most promising when paired with catalog constraints, efficient serving, and objectives that reflect long-term member value rather than raw engagement alone.

Read original(opens in new tab)
netflix4 min readCurated summary

Scaling LLM Post-Training at Netflix

Netflix argues that LLM post-training at production scale is as much an infrastructure challenge as a modeling challenge. Its internal framework abstracts distributed data processing, model sharding, GPU orchestration, checkpointing, and complex training workflows so developers can focus on experimentation. The result is a flexible system supporting SFT, DPO, reinforcement learning, and knowledge distillation across hundreds of GPUs. ## Why Post-Training Becomes an Engineering Problem - Pre-training provides general language ability, but post-training adapts models to Netflix’s catalog, member histories, recommendation tasks, personalization, and search. - Production-scale training introduces challenges involving: - Large proprietary datasets - Multi-node GPU coordination - Distributed model state - Workflows that combine training and inference - Failure recovery and experiment tracking - A simple Hugging Face fine-tuning script is insufficient for reliable, large-scale jobs. ## Preparing Data Correctly - Chat templates serialize conversations but do not determine which tokens should contribute to the loss. - Netflix applies explicit loss masking so training focuses on assistant responses rather than prompts or other non-target text. - Variable-length examples can waste GPU memory through padding and create synchronization overhead across FSDP workers. - Sequence packing combines multiple samples into fixed-length sequences. - A document mask prevents attention across separately packed samples while improving GPU utilization. ## Loading and Optimizing Large Models - Models that do not fit on one GPU require sharding strategies such as FSDP or tensor parallelism. - Partial weights should be loaded directly onto the device mesh rather than materializing the entire checkpoint on a single device. - Developers can choose full fine-tuning or LoRA and use: - Activation checkpointing - Compilation - Appropriate precision settings - Reinforcement learning requires compatible precision between rollout generation and policy training. - Large vocabularies create memory pressure because logits have dimensions `[batch, seq_len, vocab]`. - The framework reduces peak memory by removing ignored tokens before projection and computing logits and loss in sequence chunks. ## Distributed Training and Workflow Management - The framework supports standard forward/backward training for SFT as well as workflows that interleave: - Rollout generation - Reward-model and reference-model inference - Policy updates - Ray actors orchestrate distributed jobs while keeping hardware concerns separate from modeling code. - Experiment tracking covers both quality metrics, such as loss, and efficiency metrics, such as Model FLOPS Utilization (MFU). - Standardized checkpointing allows jobs to resume after failures. ## Netflix’s Post-Training Framework - The stack is built on: - Mako for AWS GPU provisioning - PyTorch, Ray, and vLLM - Netflix’s framework library for reusable utilities and training recipes - Jobs are generally defined through configuration files that select a recipe and provide task-specific components. - Unlike narrower fine-tuning systems, the framework supports: - Custom output heads - Expanded vocabularies and semantic IDs - Special tokens - Transformer models trained on non-natural-language sequences - This flexibility is important for Netflix-specific recommendation and personalization use cases. ## Four Core Abstractions ### Data - Dataset abstractions cover SFT, reward modeling, and RL. - Streaming supports datasets larger than local disk capacity. - Asynchronous sequence packing overlaps CPU preprocessing with GPU execution to reduce idle time. ### Model - The framework supports architectures such as Qwen3 and Gemma3, including Mixture-of-Experts variants. - LoRA is integrated into model definitions. - High-level sharding APIs distribute models across device meshes without requiring developers to write low-level distributed code. ### Compute - A unified job interface scales from one node to hundreds of GPUs. - MFU measurement remains accurate for custom architectures and LoRA configurations. - Checkpoints include parameters, optimizer state, dataloader state, and data-mixer state, enabling exact resumption. ### Workflow - The system supports SFT, DPO, RL, and knowledge distillation. - Online RL uses a hybrid architecture combining a single controller with Single Program, Multiple Data (SPMD) workers. - This extends conventional SPMD training to multi-stage workflows that cannot be represented as a simple training loop. Netflix’s approach is to standardize the difficult operational parts of post-training while preserving enough flexibility for unconventional models and objectives. A framework built around reusable data, model, compute, and workflow abstractions can help teams iterate faster and scale experiments without repeatedly rebuilding distributed infrastructure.

Read original(opens in new tab)
netflix3 min readCurated summary

The AI Evolution of Graph Search at Netflix

Netflix is evolving Graph Search from structured DSL queries toward natural-language search using large language models (LLMs). The goal is to let users describe what they want in everyday language while preserving the accuracy and trustworthiness required by Netflix’s complex, federated GraphQL data. Rather than replacing existing applications, Netflix plans to augment them with AI-generated filters and future retrieval-augmented generation capabilities. ## Why Natural-Language Search Is Needed - Graph Search currently relies on a Filter DSL, with applications translating UI interactions into structured queries. - Netflix has hundreds of applications with inconsistent query-building experiences, forcing users to learn different interfaces. - Some indexes contain hundreds of filterable fields, making large forms slow and cumbersome even for subject-matter experts. - Users naturally express goals in language such as “show all movies from the 90s about robots from the US,” not through query builders or DSL syntax. - Natural-language input could reduce friction while allowing each application to retain its own domain-specific presentation. ## Converting Text into Graph Search Filters - The core task is translating an ambiguous natural-language request into a valid Graph Search Filter DSL statement. - Graph Search indexes are defined through GraphQL queries containing typed fields, including booleans, strings, enums, and controlled vocabularies. - Generated filters can combine: - Comparisons such as `>` and `==` - Inclusion or exclusion operators such as `IN` - Logical operators such as `AND` - Netflix evaluates generated queries at three levels: - **Syntactic correctness:** The statement follows the DSL grammar and can be parsed. - **Semantic correctness:** The query uses existing fields, respects field types, and selects valid controlled-vocabulary values. - **Pragmatic correctness:** The filter accurately reflects the user’s intended meaning. ## Context Engineering for the LLM - The LLM needs index metadata to generate semantically valid filters. - Netflix derives much of this context from GraphQL schemas, including: - Field paths - Field descriptions from schema comments - Field types - Valid enum or controlled-vocabulary values - Controlled vocabularies define finite, governed sets of values, such as countries, and prevent generated queries from using invalid alternatives. - Supplying all metadata works for simple examples but does not scale: - Some indexes contain hundreds of fields. - Some vocabularies contain thousands of values. - Larger prompts increase latency and can reduce generation accuracy. - Netflix therefore needs ways to provide the LLM with relevant metadata without overwhelming its context, while still grounding generated queries in the actual schema and allowed values. Netflix’s approach combines schema-aware context, LLM-based query generation, and validation to make natural-language Graph Search practical. The key recommendation is to use AI as an augmentation layer over existing Graph Search applications, with strong grounding and correctness checks rather than treating generated queries as inherently reliable.

Read original(opens in new tab)