Google dévoile TabFM, son modèle de fondation pour prédire des données tabulaires

Prédire le contenu de tables avec un Transformer

Comment ? En s’inspirant des capacités d’apprentissage en contexte des LLM. « Cette technique permet à un modèle préentraîné d’apprendre une nouvelle tâche grâce à des exemples et des instructions fournis dans le contexte d’entrée, sans modifier les poids sous-jacents du modèle », rappellent les chercheurs de Google.

Appliquée aux tables, cette méthode consiste à confier l’ensemble du jeu de données, les données d’entraînement et les lignes de test contenant les résultats attendus « dans un seul prompt » au modèle. « Au moment de l’inférence, le modèle apprend à interpréter les relations entre les colonnes et les lignes directement à partir de ce contexte ».

Or cet effort, selon les chercheurs, n’est pas nécessairement plus facile que l’entraînement d’un modèle de langage. Alors que la tokenisation, le découpage en tokens de mots est unidimensionnel, faire la même chose avec des tables demande de prendre en compte deux dimensions : les lignes et les colonnes. De ce fait, SAP expliquait que son modèle était proportionnellement deux fois plus grand que BERT, utilisé pour classer des textes, extraire des entités nommées et propulser des chatbots.

Un modèle inspiré des travaux de recherche allemands et français

Pour ce faire, ils ont « synthétisé les forces architecturales de TabPFN et de TabICL » et en ont déduit trois mécanismes. Les tables en entrée sont traitées par un mécanisme multicouche qui alterne l’attention sur les colonnes et les lignes, comme TabPFN. Le modèle apprend à identifier les relations entre les colonnes contenant les caractéristiques (jusqu’à 500 features) et comment elles influencent le comportement des exemples (les variables cibles) stockés dans les lignes. Il construit ainsi des représentations des interactions entre les features, des dépendances non linéaires entre variables et des patterns spécifiques aux jeux de données.

Après cette phase de contextualisation, chaque ligne est compressée dans un vecteur dense avec un mécanisme de rotation des embeddings (RoPE). Enfin, un Transformer dédié s’entraîne sur ces vecteurs compressés, ce qui permettrait de réduire le coût de calcul et de traiter de grandes tables. Comme TabICL.

« Honnêtement, je suis très fier et flatté de voir à quel point TabFM s’est inspiré de TabICL pour se développer à plus grande échelle », a commenté Gaël Varoquaux, chercheur à l’INRIA et directeur scientifique chez : probabl. « C’est un honneur qu’une équipe aussi modeste que celle derrière TabICL ait pu inspirer un géant tel que Google ».

Contrairement à SAP (qui compte au moins s’inspirer de ses propres données), les chercheurs de Google déplorent la disponibilité de données publiques suffisamment propres. « Les tables synthétiques pouvant être générées à une taille arbitraire, elles constituent en réalité la seule option viable pour le préentraînement d’un modèle de base à cette échelle », écrivent-ils. « Par conséquent, TabFM est entièrement entraîné sur des centaines de millions de jeux de données synthétiques ». Elles ont été obtenues en utilisés des modèles causaux structurels. Contrairement aux modèles statistiques qui capturent uniquement les corrélations, ils décrivent explicitement les relations de cause à effet entre les variables. Il y aurait suffisamment de tables variées pour généraliser correctement les résultats, d’après les chercheurs. 

TabFM dépasse ses aînés, mais est plus gourmand en ressources de calcul

Sur le parangonnage TabArena (51 tables, dont 38 dédiées à la classification), TabFM dépasse Autogluon 1.5 sur les tâches de régression et de classification, un outil d’AutoML développé par AWS. Jusqu’alors, les « Transformer tabulaires » peinait à égaler ce framework. Les résultats les plus probants concernent TabFM-Ensemble. Cette variante crée de nouvelles variables en combinant les colonnes existantes, exploite la décomposition en valeurs singulières (réduction des données, extraction des patterns les plus importants, création de features compressées) et combine les prédictions de 32 modèles pour affiner le résultat final.

La collection TabFM ne s’arrête pas à l’exercice académique : les modèles seront intégrés à Google BigQuery dans les prochaines semaines à travers la commande AI.PREDICT SQL.

En attendant, les chercheurs préviennent que la consommation de mémoire augmente avec le nombre de lignes et que les performances de TabFM ne sont pas garanties, surtout face à un modèle fine-tuné. « Les performances du modèle n’ont pas été pleinement évaluées sur des domaines spécifiques, des groupes minoritaires ou des cas limites », ajoutent-ils. « Il est recommandé de tester le modèle sur vos propres données avant de l’utiliser dans des situations critiques ».

Selon les tests de Yann Debray, Chief Product Officer chez : probabl., « TabFM a devancé TabICL sur 4 des 6 [petits] jeux de données, mais avec des écarts infimes ». En revanche, sur une puce Apple, le modèle léger de Google Research prend deux fois plus de temps pour afficher une prédiction. Il n’a pas reproduit le test avec TabFM-Ensemble.

TabFM se comporte mieux avec le framework JAX, mais il est possible d’utiliser PyTorch avec un CPU ou un GPU.

Selon les benchmarks menés par AIMultiple, un cabinet spécialisé dans le domaine, TabFM fait légèrement mieux que TabICLv2, TabFPN3 sur 15 data sets et dépasse amplement les frameworks principaux de Gradient Boosting (LightBGM, Catboost, XGBoost).

« Le hic c’est le temps de calcul », confirme Cem Dilmegani, analyste principal chez AIMultiple. « TabFM a pris en moyenne 174 secondes par itération là où TabICLv2 n’en a eu besoin que de 3,1 et TabPFN 3 de 4,2, si bien que le même test a coûté 27 dollars en temps GPU contre 0,48 et 0,65 dollar pour les deux autres [TabICLv2 et TabPFNv3], et il faut attendre 20 à 25 minutes avant d’obtenir sa première prédiction ».

Et l’analyste de recommander le recours à TabICLv2 quand la vitesse compte et les frameworks de Gradient Boosting « là où il n’y a pas de GPU ». Dans le cloud, Google peut « préchauffer » des clusters.

Les porte-parole de Google Research n’ont pas précisé les suites de leurs travaux. Si des acteurs comme SAP/Prior Labs et : probabl insistent sur cette voie, il y a fort à parier que le géant du cloud poursuive ces efforts. Reste à voir l’adoption de la technologie par les usagers de BigQuery. A noter que les LLM ne savent pas traiter ce problème de prédiction.

Puisqu’il n’est pas nécessaire d’être data scientist pour manipuler la fonction SQL associée, il faudra aussi rendre les résultats aisément explicables.