🤖 machine learning

iML: Executable, Problem-Grounded, and Broadly Exploratory Code-Driven AutoML

L'article présente iML, un cadre d'AutoML multi-agents piloté par le code qui garantit des solutions exécutables, ancrées dans le problème et largement exploratoires grâce à des plans structurés et un débogage itératif, atteignant des performances de pointe et une grande fiabilité sur divers benchmarks d'apprentissage automatique.

Auteurs originaux : Dat Le, Duc-Cuong Le, Anh-Son Nguyen, Tuan-Dung Bui, Thu-Trang Nguyen, Son Nguyen, Hieu Dinh Vo

Publié 2026-06-02

📖 5 min de lecture🧠 Analyse approfondie

CC0 1.0

Auteurs originaux : Dat Le, Duc-Cuong Le, Anh-Son Nguyen, Tuan-Dung Bui, Thu-Trang Nguyen, Son Nguyen, Hieu Dinh Vo

Article original placé dans le domaine public sous CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous vouliez construire une machine complexe, comme une voiture de course de haute performance, mais que vous ne savez pas comment être mécanicien. Vous demandez à un assistant très intelligent, érudit mais parfois trop sûr de lui (une IA) d'écrire les plans et de construire la voiture pour vous.

Par le passé, ces assistants écrivaient souvent des plans qui semblaient parfaits sur le papier, mais qui s'effondraient au moment où vous tentiez de démarrer le moteur. Ils pouvaient supposer que votre voiture possède un moteur V8 alors que vous n'avez qu'un V6, ou oublier de boulonner les roues parce qu'ils étaient trop occupés à rédiger un magnifique discours sur la vitesse.

Ce document présente 𝑖ML, une nouvelle équipe d'assistants IA conçue pour résoudre ces problèmes. Au lieu d'un seul assistant essayant de tout faire à la fois, 𝑖ML utilise une équipe multi-agents qui travaille comme une équipe de construction hautement organisée. Leur objectif est de construire un modèle d'apprentissage automatique (la « voiture ») qui fonctionne réellement, qui est construit avec les matériaux dont vous disposez réellement, et qui explore de nombreuses façons de gagner la course.

Voici comment fonctionne 𝑖ML, décomposé en trois principes simples :

1. La règle du « Est-ce que ça tourne vraiment ? » (Exécutabilité)

La plupart des assistants IA écrivent du code qui semble beau en texte, mais qui plante quand on essaie de l'exécuter. 𝑖ML considère l'exécution du code comme le test le plus important.

L'analogie : Imaginez un chef qui ne se contente pas d'écrire une recette ; il cuisine réellement le plat, le goûte, et si c'est trop salé, il le corrige avant de servir le client.
Comment 𝑖ML procède : L'équipe divise le travail en petites parties (préparation des données, construction du modèle). Ils construisent chaque partie séparément, puis tentent de les assembler. Si les pièces ne s'emboîtent pas (comme un pion carré dans un trou rond), le système s'arrête immédiatement, trouve l'erreur exacte et répare uniquement cette pièce. Il continue d'essayer et de réparer jusqu'à ce que toute la machine fonctionne sans accroc. Cela garantit que 90 % du temps, le résultat final fonctionne réellement.

2. La règle du « Regardez ce que vous avez sous la main » (Ancrage sur le problème)

Parfois, les assistants IA inventent des choses. Ils peuvent supposer que vos données sont propres alors qu'elles sont désordonnées, ou supposer que vous voulez prédire les ventes alors que vous voulez prédire la météo.

L'analogie : Imaginez un entrepreneur qui ignore les plans que vous lui avez donnés et la terre réelle sur votre terrain, et décide à la place de construire une piscine parce qu'il pense que c'est ce que vous vouliez.
Comment 𝑖ML procède : Avant d'écrire la moindre ligne de code, 𝑖ML envoie un « éclaireur » pour inspecter vos données réelles. Il compte les éléments manquants, vérifie les types d'informations et recherche ce que d'autres experts ont fait avec des données similaires. Il crée ensuite un plan strict (un « blueprint ») basé sur la réalité, et non sur des suppositions. Cela empêche l'équipe de construire un modèle qui est logiquement cohérent mais inutile pour votre problème spécifique.

