Dans la plupart des entreprises, les données utiles ne vivent pas dans un seul tableau. Elles sont dispersées entre plusieurs tables reliées : clients, commandes, produits, paiements, événements. Pour faire une prédiction, les équipes doivent souvent recoller tout ça, définir des variables, entraîner un modèle, puis maintenir le pipeline. Et, dans la vraie vie, le coût ne se limite pas au modèle : il faut aussi préparer les données et suivre les évolutions du produit.
NVIDIA propose justement une approche différente avec Kumo Relational : un modèle de fondation pré-entraîné pensé pour raisonner directement sur des données relationnelles. L'idée annoncée est simple sur le papier : traiter des requêtes prédictives (estimer un risque de résiliation, prévoir une demande future, etc.) sans devoir réentraîner un modèle pour chaque nouvelle tâche. Les résultats publiés sur plusieurs benchmarks donnent envie, mais ils ne suffisent pas à eux seuls à conclure que Kumo Relational va remplacer votre pipeline de machine learning en production. Voici comment il fonctionne, ce que montrent les évaluations, et les vérifications à faire avant de l'intégrer.
Pourquoi les données relationnelles compliquent le machine learning
Beaucoup d'applications métiers s'appuient sur des bases relationnelles. Un client est lié à des commandes, elles-mêmes reliées à des produits, à des moyens de paiement ou à des retours. Ces liens ne sont pas du « bruit » : ils portent de l'information (rythme d'achat, évolution du comportement, associations entre produits, enchaînement des événements dans le temps).
Avec des algorithmes classiques, les équipes finissent souvent par transformer ce graphe en table « plate ». On calcule par exemple le panier moyen sur les 30 derniers jours, le nombre de commandes, ou le délai depuis le dernier achat. Cette étape d'ingénierie de caractéristiques peut être pertinente : elle injecte une connaissance métier explicite dans le modèle. Mais elle coûte du temps, et certaines agrégations peuvent aussi faire disparaître des signaux plus fins qui existent pourtant dans les relations entre tables.
Le coût caché des modèles prédictifs
Dans un projet concret, entraîner un modèle n'est qu'une partie du travail. Il faut aussi :
- choisir une cible mesurable et éviter les fuites de données entre passé et futur ;
- construire des extractions fiables depuis plusieurs tables ;
- sélectionner et tester les caractéristiques ;
- comparer des approches, régler les paramètres ;
- surveiller les données, les performances et les dérives après déploiement.
Si votre cas d'usage est clair et que l'équipe a déjà les compétences ML, ce processus reste gérable. En revanche, quand chaque nouvelle question métier réclame son propre pipeline, ça peut vite devenir lourd. Prédire la résiliation d'abord, puis estimer une demande par produit ensuite : au final, plusieurs mois de travail et des composants difficiles à maintenir peuvent s'empiler.
C'est précisément là que Kumo Relational veut se placer. L'approche consiste à ne pas demander aux équipes de tout transformer en une table unique avant de commencer. Le modèle exploite les relations entre les enregistrements : la question prédictive ressemble davantage à une requête sur vos données qu'à un projet complet de préparation + entraînement.
Une promesse Ă mettre en contexte
NVIDIA présente Kumo Relational comme un modèle de fondation relationnel qui permet de faire des prédictions sans entraînement dédié à chaque tâche. Ça ne veut pas dire que le modèle n'a jamais été entraîné : il a été pré-entraîné sur des données relationnelles synthétiques. La promesse concerne surtout l'absence d'entraînement spécifique au moment où vous l'utilisez pour une nouvelle tâche.
Et c'est important. Un modèle pré-entraîné peut accélérer le démarrage, mais il ne « devine » pas vos objectifs, vos contraintes ni l'impact d'une décision métier. Vous devrez toujours définir ce que vous voulez prédire, contrôler la qualité des données, et évaluer le résultat dans le contexte réel où il servira.
Ce que montrent les résultats publiés
NVIDIA indique avoir évalué Kumo Relational sur 41 tâches réparties entre 15 bases relationnelles, issues notamment de RelBench V1 et V2, de SAP SALT et de 4DBInfer. Les domaines cités couvrent le commerce en ligne, la santé, les entreprises, les réseaux sociaux et des jeux plus académiques. NVIDIA précise aussi que ces jeux de données n'étaient pas utilisés pour le pré-entraînement.
L'entreprise affirme que le modèle dépasse les meilleurs systèmes supervisés comparés : des modèles d'apprentissage relationnel profond, et des pipelines avec des caractéristiques conçues par des experts. Le point intéressant, c'est que la comparaison porte sur des données structurées en relations, pas uniquement sur des tables plates.
Des benchmarks utiles, mais pas un verdict automatique
Sur les tâches de classification de RelBench V1, NVIDIA rapporte que Kumo Relational dépasse en moyenne les arbres de gradient boostés entraînés sur des caractéristiques conçues par des experts, d'environ quatre points d'AUROC. Sur SAP SALT, l'article mentionne une avance de sept points de MRR face à XGBoost avec des caractéristiques conçues, et de treize points après ajustement fin.
Sur SAP SALT, NVIDIA indique aussi une amélioration de 8 % du MRR par rapport à de grands ensembles AutoGluon, avec 16 % après ajustement fin. Ce sont des résultats publiés par l'équipe qui développe le modèle. Ils doivent donc être lus avec prudence : l'écart réel dépend toujours du protocole, de la tâche, des métriques, et surtout de votre contexte.
Un autre point concerne le compromis précision/temps de calcul. Sur RelArena-α, Kumo Relational apparaît sur la frontière de Pareto, avec un temps médian d'environ 17 secondes pour 1 000 échantillons. À l'inverse, l'entrée la mieux notée du classement serait environ 430 fois plus lente tout en restant proche en précision. Le message à retenir : ce sont des chiffres de benchmark, pas une garantie de latence identique pour toutes les bases, tous les GPU et tous les environnements.
Pourquoi ça peut parler aux équipes produit
L'enjeu n'est pas juste de grappiller quelques points de métrique. Si une équipe peut tester une hypothèse métier sans monter un pipeline complet à chaque fois, elle peut explorer plus vite des cas d'usage : anticipation des ruptures de stock, détection de comportements atypiques, estimation d'un risque de churn, ou priorisation de comptes.
Pour une entreprise française, on peut imaginer une plateforme e-commerce qui relie clients, commandes, articles et retours, ou un service B2B qui cherche à anticiper des renouvellements. Ce sont des exemples plausibles, pas une démonstration faite sur votre configuration exacte.
Ensuite, l'évaluation doit se faire sur la valeur opérationnelle : est-ce que la prédiction améliore une décision ? Peut-on agir à temps ? Le coût de calcul et d'intégration reste-t-il inférieur à votre approche actuelle ? Une meilleure métrique n'épuise pas ces questions.
Limites, risques et critères de décision
Kumo Relational est conçu pour les données où les relations et les dynamiques temporelles comptent. Dit autrement : l'approche a plus de chances d'être pertinente quand l'historique et les liens entre tables apportent un signal que vous ne retrouverez pas en regardant seulement une ligne isolée. Pour une tâche sur une table « simple », un modèle tabulaire classique peut rester plus direct à déployer et suffire en performance.
NVIDIA reconnaît aussi que des modèles supervisés dédiés peuvent rester meilleurs quand on dispose de très grands volumes d'exemples. Les évaluations citées utilisent jusqu'à 10 000 exemples de contexte, et l'ajustement fin est proposé quand maximiser la précision devient la priorité.
Démarrer avec un périmètre de données maîtrisé
Les signaux utiles doivent être accessibles via un nombre raisonnable de relations. NVIDIA recommande de commencer par une requête ciblée sur quelques tables, puis d'élargir le graphe seulement si les résultats suivent. Brancher « beaucoup de tables au cas où » n'est pas une stratégie neutre : ça augmente la complexité, le volume de données manipulé, et le risque d'inclure des informations inutiles (ou sensibles).
Un pilote réaliste peut suivre cette logique :
- Définir une décision métier précise et le coût d'une erreur.
- Choisir une cible, une fenêtre de prédiction, et une date de référence.
- Identifier les tables et relations strictement nécessaires.
- Comparer Kumo Relational à votre méthode actuelle, sur le même découpage temporel.
- Mesurer précision, latence, coût, stabilité et capacité à déclencher une action utile.
- Vérifier les erreurs par population et documenter les limites avant tout déploiement.
NVIDIA rapporte aussi de la stabilité même après suppression d'une partie des clés étrangères et ajout de colonnes bruitées. Il mentionne également de bons résultats avec une fraction réduite des données d'entraînement comme contexte. Ces tests de robustesse sont rassurants, mais ils ne remplacent pas une évaluation sur vos données : retards de mise à jour, différences de schéma ou changements de comportement peuvent produire un autre type d'erreurs.
Sécurité, RGPD et responsabilité métier
Le fait qu'un modèle traite des données d'entreprise ne veut pas dire qu'on peut les brancher sans analyse. Avant d'utiliser des données personnelles, il faut cadrer la finalité, la base légale, les durées de conservation, les accès et les transferts éventuels. Dans un contexte européen, l'évaluation doit s'inscrire dans les procédures RGPD et les règles de sécurité internes.
Il faut aussi clarifier le mode de déploiement. NVIDIA cite une bibliothèque open source native GPU, des connecteurs et une option NVIDIA NIM. Ces choix ne sont pas interchangeables : où les données sont-elles traitées ? Quels journaux sont conservés ? Qui gère les mises à jour, les poids et les incidents ? Le détail dépend du déploiement retenu, donc il faut vérifier dans la documentation et les conditions applicables.
Enfin, une prédiction n'est pas une décision. Si votre usage affecte directement des personnes (accès à un service, tarification, traitement d'un dossier), il faut regarder les effets des erreurs, les biais possibles et les mécanismes de contestation. L'automatisation est plus simple à justifier quand elle assiste un professionnel, avec supervision et traçabilité adaptées, plutôt que quand elle déclenche seule une décision difficile à corriger.
Conclusion
Kumo Relational vise un vrai problème en entreprise : exploiter les relations entre tables sans reconstruire un pipeline d'ingénierie de caractéristiques et d'entraînement pour chaque question. Les résultats rapportés sur RelBench et SAP SALT rendent l'approche intéressante à tester, en particulier quand les relations et l'historique temporel font une grande partie du signal.
Mais la décision ne devrait pas reposer uniquement sur un classement. Commencez par un cas d'usage étroit, comparez avec votre solution actuelle, et mesurez à la fois le coût opérationnel et la qualité prédictive. Ensuite, vérifiez la gouvernance des données, la latence et les conséquences des erreurs. Si ces points sont bons, l'apprentissage en contexte peut effectivement réduire le délai entre une question métier et un premier système testable.
Pour aller plus loin, consultez la documentation officielle de Kumo Relational et lancez un pilote sur des données dont la finalité et les règles d'accès sont déjà cadrées.
Comment fonctionne Kumo Relational
Kumo Relational prend en entrée une demande prédictive, les entités concernées et les tables liées. Ensuite, le système construit un contexte à partir d'exemples historiques : chaque exemple relie une partie du graphe relationnel (observée à un instant donné) à une cible connue. Le modèle peut utiliser jusqu'à 10 000 exemples de contexte pour produire une prédiction, en une passe.
On appelle ça de l'apprentissage en contexte. L'objectif n'est pas de mettre à jour les poids du modèle pour chaque nouvelle tâche : au moment de la prédiction, on lui fournit des exemples pertinents. Pour une entreprise, l'intérêt est de pouvoir tester une tâche sans repartir à zéro avec un entraînement dédié.
Une requête prédictive décrit le résultat visé
Les tâches sont exprimées via le Predictive Query Language (PQL). Cette interface déclarative sert à décrire ce qu'il faut prédire, sans détailler toutes les transformations techniques nécessaires.
Par exemple, une équipe peut vouloir estimer le nombre de commandes passées par chaque utilisateur dans les 30 prochains jours. La requête porte sur l'entité, une mesure, et une fenêtre temporelle. Kumo Relational exploite ensuite les liens entre les tables correspondantes. L'exemple donné par NVIDIA ressemble à ceci :
PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id.En pratique, « plus simple » ne veut pas dire « sans travail ». Il faut toujours décider ce que vous prédisez (commandes, chiffre d'affaires, risque de désabonnement), choisir une période pertinente, et vérifier que la cible peut être calculée sans utiliser d'informations qui arrivent après la date de référence.
Le modèle travaille dans les tables, pas seulement dans des lignes
Le traitement se fait en plusieurs étapes. D'abord, un réseau analyse les colonnes et les lignes de chaque table pour repérer les valeurs et les enregistrements utiles à la tâche. Ensuite, un réseau plus large propage des représentations de lignes à travers les relations, via les clés primaires et étrangères. L'idée est que le modèle peut relier, par exemple, le profil d'un utilisateur à son historique de transactions.
Le système compare aussi les exemples de contexte entre eux et avec l'entité à prédire. D'après NVIDIA, représenter des lignes plutôt que chaque cellule individuellement permet d'éviter un coût quadratique, tout en gérant des contextes plus larges.
Pour les tâches qui dépendent du temps, il faut respecter la chronologie : le modèle reçoit les données disponibles avant une date de référence, et la cible est calculée à partir d'événements ultérieurs. Ce mécanisme vise à éviter la fuite de données, un problème qui rend souvent les évaluations plus optimistes que ce qui se passe en production.
Un pré-entraînement sur des données synthétiques
Les données d'entreprise prêtes pour l'entraînement ne sont généralement pas publiques. NVIDIA explique donc avoir pré-entraîné le modèle sur des bases synthétiques conçues pour reproduire des caractéristiques de données réelles : schémas variés, relations entre lignes, tendances temporelles et dépendances entre tables.
Cette approche, associée au générateur PluRel, permet de créer des jeux de données sans exposer directement des bases métier. L'objectif est de donner au modèle l'occasion d'apprendre des motifs relationnels variés. Reste que rien ne garantit que chaque structure synthétique corresponde parfaitement à votre réalité, ni que les signaux appris soient directement transférables à toutes les tâches.