1 Introduction↩︎

Large language models (LLMs) have demonstrated a powerful paradigm: a single generative transformer can perform diverse tasks by generating a response to a prompt. More broadly, they have reshaped how we think about machine learning systems: a sufficiently expressive model trained end-to-end can often reduce the need for manually engineered representations and features.

Traditionally, recommender systems have been built as multi-stage pipelines—candidate generation, ranking, and re-ranking—with each stage optimized separately [1], [2]. Constructing a homepage like Netflix’s adds further complexity: the output is not a single ranked list but a structured layout of rows and the entities within each row, historically assembled by many specialized models (e.g., separate models for rows and entities).

In this paper, we present GenPage, an end-to-end generative approach to Netflix homepage construction. Instead of building homepages through a multi-stage pipeline of specialized models and extensive feature engineering, we train a single generative model to answer a simpler, more direct question:

We treat the user and request context as the prompt, and generate the entire homepage autoregressively as the response. This shift is motivated by several aspirations:

• End-to-end modeling. A single transformer that consumes raw input signals can replace a complex multi-stage recommender stack. This reduces the number of ML models to maintain, avoids misaligned objectives across stages, and eliminates much of the traditional feature engineering.

• Better scaling behavior. Model quality improves with more data, compute, and model capacity, without redesigning the system.

• Whole-page optimization via reinforcement learning (RL). Operating at the page level enables RL with page-level rewards that capture interactions across rows and entities, such as diversity or balancing rows with differing stopping power—how strongly a row or entity captures attention and stops the user from browsing further.¹ This aligns recommendations with user satisfaction and business objectives more directly than the entity-level objectives (e.g., movie or show level) used by most traditional recommender systems.

• Flexibility and extensibility. The prompt-response paradigm is flexible by design, lowering the barrier for new product features. By simplifying feature engineering and enabling whole-page optimization, it becomes easier to support new content types (e.g., live events, games, podcasts), new layouts beyond the current 2D structure, personalized UI components, and per-entity artwork personalization without major architectural changes.

Bringing GenPage into production at Netflix also requires addressing several challenges specific to industry-scale recommender systems. Because our homepage is generated in real time, users are sensitive to serving latency, making it a primary engineering constraint. We also need to handle entity cold start in a constantly evolving catalog, keep the model fresh as trends shift, and enforce complex business rules on the generated output.

Despite these challenges, GenPage has already had substantial production impact. We validated the weighted binary classification (WBC) post-training variant in an online A/B test against a mature, highly optimized multi-stage production recommender on the Netflix homepage. It delivered a \(+0.24\%\) lift on the core user engagement metric we use for launch decisions (\(p < 0.001\)), while reducing end-to-end serving latency by \(20\%\). Our RL-based post-training has not yet shipped online, but we view it as the key path to realizing GenPage’s full vision.

Concretely, this paper makes the following contributions:

• We formulate the construction of structured, multi-row personalization surfaces as an end-to-end generative sequence modeling problem, in which a single transformer directly generates the entire page. This problem is shared by many industry-scale recommenders, such as Netflix’s homepage, Amazon’s homepage, and Spotify’s home shelves, where the output is a structured layout of rows or modules whose elements interact—for example, balancing rows and entities of differing stopping power, or maintaining diversity across the page—so the page must be optimized as a whole, subject to product constraints. This contrasts with prior work on generative recommendation [3]–[10], which generates a flat (ranked) list of items.

• We adapt the LLM training recipe to this setting: pretraining on positively engaged production pages to learn the “language” of homepage construction, followed by post-training via weighted binary classification (WBC) or reinforcement learning (RL) to align the pages with user satisfaction. WBC trains the model to estimate the immediate value of each token while still decoding the full homepage autoregressively; RL optimizes the policy against a page-level reward model trained directly from organic user engagement on each page—in contrast to the pairwise human preferences typical of LLM RLHF [11], [12].

• We present a set of techniques tailored to industry-scale generative recommendation: a custom tokenization for serving efficiency and product control; context injection and semantic embedding fusion for entity cold start; multi-cadence incremental training for model freshness; constrained decoding for business-rule enforcement; and hybrid row decoding for further latency and cost reduction at inference time.

• We report offline experiments characterizing the role of pretraining, model scaling, context richness, and RL post-training. Two findings stand out: enriching the prompt yields a larger improvement than scaling model capacity in our current regime, and RL post-training increases homepage diversity even though diversity is not part of the objective.

• We validate GenPage in an online A/B test against the production homepage recommender at Netflix, demonstrating that it can outperform a multi-stage production stack on both user engagement and serving latency.

We expect this approach to generalize to many personalization settings. We focus on Netflix homepage construction as a concrete case study, sharing our design, trade-offs, and lessons learned.

2 Data↩︎

Transitioning from a traditional recommendation model to a generative transformer requires a fundamental shift in data representation. Just as an LLM represents text as a sequence of tokens, our approach represents the Netflix experience—user context and the resulting homepage—as a unified sequence of discrete tokens (Figure 1). The homepage itself—an entire structured, multi-row layout—lives within this token sequence, allowing the model to generate the page as a whole rather than scoring rows and entities independently.

Each training example represents a homepage impression and consists of three components:

• Context: user engagement history, profile attributes, and request context.

• Page: the recommended rows and entities shown on the homepage in layout order.

• Feedback: user interactions with that page, such as play, thumbs-up, or abandonment for entities on the page.

Only Context and Page are tokenized as model inputs and outputs. Feedback is used to derive supervision signals via our internal reward system (Section 3).

Instead of using an off-the-shelf text tokenizer, we build a domain-specific tokenizer for the homepage construction data, a proven approach in recommender systems [13] and other specialized domains such as computer vision [14], biology [15], and chemistry [16]. This choice provides two key advantages over generic text tokenization:

• Computational efficiency. Custom tokenization significantly reduces sequence length, thus lowering inference cost and latency. For example, representing the event “User watched Orange is the New Black for 50 minutes 30 days ago.” would require 16 tokens in GPT-5, whereas our scheme compresses it to 4 tokens: [Entity_ID], [Action_Type], [Action_Time_Bucket], and [Action_Duration_Bucket].

• Product control. A direct mapping between tokens and product concepts (e.g., rows and entities) makes it straightforward to control what we generate—a crucial capability for enforcing business rules (Section 6.3).

2.1 Context Tokens↩︎

Context tokens encode user engagement history, user profile, and request context.

User history is represented as a sequence of tokenized actions [13], [17], [18]. For each action, we extract key metadata as tokens, such as action type, entity ID, timestamp, and duration. We include both explicit actions (e.g., play, add to My List, thumbs-up) and implicit signals (e.g., trailer views, visiting a details page).

User profile tokens capture attributes such as language and profile type. Request context tokens encode signals like time of day, day of week, and device.

Some data sources are too long to convert directly into a raw token sequence. A user’s full impression history, for example, would be prohibitively expensive to tokenize in full. In such cases, we tokenize a summarized version. This partially undercuts our goal of operating on raw inputs: any handcrafted summary reintroduces a form of prompt engineering into an otherwise end-to-end pipeline. A key direction for future work is to learn to compress these long sources end-to-end, avoiding this prompt engineering.

To help the model distinguish between data sources, we insert special tokens that mark the start of each source segment. Continuous signals (e.g., timestamps, durations) are bucketized into discrete ranges to maintain a finite vocabulary.

2.2 Page Tokens↩︎

Each entity (e.g., show, movie, game) and each row (e.g., Korean TV Shows) is represented as a single token. The homepage is tokenized in layout order: left to right, top to bottom. We update the entity and row vocabulary daily to incorporate newly added entities and rows. Entities still out of vocabulary at serving time are handled via semantic embedding fusion (Section 6.1) and fallback tokens (Section 6.2).

In principle, the same paradigm extends to any output that can be expressed as a linear token sequence: layouts beyond the current 2D structure (e.g., one-dimensional feeds or mixed layouts), personalized UI components, or per-entity outputs such as personalized artwork. We leave these extensions to future work.

2.3 Paginated Recommendation↩︎

To make recommendations responsive to in-session user preferences, the homepage is often generated incrementally, a few rows at a time. Before each pagination request, we append the page tokens from previously recommended rows to the prompt, along with the latest user engagements on those rows, derived from Netflix’s real-time event-logging infrastructure. This allows the model to generate the next set of recommendations using both the user’s long-term preferences and their most recent in-session engagements.

3 Reward System↩︎

To quantify the long-term value of a recommendation, we rely on an internal reward system described in prior work [19]. This reward system is tuned through online A/B testing to align with long-term user satisfaction and serves as the core supervision signal for both supervised and reinforcement learning.

The reward system processes user feedback and outputs a scalar reward for every impressed entity on the homepage. For instance, a TV show binge-watched in one night reflects higher user satisfaction and receives a higher reward than a movie watched for only 10 minutes. An impressed but abandoned entity receives a negative reward.

We define the page-level reward as the sum of rewards across all impressed entities on the homepage.

4 Model Architecture↩︎

To process data represented as sequences of tokens, we adopt a standard decoder-only transformer architecture [20] used in advanced LLMs for its simplicity, flexibility, and broad ecosystem support.

We untie the input embedding and output projection weights [21], [22]. The optimal logit scales differ substantially between next-token-prediction pretraining (which optimizes a softmax over the vocabulary) and WBC post-training (which optimizes per-token sigmoids); see Section 5 for both. Untied weights let the model adapt to each objective.

For our first rounds of online A/B tests, we use a \(\sim 200\)M-parameter model to ensure we stay within our serving latency budget. The offline scaling trends (Section 7) suggest further quality improvements are available as inference optimizations create latency headroom.

5 Training Recipe↩︎

Our training pipeline mirrors the LLM recipe: we first teach the model the “language” of the Netflix homepage through pretraining, then align its outputs with user satisfaction through post-training. For post-training, we explore two alternative approaches: weighted binary classification (WBC) and reinforcement learning (RL). WBC is simpler to optimize and aligns directly with the entity-level objectives of our production ranking models. RL is harder to evaluate and optimize, but it is the key path to GenPage’s full vision of page-level optimization, with the flexibility to incorporate test-time reasoning and multi-token entity representations.

5.1 Pretraining via Next-Token Prediction↩︎

We pretrain the model with a standard next-token-prediction objective: given the context tokens and a prefix of page tokens, the model learns to predict the next page token. This stage focuses on representation learning, teaching the model the relationship between user contexts and successful homepages. Note that our (context, page) data resembles the prompt-response pairs used in LLM supervised fine-tuning (SFT) more than the raw text used in LLM pretraining; we nonetheless call this stage pretraining because we train the model from scratch rather than fine-tuning from an existing checkpoint.

Whereas LLMs often face scarce high-quality labeled data, we have an abundance of user feedback data. For pretraining, we use homepage impressions that received positive user feedback when served in production, bootstrapping the model to generate pages similar to those produced by the production system.

However, pretraining largely mimics the existing production model, and training recursively on self-generated data without external feedback risks model degeneration [23]. Furthermore, pretraining does not directly optimize the magnitude of the reward. To address these limitations, we explore two post-training approaches.

5.2 Post-Training via Weighted Binary Classification↩︎

One effective approach to aligning the generative model with fine-grained user satisfaction is weighted binary classification (WBC). At a high level, WBC trains the model to predict the immediate value of generating the next entity or row, while still decoding the full page autoregressively. This entity-level objective is easier to optimize than page-level RL: by decomposing the page into per-token targets, WBC assigns credit at the token level by construction rather than requiring RL to learn it.

Concretely, the model predicts this value per token, conditioned on user context and the preceding generated tokens, rather than learning an explicit generation policy. This entity-level training is enabled by our custom tokenization (Section 2): each entity and row is a single token, giving a direct one-to-one correspondence between per-token model outputs and per-entity (or per-row) rewards.

Recall that each training example is a homepage impression. For every impressed entity on the page, our reward system provides a scalar reward based on user feedback on it; for each impressed row, we derive a row-level reward by aggregating the rewards for the entities in the row. From each reward, we derive a binary label from the sign (e.g., play vs.abandonment) and a weight from the magnitude (e.g., binge-watching receives higher weight than short-play). We then optimize a weighted binary cross-entropy loss on the logit for the corresponding token. In this setup, the logit for a token can be interpreted as the model’s value estimate for generating that token at that position.

For each impressed entity and row target, we additionally sample random tokens as negative targets. Because rarely-impressed tokens are drawn as random negatives far more often than they appear as positives, this injects a mild pessimism [24], [25]—effectively a popularity prior—into their learned values, and prevents the model from confidently surfacing niche entities whose high scores would otherwise be dominated by noise.

Despite being trained as a value predictor, the model can still generate pages autoregressively. At each step, it computes the values (logits) for all candidate tokens, greedily selects the one with the maximum value, and appends it to the prefix. This process repeats token by token to generate the entire homepage.

On our standard held-out evaluation set for production ranking models, the WBC-trained generative model outperforms our production rankers on key entity-level metrics such as weighted AUC. This demonstrates that an end-to-end generative formulation can match or exceed a multi-stage production stack on standard entity-level offline metrics.

5.3 Post-Training via Reinforcement Learning↩︎

Reinforcement learning (RL) is the post-training direction we are actively exploring. While WBC is effective at optimizing entity-level metrics, it cannot consider the homepage as a whole. By treating page generation as a sequential decision-making process, RL enables whole-page optimization with the flexibility to support several useful extensions:

• Whole-page optimization. RL directly optimizes an aggregate page-level reward, accounting for interactions across rows and entities—such as diversity, or balancing rows and entities of differing stopping power—as well as page-level business constraints.

• Test-time reasoning. Analogous to its application in LLMs, RL can optimize reasoning capabilities for generative recommendation [26], [27]. Reasoning outputs can also be viewed as a form of automated feature engineering.