3. La règle du « Essayez tout » (Exploration large)

Les anciens systèmes d'AutoML choisissent souvent un chemin et s'y tiennent, comme un conducteur qui ne connaît que les autoroutes. Si la route devient un chemin de terre, ils restent bloqués.

L'analogie : Imaginez un détective qui ne vérifie qu'un seul suspect. 𝑖ML est comme un détective qui interroge trois suspects différents : l'un qui utilise des méthodes traditionnelles, l'un qui utilise des gadgets de haute technologie, et l'un qui utilise un outil sur mesure.
Comment 𝑖ML procède : L'équipe ne se contente pas de choisir une seule voie pour résoudre le problème. Elle exécute trois stratégies différentes en parallèle :
1. Méthodes traditionnelles (fiables, comme une berline robuste).
2. Modèles pré-entraînés (en utilisant des outils intelligents existants, comme une voiture de sport).
3. Réseaux de neurones personnalisés (en construisant un moteur unique et sur mesure).
  Ils testent les trois, voient lequel gagne la course, et choisissent le vainqueur. Si l'un échoue, ils n'abandonnent pas ; ils passent simplement à la meilleure option suivante.

La structure de l'équipe

Pour réaliser cela, 𝑖ML organise ses agents IA en rôles spécifiques :

Le Stratège : Lit le problème et inspecte les données pour créer le plan directeur.
Les Spécialistes : Différents agents écrivent le code pour des parties spécifiques (un pour le nettoyage des données, un pour la construction du modèle) afin qu'ils ne s'embrouillent pas.
L'Assembleur et le Débugueur : Ils assemblent les pièces, les testent, et si quelque chose casse, ils agissent comme un mécanicien muni d'un outil de diagnostic pour trouver et réparer l'exact boulon cassé sans avoir à reconstruire toute la voiture.

Les résultats

Les auteurs ont testé ce système sur deux ensembles de défis difficiles (comme les célèbres compétitions Kaggle).

Fiabilité : Alors que les autres systèmes échouaient à produire un résultat fonctionnel environ la moitié du temps, 𝑖ML a réussi 90 % du temps.
Performance : 𝑖ML ne s'est pas contenté de fonctionner ; il a gagné. Il a obtenu des « médailles » (classements de haut niveau) dans 45 % des compétitions, battant à la fois les anciens outils automatisés et d'autres agents IA.
Robustesse : Même lorsque les instructions étaient vagues ou réduites au strict minimum (comme dire « corrige ces données » sans expliquer comment), 𝑖ML a tout de même réussi 70 % du temps en s'appuyant sur son inspection des données réelles plutôt que sur les instructions textuelles.

En résumé, 𝑖ML est un système qui cesse de deviner, commence à tester, et déploie une équipe de spécialistes pour garantir que le modèle d'apprentissage automatique final n'est pas seulement une belle idée, mais une réalité fonctionnelle et performante.

Résumé Technique : $i$ ML – AutoML piloté par le code, exécutable, ancré dans le problème et largement exploratoire

1. Énoncé du Problème

Bien que l'apprentissage automatique automatisé (AutoML) ait démocratisé l'accès au machine learning, les systèmes existants font face à des limitations significatives en termes de flexibilité, de transparence et de fiabilité d'exécution. Les outils d'AutoML traditionnels fonctionnent souvent comme des « boîtes noires » rigides, limitées à des espaces de recherche prédéfinis (par exemple, les données tabulaires), manquant la capacité de personnaliser les pipelines pour des problèmes complexes ou multimodaux.

Les agents récents basés sur les grands modèles de langage (LLM) se sont tournés vers l'AutoML piloté par le code, synthétisant du code exécutable pour le prétraitement, l'entraînement et l'évaluation. Cependant, les approches actuelles souffrent de trois défauts critiques :

