Résumé Technique : RankGraph-2

Énoncé du Problème

Le déploiement de la recherche basée sur les graphes à l'échelle du milliard de nœuds pour les systèmes de recommandation nécessite de résoudre trois problèmes étroitement liés : la construction du graphe, l'apprentissage de représentations et le service en temps réel. Les travaux existants traitent généralement ces étapes de manière isolée. La recherche académique optimise souvent les architectures de modèles sur de petits graphes statiques, tandis que les systèmes industriels font progresser l'infrastructure d'entraînement mais supposent que le graphe d'entrée est donné et ignorent les coûts de service. Cette approche cloisonnée crée des goulots d'étranglement :

• Construction : La construction naïve de graphes de co-engagement complets pour des systèmes de milliards de nœuds génère des centaines de milliers de billions d'arêtes, rendant le stockage et le traitement irréalisables.
• Entraînement : L'entraînement sur de tels graphes massifs nécessite souvent une infrastructure de graphes en ligne coûteuse (par exemple, des moteurs d'échantillonnage distribués) pour gérer l'extraction de voisinage en temps réel.
• Service : Le service d'embeddings via la recherche de plus proches voisins (KNN) approximative en ligne pour des pools d'utilisateurs dynamiques (par exemple, les utilisateurs actifs des 15 dernières minutes) nécessite des milliers de machines, créant une latence et un coût prohibitifs.

L'article soutient que l'optimisation d'une seule étape sans considérer les contraintes des autres mène à des résultats sous-optimaux. Le défi central est de co-concevoir la construction, l'entraînement et le service lorsque le graphe possède des milliards de nœges et des centaines de milliers de billions d'arêtes potentielles.

Méthodologie : Co-conception du Cycle de Vie

RankGraph-2 est un cadre unifié qui co-conçoit les trois étapes du cycle de vie pour la recherche basée sur la similitude (User-to-User-to-Item [U2U2I] et User-to-Item-to-Item [U2I2I]). Le système repose sur le principe que les exigences des étapes en aval (service, entraînement) doivent façonner les étapes en amont (construction).

1. Construction du Graphe (Amont)

Pour satisfaire les besoins de l'entraînement (données autonomes) et du service (fraîcheur à l'échelle de l'heure), le pipeline de construction effectue les opérations suivantes :

• Schéma de Graphe Hétérogène : Construit un graphe avec trois types d'arêtes dérivés uniquement des données d'engagement (clics, likes, partages, achats) : User-Item (U-I), User-User (U-U) et Item-Item (I-I).
• Correction du Biais de Popularité : Ajuste les poids des arêtes I-I pour empêcher les articles populaires de dominer les représentations. Le poids est mis à l'échelle par un facteur inversement proportionnel à la popularité de l'article cible, garantissant que les articles de la "longue traîne" ne sont pas éclipsés.
• Sous-échantillonnage d'Arêtes : Réduit le graphe de centaines de milliers de billions d'arêtes à des centaines de milliards. Cela implique de conserver les nœuds à haute valeur pour les arêtes U-U et de garder les arêtes les plus pondérées ($K_{CAP}$) pour chaque nœud.
• Voisinages Pré-calculés : Au lieu de l'échantillonnage en ligne, le système utilise le Personalized PageRank (PPR) sur le graphe "épine dorsale" pour pré-calculer les $K_{IMP}$ voisins multi-sauts les plus importants pour chaque nœud. Pour les nœuds manquant de voisins du même type, le KNN sur les embeddings précédents est utilisé comme solution de repli.
• Sortie : Le pipeline produit des données "centrées sur les arêtes" où chaque enregistrement contient l'arête, les caractéristiques du nœud et les voisins pré-calculés, prêts pour une ingestion directe sans stockage de graphe en ligne. L'ensemble du pipeline se termine en une heure, permettant un cycle de rafraîchissement de 3 heures.

2. Entraînement du Modèle (Milieu)

