Comparaison des modèles de fondation relationnels

Nous avons comparé SAP-RPT-1-OSS au gradient boosting (LightGBM, CatBoost) sur 17 jeux de données tabulaires couvrant le spectre sémantique‑numérique, des petites tables à haute sémantique, 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 priors 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 défis en termes d’échelle ou de structure à faible sémantique.

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

• Taux de succès : Représente le score normalisé moyen (0.0 à 1.0). Une barre plus haute indique que le modèle est systématiquement 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 meilleures performances 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 priors du LLM peuvent être bénéfiques lorsque les données d’entraînement sont rares. Cependant, CatBoost a obtenu une victoire étroite sur le jeu de données vote (à 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 meilleures performances sur les 3 jeux de données. Sur cylinder_bands, SAP a surpassé LightGBM 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 des 5 jeux de données, avec des performances particulièrement bonnes 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 spécifiques 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 résultats du benchmark par jeu de données

Voici la répartition complète des performances des modèles sur les 17 jeux de données.

2. Analyse coût & efficacité

Nous avons calculé le coût de calcul direct pour chaque modèle en nous basant sur le prix de l’instance H200 de RunPod, soit $3.59/heure.

SAP-RPT-1-OSS engendre des coûts nettement plus élevés en raison du temps nécessaire au prétraitement des embeddings textuels et de la lourde empreinte mémoire de l’architecture du LLM. En revanche, LightGBM et CatBoost accomplissent 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 en validation croisée 3-fold.

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

Détail 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 victoire élevé ici rend 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 folds.
  • 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 termes absolus, SAP est 22x plus cher que la référence. Cet écart de coût peut se justifier pour les 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 les grands jeux de données où les modèles arborescents atteignent une performance égale ou meilleure pour une fraction du coût.

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

Pour interpréter ces résultats, il est crucial 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 lorsque les données possèdent un sens linguistique, tandis que les modèles arborescents domineraient dans le calcul numérique brut. Nous avons réparti nos jeux de données en trois groupes distincts :

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

Caractéristiques : Les variables contiennent des descriptions textuelles riches, des étiquettes catégorielles ayant une signification réelle (par exemple, « physician fee freeze »), ou une terminologie de domaine spécifique.

• Jeux de données :
  • cylinder_bands : Défauts d’impression industrielle.
  • titanic : Noms et titres des passagers.
  • vote : Registres de vote du Congrès américain (catégoriel « Oui/Non » sur des politiques).
  • breast_cancer : Descriptions de tumeurs médicales.
  • 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 ethnique, service).

• Jeux de données :
  • employee_salaries : Intitulés de poste vs. salaire.
  • compas : Antécédents criminels et démographie (attributs sensibles).
  • adult_income : Démographie de recensement.
  • credit_g : Profils de risque de crédit allemands.
  • default_credit : Données de défaut de crédit à 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 variables sont des mesures abstraites, des relevés de capteurs ou des coordonnées physiques. Les noms des colonnes importent souvent peu ; 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 latitude/longitude et statistiques de recensement.
  • house_sales : Immobilier du comté de King (caractéristiques principalement numériques).

4. Analyse approfondie : où SAP gagne et où il é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 rencontre des difficultés.

Fondements conceptuels des modèles de fondation relationnels

L’objectif principal d’un modèle de fondation relationnel est de produire des prédictions précises et d’effectuer des tâches diverses 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 l’information temporelle influence les résultats.

Les capacités clés de ces modèles incluent :

• Généralisation de schéma : La capacité de s’adapter à de nouveaux schémas relationnels sans réentraînement complet.
• Représentation d’entrée unifiée : Gérer différents types de colonnes, comme 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é : Effectuer 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 hétérogène, où chaque ligne devient un nœud et les arêtes correspondent aux relations de clé étrangère. Ses principales caractéristiques sont les suivantes :

Encodeur de caractéristiques unifié

• Les caractéristiques catégorielles et textuelles sont encodées avec un encodeur de texte pré‑entraîné, tandis que les valeurs numériques utilisent un encodeur de flottants appris.
• Les métadonnées telles que les noms des tables, des colonnes et les types d’arêtes sont intégrées pour aider le modèle à reconnaître le schéma relationnel.
• Des embeddings 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 de neurones à passage de messages avec un module d’attention croisée. La composante de passage de messages agrège les informations au sein et entre les relations, tandis que l’attention croisée se concentre sur les cellules pertinentes dans chaque ligne. Cette conception aide le modèle à traiter des données diverses et à maintenir le contexte entre les entités connectées.

Pré‑entraînement et fine‑tuning

Le modèle est pré‑entraîné sur des jeux de données mono‑table via une tâche de complétion de cellule masquée, puis fine‑tuné 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 basés sur les GNN traditionnels et les modèles mono‑table, à la fois en précision et en efficacité d’apprentissage par transfert.

Figure 1 : Graphique illustrant le cadre du modèle Griffin.¹

Transformeur relationnel

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

Représentation de l’entrée

Chaque token combine :

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

Cette structure permet à RT de traiter des bases de données relationnelles avec des schémas différents tout en conservant 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 inclut :

• L’attention de colonne pour apprendre les distributions de valeurs au sein des colonnes.
• L’attention de caractéristique pour combiner les attributs d’une même ligne ou des lignes parentes liées.
• L’attention de voisinage 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. Lors des 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 pendant le fine‑tuning, 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 motifs transférables entre les 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.

Étant donné que 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 des structures relationnelles plutôt que de s’appuyer sur 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, y compris une nouvelle classe de tâches d’auto‑complé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 via 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ée sur les réseaux de neurones sur graphes, utilisant PyTorch Geometric pour la construction des 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 de multiples améliorations de l’utilisabilité et des performances, notamment des étiquettes optionnelles censurées dans le temps, la prise en charge de la métrique NDCG pour la prédiction de liens, une génération plus rapide des embeddings 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 logique probabiliste SCALLOP avec un langage déclaratif qui intègre des grands modèles de langage, des modèles de vision et d’autres composants pré‑entraînés en tant que prédicats étrangers.⁵

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 comme GPT, CLIP ou SAM selon des règles logiques. Par exemple :

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

Applications

Le cadre prend en charge :

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

En unifiant logique symbolique et inférence neuronale, VIEIRA permet aux analystes de données et aux développeurs de construire 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 une base de données en tant que service cloud‑native entièrement gérée, conçue pour servir de fondation de données unifiée pour les applications d’entreprise qui combinent transactions, analytique et IA. Plutôt que d’être une simple base de données relationnelle à usage unique, SAP HANA Cloud se positionne comme une plateforme multi‑modèle qui permet aux organisations de construire 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 le stockage sur disque et l’intégration d’un lac de données pour répondre à différents besoins de performance et de coût. Cette conception flexible prend en charge les charges de travail en temps réel tout en s’adaptant dynamiquement à l’évolution des volumes de données et de l’utilisation.

Un de ses principaux différenciateurs est son moteur multi‑modèle natif, qui prend en charge les données relationnelles, JSON/document, 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 des recherches de similarité vectorielle sans déplacer les données entre différents systèmes, simplifiant ainsi l’architecture et réduisant la latence.

Faisant partie de la plateforme technologique SAP Business Technology Platform, SAP HANA Cloud s’intègre directement avec les 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.

Dans l’ensemble, SAP HANA Cloud est une plateforme de données orientée relationnel et native‑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 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 une large gamme 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 motif cible, comme « clients qui ont payé à temps » et « clients qui ont payé en retard ». Le modèle reconnaît alors le motif et produit immédiatement des prédictions précises pour les 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 les métadonnées, comme les noms des tables et des colonnes, dans des embeddings vectoriels. Cette conception lui permet de comprendre la sémantique des schémas relationnels et les informations temporelles contenues dans les tables métier.

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

• Un seul modèle qui fonctionne sur plusieurs tables et domaines.
• Pas besoin de fine‑tuning répété ou de développement personnalisé.
• Accès à des informations prédictives en quelques minutes plutôt qu’en 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 d’erreur 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 de 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 sortie officialise le rôle de SAP‑RPT‑1 en tant que modèle de fondation déployable au sein de la pile IA d’entreprise de SAP, plutôt qu’une simple capacité de recherche.

De plus, SAP propose le SAP‑RPT Playground, un environnement sans code 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 des 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 a été 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, mettre en évidence les bonnes pratiques et fournir un accès aux connaissances de développement SAP actualisées.

SAP propose un accès d’essai gratuit à SAP‑ABAP‑1 via le hub d’IA générative, avec des capacité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 la forme d’un graphe temporel hétérogène, où chaque entité est un nœud et 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 à partir de plusieurs tables simultanément 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 construire un modèle séparé pour chaque tâche prédictive.

KumoRFM peut être utilisé via différentes interfaces selon le niveau d’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.
• Python SDK : Permet aux développeurs d’intégrer le modèle dans les pipelines et applications d’IA d’entreprise.

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 de l’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 nécessitent 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 e‑commerce, à la finance et à la santé, où les relations, les motifs temporels et l’évolution du contexte sont essentiels pour des prédictions fiables.

Les principales capacités de KumoRFM incluent :