Manque d'exécutabilité : Le code généré semble plausible textuellement mais échoue lors de l'exécution en raison d'erreurs d'exécution, de discordances de types ou d'hypothèses non vérifiées.
Ancrage insuffisant dans le problème : Les décisions de planification reposent fréquemment sur des hypothèses textuelles non vérifiées ou des propriétés de données « hallucinées » plutôt que sur une analyse empirique du jeu de données réel.
Exploration étroite : De nombreux systèmes s'engagent prématurément dans une voie de modélisation unique (par exemple, en affinant un script monolithique ou en enveloppant un backend fixe comme AutoGluon), échouant à explorer des stratégies de solutions diverses et actualisées à travers le ML traditionnel, l'adaptation de modèles pré-entraînés et les architectures neuronales personnalisées.

2. Méthodologie : Le Cadre $i$ ML

Les auteurs introduisent $i$ ML, un cadre d'AutoML multi-agents piloté par le code, conçu pour satisfaire trois exigences : l'Exécutabilité, l'Ancrage dans le Problème et l'Exploration Large. Le cadre opère à travers trois phases coordonnées :

Phase I : Planification Stratégique Guidée par le Code

Au lieu d'un prompting direct vers le code, $i$ ML construit d'abord un plan stratégique ancré dans le problème ( $B$ ).

Analyse de Tâche et Profilage : Un Analyseur de Tâche extrait les contraintes sémantiques, tandis qu'un Agent de Profilage analyse empiriquement le jeu de données brut ( $\mathcal{D}$ ) pour générer des méta-caractéristiques ( $F_{meta}$ ), incluant le schéma, les modèles d'absence de données et la qualité des données.
Récupération de Connaissances : Un Récupérateur de Connaissances acquiert des contraintes de domaine et des stratégies de prétraitement à partir de sources externes.
Synthèse du Blueprint : Un Agent de Directives synthétise un blueprint structuré spécifiant les directives de prétraitement, la logique de sélection de modèle (choisissant entre ML Traditionnel, Adaptation de Modèles Pré-entraînés ou Architectures Neuronales Personnalisées), les protocoles d'entraînement et les métriques d'évaluation. Ce blueprint agit comme un ensemble d'invariants architecturaux pour contraindre l'espace de recherche.

Phase II : Implémentation Modulaire du Code

Des agents de codage spécialisés implémentent les composants séparément sous des Contrats d'Interface explicites ( $IC_{\mathcal{T}}$ ).

