Comparer les modèles de fondation relationnels

Nous avons évalué SAP-RPT-1-OSS par rapport au gradient boosting (LightGBM, CatBoost) sur 17 jeux de données tabulaires couvrant le spectre sémantique-numérique, des tables petites/hautement sémantiques, des jeux de données métier mixtes et de grands jeux de données numériques à faible sémantique.

Notre objectif est de mesurer où les a priori sémantiques pré-entraînés d’un LLM relationnel peuvent offrir des avantages par rapport aux modèles arborescents traditionnels et où ils rencontrent des difficultés en cas d’échelle ou de structure à faible sémantique.

SAP-RPT-1-OSS vs Gradient Boosting : Résultats du benchmark

• Taux de réussite : Représente le score normalisé moyen (0.0 à 1.0). Une barre plus haute indique que le modèle est régulièrement plus proche de la meilleure performance possible pour les jeux de données de cette catégorie.
• 100 – 500 lignes (3 jeux de données) :
  • Inclus : wine (178), sonar (208), vote (435).
  • Résultat : SAP obtient les meilleurs résultats sur 2 des 3 jeux de données. Il atteint les scores les plus élevés sur wine et sonar, ce qui suggère que les a priori du LLM peuvent être bénéfiques lorsque les données d’entraînement sont rares. Cependant, CatBoost a remporté une victoire étroite sur le jeu de données vote (à moins de 0,1 % près), ce qui indique que les modèles arborescents restent très compétitifs même à petite échelle.
• 501 – 1 000 lignes (3 jeux de données) :
  • Inclus : cylinder_bands (540), breast_cancer (569), credit_g (1 000).
  • Résultat : SAP obtient les meilleurs résultats sur les 3 jeux de données. Sur cylinder_bands, SAP a surpassé LightGBM d’une marge de 5,5 %, potentiellement grâce à une meilleure gestion des descriptions sémantiques des défauts industriels, bien que des études d’ablation supplémentaires soient nécessaires pour confirmer ce mécanisme.
• 1 000 – 10 000 lignes (5 jeux de données) :
  • Inclus : titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
  • Résultat : SAP obtient les meilleurs résultats sur 4 jeux de données sur 5, avec de très bonnes performances sur les tâches riches en texte comme spambase et titanic. Cependant, CatBoost surpasse nettement SAP sur compas de 10,4 %, ce qui indique des caractéristiques propres au jeu de données qui favorisent les modèles arborescents même dans cette plage de taille.
• 10 000+ lignes (6 jeux de données) :
  • Inclus : california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs_100k (98K).
  • Résultat : À mesure que le volume de données augmente, l’avantage potentiel de « connaissances préalables » du LLM diminue. LightGBM et CatBoost obtiennent les meilleurs résultats sur 5 des 6 jeux de données, offrant une meilleure précision pour une fraction du coût de calcul. La seule exception, california_housing, montre un avantage modeste de 1,7 % pour SAP.

1. Tableau des jeux de données des résultats du benchmark

Vous trouverez ci-dessous la répartition complète des performances des modèles sur l’ensemble des 17 jeux de données.

2. Analyse des coûts et de l’efficacité

Nous avons calculé le coût de calcul direct pour chaque modèle sur la base du tarif de l’instance RunPod H200 de $3,59/heure.

SAP-RPT-1-OSS entraîne des coûts nettement plus élevés en raison du temps nécessaire au prétraitement des plongements de texte et de la lourde surcharge mémoire de l’architecture du LLM. En revanche, LightGBM et CatBoost exécutent les tâches presque instantanément sur ce matériel. Les coûts ci-dessous reflètent le temps total écoulé (prétraitement + entraînement) pour une exécution de validation croisée à 3 plis.

Coût moyen par jeu de données (moyenne sur 17 jeux de données)

Répartition des coûts par taille de jeu de données