• Flexibilité à travers différentes tables et structures de schéma.
• Compatibilité avec une variété de types de colonnes et d’identifiants personnalisés.
• Adaptation à des tâches spécifiques au moment de l’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, comme le e‑commerce, la finance et la santé, pour faire des prédictions, fournir des explications et évaluer les résultats.⁸

Méthodologie du benchmark

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 épinglé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 tous les splits, 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 », testant l’hypothèse selon laquelle les LLM excellent lorsque les caractéristiques contiennent du sens linguistique plutôt que des statistiques brutes.

L’inventaire :

• Petits & 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 & prétraitement

Nous avons visé une « comparaison pratique » réaliste, en utilisant des paramètres par défaut robustes plutôt qu’une optimisation exhaustive des hyperparamètres.

LightGBM & CatBoost

Pour assurer une comparaison équitable avec le modèle SAP, coûteux en calcul, nous avons augmenté le nombre d’estimateurs par défaut, déjà robustes.

• LightGBM : n_estimators=500, learning_rate=0.05, num_leaves=31. Fonctionne sur CPU (n_jobs=-1).
• CatBoost : iterations=500, learning_rate=0.05, depth=6. Fonctionne sur GPU (task_type=”GPU”).
• Prétraitement : Encodage par étiquette simple pour les variables catégorielles ; pas de mise à l’échelle pour les numériques ; imputation par la 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.
• Note :
  • Contexte : Les tests sur adult_income ont montré que 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 vs 0.917 ROC‑AUC).
  • Bagging : Passer le bagging de 4 à 8 (le paramètre par défaut de SAP utilisé dans l’article⁹ ) offrait des rendements décroissants.
• Prétraitement : Aucun. Le DataFrame pandas brut est passé directement. Le modèle encode à l’aide d’embeddings textuels (sentence‑transformers/all‑MiniLM‑L6‑v2).

Protocole d’évaluation

Stratégie de validation croisée

Nous avons utilisé la validation croisée 3‑fold avec mélange.

• Nous avons réduit le standard de 5‑fold à 3‑fold pour tenir compte des temps d’inférence lents de SAP (gain de temps 40 %) tout en maintenant la validité statistique.
• Découpage : StratifiedKFold pour la classification ; K‑Fold standard pour la régression.

Métriques & diagnostics

Nous sommes allés au‑delà de la simple précision pour saisir une vision holistique 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 perte logarithmique pour s’assurer que les gains n’étaient pas des artefacts de déséquilibre de classes, et le 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).

Signification statistique

Nous avons appliqué un test des rangs signés de Wilcoxon (p<0.05) aux comparaisons par paires de modèles pour déterminer si les différences de performance étaient statistiquement significatives ou du bruit aléatoire.

Limites & validité interne

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

1. Configurations standardisées vs optimisation : 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). Bien que cela garantisse une référence cohérente, il convient de noter que les modèles arborescents bénéficient souvent de gains de performance avec un réglage spécifique au jeu de données, ce qui pourrait réduire les marges dans le groupe « Compétitif ».
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 typiques de taille moyenne en entreprise. 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 de millions de lignes où la latence et le coût d’inférence deviendraient probablement les contraintes principales.
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 standards ; par conséquent, dans un environnement de production dédié uniquement aux modèles arborescents, le différentiel de coût serait probablement plus large.
4. Généralisation au‑delà de la sémantique : Notre hypothèse du « Spectre Sémantique » a prédit avec succès de nombreux résultats, mais la bonne performance du LLM sur des jeux de données abstraits comme sonar et california_housing suggère des capacités allant au‑delà de la compréhension linguistique. Cela indique que le modèle pourrait également tirer parti de motifs de régularisation en haute dimension, un phénomène qui mérite une investigation plus approfondie au‑delà du cadre de cette étude initiale.

Citer cette recherche

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  = {{Comparaison des modèles de fondation relationnels}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Consulté le 4 Août 2026}
}

Liens de référence

1.

https://arxiv.org/pdf/2505.05568

2.

https://arxiv.org/pdf/2510.06377

3.

https://arxiv.org/pdf/2407.20060

4.

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

5.

https://arxiv.org/pdf/2412.14515

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 sectoriel

Suivre

Sıla Ermut est une analyste sectorielle chez AIMultiple couvrant les modèles d'IA, l'infrastructure d'IA, la gouvernance de l'IA et les applications d'IA en entreprise. Ses recherches se concentrent principalement sur l'utilisation de l'IA dans le marketing, la santé, les chaînes d'approvisionnement et la durabilité. Elle a précédemment travaillé comme recruteuse dans des sociétés 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 analyste de 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