Comparer les modèles de fondation relationnels

Nous avons comparé SAP-RPT-1-OSS à l'optimisation par gradient (LightGBM, CatBoost) sur 17 ensembles de données tabulaires couvrant le spectre sémantique-numérique, des tables petites/à forte sémantique, des ensembles de données commerciales mixtes et de grands ensembles de données numériques à faible sémantique.

Notre objectif est de mesurer dans quels cas les connaissances sémantiques pré-entraînées d'un LLM relationnel peuvent offrir des avantages par rapport aux modèles arborescents traditionnels et dans quels cas elles rencontrent des difficultés en cas de changement d'échelle ou de faible structure sémantique.

Comparaison entre SAP-RPT-1-OSS et Gradient Boosting : résultats des tests de performance

• Taux de réussite : représente le score normalisé moyen (de 0,0 à 1,0). Plus la barre est haute, plus le modèle se rapproche des performances optimales pour les jeux de données de cette catégorie.
• 100 à 500 lignes (3 jeux de données) :
  • Inclus : vin (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 les jeux de données « wine » et « sonar », ce qui suggère que les a priori LLM peuvent être avantageux lorsque les données d’entraînement sont rares. Cependant, CatBoost remporte une courte victoire sur le jeu de données « vote » (à moins de 0,1 %), 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 trois jeux de données. Sur cylinder_bands, SAP surpasse LightGBM de 5,5 %, probablement grâce à une meilleure prise en compte des descriptions sémantiques des défauts industriels ; toutefois, des études d’ablation supplémentaires seraient nécessaires pour confirmer cette hypothèse.
• 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 pour les tâches riches en texte comme Spambase et Titanic. Cependant, CatBoost surpasse nettement SAP sur Compass (10,4 %), ce qui indique des caractéristiques propres à chaque jeu de données qui favorisent les modèles arborescents, même pour des ensembles de cette taille.
• Plus de 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 modèle linéaire à longue portée (LLM) diminue. LightGBM et CatBoost obtiennent les meilleurs résultats sur 5 des 6 jeux de données, offrant une meilleure précision pour un coût de calcul considérablement réduit. La seule exception, california_housing, ne présente qu’un modeste avantage de 1,7 % pour SAP.

1. Tableau des jeux de données des résultats de référence

Vous trouverez ci-dessous le détail complet des performances du modèle 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 en nous basant sur le prix de l'instance RunPod H200 de 3,59 $/heure .

SAP-RPT-1-OSS engendre des coûts nettement plus élevés en raison du temps nécessaire au prétraitement de l'intégration de texte et de la forte consommation de mémoire de l'architecture LLM. À l'inverse, LightGBM et CatBoost exécutent les tâches quasi instantanément sur ce matériel. Les coûts indiqués ci-dessous correspondent au temps d'exécution total (prétraitement + entraînement) pour une validation croisée à 3 plis.

Coût moyen par ensemble de données (moyenne de 17 ensembles de données)

Répartition des coûts en fonction de la taille de l'ensemble de données

• Petits ensembles de données (< 1 000 lignes) : SAP est relativement peu coûteux (environ 0,03 $ par exécution). Le taux de réussite élevé rend ce coût négligeable.
• Ensembles de données volumineux (>20 000 lignes) : SAP devient coûteux.
  • Exemple : L'entraînement sur adult_income (48 000 lignes) prend environ 12 minutes au total pour 3 plis.
  • Coût : 12 min x 0,06 $/min = 0,72 $ par expérience.
  • Comparaison : LightGBM effectue la même tâche pour 0,01 $ .

Conclusion : Bien que 0,22 $ par jeu de données ne soit pas un prix élevé en valeur absolue, SAP coûte 22 fois plus cher que la solution de référence. Cet écart de coût peut se justifier pour les petits jeux de données riches en sémantique où SAP améliore significativement la précision (par exemple, cylinder_bands avec un gain de 5,5 %), mais il devient plus difficile à justifier pour les grands jeux de données où les modèles arborescents atteignent des performances égales, voire supérieures, à un coût bien moindre.

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 série de 17 jeux de données spécifiquement choisis pour couvrir le spectre sémantico-numérique .

Notre hypothèse principale était que SAP (étant basé sur les modèles linguistiques) excellerait lorsque les données ont une signification linguistique, tandis que les modèles arborescents domineraient pour les calculs numériques bruts. Nous avons classé nos ensembles de données en trois groupes distincts :

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

Caractéristiques : Les fonctionnalités contiennent des descriptions textuelles enrichies, des étiquettes catégorielles ayant une signification concrète (par exemple, « gel des honoraires des médecins ») ou une terminologie spécifique au domaine.

• Ensembles de données :
  • cylinder_bands : Défauts d’impression industrielle.
  • Titanic : Noms et titres des passagers.
  • vote : résultats des votes du Congrès (réponses catégoriques « Oui/Non » aux politiques).
  • cancer_du_sein : Descriptions médicales des tumeurs.
  • spambase : Fréquences des mots dans les e-mails.
  • vin : Origines chimiques.

Groupe B : Données commerciales mixtes (6 ensembles de données)

Caractéristiques : Le format tabulaire standard que l'on retrouve 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é du poste, race, département).

• Ensembles de données :
  • salaires des employés : Intitulés de poste et salaires.
  • compas : Antécédents criminels et données démographiques (Attributs sensibles).
  • revenu des adultes : Données démographiques du recensement.
  • credit_g : Profils de risque de crédit allemands.
  • default_credit : données sur les défauts de paiement de Taïwan.
  • car_evaluation : Paramètres d'achat du véhicule.

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

Caractéristiques : Les caractéristiques sont des mesures abstraites, des relevés de capteurs ou des coordonnées physiques. Le nom des colonnes importe peu ; seules les relations mathématiques sont pertinentes.

• Ensembles de données :
  • higgs_100k : Cinématique des particules physiques.
  • Diamants : Dimensions physiques et prix.
  • Sonar : rebonds d'énergie de fréquence.
  • Logement en Californie : coordonnées latitude/longitude et statistiques du recensement.
  • ventes_de_maisons : Immobilier du comté de King (principalement des données numériques).

4. Analyse approfondie : Points forts et points faibles de SAP

L'application de ce cadre d'analyse à nos résultats révèle quatre profils de performance distincts. Le tableau ci-dessous récapitule précisément les points forts et les points faibles de SAP.

Fondements conceptuels des modèles de fondements relationnels

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

Les principales caractéristiques de ces modèles sont les suivantes :

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

Griffon

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

Encodeur de fonctionnalités 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 flottant appris.
• Metadonné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âches permettent à un seul modèle d'effectuer des tâches de régression et de classification avec des décodeurs partagés.

Transmission de messages et attention

Griffin intègre des réseaux neuronaux à propagation de messages avec un module d'attention croisée. La propagation de messages agrège les informations au sein des relations et entre elles, tandis que l'attention croisée se concentre sur les cellules pertinentes de chaque ligne. Cette conception permet au modèle de traiter des données hétérogènes et de maintenir le contexte entre les entités connectées.

Pré-entraînement et mise au point

Le modèle est pré-entraîné sur des ensembles de données mono-tables via une tâche de complétion de cellules masquées, puis affiné sur des bases de données relationnelles pour des tâches spécifiques. Des expériences menées sur de vastes ensembles de données relationnelles de référence montrent que Griffin surpasse les modèles GNN traditionnels et les modèles mono-tables, tant en termes de précision que d'efficacité d'apprentissage par transfert.

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

Transformateur relationnel

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

Représentation d'entrée

Chaque jeton combine :

• Une valeur intégrée qui dépend de son type de données (numérique, texte ou date/heure).
• Un schéma d'intégration est généré à partir du texte du tableau et des colonnes.
• Un jeton de 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 cellulaire. Il comprend :

• Attention portée aux colonnes pour l'apprentissage des distributions de valeurs au sein des colonnes.
• Fonctionnalité permettant de combiner des attributs au sein d'une même ligne ou de lignes parentes liées.
• Attention aux voisins pour l'agrégation des informations provenant des lignes enfants connectées.

Ensemble, ces couches d'attention forment un transformateur de graphes relationnels qui modélise les dépendances entre les lignes, les colonnes et les tables.

Résultats de formation et de transfert

RT est pré-entraîné sur des bases de données relationnelles issues de RelBench. Lors d'expérimentations, le modèle pré-entraîné a atteint jusqu'à 94 % des performances de modèles entièrement supervisés en contexte de zéro exemple. 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 modèles transférables entre les domaines et que la tokenisation au niveau cellulaire fournit une base pratique pour les tâches prédictives sur les 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 fonctionnent directement sur les structures relationnelles plutôt que de s'appuyer sur un aplatissement manuel des caractéristiques.

Les versions précédentes de RelBench introduisaient 11 bases de données relationnelles couvrant des domaines tels que la santé, les réseaux sociaux , le commerce électronique et le sport, avec 70 tâches prédictives conçues pour être à la fois stimulantes 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 les colonnes existantes dans une base de données relationnelle.

Cette version a également étendu l'accès aux données grâce à l'intégration de CTU, permettant l'accès à plus de 70 ensembles de données relationnels via ReDeLEx ; a ajouté une connectivité directe aux bases de données SQL ; et a intégré sept ensembles de données du référentiel 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 des réseaux neuronaux graphiques, 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 2 a également introduit de nombreuses améliorations en termes d'ergonomie et de performances, notamment des étiquettes temporelles censurées optionnelles, la prise en charge de la métrique NDCG dans la prédiction des liens, une génération d'intégration de phrases plus rapide et une gestion du cache configurable. ⁴

VIEIRA

VIEIRA adopte une approche différente en privilégiant la programmation à l'aide de modèles de base plutôt que la construction d'un moteur prédictif unique. Elle é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 en tant que prédicats externes . ⁵

Paradigme relationnel

Dans VIEIRA, les modèles de base sont traités comme des fonctions sans état avec des entrées et des 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 les images et les associer à des étiquettes textuelles dans un tableau.

Applications

Le cadre prend en charge :

• Raisonnement mathématique et de données utilisant GPT.
• Raisonnement sur la parenté par extraction de texte et inférence logique.
• Réponse aux questions combinant récupération et raisonnement.
• Réponse visuelle aux questions et retouche 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 construire des systèmes interprétables qui utilisent des modèles de base pré-entraînés pour répondre aux requêtes prédictives sur des données structurées et des images.

Études de cas

SAP Hana Cloud

SAP HANA Cloud est une base de données en tant que service (DBaaS) native du cloud et entièrement gérée, conçue pour servir de socle de données unifié aux applications d'entreprise combinant transactions, analyses et intelligence artificielle. Plutôt qu'une simple base de données relationnelle, SAP HANA Cloud se positionne comme une plateforme multi-modèles permettant aux organisations de développer des applications de données intelligentes à partir de leurs données opérationnelles.

SAP HANA Cloud combine le traitement en mémoire avec le stockage sur disque et l'intégration de lacs de données pour répondre à différents besoins en termes de performances et de coûts. Cette architecture flexible prend en charge les charges de travail en temps réel tout en s'adaptant dynamiquement aux fluctuations des volumes de données et de l'utilisation.

L'un de ses principaux atouts réside dans son moteur multi-modèles natif, qui prend en charge les données relationnelles, JSON/documents, graphiques, spatiales et vectorielles au sein d'une base de données unique. Ceci permet aux applications de combiner requêtes SQL, relations graphiques et recherches de similarité vectorielle sans avoir à 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 aux sources de données SAP et non-SAP, y compris l'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 relationnelle et native de l'IA dans laquelle la base de données relationnelle sert de couche fondamentale pour l'analyse, 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
Traitement de données multi-modèles. ⁶

SAP SAP-rpt-1

SAP RPT-1 introduit un modèle relationnel unique qui réalise un large éventail de tâches prédictives grâce à l'apprentissage contextuel. Au lieu de réentraîner un nouveau modèle pour chaque cas d'utilisation, les utilisateurs fournissent quelques exemples de leur comportement cible, tels que « clients ayant payé à temps » et « clients ayant payé en retard ». Le modèle reconnaît alors ce comportement et génère 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 des métadonnées, telles que les noms des tables et des colonnes, dans des représentations vectorielles. 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 présente plusieurs avantages pour les analystes de données et les utilisateurs métiers :

• Un modèle unique qui fonctionne sur plusieurs tables et domaines.
• Aucun besoin de réglages fins répétés ni de développement sur mesure.
• Accédez à des analyses 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 à l'écosystème SAP, les experts métiers peuvent interagir directement avec leurs données et obtenir des prédictions via des interfaces intuitives. Il en résulte une transformation plus rapide des données structurées en décisions exploitables, sans ingénierie manuelle des caractéristiques.

Figure 3 : Facteur de réduction d'erreur des lignes de base sap-rpt-1-large par rapport aux lignes de base narrow-AI dans tous les domaines SAP.

Fin 2025, SAP a confirmé que SAP-RPT-1 était disponible pour tous via le hub d'IA générative de SAP AI Foundation (SAP AI Core).

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

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

Cette version officialise le rôle de SAP-RPT-1 en tant que modèle de base déployable au sein de la pile d'IA d'entreprise de SAP, plutôt qu'en tant que capacité uniquement dédiée à la recherche.

De plus, SAP propose SAP-RPT Playground, un environnement web sans code où les utilisateurs peuvent tester l'apprentissage en contexte en utilisant leurs propres données ou des exemples de données fournis par SAP.

SAP-ABAP-1

SAP-ABAP-1 est un modèle de base conçu pour prendre en charge les cas d'utilisation de la productivité des développeurs basés sur l'IA pour les clients et partenaires SAP.

Disponible via la plateforme d'IA générative de SAP, ce modèle 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 exhaustive. Il est optimisé pour comprendre et expliquer le code ABAP, identifier les bonnes pratiques et donner accès aux connaissances les plus récentes en matière de développement SAP.

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.AI : un transformateur de graphes relationnels pour l’analyse prédictive

Kumo.AI, fondée par Jure Leskovec, professeur à Stanford, a créé KumoRFM, un modèle de base relationnel qui utilise un transformateur de graphes relationnels 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 et 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 simultanément à partir de plusieurs tables et de s'adapter à de nouveaux schémas relationnels. Le modèle est pré-entraîné sur diverses sources de données et peut se généraliser à de nouveaux ensembles de données sans nécessiter la création de modèles distincts pour chaque tâche prédictive.

KumoRFM peut être utilisé via différentes interfaces en fonction du 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.
• Kit de développement logiciel (SDK) Python : Permet aux développeurs d’intégrer le modèle dans les pipelines et applications d’IA d’entreprise.

L'architecture 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 transformateur de graphes relationnels, 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 simplifiés.
• Entrepôt de données natif : Permet aux organisations d’utiliser leurs propres données dans Snowflake ou Databricks sans les déplacer hors 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. Il est ainsi particulièrement adapté au e-commerce, à la finance et à la santé , où les relations, les tendances temporelles et l'évolution du contexte sont essentielles à des prédictions fiables.

Les principales fonctionnalités de KumoRFM incluent :

• Flexibilité pour différentes tables et structures de schémas.
• Compatibilité avec divers types de colonnes et d'identifiants personnalisés.
• Adaptation aux tâches spécifiques pendant la phase d'inférence.
• Haute précision et interprétabilité dans les tâches de prédiction.

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

Méthodologie de référence

Configuration et environnement de référence

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

• Matériel : Instance RunPod avec un GPU H200 140 Go NVIDIA .
• Logiciel : Python 3.12 avec des bibliothèques spécifiques pour garantir 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 dans toutes les divisions, initialisations et modèles.

Ensembles 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 que d'opter pour une sélection aléatoire, nous avons constitué cet ensemble de données de manière à couvrir le « spectre sémantico-numérique », testant ainsi l'hypothèse selon laquelle les modèles linéaires linguistiques (LLM) excellent lorsque les caractéristiques possèdent une signification linguistique plutôt que de simples statistiques brutes.

L'inventaire :

• Petit et sémantique (<1K lignes) :
  • vin (178), sonar (208), vote (435), bandes_cylindriques (540), cancer_du_sein (569).
• Moyen/mixte (1K – 10K rangs) :
  • credit_g (1K), titanic (1,3K), car_evaluation (1,7K), spambase (4,6K), compas (5,2K), employee_salaries (9,2K).
• Données volumineuses/numériques (plus de 10 000 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 et prétraitement des modèles

Nous avons visé une « comparaison réaliste pour les praticiens », 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, qui nécessite beaucoup de calculs, 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 : itérations=500, taux_apprentissage=0,05, profondeur=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 par la médiane/le mode pour les valeurs manquantes.

SAP-RPT-1-OSS

Nous avons configuré SAP afin d'équilibrer performances et coûts 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é qu'augmenter le contexte de 4096 à 8192 triplait le temps d'exécution (de 4 min à 12 min) pour un gain de précision négligeable (0,917 contre 0,917 ROC-AUC).
  • Bagging : Augmenter le nombre de bagging de 4 à 8 (paramètre par défaut de SAP utilisé dans l’article) ⁹ ) offrait des rendements décroissants.
• Prétraitement : aucun. Le DataFrame pandas brut est transmis directement. Le modèle effectue l’encodage à l’aide d’embeddings 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 le facteur standard de 5 à 3 pour tenir compte des temps d'inférence lents de SAP (gain de temps de 40 %) tout en maintenant la validité statistique.
• Division : K-fold stratifié 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 vision globale des performances du modèle :

• 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 nous assurer que les victoires n’étaient pas des artefacts du déséquilibre des classes, et le MAPE pour l’étalonnage de l’erreur de régression.
• Calcul du coût : basé sur le temps total d'exécution (prétraitement + entraînement + inférence) sur l'instance RunPod H200 (3,59 $/h).

Signification statistique

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

Limites et 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 de procéder à une optimisation exhaustive des hyperparamètres (par exemple, validation croisée imbriquée ou balayages Optuna). Bien que cela garantisse une base de référence cohérente, il convient de noter que les modèles Tree bénéficient souvent d’améliorations de performance grâce à une optimisation spécifique à l’ensemble de données, ce qui pourrait réduire les écarts dans le groupe « Compétitif ».
2. Limites d'échelle des données : Notre analyse s'est concentrée sur des ensembles de données de moins de 100 000 lignes afin de simuler des scénarios typiques d'entreprises de taille moyenne. Nous avons observé que l'avantage du LLM diminuait avec l'augmentation du volume de données, mais nous n'avons pas étendu les tests à des ensembles de plusieurs millions de lignes, où la latence d'inférence et le coût deviendraient probablement les principales contraintes.
3. Uniformité de l'infrastructure : Afin de garantir un environnement de test homogène, tous les modèles ont été exécutés sur le même matériel H200 (référence NVIDIA). LightGBM et CatBoost étant optimisés pour les processeurs grand public, l'écart de coût serait probablement plus important dans un environnement de production dédié exclusivement aux modèles Tree.
4. Généralisation au-delà de la sémantique : Notre hypothèse du « spectre sémantique » a permis de prédire avec succès de nombreux résultats, mais les excellentes performances du modèle linguistique sur des jeux de données abstraits comme sonar et california_housing suggèrent des capacités qui dépassent la simple compréhension linguistique. Cela indique que le modèle pourrait également exploiter des schémas de régularisation de grande dimension, un phénomène qui mérite d’être approfondi au-delà du cadre de cette étude initiale.

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 - snap-stanford/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 du secteur

Suivre

Sıla Ermut est analyste chez AIMultiple, spécialisée dans le marketing par e-mail et les vidéos de vente. Auparavant, elle travaillait comme recruteuse dans des cabinets de conseil et de gestion de projets. 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 chez AIMultiple, spécialisé dans l'automatisation intelligente, les GPU, les agents IA et les frameworks RAG.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire