AIDE ML : l'agent d'ingénierie ML qui explore un arbre de scripts

Le problème : écrire du code ML quand on sait décrire l'objectif mais pas l'implémentation

Décrire une tâche de machine learning en langage naturel est devenu facile. Écrire le script qui la résout, le déboguer et l'améliorer par itérations successives reste coûteux. AIDE ML prend cette deuxième partie en charge. Le README le présente comme un agent piloté par LLM qui écrit, évalue et améliore du code d'apprentissage automatique, à partir d'une description d'objectif et d'une métrique. Le public visé est nommé sans ambiguïté : d'un côté les chercheurs en architecture d'agents, qui veulent remplacer les heuristiques de recherche, les évaluateurs ou le backend LLM ; de l'autre les praticiens qui veulent construire rapidement un pipeline performant sur un jeu de données donné. Le dépôt se positionne lui-même comme la version open source de référence de l'algorithme AIDE, distincte du produit commercial Weco qui généralise l'approche à d'autres scénarios d'optimisation de code.

Un arbre de solutions plutôt qu'une chaîne de corrections

Le mécanisme central est une recherche arborescente guidée par LLM dans l'espace du code. Chaque script Python produit devient un nœud d'un arbre de solutions. L'agent génère des correctifs, qui donnent naissance à des nœuds enfants. La métrique mesurée sert à la fois à élaguer les branches peu prometteuses et à orienter la suite de l'exploration. Cette structure diffère d'un agent linéaire, qui corrige le même script en boucle : ici, plusieurs pistes coexistent et la meilleure est conservée. Le README cite le benchmark MLE-bench d'OpenAI, composé de 75 compétitions Kaggle, selon lequel la recherche arborescente d'AIDE remporte quatre fois plus de médailles que le meilleur agent linéaire évalué dans ce cadre. C'est un chiffre rapporté par le projet, pas une mesure indépendante. Le dépôt indique aussi que l'algorithme est décrit dans un article arXiv, et plusieurs travaux externes sont listés comme construits sur ou avec AIDE, notamment MLE-bench, RE-Bench de METR, AI Scientist-v2 de Sakana AI et deux projets Meta.

Installation et première exécution en trois commandes

Le paquet s'installe depuis PyPI avec pip install -U aideml, et requiert Python 3.10 ou plus récent d'après les badges du README. Il faut ensuite exposer une clé d'API, par exemple export OPENAI_API_KEY=<votre-clé>. L'exécution se fait avec la commande aide, à laquelle on passe le répertoire de données, l'objectif et la métrique : aide data_dir="example_tasks/house_prices" goal="Predict the sales price for each house" eval="RMSE between log-prices". À la fin du run, deux fichiers sont produits dans logs/<id>/ : best_solution.py, qui contient le meilleur code trouvé, et tree_plot.html, qui permet d'inspecter l'arbre des solutions. Le README ne documente pas de fichier de configuration global ni de format de sortie supplémentaire. La métrique est fournie sous forme de chaîne libre, ce qui suppose que l'agent l'interprète correctement dans le code qu'il génère.

Choisir le modèle, le nombre d'itérations et les brouillons

Trois paramètres structurent le comportement de l'agent. agent.code.model désigne le LLM qui écrit le code, avec gpt-4-turbo comme valeur par défaut. agent.steps fixe le nombre d'itérations d'amélioration, vingt par défaut. agent.search.num_drafts contrôle le nombre de brouillons produits à chaque étape, cinq par défaut. On peut les surcharger en ligne de commande, comme dans l'exemple du README qui remplace le modèle par claude-4-sonnet et porte les étapes à cinquante. Ces valeurs par défaut ont un coût direct : vingt étapes à cinq brouillons représentent un volume d'appels LLM non trivial avant même de compter les correctifs. Le projet revendique une neutralité vis-à-vis des fournisseurs : OpenAI, Anthropic, Gemini, ou tout LLM local qui parle l'API OpenAI. C'est un point d'architecture utile, mais il déplace la question du coût vers l'utilisateur, qui doit arbitrer entre qualité du code généré et dépense en inférence.

Utilisation depuis Python et interface Streamlit

AIDE ML s'utilise aussi comme bibliothèque. Le README donne un exemple complet : on importe aide, on configure le logging, puis on instancie aide.Experiment avec data_dir, goal et eval, avant d'appeler exp.run(steps=2). L'objet retourné expose valid_metric et code. L'exemple du README porte sur un jeu de données de prix de bitcoin avec RMSLE comme métrique. Pour l'interface web, il faut cloner le dépôt, exécuter pip install -e . pour récupérer Streamlit, se placer dans aide/webui et lancer streamlit run app.py. La barre latérale permet de coller une clé d'API, de téléverser des données, de définir Goal et Metric, puis de lancer l'exécution. L'interface affiche les journaux en direct, l'arbre des solutions et le meilleur code. La différence entre les deux modes est nette : la CLI suppose des données déjà présentes sur le disque, l'interface web accepte un téléversement.

Ce que le projet ne fait pas

Le README est explicite sur la frontière : AIDE ML est une implémentation allégée destinée à l'expérimentation et à l'extension, tandis que le produit Weco est présenté comme la version qui généralise les capacités d'AIDE à d'autres scénarios d'optimisation de code, avec suivi d'expériences et contrôle utilisateur renforcé. Autrement dit, si vous cherchez une plateforme de production avec traçabilité des runs et garde-fous, ce dépôt n'est pas l'outil annoncé. Deuxième réserve : le benchmark MLE-bench est mis en avant par le projet lui-même, et le chiffre des quatre fois plus de médailles provient de ce même matériau promotionnel. Il n'est pas vérifié ici. Troisième point, plus concret : la qualité du résultat dépend entièrement du modèle configuré et de la clarté de la métrique fournie en langage naturel. Rien dans le README ne décrit de validation de cette chaîne de métrique, ni de garde-fou si l'agent génère du code qui triche sur l'évaluation.

Face à un agent linéaire comme OpenHands

La comparaison la plus directe proposée par le README oppose AIDE à OpenHands, décrit comme le meilleur agent linéaire évalué sur MLE-bench. La différence n'est pas dans le modèle utilisé mais dans la topologie de la recherche. Un agent linéaire maintient une seule trajectoire de code et la corrige à chaque retour de métrique. AIDE maintient un arbre : les branches ratées ne sont pas jetées, elles restent explorables, et la métrique sert de signal d'élagage. En pratique, cela se traduit par davantage d'appels LLM par run, puisque chaque étape produit plusieurs brouillons, mais aussi par une probabilité plus élevée de sortir d'un optimum local. Le compromis est donc explicite : plus de calcul, une meilleure couverture de l'espace des solutions. Pour un budget d'inférence serré, un agent linéaire reste défendable. Pour un problème où la première implémentation plausible échoue souvent, la recherche arborescente a un argument structurel.

Maintenance, licence et coût de mise à jour

Le dépôt n'est pas archivé et la dernière poussée de code date du 3 septembre 2026 selon les métadonnées fournies. La version publiée la plus récente est v0.2.2, datée du 5 novembre 2025, après v0.2.0 en janvier 2025 et v0.1.4 en avril 2024. Le rythme est irrégulier : une version majeure par an environ, ce qui suggère un projet de recherche maintenu sans cadence industrielle. Le paquet est publié sous licence MIT, ce qui autorise la réutilisation et la modification, y compris dans un contexte commercial, sous réserve de conserver la notice de licence. Cette lecture ne constitue pas un avis juridique : pour un usage en produit, faites vérifier les conditions exactes, en particulier si vous redistribuez le paquet ou l'intégrez à un service. Le coût de mise à jour se concentre sur deux points : les valeurs par défaut de agent.steps et agent.search.num_drafts, qui déterminent la facture d'inférence, et la compatibilité des noms de modèles dans agent.code.model, qui dépendent de fournisseurs externes et peuvent devenir obsolètes indépendamment du projet.

Conclusion éditoriale

AIDE ML convient aux chercheurs en architecture d'agents et aux praticiens qui veulent prototyper un pipeline ML à partir d'une description en langage naturel, avec la possibilité de lire le code produit et l'arbre de recherche. Il ne convient pas à ceux qui cherchent une plateforme de production avec suivi d'expériences et contrôle utilisateur étendu : le README renvoie explicitement vers le produit Weco pour ce cas. Avant d'adopter, vérifiez le coût en appels LLM induit par les valeurs par défaut de agent.steps et agent.search.num_drafts, et lisez la licence MIT du dépôt pour les conditions de redistribution.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. WecoAI/aideml on GitHub