TML-Bench: Benchmark for Data Science Agents on Tabular ML Tasks

Ce papier présente TML-Bench, un nouveau benchmark évaluant la fiabilité et les performances de dix modèles de langage open-source sur des tâches d'apprentissage automatique tabulaire de type Kaggle, en mesurant leur capacité à générer des soumissions valides et performantes sous différentes contraintes de temps.

L'essentiel

🏁 Le Grand Défi des "Cuisiniers" IA : TML-bench

Imaginez que vous organisez un concours de cuisine. Mais au lieu de demander aux chefs de préparer un plat complexe, vous leur donnez une liste d'ingrédients (des données) et une recette à suivre (un problème à résoudre), et vous les chronométrez.

C'est exactement ce que fait ce papier, mais avec des Intelligences Artificielles (IA) qui écrivent du code pour résoudre des problèmes de données. L'auteur, Mykola Pinchuk, a créé un terrain de jeu spécial appelé TML-bench.

Voici les 5 points clés pour comprendre l'histoire :

1. Le Terrain de Jeu : Une Cuisine avec un Chronomètre

Dans le monde réel, une IA ne sert à rien si elle est lente ou si elle plante souvent.

• Le Défi : L'IA doit prendre des données brutes (comme un tableau Excel), nettoyer les ingrédients, choisir la bonne recette (modèle mathématique), cuisiner, et servir le plat final (le résultat) avant que le chronomètre ne sonne.
• Les Règles : L'IA n'a pas le droit de tricher. Elle ne peut pas aller sur Internet chercher la solution (c'est interdit pendant le test) et elle ne connaît pas la réponse exacte à l'avance. C'est comme si le chef cuisinait les yeux bandés, sans pouvoir goûter le plat avant de le servir.

2. Le Test : Pas de "Coup de Chance"

Souvent, une IA peut réussir une fois par pur hasard (comme un joueur de fléchettes qui touche le centre une fois sur dix).

• La Méthode : Ici, l'auteur ne se contente pas d'une seule tentative. Il demande à chaque IA de jouer 5 fois pour chaque défi.
• Le Résultat : On ne regarde pas le meilleur score, mais la moyenne (le "médian"). Si une IA est excellente mais instable (elle réussit 4 fois sur 5, mais plante une fois), elle sera pénalisée. On veut des IA fiables, pas des IA chanceuses.

3. Les Trois Niveaux de Difficulté (Le Temps)

Le test a été fait avec trois limites de temps différentes, comme des niveaux de jeu vidéo :

• 240 secondes (4 minutes) : C'est le mode "Express". L'IA doit faire vite. C'est comme commander un café rapide.
• 600 secondes (10 minutes) : Le mode "Standard". Assez de temps pour réfléchir un peu.
• 1200 secondes (20 minutes) : Le mode "Chef étoilé". L'IA a le temps d'essayer plusieurs recettes et d'affiner son plat.
• Leçon apprise : Plus on donne de temps, mieux les IA cuisinent, mais certaines restent lentes même avec du temps en plus !

4. Le Grand Champion : MiniMax-M2.1-TEE

Après avoir testé 10 modèles d'IA différents sur 4 défis différents (comme prédire qui va arrêter son abonnement à une banque ou combien de clients vont entrer dans un magasin), un modèle s'est démarqué.

• Le Gagnant : Un modèle appelé MiniMax-M2.1-TEE. C'est le "Meilleur Chef" du concours. Il a été le plus constant, le plus rapide et a donné les meilleurs plats, peu importe le temps qu'on lui donnait.
• Les Autres : Certains modèles étaient très bons mais instables (ils rataient parfois le plat), et d'autres étaient trop lents ou faisaient des erreurs bêtes.

5. Pourquoi c'est important pour nous ?

Avant ce test, on comparait les IA sur des tâches isolées (comme "peut-elle écrire un code Python ?").

• La Révolution : Ce papier dit : "Ce n'est pas assez !". Une vraie IA utile doit être capable de faire tout le travail, de A à Z, sans planter, et dans un délai raisonnable.
• L'Analogie : C'est la différence entre un étudiant qui sait réciter une leçon par cœur (bon pour un examen écrit) et un médecin qui doit diagnostiquer un patient, prescrire un traitement et gérer une urgence en même temps (bon pour la vie réelle).

En résumé

Ce papier est comme un rapport de fiabilité automobile. Au lieu de regarder juste la vitesse de pointe d'une voiture (le score maximum), il regarde combien de fois elle tombe en panne, combien de temps elle met pour démarrer, et si elle arrive à destination à l'heure, 5 fois de suite.

Il nous dit que pour que les IA deviennent de véritables assistants dans notre quotidien, nous devons arrêter de chercher le "coup de chance" et commencer à exiger de la régularité et de la fiabilité. Et pour l'instant, le modèle MiniMax est celui qui roule le mieux sur la route ! 🚗💨

Résumé technique

Titre et Contexte

TML-bench : Benchmark pour les agents de science des données sur les tâches d'apprentissage automatique tabulaire
Auteur : Mykola Pinchuk (Chercheur indépendant, San Jose, USA)
Date : 4 mars 2026

---

1. Problématique

L'apprentissage automatique sur données tabulaires reste une charge de travail pratique très courante. Bien que les agents de codage autonomes puissent générer rapidement des baselines solides pour des tâches de type Kaggle, leur valeur pratique réelle dépend de leur correctitude et fiabilité de bout en bout, notamment sous des contraintes de temps strictes.

Les benchmarks existants souffrent souvent de lacunes :

• Ils testent des tâches de codage isolées, manquant ainsi les modes d'échec et les compromis réels du flux de travail complet (chargement des données, préparation des caractéristiques, entraînement, itération, soumission).
• Ils ne mesurent pas la fiabilité (un seul "coup de chance" ne suffit pas).
• Ils peinent à comparer des modèles sur des tâches utilisant des métriques hétérogènes et des budgets de temps différents.

L'objectif est de créer un benchmark strict, auditable et reproductible pour évaluer la fiabilité des agents sur des tâches tabulaires complètes.

2. Méthodologie

2.1. Protocole d'évaluation

Le benchmark évalue des agents sur une suite de 4 compétitions Kaggle (tâches tabulaires) avec 3 budgets de temps (240s, 600s, 1200s).

• Couverture : Chaque modèle est exécuté 5 fois par tâche et par budget.
• Critère de succès : Une exécution est considérée comme réussie si elle produit une soumission valide et obtient un score sur un ensemble de données de validation privé (holdout) inaccessible à l'agent.
• Modèles testés : 10 modèles LLM Open Source (OSS). Seuls les modèles ayant une couverture complète (5 runs réussis pour les 12 configurations : 4 tâches × 3 budgets) sont inclus dans les tableaux principaux.

2.2. Environnement et Contrôle de Contamination

• Environnement d'exécution : Utilisation de la "Kilo Code harness" qui gère un espace de travail propre par exécution, applique les limites de temps et valide le format de soumission.
• Contrôles de contamination :
  • Accès Internet désactivé pendant les runs.
  • Sélection des modèles : Seuls les modèles dont la date de coupure des connaissances (knowledge cutoff) est antérieure à la date de début des compétitions testées (octobre 2025) sont évalués.
• Instructions : Un modèle d'instruction fixe est utilisé pour tous les runs. Le budget de 1200s utilise un ensemble d'instructions spécifique axé sur XGBoost.

2.3. Agrégation et Normalisation des Métriques

Pour permettre la comparaison entre des tâches ayant des métriques différentes (ex: AUC où "plus c'est haut, mieux c'est" vs RMSE où "plus c'est bas, mieux c'est") :

1. Médiane : La valeur rapportée pour chaque configuration est la médiane des 5 premiers runs réussis.
2. Normalisation Min-Max :
   • Conversion vers une direction commune ("plus c'est haut, mieux c'est").
   • Normalisation min-max au sein de chaque configuration (tâche × budget) pour que le meilleur modèle obtienne 1,0 et le pire 0,0.
3. Score Agrégé : Le classement principal utilise l'agrégation du "meilleur budget par compétition" (moyenne des scores normalisés des meilleurs budgets sur les 4 compétitions).

3. Contributions Clés

1. Protocole strict : Introduction d'un benchmark pour les tâches tabulaires avec préparation déterministe, validation stricte des soumissions et scoring sur holdout privé.
2. Politique de rapport reproductible : Utilisation d'instructions fixes, d'une suite fixe et d'une agrégation par médiane de 5 runs avec des exigences de couverture explicites.
3. Contrôles de contamination : Mise en place d'une évaluation hors ligne et sélection de modèles pré-entraînement pour éliminer le risque de fuite d'information post-compétition.
4. Accessibilité : Une configuration à faible coût (environ 10 $ pour la suite complète) permettant aux praticiens individuels de reproduire les résultats.
5. Analyse de fiabilité : Rapport détaillé sur la performance, la cohérence inter-compétitions, la fiabilité (taux de succès) et l'échelle de performance par rapport au temps.

4. Résultats Principaux

4.1. Performance Agrégée

• MiniMax-M2.1-TEE obtient le meilleur score agrégé sur les quatre compétitions selon le protocole principal.
• La performance moyenne s'améliore avec l'augmentation des budgets de temps.

4.2. Fiabilité et Stabilité

• La fiabilité varie considérablement, même parmi les modèles performants.
• Des graphiques de type "Pareto" (performance vs stabilité) montrent une séparation claire entre les modèles fiables et ceux qui sont instables.
• Certains modèles montrent une grande variabilité (IQR large) ou des échecs spécifiques dans certaines configurations (ex: GLM 4.7 Flash sur la tâche "foot-traffic" à 1200s).

4.3. Échelle avec le Budget de Temps

• Globalement, l'augmentation du temps (240s → 1200s) améliore les performances.
• Cependant, l'échelle est "bruyante" au niveau des modèles individuels avec seulement 5 runs. Environ 57,5 % des courbes de scaling (modèle × compétition) sont monotones (les performances ne se dégradent pas avec plus de temps).
• Les gains marginaux ne sont pas uniformes : certains modèles s'améliorent substantiellement avec plus de temps, tandis que d'autres restent plats.

4.4. Résultats par Compétition (Exemples)

• Bank Customer Churn (AUC) : Forte concentration des performances dans la plage 0.92x. GPT OSS 120B TEE excelle à 1200s, mais certains modèles (ex: NVIDIA-Nemotron-3-Nano) sous-performent notablement.
• Foot Traffic (RMSE) : MiniMax-M2.1-TEE est le leader sur les trois budgets.
• Playground Series : Les médianes sont très serrées, soulignant la difficulté de la tâche.

5. Signification et Limites

Signification

TML-bench déplace le focus de la simple "capacité à coder" vers la fiabilité opérationnelle dans des conditions réalistes (temps limité, pas d'internet, données privées). Il fournit une base pour comparer les agents non seulement sur leur pic de performance, mais sur leur capacité à produire des résultats cohérents et reproductibles. La faible coût d'exécution rend ce benchmark accessible à la communauté.

Limites

• Comptabilisation des Tokens : Les logs actuels ne contiennent pas la consommation de tokens, empêchant une analyse de l'efficacité des coûts (reportée à une version future).
• Couplage Budget/Instructions : L'augmentation du temps s'accompagne d'un changement d'instructions (le budget 1200s utilise un ensemble axé sur XGBoost), ce qui rend difficile la séparation pure de l'effet "temps" vs "instruction".
• Bruit Statistique : Avec seulement 5 runs par configuration, les courbes de scaling individuelles peuvent être bruyantes ; davantage de runs seraient nécessaires pour une stabilité parfaite au niveau du modèle.

Conclusion

TML-bench établit un nouveau standard pour l'évaluation des agents de science des données sur les données tabulaires, en mettant l'accent sur la reproductibilité, l'intégrité des données (pas de contamination) et la fiabilité statistique plutôt que sur le meilleur résultat unique. Les résultats indiquent que si les agents sont capables de performances élevées, leur stabilité et leur capacité à exploiter efficacement le temps supplémentaire varient considérablement d'un modèle à l'autre.