La phase d'entraînement ingère les données pré-calculées et autonomes, éliminant le besoin d'une infrastructure de graphe en ligne (pas de stockage de graphe ou de moteurs d'échantillonnage distribués).

• Architecture : Utilise un agrégateur hétérogène simple avec des encodeurs multi-têtes pour les utilisateurs et les articles. Il se généralise aux nœuds non vus (cadre inductif).
• Objectif : Combine la perte de classement par marge (margin ranking loss) et la perte InfoNCE pour la prédiction de liens contrastive.
• Co-apprentissage : Crucialement, le processus d'entraînement co-apprend un index de cluster parallèlement aux embeddings. Le modèle optimise non seulement la qualité de l'embedding, mais aussi la qualité de l'embedding reconstruit via un objectif de quantification résiduelle.
• Régularisation : Pour éviter l'effondrement du codebook (où quelques codes sont surutilisés) pendant l'entraînement continu, le système emploie :
  • Perte de Régularisation : Pénalise le batch actuel pour renforcer les codes fréquemment utilisés sur la base d'une distribution empirique des batches passés.
  • Sélection de Code Biaisée : Sélectionne des codes qui favorisent les entrées sous-utilisées, agissant comme un mécanisme d'exploration.

3. Service en Temps Réel (Aval)

La stratégie de service remplace le coûteux KNN en ligne par une approche basée sur les clusters pilotée par l'index co-appris.

• Assignation de Cluster : Chaque utilisateur est assigné à un code de cluster hiérarchique via la quantification résiduelle.
• Récupération U2U2I : Au lieu de chercher des utilisateurs similaires, le système lit les derniers articles de la file d'attente de cluster du cluster assigné à l'utilisateur cible. Cette file est maintenue par les membres récemment actifs de ce cluster.
• Efficacité : Cela réduit la récupération U2U2I à une simple lecture (lookup), éliminant le besoin de KNN en ligne sur des pools d'utilisateurs dynamiques.

Contributions Clés

1. Cadre de Co-conception du Cycle de Vie : Identifie et implémente un cadre où les exigences de service, d'entraînement et de construction se répercutent sur les étapes, débloquant des performances inaccessibles par une optimisation indépendante.
2. Entraînement Sans Infrastructure de Graphe : Démontre que la recherche basée sur la similitude ne nécessite pas d'infrastructure de graphe en ligne. Les voisinages pré-calculés (via PPR) offrent une qualité comparable à l'échantillonnage en ligne, permettant l'entraînement sur une infrastructure ML standard.
3. Construction de Graphe Hétérogène : Propose un graphe dérivé entièrement des données d'engagement avec trois types d'arêtes (U-U, I-I, U-I), présentant une correction du biais de popularité et un pré-calcul de voisinage par PPR.
4. Index de Cluster Co-appris : Développe un index de quantification résiduelle avec une régularisation et une sélection de code biaisée novatrices pour prévenir l'effondrement du codebook, réduisant les coûts de service de 83 %.
5. Gains de Performance : Montre qu'une architecture simple, lorsqu'elle est co-conçue, surpasse de manière significative les bases complexes (GAT + Deep Graph Infomax et PyTorch-BigGraph) en termes de rappel et de métriques en ligne.

Résultats

Le système a été déployé sur plusieurs surfaces chez Meta, servant des milliards d'utilisateurs.

• Rappel Hors-ligne :
  • Embeddings Utilisateurs : RankGraph-2 a atteint un Rappel@5 3,8× supérieur à un modèle GAT + Deep Graph Infomax (qui utilise une architecture plus complexe mais un graphe bipartite plus simple).
  • Embeddings Articles : A atteint un Rappel@100 2,1× supérieur à PyTorch-BigGraph pour la recherche d'articles.
• Tests A/B en Ligne (14 jours) :
  • A délivré jusqu'à +0,96 % de CTR et +2,75 % de CVR pour la récupération U2I2I.
  • A montré des améliorations constantes pour la récupération U2U2I.
• Coût d'Infrastructure :
  • A réduit le coût d'infrastructure de service U2U de 83 % en remplaant le KNN en ligne par l'index de cluster co-appris.
• Déploiement : A alimenté plus de 20 lancements de récupération sur les principales surfaces de Meta.

Signification et Revendications

L'article affirme que le principal moteur de performance est la co-conception du cycle de vie, et non la complexité du modèle. En déplaçant le calcul des voisinages hors ligne, le système permet des opérations (PPR multi-sauts, correction de popularité, construction de graphe hétérogène) qui sont irréalisables dans des contextes en ligne en raison de la latence et des contraintes d'infrastructure.

Les auteurs soutiennent que pour la recherche basée sur la similitude, l'approche conventionnelle consistant à investir dans une infrastructure de graphe en ligne pour supporter des GNN complexes peut être le mauvais compromis. Au lieu de cela, investir dans une construction de graphe hors ligne de haute qualité sur une infrastructure ML standard permet d'obtenir à la fois une qualité de recherche supérieure et des coûts opérationnels moindres. L'article positionne RankGraph-2 non pas comme un concurrent des modèles de fondation génératifs, mais comme un a priori structurel complémentaire qui capture la structure collaborative globale, lequel peut être combiné avec des modèles d'intention temporelle pour le classement en aval.