• Petits jeux de données (<1K lignes) : SAP est relativement bon marché (≈ $0,03 par exécution). Le taux de réussite élevé rend ici le coût négligeable.
• Grands jeux de données (>20K lignes) : SAP devient coûteux.
  • Exemple : L’entraînement sur adult_income (48k lignes) prend environ $12 minutes au total pour 3 plis.
  • Coût : 12 min × $0,06/min = $0,72 par expérience.
  • Comparaison : LightGBM termine la même tâche pour $0,01.

Conclusion : Bien que $0,22 par jeu de données ne soit pas coûteux en valeur absolue, SAP est 22x plus cher que la référence. Cette différence de coût peut se justifier pour de petits jeux de données riches en sémantique où SAP montre des améliorations de précision significatives (par exemple, cylinder_bands avec un gain de +5,5 %), mais devient plus difficile à justifier pour de grands jeux de données où les modèles arborescents atteignent des performances égales ou meilleures pour une fraction du coût.

3. Cadre d’analyse : le spectre sémantique

Pour interpréter ces résultats, il est essentiel de comprendre comment nous avons sélectionné les données. Nous n’avons pas choisi les jeux de données au hasard ; nous avons constitué une suite de 17 jeux de données spécifiquement choisis pour couvrir le spectre sémantique-numérique.

Notre hypothèse centrale était que SAP (étant basé sur un LLM) excellerait là où les données ont une signification linguistique, tandis que les modèles arborescents domineraient dans le calcul numérique brut. Nous avons classé nos jeux de données en trois groupes distincts :

Groupe A : jeux de données à forte sémantique (6 jeux de données)

Caractéristiques : Les caractéristiques contiennent de riches descriptions textuelles, des étiquettes catégorielles ayant une signification réelle (par exemple, « gel des honoraires des médecins ») ou une terminologie propre au domaine.

• Jeux de données :
  • cylinder_bands : défauts d’impression industrielle.
  • titanic : noms et titres des passagers.
  • vote : enregistrements de votes du Congrès (catégoriel « Oui/Non » sur les politiques).
  • breast_cancer : descriptions médicales de tumeurs.
  • spambase : fréquences des mots dans les e-mails.
  • wine : origines chimiques.

Groupe B : données métier mixtes (6 jeux de données)

Caractéristiques : Le format tabulaire standard que l’on trouve dans la plupart des bases de données d’entreprise, un mélange de valeurs numériques (salaire, âge) et de chaînes catégorielles (intitulé de poste, origine, service).

• Jeux de données :
  • employee_salaries : intitulés de poste par rapport au salaire.
  • compas : antécédents judiciaires et données démographiques (attributs sensibles).
  • adult_income : données démographiques de recensement.
  • credit_g : profils de risque de crédit allemands.
  • default_credit : données de défaut de crédit de Taïwan.
  • car_evaluation : paramètres d’achat de véhicule.

Groupe C : données à faible sémantique / purement numériques (5 jeux de données)

Caractéristiques : Les caractéristiques sont des mesures abstraites, des relevés de capteurs ou des coordonnées physiques. Les noms de colonnes n’ont souvent pas d’importance ; ce sont les relations mathématiques qui comptent.

• Jeux de données :
  • higgs_100k : cinématique des particules physiques.
  • diamonds : dimensions physiques et prix.
  • sonar : rebonds d’énergie de fréquence.
  • california_housing : coordonnées lat/long et statistiques de recensement.
  • house_sales : immobilier du comté de King (caractéristiques essentiellement numériques).

4. Analyse approfondie : où SAP réussit et échoue

L’application du cadre d’analyse à nos résultats révèle quatre schémas de performance distincts. Le tableau ci-dessous résume exactement où SAP excelle et où il échoue.

Fondements conceptuels des modèles de fondation relationnels

L’objectif principal d’un modèle de fondation relationnel est de faire des prédictions précises et d’effectuer diverses tâches sur des tables structurées. Ces modèles doivent comprendre comment l’information est représentée dans différentes tables, comment les entités sont liées par des relations et comment les informations temporelles influencent les résultats.

Les principales capacités de ces modèles sont les suivantes :

• Généralisation de schéma : la capacité de s’adapter à de nouveaux schémas relationnels sans réentraînement à partir de zéro.
• Représentation d’entrée unifiée : gérer différents types de colonnes tels que les caractéristiques numériques, catégorielles et textuelles.
• Intégration du contexte temporel et structurel : capturer les dépendances dans le temps et entre les entités liées par des clés primaires et étrangères.
• Transférabilité : exécuter des tâches prédictives sur de nouveaux jeux de données grâce au pré-entraînement et à l’apprentissage zéro-shot.

Griffin

Griffin est l’une des premières tentatives à grande échelle de construction d’un modèle de fondation relationnel unifié. Il représente les données relationnelles sous la forme d’un graphe temporel et hétérogène, où chaque ligne devient un nœud et les arêtes correspondent aux relations par clés étrangères. Les principales caractéristiques sont les suivantes :

Encodeur de caractéristiques unifié

• Les caractéristiques catégorielles et textuelles sont encodées à l’aide d’un encodeur de texte pré-entraîné, tandis que les valeurs numériques utilisent un encodeur de nombres réels appris.
• Les métadonnées telles que les noms de tables, les noms de colonnes et les types d’arêtes sont intégrées pour aider le modèle à reconnaître le schéma relationnel.
• Les plongements de tâche permettent à un seul modèle d’effectuer des tâches de régression et de classification avec des décodeurs partagés.

Passage de messages et attention

Griffin intègre des réseaux neuronaux à passage de messages avec un module d’attention croisée. Le composant de passage de messages agrège les informations au sein des relations et entre celles-ci, tandis que l’attention croisée se concentre sur les cellules pertinentes de chaque ligne. Cette conception aide le modèle à gérer des données diverses et à maintenir le contexte entre les entités connectées.

Pré-entraînement et ajustement fin

Le modèle est pré-entraîné sur des jeux de données à table unique via une tâche de complétion de cellules masquées, puis ajusté finement sur des bases de données relationnelles pour des tâches spécifiques. Les expériences sur de grands benchmarks relationnels montrent que Griffin surpasse les modèles de référence GNN traditionnels et les modèles à table unique, tant en précision qu’en efficacité d’apprentissage par transfert.

Figure 1 : graphique montrant le cadre du modèle Griffin.¹

Relational transformer

Alors que Griffin se concentre sur l’agrégation de graphes, le Relational Transformer (RT) applique les architectures de type Transformer directement aux bases de données relationnelles. Il traite chaque cellule comme un token enrichi de sa valeur, du nom de colonne et du nom de table.

Représentation d’entrée

Chaque token combine :

• Un plongement de valeur qui dépend de son type de données (numérique, texte ou datetime).
• Un plongement de schéma est généré à partir du texte de la table et de la colonne.
• Un token de masque est utilisé lorsque la valeur est masquée pendant le pré-entraînement.

Cette structure permet à RT de traiter des bases de données relationnelles avec différents schémas tout en maintenant un format d’entrée cohérent.

Attention relationnelle

RT introduit un mécanisme d’attention relationnelle qui opère au niveau de la cellule. Il comprend :

• Attention de colonne pour apprendre les distributions de valeurs au sein des colonnes.
• Attention de caractéristiques pour combiner les attributs dans la même ligne ou dans les lignes parentes liées.
• Attention des voisins pour agréger les informations des lignes enfants connectées.

Together, ces couches d’attention forment un transformeur de graphe relationnel qui modélise les dépendances entre les lignes, les colonnes et les tables.

Résultats d’entraînement et de transfert

RT est pré-entraîné sur des bases de données relationnelles de RelBench. Dans les expériences, le modèle pré-entraîné a atteint jusqu’à 94 % des performances des modèles entièrement supervisés en configuration zéro-shot. Il a également appris plus rapidement lors de l’ajustement fin, nécessitant moins d’étapes d’entraînement pour atteindre une précision élevée.²

Cette approche suggère que les bases de données relationnelles partagent des schémas transférables entre domaines et que la tokenisation au niveau des cellules fournit une base pratique pour les tâches prédictives sur des données structurées.

RelBench

RelBench est conçu pour faire progresser l’apprentissage profond relationnel, qui se concentre sur l’apprentissage de bout en bout à partir de données réparties sur plusieurs tables liées dans des bases de données relationnelles.

Comme les bases de données relationnelles restent le système de gestion de données dominant dans l’industrie et la science, RelBench fournit un cadre standardisé et reproductible pour évaluer les modèles qui opèrent directement sur les structures relationnelles plutôt que de recourir à un aplatissement manuel des caractéristiques.

Les versions antérieures de RelBench ont introduit 11 bases de données relationnelles couvrant des domaines tels que la santé, les réseaux sociaux, le e-commerce et le sport, avec 70 tâches prédictives conçues pour être à la fois difficiles et pertinentes pour le domaine.³

En janvier 2026, RelBench v2 a été publié, ajoutant quatre nouvelles bases de données (SALT, RateBeer, arXiv et MIMIC-IV) et 40 tâches prédictives supplémentaires, dont une nouvelle classe de tâches d’autocomplétion qui évaluent la capacité d’un modèle à prédire des colonnes existantes dans une base de données relationnelle.

Cette version a également élargi l’accès aux données grâce à l’intégration CTU, permettant d’accéder à plus de 70 jeux de données relationnels via ReDeLEx ; a ajouté une connectivité directe aux bases de données SQL ; et a incorporé sept jeux de données du dépôt 4DBInfer au format RelBench.

Au-delà des jeux de données et des tâches, RelBench fournit une implémentation de référence open source pour l’apprentissage profond relationnel basé sur les réseaux de neurones sur graphes, en utilisant PyTorch Geometric pour la construction de graphes et PyTorch Frame pour la modélisation tabulaire, ainsi qu’un classement public pour suivre les progrès.

La version v2 a également introduit plusieurs améliorations d’utilisabilité et de performance, notamment des étiquettes censurées dans le temps en option, la prise en charge de la métrique NDCG dans la prédiction de liens, une génération plus rapide des plongements de phrases et une gestion configurable du cache.⁴

VIEIRA

VIEIRA adopte une approche différente en se concentrant sur la programmation avec des modèles de fondation plutôt que sur la construction d’un moteur prédictif unique. Il étend le compilateur de logique probabiliste SCALLOP avec un langage déclaratif qui intègre de grands modèles de langage, des modèles de vision et d’autres composants pré-entraînés comme prédicats externes.⁵

Paradigme relationnel

Dans VIEIRA, les modèles de fondation sont traités comme des fonctions sans état avec des entrées et sorties relationnelles. Cela permet de composer des modèles tels que GPT, CLIP ou SAM selon des règles logiques. Par exemple :

• Un programme peut utiliser GPT pour extraire des connaissances d’un texte et les stocker sous forme de relations structurées.
• CLIP peut classer des images et les relier à des étiquettes textuelles dans une table.

Applications

Le cadre prend en charge :

• Le raisonnement sur les dates et les mathématiques à l’aide de GPT.
• Le raisonnement sur la parenté à l’aide de l’extraction de texte et de l’inférence logique.
• La réponse à des questions combinant recherche et raisonnement.
• La réponse à des questions visuelles et l’édition d’images par composition multimodale.

En unifiant la logique symbolique et l’inférence neuronale, VIEIRA permet aux analystes de données et aux développeurs de créer des systèmes interprétables qui utilisent des modèles de fondation pré-entraînés pour répondre à des requêtes prédictives sur des données structurées et des images.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Études de cas

SAP Hana Cloud

SAP HANA Cloud est un service de base de données cloud-natif entièrement géré, conçu pour servir de socle de données unifié aux applications d’entreprise qui combinent transactions, analytique et IA. Plutôt que de servir de base de données relationnelle à usage unique, SAP HANA Cloud se positionne comme une plateforme multi-modèle qui permet aux organisations de créer des « applications de données intelligentes » au-dessus des données métier opérationnelles.

