GenPage: Hacia la construcción de páginas de inicio generativas de extremo a extremo en Netflix.

Autores: Lequn Wang, Jiangwei Pan y Linas Baltrunas

Figura 1. Generación autorregresiva de la página de inicio. GenPage construye una página de inicio de Netflix una fila o entidad a la vez, cada una condicionada por lo que ya está en la página y el contexto del usuario.

Introducción

La página de inicio de Netflix es lo primero que los usuarios ven cuando abren la aplicación y la principal forma en que descubren contenido para disfrutar. Casi cada parte de ella está personalizada, incluyendo qué filas aparecen, qué entidades se muestran dentro de esas filas y cómo está todo arreglado en la página. Construir esa página de inicio es un problema verdaderamente difícil. No se trata simplemente de producir una lista clasificada. La página de inicio es un diseño estructurado bidimensional, compuesto de filas de recomendaciones y las entidades dentro de ellas. Aquí, una entidad puede ser una película, un programa, un juego, un evento en vivo u otro ítem recomendable. Cada elección puede afectar el valor de las demás. Tradicionalmente, se construye a través de un pipeline complejo de múltiples etapas, con componentes separados para la generación de candidatos y el ranking tanto a nivel de filas como de entidades. Vimos una oportunidad para repensar este diseño. Los grandes modelos de lenguaje han demostrado que un único modelo generativo puede realizar diversas tareas simplemente generando una respuesta a un aviso. Inspirados por este paradigma de aviso-respuesta, entrenamos un único modelo generativo para construir la página de inicio respondiendo directamente a una pregunta: Dado todo lo que sabemos sobre este usuario y esta solicitud, ¿qué página de inicio deberíamos generar para maximizar la satisfacción del usuario? Llamamos a este enfoque GenPage. Trata el historial del usuario y el contexto de la solicitud como el aviso, y genera autorregresivamente toda la página de inicio como la respuesta (Figura 1). A diferencia de la mayoría de los recomendadores generativos, como TIGER, HSTU y OneRec, que generan listas planas clasificadas, GenPage genera las filas, las entidades y el diseño juntos. Este cambio está motivado por varios objetivos:

Modelado de extremo a extremo. Un único modelo de transformador que construye la página a partir de señales de entrada en bruto puede reemplazar un complejo stack recomendador de múltiples etapas. Esto reduce la cantidad de modelos de ML a mantener, evita objetivos desalineados a través de las etapas y elimina gran parte de la tradicional ingeniería de características.

Optimización de página completa a través de aprendizaje por refuerzo (RL). La generación autorregresiva de la página hace posible optimizar para recompensas a nivel de página con RL. Esto puede capturar interacciones a través de filas y entidades, como la diversidad o el equilibrio entre filas con diferentes poderes de detención. Por ejemplo, una fila de "Seguir viendo" cerca de la parte superior de la página puede satisfacer fuertemente la intención inmediata de un usuario, pero también puede reducir cuánto de la página exploran. Modelar estas interacciones a nivel de página nos permite alinear el sistema más directamente con la satisfacción del usuario que los objetivos a nivel de entidad por sí solos.

Mejor comportamiento de escalado. Un modelo generativo de transformador nos proporciona un camino más claro para mejorar la calidad mediante más datos, computación y capacidad del modelo, sin rediseñar repetidamente el sistema.

Flexibilidad y extensibilidad. El paradigma de aviso-respuesta es flexible por diseño. Al simplificar la ingeniería de características y permitir la optimización de la página completa, GenPage facilita el soporte de nuevas experiencias de producto, como tipos de contenido adicionales como eventos en vivo, juegos y podcasts; diseños más allá de la actual estructura bidimensional; componentes de UI personalizados; y personalización de obras de arte por entidad, todo con menos cambios arquitectónicos.

Llevar GenPage a producción en Netflix también requirió resolver desafíos específicos de los sistemas recomendadores de escala industrial. Dado que la página de inicio se genera en tiempo real, la latencia de servicio es una restricción de ingeniería primaria. También necesitamos manejar el arranque en frío de entidades en un catálogo que evoluciona constantemente, mantener el modelo fresco a medida que cambian los intereses de los usuarios y las tendencias culturales, y hacer cumplir reglas complejas de producto y negocio en la salida generada. A pesar de estos desafíos, GenPage ya ha tenido un impacto sustancial en producción. En una prueba A/B en línea contra un recomendador de producción multi-etapa maduro y altamente optimizado, GenPage ofreció ganancias estadísticamente significativas en la métrica central de compromiso del usuario que utilizamos para decisiones de lanzamiento, mientras que redujo la latencia de servicio de extremo a extremo en un 20%.

