NVIDIA Kumo Relational surpasse le ML supervisé sur 41 tâches, sans entraînement

NVIDIA a publié Kumo Relational, un foundation model relationnel préentraîné qui produit ses prédictions directement sur la base de données de l'entreprise. L'utilisateur décrit ce qu'il veut prédire et obtient le résultat en une seule passe avant, sans entraînement spécifique à la tâche, sans agrégats manuels et sans aplatissement des tables. Sur 41 tâches issues de 15 bases, le modèle a surpassé des modèles supervisés et un gradient boosting sur features expertes. Sur SAP SALT, il devance de 8% les grands ensembles AutoGluon en mean reciprocal rank. Parmi les auteurs figurent Jure Leskovec et Matthias Fey ; les travaux ont été menés avec l'équipe Kumo.

La prédiction comme requête, pas comme projet

Pour une tâche comme l'attrition client, la voie habituelle prend des semaines. Les ingénieurs calculent un « panier moyen sur 30 jours », fusionnent users, orders et products en une seule ligne, paramètrent XGBoost et maintiennent le pipeline. Kumo Relational procède autrement : il lit les tables, les clés étrangères et les horodatages tels quels. La tâche se formule en Predictive Query Language, par exemple `PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id`.

Le système assemble lui-même le contexte. Il prend des exemples historiques, découpe autour de chaque entité un sous-graphe local à un instant donné et y rattache l'issue connue, comme « l'utilisateur est parti » ou « le produit s'est vendu 142 fois ». Pour les tâches temporelles, la base est rejouée selon ses états historiques : le modèle ne voit que les données antérieures au repère d'ancrage, et la cible est calculée à partir des événements postérieurs. Toute fuite de données issues du futur est exclue par construction.

L'architecture comporte deux étages. Un réseau léger traite chaque table séparément via column attention et row attention, et filtre le bruit. Un réseau plus grand propage ensuite les embeddings de lignes à travers la structure de la base par graph attention, le long des liens entre clés primaires et étrangères, puis applique une cross-sample attention entre les exemples de contexte. Comme ce second étage opère sur des embeddings de lignes et non sur chaque cellule, il n'y a pas de coût quadratique, et les contextes à sous-graphes profonds restent tractables.

Des données synthétiques plutôt que des bases fermées

Il existe presque aucune base relationnelle diversifiée en accès libre pour le préentraînement ; le modèle est donc entraîné entièrement sur des données synthétiques. Le générateur s'appuie sur PluRel (Kothapalli et al., ICML 2026) et construit une base en trois étapes : le schéma, les liens entre lignes avec un clustering réaliste, puis les valeurs des colonnes issues de modèles causaux structurels, avec tendances temporelles et dépendances entre tables.

La génération coûte peu, de sorte que le volume de données de préentraînement est pratiquement illimité. La loss décroît selon une loi de puissance à mesure que l'on ajoute des bases, et le gain se transfère aux données réelles. L'entraînement suit un curriculum : des tables isolées vers des structures relationnelles complexes.

L'évaluation a porté sur des jeux de données que le modèle n'avait jamais vus : RelBench V1 et V2, SAP SALT et 4DBInfer. Ils couvrent l'e-commerce, la santé, l'entreprise, les réseaux sociaux et les données académiques.

• 41 tâches sur 15 bases relationnelles.
• RelBench V1, classification : environ 4 points d'AUROC de plus que le gradient boosting sur features expertes.
• SAP SALT : 7 points de MRR de plus que XGBoost sur features d'ingénierie prêtes à l'emploi, et 13 points après fine-tuning.
• SAP SALT face aux grands ensembles AutoGluon : +8% de MRR, +16% après fine-tuning.
• RelArena-α (classement au 21.09.2026) : le modèle se situe sur le front de Pareto précision/vitesse, environ 430 fois plus rapide que rtl-plurel à précision comparable.
• Robustesse : fonctionne avec 0,2% des données d'entraînement dans le contexte, tient jusqu'à 75% de liens par clés étrangères supprimés et se dégrade à peine quand on ajoute des colonnes de bruit.
• Échelle : kumo-engine traite des bases de plus de 500 milliards de lignes via du memory-mapped I/O, à une vitesse allant jusqu'à 5 Go/s.

Les auteurs énoncent eux-mêmes les limites. Le modèle donne ses meilleurs résultats là où les liens ont du sens et où la dynamique temporelle compte, par exemple dans le comportement des utilisateurs. Sur des tâches à très gros échantillons d'entraînement, les modèles supervisés spécialisés peuvent l'emporter. Le signal prédictif doit se trouver dans un nombre limité de sauts le long des liens.

Comment le lancer et où économiser

L'économie principale se compte ici en heures d'ingénierie, pas en tokens. Au lieu d'un pipeline distinct par tâche, on dispose d'un seul modèle et d'un ensemble de requêtes. Une nouvelle prévision se réduit à une ligne de PQL, et les équipes peuvent s'attaquer à des scénarios qui ne justifiaient pas auparavant le coût de développement. Pour les agents, PQL sert d'interface simple : le LLM lit et raisonne, tandis que Kumo Relational fournit la prévision, par exemple quel client va partir.

Trois voies de lancement existent. La première : la bibliothèque open source GPU-native structured-data-models (`pip install structured-data-models`), où `sdm.models.KumoRelational(device="cuda")` accepte les tables de contexte, les tables de requête et les tables liées. Les poids sont téléchargés depuis Hugging Face Hub à la première utilisation. La deuxième : un déploiement sous forme de NVIDIA NIM avec le client structured-data-models-client, où la requête PQL et le DataFrame pandas sont convertis automatiquement en contexte. Le dépôt contient des notebooks pour un NIM local et pour Databricks. La troisième : kumo-engine, avec des connecteurs vers des bases et des entrepôts de données pour les gros volumes.

Le code est publié sous Apache 2.0, les poids sous OpenMDW License Agreement 1.1. Le test pratique est simple : prenez une tâche de production tournant sur XGBoost, par exemple l'attrition ou la demande, exécutez-la sur Kumo Relational et comparez les métriques et le temps de développement. Si le signal se trouve à quelques sauts de clés dans les données, il y a de fortes chances de pouvoir remplacer le pipeline.