SAP HANA Cloud combine le traitement en mémoire avec un stockage sur disque et une intégration de data lake pour répondre à différentes exigences de performance et de coût. Cette conception flexible prend en charge les charges de travail en temps réel tout en évoluant dynamiquement à mesure que les volumes de données et l’utilisation fluctuent.

Un différenciateur clé est son moteur multi-modèle natif, qui prend en charge les données relationnelles, JSON/document, de graphe, spatiales et vectorielles au sein d’une même base de données. Cela permet aux applications de combiner des requêtes SQL, des relations de graphe et une recherche de similarité vectorielle sans déplacer les données entre des systèmes distincts, simplifiant ainsi l’architecture et réduisant la latence.

Dans le cadre de SAP Business Technology Platform, SAP HANA Cloud s’intègre directement aux sources de données SAP et non SAP, y compris un accès en direct sans réplication, et offre par défaut une sécurité, une disponibilité et une conformité de niveau entreprise.

Globalement, SAP HANA Cloud est une plateforme de données centrée sur le relationnel et native pour l’IA, dans laquelle la base de données relationnelle sert de couche fondamentale pour l’analytique, les données multi-modèles et les applications d’IA d’entreprise.

Figure 2 : image montrant la base de données unifiée de Hana et le
traitement de données multi-modèle.⁶

sap-rpt-1 de SAP

sap-rpt-1 introduit un modèle de fondation relationnel unique qui effectue un large éventail de tâches prédictives par apprentissage en contexte. Au lieu de réentraîner un nouveau modèle pour chaque cas d’usage, les utilisateurs fournissent quelques exemples de leur schéma cible, comme « clients qui ont payé à temps » et « clients qui ont payé en retard ». Le modèle reconnaît alors le schéma et produit immédiatement des prédictions précises pour de nouvelles données.

Le modèle est conçu avec un mécanisme d’attention bidimensionnel qui capture les relations entre les lignes et les colonnes, tout en intégrant également les métadonnées, telles que les noms de tables et de colonnes, dans des plongements vectoriels. Cette conception lui permet de comprendre la sémantique des schémas relationnels et les informations temporelles au sein des tables métier.

L’approche de SAP présente plusieurs avantages pour les analystes de données et les utilisateurs métier :

• Un modèle unique qui fonctionne sur plusieurs tables et domaines.
• Aucun besoin d’ajustements fins répétés ni de développement personnalisé.
• Accès à des informations prédictives en quelques minutes plutôt qu’en quelques semaines.
• Intégration avec les entrepôts de données et les systèmes SAP existants.

En intégrant sap-rpt-1 dans l’écosystème SAP, les experts métier peuvent interagir directement avec leurs propres données et recevoir des prédictions via des interfaces intuitives. Le résultat est un chemin plus rapide des données structurées aux décisions exploitables, sans ingénierie manuelle des caractéristiques.

Figure 3 : facteur de réduction des erreurs de sap-rpt-1-large par rapport aux références d’IA étroite dans les domaines SAP.

Fin 2025, SAP a confirmé que SAP-RPT-1 est disponible via le hub d’IA générative dans SAP IA Foundation (SAP IA Core).

Le modèle est proposé en deux variantes de production :

• SAP-RPT-1-small, optimisé pour des prédictions à faible latence et à haut débit,
• SAP-RPT-1-large, conçu pour privilégier la précision prédictive.

Cette version officialise le rôle de SAP-RPT-1 en tant que modèle de fondation déployable au sein de la pile d’IA d’entreprise de SAP, plutôt que comme une capacité réservée à la recherche.

De plus, SAP propose le SAP-RPT Playground, un environnement sans code et basé sur le Web où les utilisateurs peuvent tester l’apprentissage en contexte avec leurs propres données ou des données d’exemple fournies par SAP.

SAP-ABAP-1

SAP-ABAP-1 est un modèle de fondation conçu pour soutenir les cas d’usage de productivité des développeurs basés sur l’IA pour les clients et partenaires SAP.

