Kumo sait prédire, mais ne sait pas ce qui est valide

La promesse: zéro feature engineering sur le relationnel

Nvidia a récemment ouvert Kumo, une plateforme qui combine modèles tabulaires et accès relationnel. L'argument commercial est fort: prédire sans construire de features, directement sur les schémas normalisés. Des chiffres circulent, comme une précision de 89 % en zero-shot sur le benchmark SAP SALT. Pour un décideur, cela ressemble à un raccourci majeur: plus besoin d'aplatir des dizaines de tables, le modèle s'en charge.

Le terrain réel: une table propre n'existe pas

En entreprise, les données utiles à la prédiction ne sont presque jamais dans une table unique. Elles vivent dans des data warehouses normalisés, des star schemas imbriqués, des centaines de tables où la sémantique est implicite. Une colonne total n'est pas un nombre, c'est le résultat d'un calcul quantity unit_price (1 - discount) + tax. Un modèle tabulaire voit trois colonnes numériques; il ne voit pas la règle de calcul. Cette distinction entre observer des valeurs et comprendre les règles qui les produisent est fondamentale.

La barrière formelle

Un papier récent le démontre de façon élégante. Les auteurs construisent des paires d’états de base de données: l’un respecte les règles métier, l’autre les viole, mais leurs colonnes ont des distributions quasi identiques. Résultat: XGBoost, TabPFN et TabICL obtiennent 50 % de précision, soit le hasard, et la théorie montre qu’aucun modèle qui ne regarde que les valeurs ne peut faire mieux. Les LLM ne s’en sortent pas mieux, même avec le schéma, le code des triggers et un exécuteur SQL. En revanche, un simple classifieur alimenté par des contrôles dérivés des règles métier atteint 100 %. Le problème n’est pas la puissance du modèle, c’est l’accès aux règles.

Le même schéma se reproduit sur un second domaine, un registre bancaire avec des règles de solde inter-lignes et d'agrégats cumulés. La conclusion est robuste: sans ancrage opérationnel, ni l'échelle, ni la richesse des features ne suffisent [1].

La conséquence architecturale: une chaîne d'agents, pas un modèle magique

Kumo Relational supprime l'étape d'aplatissement, mais pas les étapes amont. Pour passer d'un schéma d'entreprise à une prédiction, il faut une chaîne d'agents: découverte du schéma, sélection des tables pertinentes, construction de la vue ou du sous-graphe, définition de la cible, puis inférence. Chaque étape introduit une probabilité d'erreur. Si chaque étape réussit avec une probabilité p, la chaîne complète réussit avec p^N. Avec p = 0,9 et cinq étapes, on obtient environ 0,59: un pipeline où chaque étape réussit 9 fois sur 10, échoue une fois sur deux. C'est le vrai problème du zero-shot en conditions réelles: les erreurs se composent silencieusement.

Le goulot d'étranglement: la couche sémantique et la vérification

Le papier cité plus haut montre que les audits dérivés des règles exécutables permettent de passer de 0,50 à 1,00. Autrement dit, pour tout ce qui relève de la conformité aux règles, ce qui manque n’est pas un meilleur modèle, mais un accès aux contraintes déclaratives, aux triggers, à la logique métier. Dans une architecture d'entreprise, cela signifie que l'investissement doit porter sur la couche sémantique.

Recommandation pour les décideurs

Kumo et les modèles tabulaires sont de bons outils de prédiction. Ils ne savent pas ce qui est valide dans votre métier, et la chaîne d’agents nécessaire pour les brancher sur votre warehouse multiplie les points d’échec. Avant de déployer:

Séparez prédire et valider. Le modèle estime un risque ; vos règles métier, rendues exécutables, décident de ce qui est conforme. Ne demandez pas au premier de faire le travail des secondes.

• Raccourcissez la chaîne. Chaque vue métier pré-validée est une étape d’agent en moins, donc une source d’erreur en moins.
• Vérifiez entre les étapes. Un contrôle explicite après la sélection des tables et la définition de la cible coûte peu et évite que l’erreur se propage.
• Mesurez de bout en bout. Une précision affichée par modèle ou par étape ne dit rien de la fiabilité du pipeline complet.

Le modèle est la partie facile. Le travail est de rendre vos règles interrogeables et votre chaîne courte. C’est un chantier d’architecture, pas de data science.