• Multi-token entity support. With our custom tokenization, each entity and row is a single token, so the per-entity reward maps directly onto that one token and credit assignment is immediate. In a more complex catalog, however, a single entity may be represented by multiple tokens (e.g., [Show_ID] + [Episode_#] for an episode within a show, or multi-token semantic IDs [3]). In that case it is unclear how to distribute the single entity-level reward across the constituent tokens, so WBC’s per-token labeling breaks down. RL instead optimizes the sequence-level return, so it handles variable-length, multi-token entities naturally.

Of these, only whole-page optimization is explored in this paper; test-time reasoning and multi-token entity support are part of the motivation for adopting RL but are directions for future work.

Inspired by the RLHF [11], [12] recipe used to align large language models, we adopt a two-step approach: we first train a reward model that predicts the page-level outcome reward from a generated page. This reward model is distinct from the reward system of Section 3: the reward system converts observed user feedback into a scalar reward for a page that was actually shown, whereas the reward model predicts the page-level reward for a generated page before it is ever shown to a user. This prediction is what lets RL optimize against arbitrary candidate pages during training. Training against a reward model avoids the high variance of off-policy correction on logged or predicted propensities [28], but introduces the risk of reward hacking. Since the reward model is trained on data generated from the production policy, it is most reliable on pages similar to those the production policy generates. We therefore use a KL penalty to keep the policy close to the pretrained checkpoint, which itself was trained to mimic the production policy. This keeps the pages within the reward model’s region of coverage and limits opportunities for reward hacking.

For the RL algorithm, we adopt Dr.GRPO [29], a variant of GRPO [30] that mitigates biases in the training objective. We build our training pipeline using the verl RL library [31], with vLLM [32] as the inference engine. To train the model within this framework, we need the following components:

• Prompts: Production user requests, represented by context tokens.

• Policy and reference models: Both are initialized from the pretrained checkpoint; the reference model anchors the KL penalty discussed above.

• Reward model: A dedicated transformer-based reward model, also initialized from the pretrained checkpoint, predicts the page-level outcome reward, using the sum of entity-level rewards from our internal reward system as the supervision target. We also incorporate rule-based format rewards to guide the RL policy. For example, the page should resemble a list of rows, and business-critical rows or entities should not appear too low on the page.

Open Challenges↩︎

Unlike LLM RLHF, which relies on scarce, human-labeled pairwise preference comparisons over unstructured text responses, our setting has direct user feedback at the entity and row level on a structured page. Fully leveraging this richer, structured signal raises two related challenges. (1) Offline evaluation: our current page-level evaluation relies on a reward model the policy is also optimizing against, making it largely circular. Human labels—a common alternative in LLM evaluation—are also problematic, since each user’s preferences depend on personal context that third-party labelers cannot replicate. Candidate directions include dedicated held-out reward models, rule-based evaluations, and counterfactual estimators [33]–[35]. (2) Decomposition vs.joint modeling: WBC and page-level RL sit at opposite extremes: WBC fully decomposes the page into entity-level optimization (simplifying optimization but losing some interactions across rows and entities), while page-level RL optimizes the entire page jointly without structural decomposition (capturing all interactions across rows and entities but harder to optimize and less sample-efficient). Middle grounds that exploit partial structure—mixed objectives, structured policy parameterizations, or assumptions from user behavior models (e.g., click models [36] or choice models [37])—are promising.

6 Addressing Production Challenges↩︎

6.1 Cold Start↩︎

New entities lack the rich interaction data needed to learn robust token embeddings. We address this through two complementary strategies:

• Context injection. We inject metadata about new or time-sensitive entities (e.g., Live Now events) directly into the context tokens, providing the model with semantic and time-sensitive information.

• Semantic embedding fusion. Rather than relying solely on entity ID embeddings learned from user interaction data, we represent each entity as a fusion of its ID embedding and a content-based embedding derived from semantic information such as synopses, cast, transcripts, genres, and video content. This fused embedding serves as the input embedding for the entity’s token in the transformer. During training, with small probability, we randomly replace an entity ID token with the generic fallback token (Section 6.2), so the model learns to make recommendations from the content-based embedding alone. This ensures that a new entity has a meaningful representation in the same latent space as established entities as soon as its content metadata is available, even before it has any interaction data.

6.2 Multi-Cadence Incremental Training↩︎

At Netflix scale, daily retraining of a large transformer from scratch is prohibitively expensive, but recommendation models must remain fresh to capture shifting trends and new catalog additions. We address this with a multi-cadence incremental training strategy (Figure 2).

Our training pipeline operates on a cyclic schedule with two distinct rhythms. At a tunable cadence, we conduct a large-scale pretraining and post-training pass on data from a broad historical window. Between these passes, each day we perform an incremental update by continuing post-training from the previous day’s checkpoint, using a mix of the latest day’s data and a sampled subset of past data. This helps the model stay current with new trends and catalog changes while preventing overfitting and catastrophic forgetting [38].

To manage the daily influx of new tokens (e.g., new entities, rows), we employ fallback tokens. New tokens are initialized using fallback tokens of their type (e.g., [Row_Fallback_Token] for new rows, [Entity_Fallback_Token] for new entities). During training, we randomly replace a small percentage of known tokens with fallback tokens, teaching the model to handle unknown tokens gracefully.

6.3 Enforcing Business Rules↩︎

A Netflix homepage must satisfy structural constraints (e.g., organized as a list of rows) as well as product logic such as deduplication, row pinning, and category consistency (e.g., entities in a Comedy row must be comedies). While training signals can encourage rule adherence, they cannot guarantee strict compliance.

We enforce these rules at inference time through constrained decoding. At each autoregressive generation step, we compute a mask of eligible tokens based on the applicable business rules and apply it to the output logits, allowing only rule-compliant tokens to be generated. This is greatly simplified by our custom tokenization (Section 2): because each entity and row is a single token, business rules map directly to token-level masks, avoiding the multi-token bookkeeping that constrained decoding requires over a text vocabulary. For example, to pin a specific row (e.g., popular games) at a fixed position (e.g., row position 2), we simply mask out all other tokens at that position.

6.4 Hybrid Row Decoding↩︎

Autoregressive generation ensures that each newly generated token is conditioned on the full preceding context, but generating every entity token one at a time can be expensive. We leverage the structure of the homepage to balance inference efficiency with the amount of contextual information available to each generated token.

Within each row, the first few entities are especially important: they receive the most user attention and strongly shape the row’s perceived quality and theme. To reduce inference latency, we use a hybrid row decoding strategy. The model autoregressively generates only the first few entities in each row. Conditioned on this generated prefix, we obtain logits for all eligible entities in a single forward pass and select the top-scoring remaining entities, subject to the same inference-time business-rule constraints described above.

This approach preserves autoregressive conditioning where it matters most while avoiding the latency and cost of decoding long rows token by token.

7 Offline Experiments↩︎

No public dataset captures structured homepage construction with user engagement at the row and entity level, so all evaluations use Netflix internal data. We present ablations characterizing how different components of GenPage affect model quality. Because the system was developed iteratively, individual ablations span different training configurations and data snapshots, so we report only relative comparisons within each study. Unless otherwise noted, experiments use \(\sim 200\)M-parameter models and report results on a held-out evaluation set. We focus on metrics and findings most relevant to practitioners.

7.1 Does pretraining help?↩︎

We compare WBC post-training with and without a preceding next-token-prediction pretraining stage. Table 1 shows that pretraining yields substantial improvements across all metrics. The gains may look small in absolute terms, but they are large in our production regime: setting aside the sample weighting, an Entity AUC lift from \(0.91\) to \(0.92\) means that for a randomly drawn pair of impressed entities, the model’s misranking rate drops from \(9\%\) to \(8\%\)—a magnitude of improvement we rarely observe from a single change on a mature production system. Pretraining the model on the “language” of the Netflix homepage provides a strong initialization for post-training, mirroring the pretrain-then-post-train recipe behind modern LLMs.

7.2 How does the performance scale with model size?↩︎

We sweep model size from \(\sim 120\)M to \(\sim 900\)M parameters (Figure 3) and report the next-token-prediction loss from pretraining and the WBC loss from post-training. Both losses decrease in a power-law-like fashion, mirroring the scaling trends seen in LLMs [39], [40]. This confirms that the generative approach scales favorably with model size, suggesting that recommendation quality can be further improved by scaling capacity.

7.3 How does the performance scale with information in user context?↩︎

Over the course of development, we progressively enriched the prompt, both by adding new data sources to the context and by refining how each source is tokenized. With model size held fixed, Figure 4 shows that the WBC post-training loss decreases substantially as the context is enriched.

The model-size sweep and the context-enrichment sweep span different axes and are not strictly comparable: the model-size study covers roughly an order of magnitude in parameters, while the context study spans the full trajectory of our prompt design. Even so, the gap between the two is striking. Scaling the model from \(120\)M to \(900\)M parameters reduces WBC loss by roughly \(1.3\%\), whereas the cumulative effect of enriching the context is around \(6.9\%\). In several cases, a single well-designed context addition delivers a larger improvement than the entire \(\sim 7.5\times\) model capacity scaling.

This suggests that, in our regime, enriching the prompt—both what we put in the context and how we tokenize it—yields a substantially larger improvement than scaling model capacity. Personalization quality appears to be bottlenecked first by the information and representation available to the model, and only then by capacity. We expect context enrichment to dominate until the context is saturated, at which point model capacity becomes the primary driver.

7.4 Does RL post-training optimize at the page level?↩︎

In offline evaluations (Figure 5), RL post-training consistently improves the page-level reward over the pretrained checkpoint, but this is largely confirmatory: the reward is computed using the same model the policy is optimizing against. More interestingly, although diversity is not part of the RL objective, homepage diversity—measured via pairwise embedding distance among entities on the page—also increases over the course of training. This suggests that the RL-trained policy is optimizing the page as a whole rather than myopically optimizing each token in isolation.

8 Online Evaluation↩︎

We conducted an online A/B test against the current production homepage recommender using a \(\sim 200\)M-parameter WBC model. In this test, GenPage decoded over the existing production row and entity candidate sets, which help handle many business rules (e.g., eligibility). We evaluate only the WBC variant online; scaling RL training to our data volume, refining the page-level reward model, and strengthening its offline evaluation are ongoing, and we plan to evaluate RL post-training in subsequent A/B tests.

Figure 6 shows the result: all five variants delivered statistically significant improvements on the core user engagement metric we use for launch decisions (\(p < 0.001\)) against a mature, highly optimized multi-stage production baseline. The best variant delivered a \(+0.24\%\) lift (95% CI \([0.17\%, 0.30\%]\)). The variants explored different amounts of random negatives (Section 5.2) and different filters on which production impressions to include in training; that all five delivered comparable lifts suggests the gain is robust to these design choices rather than dependent on a particular configuration.

Alongside the engagement wins, we observed unintended shifts in the distribution of impressed entity categories (e.g., new vs.established titles, TV shows vs.movies). These shifts are not necessarily negative, but they are not something we explicitly optimized for, and they warrant deeper investigation. We suspect these shifts reflect GenPage personalizing more precisely than the production stack — consistent with an increase in homepage impression efficiency, i.e., members engaging with what they saw using fewer impressions. This sharper personalization appears to surface production-inherited components (such as the reward system) that aren’t yet aligned with the new generative paradigm. We plan to characterize the drivers of these shifts and, where appropriate, tune these components so the resulting distributions better align with desired product behavior.

We also observed strong responsiveness to in-session signals: the latest in-session actions (Section 2.3) quickly influenced subsequent recommendations and faded back to long-term preferences after a day or two, confirming that the model effectively attends to action timestamps. This responsiveness emerges naturally from the generative formulation, without the extensive manual feature engineering used in our production stack.

Contrary to the common assumption that generative models are slower, GenPage reduced end-to-end serving latency by \(20\%\) relative to the baseline. By replacing multiple ranking stages and heavy feature computation with a single transformer model operating on raw tokenized inputs, we eliminated substantial serving complexity and computational overhead. Custom tokenization and hybrid row decoding further reduced the number of decoding steps and thus latency. The \(20\%\) reduction was achieved without exhausting the available optimizations; further reductions are possible. This headroom can be reinvested in capacity or richer prompts.

9 Conclusion↩︎

We presented GenPage, an early step toward end-to-end generative Netflix homepage construction: representing user context as a tokenized prompt and generating the entire homepage autoregressively in real time. This collapses the traditional multi-stage recommender stack into a single transformer that can be optimized end-to-end.

In online A/B tests against a mature, highly optimized multi-stage production system, GenPage delivered a \(+0.24\%\) lift on the core user engagement metric we use for launch decisions (\(p < 0.001\)), while reducing end-to-end serving latency by \(20\%\). Achieving this required adapting the LLM training recipe—pretraining followed by WBC or RL post-training—together with a set of domain-specific techniques: custom tokenization for serving efficiency and product control, context injection and semantic embedding fusion for entity cold start, multi-cadence incremental training for model freshness, constrained decoding for business-rule enforcement, and hybrid row decoding for inference efficiency.

Two offline findings stand out. First, in our current regime, enriching the prompt yields a substantially larger improvement than scaling model capacity—a takeaway we expect to generalize to other industry-scale personalization settings, at least until the available context is fully exploited. Second, RL post-training increases homepage diversity even though diversity is not part of the objective—an indication that page-level optimization captures interactions across rows and entities.

Several pieces of the full vision are still in progress: RL post-training has not yet shipped online, long context still relies on handcrafted summarization, and broader LLM-style capabilities—language, multimodality, and reasoning—have not yet been incorporated. One promising direction here is a hybrid tokenization combining our domain-specific tokens with generic text tokens, retaining structured control while inheriting the strengths of general-purpose LLMs; conceptually, this introduces an additional recommendation modality into an LLM.

More broadly, we expect many advances from the LLM ecosystem to transfer naturally to this setting, and the boundary between an LLM and a recommender system may increasingly blur. Our results suggest this is a viable path toward simpler recommender systems that align more directly with user satisfaction.

References↩︎

---

1. For example, a Continue Watching row near the top has high stopping power: members tend to resume a title they have already started rather than explore new content. Visual treatment matters too—rows with larger artwork tend to reduce further scrolling.↩︎