Il est disponible via le hub d’IA générative de SAP et est entraîné sur plus de 250 millions de lignes de code ABAP, 30 millions de lignes de code CDS et une documentation technique approfondie. Le modèle est optimisé pour comprendre et expliquer le code ABAP, faire ressortir les bonnes pratiques et fournir un accès à des connaissances de développement SAP à jour.

SAP propose un accès d’essai gratuit à SAP-ABAP-1 via le hub d’IA générative, avec des fonctionnalités supplémentaires prévues pour 2026.⁷

KumoRFM de Kumo.IA : un transformeur de graphe relationnel pour l’analytique prédictive

Kumo.IA, fondée par le professeur de Stanford Jure Leskovec, a créé KumoRFM, un modèle de fondation relationnel qui utilise un transformeur de graphe relationnel pour analyser les bases de données relationnelles et les entrepôts de données. Il représente les données relationnelles sous forme de graphe temporel hétérogène, où chaque entité est un nœud et où les clés primaires et étrangères forment des arêtes entre les tables.

Cette approche basée sur les graphes permet à KumoRFM d’apprendre simultanément à partir de plusieurs tables et de s’adapter à de nouveaux schémas relationnels. Le modèle est pré-entraîné sur des sources de données diverses et peut se généraliser à de nouveaux jeux de données sans créer de modèles distincts pour chaque tâche prédictive.

KumoRFM peut être utilisé via différentes interfaces selon l’expertise de l’utilisateur :

• PQL (Predictive Query Language) : un langage de requête spécialisé pour définir des requêtes prédictives sur des données structurées.
• Interface en langage naturel : pour les utilisateurs non techniques, les entrées en langage naturel sont automatiquement traduites en requêtes PQL.
• SDK Python : permet aux développeurs d’intégrer le modèle dans les pipelines d’IA d’entreprise et les applications.

L’architecture de KumoRFM échantillonne dynamiquement la base de données pour créer des sous-graphes de contexte et des sous-graphes de prédiction. Ces sous-graphes sont traités par le transformeur de graphe relationnel, qui capture les dépendances et les informations temporelles entre les entités liées. Grâce à l’apprentissage en contexte, le modèle fournit des prédictions précises et peut expliquer son processus de raisonnement.

Kumo propose deux options de déploiement adaptées aux environnements d’entreprise :

• Plateforme SaaS : un service cloud basé sur Apache Spark pour un accès et une mise à l’échelle faciles
• Natif pour entrepôt de données : permet aux organisations d’utiliser leurs propres données dans Snowflake ou Databricks sans les déplacer en dehors de leur environnement sécurisé

Contrairement aux graphes de connaissances traditionnels qui exigent une définition manuelle du schéma, KumoRFM construit automatiquement son graphe relationnel à partir de sources structurées. Cela le rend particulièrement adapté au commerce électronique, à la finance et à la santé, où les relations, les schémas temporels et le contexte évolutif sont essentiels pour des prédictions fiables.

Les capacités clés de KumoRFM incluent :

• Flexibilité entre différentes tables et structures de schéma.
• Compatibilité avec divers types de colonnes et identifiants personnalisés.
• Adaptation à des tâches spécifiques pendant le temps d’inférence.
• Haute précision et interprétabilité dans les tâches prédictives.

Figure 4 : l’image montre comment les modèles de fondation relationnels (RFM) fonctionnent dans plusieurs domaines, tels que le commerce électronique, la finance et la santé, pour faire des prédictions, fournir des explications et évaluer les résultats.⁸

Méthodologie de l’évaluation comparative

Configuration et environnement du benchmark

Pour garantir des comparaisons équitables entre les modèles arborescents liés au CPU et les modèles accélérés par GPU, nous avons utilisé un environnement haute performance capable de gérer les deux efficacement.

