Resumen Técnico: RankGraph-2

Planteamiento del Problema

Desplegar la recuperación basada en grafos a la escala de miles de millones de nodos para sistemas de recomendación requiere resolver tres problemas estrechamente acoplados: construcción del grafo, aprendizaje de representaciones y servicio en tiempo real. El trabajo existente suele abordar estas etapas de forma aislada. La investigación académica optimiza a menudo las arquitecturas de modelos en grafos pequeños y estáticos, mientras que los sistemas industriales avanzan en la infraestructura de entrenamiento pero asumen que el grafo de entrada ya está dado e ignoran los costes de servicio. Este enfoque fragmentado crea cuellos de botella:

• Construcción: La construcción ingenua de grafos de co-engagement completos para sistemas de miles de millones de nodos resulta en cientos de billones de aristas, lo que hace que el almacenamiento y el procesamiento sean inviables.
• Entrenamiento: Entrenar en tales grafos masivos a menudo requiere una infraestructura de grafos en línea costosa (por ejemplo, motores de muestreo distribuidos) para gestionar la extracción de vecindades en tiempo real.
• Servicio: El servicio de embeddings mediante búsqueda de Vecinos Más Cercanos (KNN) aproximados en línea para pools de usuarios dinámicos (por ejemplo, usuarios activos en los últimos 15 minutos) requiere miles de máquinas, creando una latencia y un coste prohibitivos.

El artículo argumenta que optimizar cualquier etapa sin considerar las restricciones de las demás conduce a resultados subóptimos. El desafío central es cómo co-diseñar la construcción, el entrenamiento y el servicio cuando el grafo tiene miles de millones de nodos y cientos de billones de aristas potenciales.

Metodología: Co-Diseño del Ciclo de Vida

RankGraph-2 es un marco unificado que co-diseña las tres etapas del ciclo de vida para la recuperación basada en similitud (Usuario-a-Usuario-a-Ítem [U2U2I] e Ítem-a-Ítem-a-Ítem [U2I2I]). El sistema opera bajo el principio de que los requisitos de las etapas posteriores (servicio, entrenamiento) deben dar forma a las etapas anteriores (construcción).

1. Construcción del Grafo (Etapa Inicial/Upstream)

Para satisfacer las necesidades del entrenamiento (datos autocontenidos) y del servicio (frescura de nivel de hora), la canalización de construcción realiza lo siguiente:

• Esquema de Grafo Heterogéneo: Construye un grafo con tres tipos de aristas derivadas exclusivamente de datos de interacción (clics, likes, compartidos, compras): Usuario-Ítem (U-I), Usuario-Usuario (U-U) e Ítem-Ítem (I-I).
• Corrección de Sesgo de Popularidad: Ajusta los pesos de las aristas I-I para evitar que los ítems populares dominen las representaciones. El peso se escala por un factor inversamente proporcional a la popularidad del ítem objetivo, asegurando que los ítems de la "cola" (tail items) no sean eclipsados.
• Submuestreo de Aristas: Reduce el grafo de cientos de billones de aristas a cientos de miles de millones. Esto implica retener nodos de alto valor para las aristas U-U y mantener las aristas con mayor peso ($K_{CAP}$) para cada nodo.
• Vecindades Pre-computadas: En lugar de un muestreo en línea, el sistema utiliza PageRank Personalizado (PPR) en el grafo "columna vertebral" (backbone) para pre-computar los $K_{IMP}$ vecinos de múltiples saltos más importantes para cada nodo. Para los nodos que carecen de vecinos del mismo tipo, se utiliza KNN sobre los embeddings previos como alternativa (fallback).
• Salida: La canalización produce datos "centrados en la arista" donde cada registro contiene la arista, las características del nodo y los vecinos pre-computados, listos para la ingestión directa sin necesidad de almacenamiento de grafos en línea. Toda la canalización se completa en una hora, permitiendo un ciclo de actualización de 3 horas.

2. Entrenamiento del Modelo (Etapa Intermedia/Midstream)

La fase de entrenamiento ingiere los datos pre-computados y autocontenidos, eliminando la necesidad de infraestructura de grafos en línea (sin almacenamiento de grafos ni motores de muestreo distribuidos).

• Arquitectura: Utiliza un agregador heterogéneo simple con codificadores multi-cabezal para usuarios e ítems. Se generaliza a nodos no vistos (entorno inductivo).
• Objetivo: Combina la pérdida de ranking de margen (margin ranking loss) y la pérdida InfoNCE para la predicción de enlaces contrastivos.
• Co-Aprendizaje: Crucialmente, el proceso de entrenamiento co-aprende un índice de clúster junto con los embeddings. El modelo optimiza no solo la calidad del embedding, sino también la calidad del embedding reconstruido mediante un objetivo de cuantización residual.
• Regularización: Para prevenir el "colapso del libro de códigos" (codebook collapse) (donde unos pocos códigos son sobreutilizados) durante el entrenamiento continuo, el sistema emplea:
  • Pérdida de Regularización: Penaliza el lote actual por reforzar códigos frecuentemente utilizados basándose en una distribución empírica de lotes pasados.
  • Selección de Código Sesgada: Selecciona códigos que favorecen las entradas subutilizadas, actuando como un mecanismo de exploración.

3. Servicio en Tiempo Real (Etapa Final/Downstream)

La estrategia de servicio reemplaza el costoso KNN en línea con un enfoque basado en clústeres impulsado por el índice co-aprendido.

• Asignación de Clúster: Cada usuario es asignado a un código de clúster jerárquico mediante cuantización residual.
• Recuperación U2U2I: En lugar de buscar usuarios similares, el sistema lee los ítems más recientes de la cola de clúster (cluster queue) del clúster asignado al usuario objetivo. Esta cola es mantenida por los miembros recientemente activos de dicho clúster.
• Eficiencia: Esto reduce la recuperación U2U2I a una simple búsqueda (lookup), eliminando la necesidad de realizar un KNN en línea sobre pools de usuarios dinámicos.

Contribuciones Clave

1. Marco de Co-Diseño de Ciclo de Vida: Identifica e implementa un marco donde los requisitos de servicio, entrenamiento y construcción cascaden a través de las etapas, desbloqueando un rendimiento inalcanzable mediante la optimización independiente.
2. Entrenamiento Libre de Infraestructura de Grafos: Demuestra que la recuperación basada en similitud no requiere infraestructura de grafos en línea. Las vecindades pre-computadas (vía PPR) ofrecen una calidad comparable al muestreo en línea, permitiendo el entrenamiento en infraestructura de ML estándar.
3. Construcción de Grafo Heterogéneo: Propone un grafo derivado enteramente de datos de interacción con tres tipos de aristas (U-U, I-I, U-I), que cuenta con corrección de sesgo de popularidad y pre-computación de vecindad basada en PPR.
4. Índice de Clúster Co-aprendido: Desarrolla un índice de cuantización residual con una novedosa regularización y selección de código sesgada para prevenir el colapso del libro de códigos, reduciendo los costes de servicio en un 83%.
5. Ganancias de Rendimiento: Muestra que una arquitectura simple, cuando es co-diseñada, supera significativamente a bases complejas (GAT + Deep Graph Infomax y PyTorch-BigGraph) en términos de recall y métricas en línea.

Resultados

El sistema fue desplegado en múltiples superficies de Meta, sirviendo a miles de millones de usuarios.

• Recall Offline:
  • Embeddings de Usuario: RankGraph-2 logró un Recall@5 3.8× mayor que un modelo GAT + Deep Graph Infomax (que utilizaba una arquitectura más compleja pero un grafo bipartito más simple).
  • Embeddings de Ítem: Logró un Recall@100 2.1× mayor que PyTorch-BigGraph en la recuperación de ítems.
• Pruebas A/B Online (14 días):
  • Entregó hasta un +0.96% de CTR y un +2.75% de CVR para la recuperación U2I2I.
  • Mostró mejoras consistentes para la recuperación U2U2I.
• Coste de Infraestructura:
  • Redujo el coste de infraestructura de servicio U2U en un 83% al reemplazar el KNN en línea con el índice de clúster co-aprendido.
• Despliegue: Impulsó más de 20 lanzamientos de recuperación en las principales superficies de Meta.

Significado y Reivindicaciones

El artículo sostiene que el principal motor del rendimiento es el co-diseño del ciclo de vida, no la complejidad del modelo. Al mover la computación de vecindad fuera de línea (offline), el sistema permite operaciones (PPR multi-salto, corrección de popularidad, construcción de aristas heterogéneas) que son inviables en entornos en línea debido a las restricciones de latencia e infraestructura.

Los autores argumentan que para la recuperación basada en similitud, el enfoque convencional de invertir en infraestructura de grafos en línea para soportar GNNs complejos puede ser el intercambio (trade-off) equivocado. En su lugar, invertir en una construcción de grafos offline de alta calidad sobre infraestructura de ML estándar genera tanto un rendimiento de recuperación superior como menores costes operativos. El artículo posiciona a RankGraph-2 no como un competidor de los modelos fundacionales generativos, sino como un prior estructural complementario que captura la estructura colaborativa global, el cual puede combinarse con modelos de intención temporal para el ranking descendente (downstream).