Fuera de línea, dos hallazgos destacaron. Primero, enriquecer el aviso ayudó más que escalar la capacidad del modelo en nuestro régimen actual. Segundo, el entrenamiento posterior por RL aumentó la diversidad de la página de inicio a pesar de que la diversidad no era parte del objetivo. Esperamos que este enfoque se generalice a muchos entornos de personalización.

En este artículo, nos centramos en la construcción de la página de inicio de Netflix como un estudio de caso concreto, compartiendo nuestro diseño, compromisos y lecciones aprendidas.

Datos

Pasar de un recomendador tradicional a un transformador generativo requiere repensar cómo se representa la información. Similar a cómo un LLM convierte texto en tokens, GenPage representa tanto el contexto del usuario como la página de inicio generada como una secuencia de tokens discretos (Figura 2). Esta secuencia incluye el diseño estructurado completo de la página de inicio, con múltiples filas y las entidades dentro de ellas, para que el modelo pueda generar la página de manera holística en lugar de puntuar cada fila o entidad de forma aislada.

Figura 2. Tokenización de los datos de construcción de la página de inicio de Netflix.

Los tokens de contexto funcionan como el aviso, extrayendo de diversas fuentes de datos que incluyen el historial del usuario, atributos del perfil y el contexto de la solicitud, con ejemplos de tokens mostrados para cada fuente. Los tokens de la página representan la respuesta generada, codificando el diseño estructurado de filas y entidades. Cada ejemplo de entrenamiento representa una impresión de página de inicio y consiste en tres componentes:

Contexto: historial de compromiso del usuario, atributos del perfil y contexto de la solicitud. Página: las filas y entidades recomendadas que se muestran en la página de inicio, en orden de diseño. Retroalimentación: interacciones del usuario con esa página, como reproducir, me gusta o abandono de entidades en la página. Solo el contexto y la página se tokenizan como entradas y salidas del modelo. La retroalimentación se utiliza para derivar señales de supervisión a través de nuestro sistema de recompensas interna (ver la sección del sistema de recompensas).

En lugar de utilizar un tokenizador de texto estándar, construimos un tokenizador específico para el dominio de los datos de construcción de la página de inicio. Este es un enfoque probado en sistemas recomendadores y otros dominios especializados, incluyendo visión por computadora, biología y química, donde los datos en bruto no se representan naturalmente como texto. Comparado con la tokenización de texto genérica, esto nos da dos ventajas clave:

Eficiencia computacional. La tokenización personalizada reduce significativamente la longitud de la secuencia, disminuyendo el costo y la latencia de la inferencia. Por ejemplo, representar el evento "El usuario vio Orange Is the New Black durante 50 minutos hace 30 días" requeriría 16 tokens con el tokenizador GPT-5, mientras que nuestro esquema lo comprime a 4 tokens: [Entity_ID], [Action_Type], [Action_Time_Bucket] y [Action_Duration_Bucket].

Control del producto. Un mapeo directo entre tokens y conceptos del producto, como filas y entidades, facilita el control sobre lo que el modelo puede generar. Esto es crucial para hacer cumplir reglas de negocio en la página de inicio final.

Tokens de contexto

Los tokens de contexto codifican el historial de compromiso del usuario, el perfil del usuario y el contexto de la solicitud. Representamos el historial del usuario como una secuencia de acciones del usuario. Para cada acción, extraemos metadatos clave, incluyendo el tipo de acción, ID de entidad, marca de tiempo y duración. Estas acciones incluyen tanto señales explícitas, como reproducir, agregar a Mi lista y me gusta, como señales implícitas, como vistas de tráiler o visitas a una página de detalles.

Los tokens de perfil del usuario capturan atributos como el idioma y el tipo de perfil. Los tokens de contexto de la solicitud codifican señales como la hora del día, el día de la semana y el dispositivo. Algunas fuentes de datos son demasiado largas para incluirlas directamente como secuencias de tokens en bruto. El historial completo de impresiones de un usuario, por ejemplo, sería prohibitivamente costoso de representar en su totalidad. En estos casos, usamos una versión resumida. Este es un compromiso pragmático: mientras GenPage busca operar sobre entradas en bruto tanto como sea posible, los resúmenes hechos a mano aún introducen una forma de ingeniería de aviso en el pipeline. Aprender a comprimir estas largas fuentes de datos de extremo a extremo es una dirección importante para trabajos futuros. Para ayudar al modelo a distinguir entre fuentes de datos, insertamos tokens especiales que marcan el inicio de cada segmento. Las señales continuas, como marcas de tiempo y duraciones, se agrupan en rangos discretos para mantener el vocabulario finito.

Tokens de página

Cada entidad, como un programa, película o juego, y cada fila, como Programas de TV Coreanos, se representa como un único token. La página de inicio se serializa en orden de diseño: de izquierda a derecha, luego de arriba hacia abajo. Actualizamos el vocabulario de entidades y filas diariamente para incorporar las entidades y filas recién añadidas. Las entidades que todavía están fuera de vocabulario en el momento del servicio se manejan a través de la fusión de incrustaciones semánticas y tokens de retorno, ambos descritos más adelante. En principio, el mismo paradigma puede extenderse a cualquier salida que pueda expresarse como una secuencia de tokens lineales. Esto incluye diseños más allá de la actual estructura bidimensional, como feeds unidimensionales o diseños mixtos, así como componentes de UI personalizados y salidas por entidad, como obras de arte personalizadas. Dejamos estas extensiones para trabajos futuros.

Recomendación paginada

Para hacer que las recomendaciones respondan a las preferencias del usuario durante la sesión, la página de inicio a menudo se genera de manera incremental, unas pocas filas a la vez. Antes de cada solicitud de paginación, añadimos los tokens de la página de filas previamente generadas al aviso, junto con los compromisos más recientes del usuario sobre esas filas desde la infraestructura de registro de eventos en tiempo real de Netflix. Esto permite que el modelo genere el siguiente conjunto de recomendaciones utilizando tanto las preferencias a largo plazo del usuario como su comportamiento más reciente en la sesión.

Sistema de recompensas

Para cuantificar el valor a largo plazo de una recomendación, dependemos de un sistema de recompensas interno descrito en trabajos anteriores. El sistema de recompensas se ajusta a través de pruebas A/B en línea para alinearse con la satisfacción del usuario a largo plazo y sirve como la señal principal de supervisión tanto para el aprendizaje supervisado como para el aprendizaje por refuerzo. El sistema de recompensas procesa la retroalimentación del usuario y asigna una recompensa escalar para cada entidad impactada en la página de inicio. Por ejemplo, un programa de TV visto en un atracón en una noche refleja una mayor satisfacción del usuario y recibe una recompensa más alta que una película vista solo durante 10 minutos. Una entidad impactada que el usuario abandona recibe una recompensa negativa. Definimos la recompensa a nivel de página como la suma de las recompensas de todas las entidades impactadas en la página de inicio.

Arquitectura del modelo

GenPage utiliza una arquitectura estándar de transformador solo decodificador, la misma arquitectura general detrás de muchos LLM modernos. Esta elección mantiene el modelo simple y flexible, a la vez que nos permite beneficiarnos del amplio ecosistema de herramientas en torno al entrenamiento y servicio de transformadores. Un detalle arquitectónico es que desatamos los pesos de incrustación de entrada y proyección de salida. Esto es útil porque el preentrenamiento y el posentrenamiento imponen diferentes demandas sobre los logits. El preentrenamiento de predicción del siguiente token optimiza un softmax sobre el vocabulario, mientras que el post-entrenamiento de clasificación binaria ponderada (WBC) optimiza puntajes sigmoides por token, como se describe a continuación. Desatar los pesos le da al modelo más flexibilidad para adaptarse a ambos objetivos.

Receta de entrenamiento

Nuestro pipeline de entrenamiento refleja la receta del LLM: primero enseñamos al modelo el "idioma" de la página de inicio de Netflix a través del preentrenamiento, luego alineamos sus salidas con la satisfacción del usuario a través del posentrenamiento. Para el posentrenamiento, exploramos dos enfoques alternativos: la clasificación binaria ponderada (WBC) y el aprendizaje por refuerzo (RL). WBC es más simple de optimizar y se alinea directamente con los objetivos a nivel de entidad de nuestros modelos de clasificación de producción. El RL es más difícil de evaluar y optimizar, pero es el camino clave hacia la visión completa de GenPage de optimización a nivel de página, con la flexibilidad de incorporar razonamiento en el momento de la prueba y representaciones de entidad de múltiples tokens.

Preentrenamiento a través de la predicción del siguiente token

Preentrenamos el modelo con un objetivo estándar de predicción del siguiente token: dados los tokens de contexto y un prefijo de tokens de página, el modelo aprende a predecir el siguiente token de la página. Esta etapa se centra en el aprendizaje de representaciones, enseñando al modelo la relación entre los contextos del usuario y las páginas de inicio exitosas. Cabe notar que nuestros ejemplos de entrenamiento de contexto-página se asemejan más a los pares aviso-respuesta utilizados en el ajuste fino supervisado (SFT) de LLM que al texto en bruto utilizado en el preentrenamiento de LLM. No obstante, llamamos a esta etapa preentrenamiento porque entrenamos al modelo desde cero en lugar de ajustar un punto de control existente. A diferencia de los LLM, que a menudo enfrentan una escasez de datos etiquetados de alta calidad, los sistemas recomendadores tienen una abundancia de retroalimentación del usuario. Para el preentrenamiento, utilizamos impresiones de página de inicio que recibieron retroalimentación positiva cuando se sirvieron en producción, iniciando el modelo para generar páginas similares a las producidas por el sistema de producción existente. Sin embargo, el preentrenamiento enseña principalmente a GenPage a imitar el sistema de producción. No optimiza directamente la magnitud de la recompensa, y a medida que GenPage se convierte en parte de la producción, entrenar repetidamente en páginas generadas por versiones anteriores del modelo puede arriesgar la degeneración del modelo. Para abordar estas limitaciones, exploramos dos enfoques de posentrenamiento.

Posentrenamiento a través de la clasificación binaria ponderada

Una forma efectiva de alinear el modelo generativo con la satisfacción del usuario es la clasificación binaria ponderada (WBC). A un alto nivel, WBC convierte la generación en predicción de valor a nivel de token: dado el contexto del usuario y los tokens generados hasta ahora, el modelo aprende a estimar el valor de generar cada posible token de fila o entidad siguiente. Este objetivo es más fácil de optimizar que el RL a nivel de página. Al descomponer la página de inicio en objetivos por token, WBC proporciona asignación de crédito a nivel de token por construcción, en lugar de requerir que el RL infiera cómo cada decisión generada contribuyó a la recompensa final a nivel de página. Este setup de entrenamiento es posible gracias a nuestra tokenización personalizada. Cada token de página corresponde directamente a una entidad o fila específica, facilitando la asignación de una recompensa. Por cada entidad impactada en la página, nuestro sistema de recompensas proporciona una recompensa escalar basada en la retroalimentación del usuario. Para cada fila impactada, derivamos una recompensa a nivel de fila agregando las recompensas de las entidades en esa fila. De cada recompensa, derivamos una etiqueta binaria de su signo, como compromiso positivo versus abandono, y un peso de su magnitud, como que un maratón de visualización reciba un mayor peso que una reproducción corta. Luego optimizamos una pérdida de entropía cruzada binaria ponderada sobre el logit para el token correspondiente. Bajo este setup, el logit para un token puede interpretarse como la estimación de valor del modelo para generar ese token en esa posición. Aunque el modelo se entrena como un predictor de valor, aún puede generar páginas de manera autorregresiva. En cada paso, el modelo puntúa los tokens candidatos siguientes, selecciona codiciosamente el token con el valor más alto y lo agrega al prefijo. Este proceso se repite token por token hasta que se genera la página de inicio completa.

Posentrenamiento a través del aprendizaje por refuerzo

Nuestro segundo enfoque de posentrenamiento es el aprendizaje por refuerzo (RL). WBC es efectivo para optimizar métricas a nivel de entidad, pero no optimiza directamente la página de inicio en su conjunto. El RL trata la generación de páginas como un problema de toma de decisiones secuencial, permitiendo que el modelo optimice una recompensa a nivel de página mientras preserva la flexibilidad de la generación autorregresiva. Esto abre la puerta a varias capacidades importantes:

Optimización de página completa. El RL optimiza directamente una recompensa agregada a nivel de página, permitiendo que el modelo tenga en cuenta las interacciones entre filas y entidades, como la diversidad, el poder de detención y las restricciones comerciales a nivel de página.

Razonamiento en el momento de prueba. Análogo a su aplicación en LLM, el RL puede optimizar capacidades de razonamiento para recomendaciones generativas. Las salidas de razonamiento también pueden verse como una forma de ingeniería de características automatizada.

Soporte de entidades de múltiples tokens. En nuestra tokenización actual, cada entidad y fila se representa como un único token, por lo que las recompensas se asignan limpiamente a tokens individuales. Sin embargo, en configuraciones más complejas, una entidad puede requerir múltiples tokens, como [Show_ID] más [Episode_#] para un episodio, o una secuencia de tokens de ID semánticos. En ese caso, la etiquetación por token de WBC se vuelve ambigua porque una única recompensa a nivel de entidad debe distribuirse entre múltiples tokens. El RL evita este problema al optimizar el retorno a nivel de secuencia, lo que lo convierte en un ajuste más natural para entidades de longitud variable y múltiples tokens.

Inspirados en la receta RLHF utilizada para alinear modelos de lenguaje grandes, adoptamos un enfoque en dos pasos. Primero, entrenamos un modelo de recompensa que predice la recompensa a nivel de página para una página generada. Este modelo de recompensa es distinto del sistema de recompensas descrito anteriormente. El sistema de recompensas convierte la retroalimentación del usuario observada en una recompensa escalar para una página que se mostró realmente, mientras que el modelo de recompensa predice la recompensa a nivel de página para una página generada sin mostrarla al usuario. Esta predicción es la que permite al RL optimizar frente a páginas candidatas arbitrarias durante el entrenamiento. Entrenar contra un modelo de recompensa evita la alta varianza de la corrección fuera de política sobre propensiones registradas o predichas, pero introduce el riesgo de manipulación de recompensas. Dado que el modelo de recompensa se entrena con datos generados a partir de la política de producción, es más confiable en páginas similares a las que genera la política de producción. Por lo tanto, usamos una penalización de KL para mantener la política cerca del punto de control preentrenado, que a su vez fue entrenado para imitar la política de producción. Esto mantiene las páginas dentro de la región de cobertura del modelo de recompensa y limita las oportunidades para la manipulación de recompensas.

Para el algoritmo de RL, adoptamos Dr. GRPO, una variante de GRPO que mitiga los sesgos en el objetivo de entrenamiento. Para entrenar el modelo dentro de este marco, necesitamos los siguientes componentes:

Prompts: solicitudes de usuarios de producción, representadas por tokens de contexto. Modelos de política y referencia: ambos son inicializados desde el punto de control preentrenado; el modelo de referencia ancla la penalización de KL discutida anteriormente. Modelo de recompensa: un modelo de recompensa basado en transformadores dedicado, también inicializado desde el punto de control preentrenado, que predice la recompensa de resultado a nivel de página, usando la suma de recompensas a nivel de entidad de nuestro sistema de recompensas interno como el objetivo de supervisión. También incorporamos recompensas basadas en reglas para guiar la política de RL. Por ejemplo, la página debería parecerse a una lista de filas, y filas o entidades críticas para el negocio no deberían aparecer demasiado abajo en la página.

Abordando desafíos de producción

Arranque en frío

Las nuevas entidades carecen de los ricos datos de interacción necesarios para aprender incrustaciones de token robustas. Abordamos esto a través de dos estrategias complementarias:

Inyección de contexto. Inyectamos metadatos sobre nuevas entidades o eventos sensibles al tiempo (por ejemplo, eventos "En vivo ahora") directamente en los tokens de contexto, proporcionando al modelo información semántica y sensible al tiempo.

Fusión de incrustaciones semánticas. En lugar de depender únicamente de las incrustaciones de ID de entidades aprendidas a partir de datos de interacción de usuarios, representamos cada entidad como una fusión de su incrustación de ID y una incrustación basada en contenido derivada de información semántica como sinopsis, elenco, transcripciones, géneros y contenido de video. Esta incrustación fusionada sirve como la incrustación de entrada para el token de la entidad en el transformador. Durante el entrenamiento, con pequeña probabilidad, reemplazamos al azar un token de ID de entidad con el token de retorno genérico (descrito a continuación), para que el modelo aprenda a hacer recomendaciones solo a partir de la incrustación basada en contenido. Esto asegura que una nueva entidad tenga una representación significativa en el mismo espacio latente que las entidades establecidas tan pronto como su metadata de contenido esté disponible, incluso antes de que tenga datos de interacción.

Entrenamiento incremental de múltiples cadencias

A la escala de Netflix, el reentrenamiento diario de un gran transformador desde cero es prohibitivamente costoso, pero los modelos de recomendación deben mantenerse frescos para capturar tendencias cambiantes y nuevas adiciones al catálogo. Abordamos esto con una estrategia de entrenamiento incremental de múltiples cadencias (Figura 3).

Figura 3. Entrenamiento incremental de múltiples cadencias. Pasadas de preentrenamiento y posentrenamiento periódicas a gran escala se ejecutan en una amplia ventana histórica. Entre ellas, actualizaciones incrementales diarias combinan los datos del día más reciente con un subconjunto muestreado de datos pasados para mantener el modelo fresco mientras se evita el olvido catastrófico.

Nuestro pipeline de entrenamiento opera en un horario cíclico con dos ritmos distintos. A una cadencia ajustable, llevamos a cabo una pasada de preentrenamiento y posentrenamiento a gran escala en datos de una amplia ventana histórica. Entre estas pasadas, cada día realizamos una actualización incremental continuando el posentrenamiento desde el punto de control del día anterior, usando una mezcla de los datos del día más reciente y un subconjunto muestreado de datos pasados. Esto ayuda al modelo a mantenerse actualizado con nuevas tendencias y cambios en el catálogo mientras se previene el sobreajuste y el olvido catastrófico. Para gestionar la afluencia diaria de nuevos tokens (por ejemplo, nuevas entidades, filas), empleamos tokens de retorno. Nuevos tokens son inicializados utilizando tokens de retorno de su tipo (por ejemplo, [Row_Fallback_Token] para nuevas filas, [Entity_Fallback_Token] para nuevas entidades). Durante el entrenamiento, reemplazamos al azar un pequeño porcentaje de tokens conocidos por tokens de retorno, enseñando al modelo a manejar tokens desconocidos con elegancia.

Enforcement of business rules

Una página de inicio de Netflix debe satisfacer restricciones estructurales (por ejemplo, organizada como una lista de filas) así como lógica de producto como deduplicación, fijación de filas y consistencia de categorías (por ejemplo, entidades en una fila de Comedia deben ser comedias). Aunque las señales de entrenamiento pueden fomentar la adherencia a las reglas, no pueden garantizar un cumplimiento estricto. Hacemos cumplir estas reglas en el tiempo de inferencia a través de decodificación restringida. En cada paso de generación autorregresiva, computamos una máscara de tokens elegibles en función de las reglas de negocio aplicables y la aplicamos a los logits de salida, permitiendo que solo se generen tokens que cumplan con las reglas. Esto se simplifica enormemente gracias a nuestra tokenización personalizada: dado que cada entidad y fila es un único token, las reglas de negocio se mapean directamente a máscaras a nivel de token, evitando la contabilidad de múltiples tokens que la decodificación restringida requiere sobre un vocabulario de texto. Por ejemplo, para fijar una fila específica (por ejemplo, juegos populares) en una posición fija (por ejemplo, posición de fila 2), simplemente enmascaramos todos los demás tokens en esa posición.

Decodificación de fila híbrida

La generación autorregresiva asegura que cada nuevo token generado esté condicionado por todo el contexto precedente, pero generar cada token de entidad uno a uno puede ser costoso. Aprovechamos la estructura de la página de inicio para equilibrar la eficiencia de la inferencia con la cantidad de información contextual disponible para cada token generado. Dentro de cada fila, los primeros pocos entidades son especialmente importantes: reciben la mayor atención del usuario y moldean fuertemente la calidad percibida y el tema de la fila. Para reducir la latencia de inferencia, utilizamos una estrategia de decodificación de fila híbrida. El modelo genera autorregresivamente solo los primeros pocos entidades en cada fila. Condicionado por este prefijo generado, obtenemos logits para todas las entidades elegibles en una sola pasada hacia adelante y seleccionamos las entidades restantes con mejor puntaje, sujetas a las mismas restricciones de reglas de negocio en tiempo de inferencia descritas anteriormente. Este enfoque preserva el condicionamiento autorregresivo donde más importa, mientras evita la latencia y el costo de decodificar filas largas token por token.

Experimentos fuera de línea

Realizamos una serie de ablations en datos internos de Netflix para entender cómo diferentes componentes de GenPage afectan la calidad del modelo. Dado que el sistema se desarrolló de manera iterativa, las ablations individuales abarcan diferentes configuraciones de entrenamiento y snapshots de datos, por lo que solo informamos sobre comparaciones relativas dentro de cada estudio. A menos que se indique lo contrario, los experimentos utilizan modelos de aproximadamente 200 millones de parámetros y reportan resultados en un conjunto de evaluación reservado.

¿Ayuda el preentrenamiento?

Comparamos el posentrenamiento WBC con y sin una etapa previa de preentrenamiento de predicción del siguiente token. La Figura 4 muestra que el preentrenamiento produce mejoras sustanciales en todas las métricas.

Figura 4. Mejora relativa del preentrenamiento (versus posentrenamiento WBC sin una etapa de preentrenamiento), a través de la reducción de pérdidas, elevación de AUC de fila y elevación de AUC de entidad. La pérdida es la entropía cruzada binaria ponderada; Row y Entity AUC son ROC-AUC ponderados por muestra sobre objetivos de filas y entidades. Las ganancias pueden parecer pequeñas en términos absolutos, pero son grandes en nuestro régimen de producción: dejando de lado el ponderado por muestra, un aumento de AUC de entidad de 0.91 a 0.92 significa que, para una pareja de entidades impactadas elegidas al azar, la tasa de error del modelo cae del 9% al 8% — una magnitud de mejora que rara vez observamos con un solo cambio en un sistema de producción maduro. Preentrenar el modelo en el "idioma" de la página de inicio de Netflix provee una fuerte inicialización para el posentrenamiento, reflejando la receta de preentrenar y luego posentrenar detrás de los modernos LLM.

¿Cómo escala el rendimiento con el tamaño del modelo?

Varíamos el tamaño del modelo de aproximadamente 120M a 900M de parámetros (Figura 5) y reportamos la pérdida de predicción del siguiente token del preentrenamiento y la pérdida de WBC del posentrenamiento. Ambas pérdidas disminuyen de una manera similar a la ley de potencia, reflejando las tendencias de escalamiento observadas en LLM. Esto confirma que el enfoque generativo escala favorablemente con el tamaño del modelo, sugiriendo que la calidad de recomendación puede mejorarse aún más al aumentar la capacidad.

Figura 5. Pérdidas de preentrenamiento y WBC de posentrenamiento a medida que el tamaño del modelo escala de 120M a 900M de parámetros. Ambas disminuyen de una manera similar a la ley de potencia, reflejando las tendencias de escalamiento de LLM.

¿Cómo escala el rendimiento con la información en el contexto del usuario?

A lo largo del desarrollo, enriquecimos progresivamente el aviso, tanto al añadir nuevas fuentes de datos al contexto como al refinar cómo se tokeniza cada fuente. Con un tamaño de modelo fijo, la pérdida de posentrenamiento WBC disminuye sustancialmente a medida que se enriquece el contexto (Figura 6).

Figura 6. Pérdida de posentrenamiento WBC a medida que enriquecemos progresivamente los tokens de contexto del usuario. La pérdida se normaliza al primer paso (= 1.0). El barrido de tamaño del modelo y el barrido de enriquecimiento del contexto cubren ejes diferentes y no son estrictamente comparables: el estudio de tamaño del modelo cubre aproximadamente un orden de magnitud en parámetros, mientras que el estudio de contexto abarca toda la trayectoria de nuestro diseño de aviso. Aun así, la diferencia entre los dos es notable. Aumentar el modelo de 120M a 900M de parámetros reduce la pérdida WBC en aproximadamente un 1.3%, mientras que el efecto acumulativo de enriquecer el contexto es de alrededor del 6.9%. En varios casos, una sola adición de contexto bien diseñada entrega una mejora mayor que el incremento total de capacidad de modelo de aproximadamente 7.5×. Esto sugiere que, en nuestro régimen, enriquecer el aviso — tanto lo que ponemos en el contexto como cómo lo tokenizamos — aporta una mejora sustancialmente mayor que escalar la capacidad del modelo. La calidad de la personalización parece estar limitada primero por la información y representación disponibles para el modelo, y solo después por la capacidad. Esperamos que el enriquecimiento del contexto domine hasta que el contexto esté saturado, en cuyo punto la capacidad del modelo se convierta en el principal impulsor.

¿Optimiza el posentrenamiento RL a nivel de página?

En evaluaciones fuera de línea (Figura 7), el posentrenamiento RL mejora consistentemente la recompensa a nivel de página sobre el punto de control preentrenado, pero esto es principalmente confirmatorio: la recompensa se computa usando el mismo modelo que la política está optimizando. Más interesante, aunque la diversidad no es parte del objetivo del RL, la diversidad de la página de inicio — medida a través de la distancia de incrustación entre pares de entidades en la página — también aumenta durante el entrenamiento. Esto sugiere que la política entrenada por RL está optimizando la página en su conjunto en lugar de optimizar de manera miope cada token en aislamiento.

Figura 7. Dinámicas del posentrenamiento RL. La recompensa y la diversidad se muestran en relación con el punto de control inicial (1.0). La recompensa aumenta como se esperaba; la diversidad también aumenta, a pesar de no ser parte del objetivo de RL.

Evaluación en línea

Realizamos una prueba A/B en línea contra el actual sistema de recomendación de la página de inicio de producción utilizando GenPage. En esta prueba, GenPage decodificó sobre los conjuntos de candidatos de filas y entidades de producción existentes, que ayudan a manejar muchas reglas de negocio (como elegibilidad). La Figura 8 muestra el resultado: todas las variantes ofrecieron mejoras estadísticamente significativas en la métrica central de compromiso del usuario que utilizamos para decisiones de lanzamiento (p < 0.001) contra un baseline de producción multi-etapa maduro y altamente optimizado. Las variantes difirieron en sus configuraciones de datos de entrenamiento; que todas entregaran aumentos comparables sugiere que el incremento es robusto a estas elecciones de diseño en lugar de depender de una configuración particular.

Figura 8. Métrica diaria central de compromiso del usuario durante una prueba A/B en línea de 14 días. La figura muestra el efecto promedio del tratamiento de varias variantes de GenPage (diferentes en configuraciones de datos de entrenamiento) contra el baseline de producción. Las regiones sombreadas son intervalos de confianza del 95%. Todas las variantes ofrecieron mejoras estadísticamente significativas sobre la producción.

Junto a las ganancias de compromiso, observamos cambios no intencionados en la distribución de las categorías de entidades impresionadas (por ejemplo, títulos nuevos frente a establecidos, programas de TV frente a películas). Estos cambios no son necesariamente negativos, pero no son algo para lo que optimizamos explícitamente, y merecen una investigación más profunda. Sospechamos que estos cambios reflejan que GenPage personaliza de manera más precisa que el stack de producción — consistente con un aumento en la eficiencia de impresión de la página de inicio, es decir, los usuarios se involucran con lo que vieron usando menos impresiones. Esta personalización más aguda parece poner de manifiesto componentes heredados de producción (como el sistema de recompensas) que aún no están alineados con el nuevo paradigma generativo. Planeamos caracterizar los impulsores de estos cambios y, donde sea apropiado, ajustar estos componentes para que las distribuciones resultantes se alineen mejor con el comportamiento del producto deseado. También observamos una fuerte respuesta a señales en la sesión: las acciones más recientes en la sesión influenciaron rápidamente las recomendaciones posteriores y regresaron a las preferencias a largo plazo después de uno o dos días, confirmando que el modelo atiende efectivamente las marcas de tiempo de las acciones. Esta capacidad de respuesta se produce naturalmente a partir de la formulación generativa, sin la extensa ingeniería manual de características utilizada en nuestro stack de producción. A diferencia de la suposición común de que los modelos generativos son más lentos, GenPage redujo la latencia de servicio de extremo a extremo en un 20% en relación con el baseline. Al reemplazar múltiples etapas de clasificación y cálculos de características pesados con un único transformador que opera sobre entradas tokenizadas en bruto, eliminamos una complejidad substancial en el servicio y una sobrecarga computacional. La tokenización personalizada y la decodificación de fila híbrida redujeron aún más la cantidad de pasos de decodificación y, por ende, la latencia. La reducción del 20% se logró sin agotar las optimizaciones disponibles; son posibles reducciones adicionales, y este margen puede reinvertirse en capacidad o avisos más ricos.

Conclusión

Presentamos GenPage, un primer paso hacia la construcción generativa de la página de inicio de Netflix de extremo a extremo: representando el contexto del usuario como un aviso tokenizado y generando toda la página de inicio autorregresivamente en tiempo real. Esto colapsa el tradicional stack recomendador de múltiples etapas en un único transformador que puede ser optimizado de extremo a extremo. En pruebas A/B en línea contra un sistema de producción multi-etapa maduro y altamente optimizado, GenPage proporcionó ganancias estadísticamente significativas en la métrica central de compromiso del usuario que utilizamos para decisiones de lanzamiento, mientras que redujo la latencia de servicio de extremo a extremo en un 20%. Lograr esto requirió adaptar la receta de entrenamiento de LLM — preentrenamiento seguido de WBC o RL de posentrenamiento — junto con un conjunto de técnicas específicas del dominio: tokenización personalizada para eficiencia de servicio y control de producto, inyección de contexto y fusión de incrustaciones semánticas para arranque en frío de entidades, entrenamiento incremental de múltiples cadencias para frescura del modelo, decodificación restringida para hacer cumplir reglas de negocio y decodificación de fila híbrida para eficiencia de inferencia. Dos hallazgos fuera de línea destacan. Primero, en nuestro régimen actual, enriquecer el aviso aporta una mejora sustancialmente mayor que escalar la capacidad del modelo — un hallazgo que esperamos se generalice a otros entornos de personalización a escala industrial, al menos hasta que se agote el contexto disponible. Segundo, el posentrenamiento por RL aumenta la diversidad de la página de inicio a pesar de que la diversidad no es parte del objetivo — una indicación de que la optimización a nivel de página captura interacciones entre filas y entidades. Varias piezas de la visión completa aún están en progreso: el contexto largo aún depende de resúmenes hechos a mano, y las capacidades más amplias tipo LLM — lenguaje, multimodalidad y razonamiento — aún no se han incorporado. Una dirección prometedora aquí es una tokenización híbrida que combine nuestros tokens específicos del dominio con tokens de texto genéricos, manteniendo el control estructurado mientras hereda las fortalezas de LLM de propósito general; conceptualmente, esto introduce un modo adicional de recomendación en un LLM. Más en general, esperamos que muchos avances del ecosistema LLM se transfieran naturalmente a este contexto, y la frontera entre un LLM y un sistema de recomendación puede desdibujarse cada vez más. Nuestros resultados sugieren que este es un camino viable hacia sistemas de recomendación más simples que se alineen de manera más directa con la satisfacción del usuario.

Agradecimientos

Contribuyentes a este trabajo (en orden alfabético): Abhishek Agrawal, Baolin Li, Casey Stella, Daneo Zhang, Dan Zheng, Donnie DeBoer, Fengdi Che, Fernando Amat Gil, Grace Huang, Inbar Naor, Ishita Verma, Jason Uh, Jimmy Patel, Justin Basilico, Lanxi Huang, Lingyi Liu, Liping Peng, Louis Wang, Michelle Kislak, Nathan Kallus, Nicolas Hortiguera, Paran Jain, Qusai Al-Rabadi, Rein Houthooft, Ryan Lee, Santino Ramos, Scarlet Chen, Shaojing Li, Sheallika Singh, Si Cheng, Wei Wang y ZQ Zhang.

GenPage: Hacia la construcción generativa de páginas de inicio de extremo a extremo en Netflix fue publicado originalmente en Netflix TechBlog en Medium, donde la gente continúa la conversación destacando y respondiendo a esta historia.