• Matériel : instance RunPod avec un NVIDIA H200 140GB GPU.
• Logiciel : Python 3.12 avec des bibliothèques figées pour la reproductibilité :
  • scikit-learn 1.5.2, lightgbm 4.5.0, catboost 1.2.7
  • torch 2.5.1, pandas 2.2.3, numpy 2.1.3
  • sap-rpt-oss (source : GitHub officiel)
• Reproductibilité : random_state=42 a été utilisé de manière cohérente pour toutes les divisions, initialisations et modèles.

Jeux de données : le spectre sémantique

Nous avons évalué les modèles sur 17 jeux de données d’apprentissage supervisé provenant d’OpenML et de Scikit-Learn. Plutôt qu’une sélection aléatoire, nous avons constitué cette suite pour couvrir le « spectre sémantique-numérique » afin de tester l’hypothèse selon laquelle les LLM excellent lorsque les caractéristiques contiennent une signification linguistique plutôt que des statistiques brutes.

L’inventaire :

• Petits et sémantiques (<1K lignes) :
  • wine (178), sonar (208), vote (435), cylinder_bands (540), breast_cancer (569).
• Moyens/mixtes (1K – 10K lignes) :
  • credit_g (1K), titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
• Grands/numériques (10K+ lignes) :
  • california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs (échantillonné à 100K).

Tâches couvertes :

• 11 tâches de classification binaire
• 2 tâches de classification multiclasse
• 4 tâches de régression

Configurations des modèles et prétraitement

Nous avons visé une « comparaison de praticien » réaliste, en utilisant des valeurs par défaut robustes plutôt qu’un réglage exhaustif des hyperparamètres.

LightGBM et CatBoost

Pour garantir une comparaison équitable avec le modèle SAP, lourd en calcul, nous avons augmenté les estimateurs par défaut robustes.

• LightGBM : n_estimators=500, learning_rate=0.05, num_leaves=31. S’exécute sur CPU (n_jobs=-1).
• CatBoost : iterations=500, learning_rate=0.05, depth=6. S’exécute sur GPU (task_type=”GPU”).
• Prétraitement : encodage simple des étiquettes pour les variables catégorielles ; pas de mise à l’échelle pour les variables numériques ; imputation médiane/mode pour les valeurs manquantes.

SAP-RPT-1-OSS

Nous avons configuré SAP pour équilibrer performance et coût sur la base de nos expériences de configuration préliminaires.

• Configuration : max_context_size=4096, bagging=4.
• Remarque :
  • Contexte : les tests sur adult_income ont montré que faire passer le contexte de 4096 à 8192 triplait le temps d’exécution (4 min à 12 min) pour un gain de précision négligeable (0.917 contre 0.917 ROC-AUC).
  • Bagging : faire passer le bagging de 4 à 8 (paramètre par défaut de SAP utilisé dans l’article⁹) a offert des rendements décroissants.
• Prétraitement : Aucun. Le DataFrame pandas brut est transmis directement. Le modèle encode à l’aide de plongements de texte (sentence-transformers/all-MiniLM-L6-v2).

Protocole d’évaluation

Stratégie de validation croisée

Nous avons utilisé une validation croisée à 3 plis avec mélange.

• Nous avons réduit la validation standard de 5 plis à 3 plis pour tenir compte des temps d’inférence lents de SAP (40 % d’économie de temps) tout en maintenant la validité statistique.
• Division : StratifiedKFold pour la classification ; K-Fold standard pour la régression.

Métriques et diagnostics

Nous sommes allés au-delà de la simple précision pour obtenir une vue globale des performances des modèles :

• Métriques de classement principales : ROC-AUC (binaire), précision équilibrée (multiclasse), R² (régression).
• Diagnostics secondaires : nous avons suivi le coefficient de corrélation de Matthews (MCC) et la log loss pour garantir que les victoires n’étaient pas des artefacts de déséquilibre des classes, ainsi que la MAPE pour l’étalonnage des erreurs de régression.
• Calcul des coûts : basé sur le temps total écoulé (prétraitement + entraînement + inférence) sur l’instance RunPod H200 ($3,59/h).

Significativité statistique