Codeur de Prétraitement : Génère un script ( $S_{prep}$ ) pour transformer les données brutes en une représentation vérifiée ( $\mathcal{D}'$ ) qui satisfait strictement le schéma requis par l'étape de modélisation.
Codeur de Modélisation : Génère un script ( $S_{model}$ ) pour l'entraînement et l'inférence, assurant la compatibilité mathématique avec le $\mathcal{D}'$ vérifié.
Conception Pilotée par Contrat : Cette modularité empêche l'enchevêtrement de la logique et permet le développement et la réparation indépendants des composants.

Phase III : Intégration Vérifiable par le Code

Un Agent Assembleur intègre $S_{prep}$ et $S_{model}$ en un pipeline unifié ( $S$ ).

Exécution Dynamique et Vérification : Le système exécute $S_{prep}$ sur les données pour valider les propriétés d'exécution (formes, types) par rapport au contrat d'interface avant de procéder à l'entraînement.
Débogage Itératif : Si l'exécution échoue, un Analyseur d'Erreur localise la faute (par exemple, discordances d'API, erreurs de forme de tenseur) en utilisant les traces d'exécution. Un Agent de Débogage répare ensuite de manière itérative le composant spécifique, en utilisant la recherche web pour la syntaxe actuelle si nécessaire, jusqu'à l'obtention d'un pipeline valide.

3. Contributions Clés

Nouveaux Principes de Conception : L'article établit trois critères pour un AutoML idéal piloté par le code : Exécutabilité (synthèse de bout en bout fiable), Ancrage dans le Problème (décisions basées sur les données empiriques et les connaissances récupérées) et Exploration Diversifiée/Actualisée (recherche à travers des pistes de solutions hétérogènes).
Le Cadre $i$ ML : Une architecture multi-agents qui opérationnalise ces principes par le profilage empirique, la planification appuyée par la récupération, la synthèse de code modulaire et la vérification dynamique.
Validation Expérimentale Étendue : Évaluation complète sur MLE-BENCH et un nouveau $i$ ML-BENCH (couvrant 16 compétitions Kaggle diverses de 2021 à 2025), démontrant une fiabilité opérationnelle supérieure et des performances compétitives.

4. Résultats Expérimentaux

Les auteurs ont évalué $i$ ML par rapport à des lignes de base de pointe, incluant l'AutoML traditionnel (AutoGluon) et des agents pilotés par le code (MLZERO, MLE-STAR, AutoML-Agent).

Performance sur MLE-BENCH (Lite)

Fiabilité : $i$ ML a atteint un taux de soumission valide de 90 %, surpassant nettement MLE-STAR (55 %) et AutoML-Agent (40 %).
Qualité Compétitive : Il a obtenu des médailles (Or/Argent/Bronze) sur 45 % des tâches et un taux de « Au-dessus de la Médiane » de 80 %.
Score de Performance : Le Score de Performance Moyen (APS) était de 0,82, représentant une amélioration de 52 % à 273 % par rapport aux bases de référence basées sur les LLM.

Performance sur $i$ ML-BENCH

Robustesse : $i$ ML a obtenu l'APS le plus élevé (0,54), triplant presque la performance de MLZERO (0,19).
Tâches Complexes : Alors que les bases comme AutoGluon et MLZERO ont échoué (score de 0,00) sur des tâches multimodales complexes (ex: PetFinder, Classification Multilabelle), $i$ ML a maintenu des scores élevés (0,67 et 0,69, respectivement).
Descriptions Épurées : Même lorsque les descriptions de tâches étaient considérablement réduites à un prompt générique, $i$ ML a maintenu un taux de succès de 70 % et un APS de 0,63, démontrant sa résilience face à l'ambiguïté de l'intention de l'utilisateur.

Études d'Ablation

Exécutabilité : La suppression de la vérification dynamique ou de l'intégration modulaire a provoqué des chutes significatives des taux de soumission valide et de l'APS, confirmant que les vérifications statiques sont insuffisantes.
Ancrage : La suppression du profilage empirique des données a réduit l'APS de 0,82 à 0,66, prouvant que l'ancrage des données est un moteur primaire de la qualité compétitive.
Exploration : Restreindre $i$ ML à une seule piste de modélisation (ex: uniquement le ML Traditionnel) a entraîné un effondrement des performances sur les tâches non tabulaires, validant la nécessité d'une exploration multi-pistes.

5. Signification et Revendications

L'article affirme que $i$ ML établit un paradigme robuste pour l'AutoML en comblant le fossé entre le raisonnement stratégique de haut niveau et l'implémentation empiriquement vérifiable.

Fiabilité plutôt que Plausibilité : Contra_irement aux agents précédents qui génèrent du code textuellement plausible mais fragile, $i$ ML impose l'exécutabilité via un processus en boucle fermée d'assemblage, d'exécution, de diagnostic et de correction.
Ancrage Empirique : En ancrant la planification dans les propriétés observées des données et les connaissances récupérées, le système évite les hypothèses hallucinées qui mènent à des échecs d'exécution.
Performance Compétitive pour l'Humain : $i$ ML démontre que l'AutoML piloté par le code peut transcender les plafonds de performance des outils d'optimisation « boîte noire » (comme AutoGluon) en architecturant des pipelines natifs et spécifiques à la tâche.

Les auteurs concluent que $i$ ML représente une étape transformative vers une ingénierie autonome fiable et compétitive pour l'humain, fournissant une base vérifiable pour la prochaine génération de systèmes de ML. Ils reconnaissent que, bien que la performance sur les tâches multimodales reste une frontière pour l'optimisation future, le cadre répond avec succès aux défis fondamentaux de l'enchevêtrement de la logique et de la fiabilité d'exécution des agents d'AutoML actuels.