Nous avons appliqué un test de rang signé de Wilcoxon (p<0.05) aux comparaisons de modèles par paires afin de déterminer si les différences de performance étaient statistiquement significatives ou dues au bruit aléatoire.

Limites et validité interne

Nous reconnaissons explicitement les contraintes suivantes dans notre méthodologie :

1. Configurations standardisées ou réglage : nous avons utilisé des configurations par défaut fixes et robustes pour tous les modèles plutôt que d’effectuer une optimisation exhaustive des hyperparamètres (par exemple, CV imbriquée ou balayages Optuna). Si cela garantit une référence cohérente, il convient de noter que les modèles arborescents gagnent souvent en performance avec un réglage spécifique au jeu de données, ce qui pourrait réduire les marges dans le groupe « Concurrentiel ».
2. Limites d’échelle des données : notre analyse s’est concentrée sur des jeux de données de moins de 100k lignes pour simuler des scénarios d’entreprise typiques de taille moyenne. Nous avons observé que l’avantage du LLM diminuait à mesure que le volume de données augmentait, mais nous n’avons pas étendu les tests à des échelles d’un million de lignes où la latence d’inférence et le coût deviendraient probablement les principales contraintes.
3. Uniformité de l’infrastructure : pour maintenir un environnement de test cohérent, nous avons exécuté tous les modèles sur le même matériel NVIDIA H200. LightGBM et CatBoost sont hautement optimisés pour les CPU grand public ; par conséquent, dans un environnement de production dédié uniquement aux modèles arborescents, l’écart de coût serait probablement plus important.
4. Généralisation au-delà de la sémantique : notre hypothèse de « spectre sémantique » a prédit avec succès de nombreux résultats, mais les bonnes performances du LLM sur des jeux de données abstraits comme sonar et california_housing suggèrent des capacités allant au-delà de la compréhension linguistique. Cela indique que le modèle pourrait également exploiter des schémas de régularisation de haute dimension, un phénomène qui mérite une étude plus approfondie au-delà du cadre de cette étude initiale.

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{ermut2026,
  author = {Ermut, Sıla and Sarı, Ekrem},
  title  = {{Comparer les modèles de fondation relationnels}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Consulté le 15 septembre 2026}
}

Journal des modifications

2 mises à jour

2026

1. 4 fév

   Ajout de SAP HANA Cloud à la section Études de cas.

2. 21 jan

   Suppression de la section « Modèles fondamentaux pour les données relationnelles et structurées ».

Liens de référence

1.

Griffin: Towards a Graph-Centric Relational Database Foundation Model

2.

RELATIONAL TRANSFORMER: TOWARD ZERO-SHOT FOUNDATION MODELS FOR RELATIONAL DATA

3.

RELBENCH: A Benchmark for Deep Learning on Relational Databases

4.

GitHub - stanford-star/relbench: RelBench: Relational Deep Learning Benchmark · GitHub

5.

Relational Programming with Foundation Models

6.

SAP HANA Cloud

7.

SAP Business AI: Release Highlights Q4 2025 | SAP News Center

SAP

8.

Kumo.AI trains foundation model for relational databases

blocksandfiles

9.

[2506.10707] ConTextTab: A Semantics-Aware Tabular In-Context Learner

Sıla Ermut

Analyste sectorielle

Suivre

Sıla Ermut est analyste sectorielle chez AIMultiple, couvrant les modèles d’IA, l’infrastructure d’IA, la gouvernance de l’IA et les applications d’IA d’entreprise. Ses recherches portent principalement sur l’utilisation de l’IA dans le marketing, la santé, les chaînes d’approvisionnement et le développement durable.
Elle a précédemment travaillé comme recruteuse dans des cabinets de gestion de projet et de conseil. Sıla est titulaire d’un master en psychologie sociale et d’une licence en relations internationales.

Voir le profil complet

Recherche effectuée par

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et scientifique des données chez AIMultiple. Il conçoit et exécute des benchmarks pratiques pour les systèmes d'IA et de LLM.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire