Appliquer Autoresearch à une vieille idée de recherche

• Le système Autoresearch adopte une structure de boucle d’optimisation sous contraintes dans laquelle un agent LLM modifie train.py de manière itérative pour améliorer les performances, en automatisant tout le cycle, de la formulation des hypothèses jusqu’à l’évaluation
• Les expériences s’exécutent dans un environnement sandbox basé sur des conteneurs, qui bloque l’accès réseau et l’exécution de code arbitraire
• En utilisant le jeu de données Ukiyo-eVG, l’entraînement exploite environ 11�0 images d’estampes japonaises sur bois et leurs annotations, et un modèle basé sur CLIP atteint un Mean Rank de 34,30 et un R@5 d’environ 53 %
• Les principales améliorations proviennent de l’assouplissement du paramètre temperature (-113 de Mean Rank) et du tuning d’hyperparamètres (-30 de Mean Rank), avec un gain de performance de 54 % obtenu via 13 commits sur 42 expériences en une journée
• L’agent LLM est efficace dans un espace de recherche clairement défini, mais son instabilité augmente après l’étape des changements structurels, ce qui met en évidence les limites d’une recherche entièrement autonome

---

Idée principale

• Autoresearch repose sur une boucle d’optimisation sous contraintes centrée sur un agent LLM, qui modifie train.py afin d’améliorer itérativement les métriques d’évaluation
  • L’agent lit les instructions dans program.md et utilise scratchpad.md comme carnet de travail pour consigner le déroulement des expériences
• L’exploration est structurée en plusieurs phases : elle commence par le tuning d’hyperparamètres, passe à de petites modifications structurelles, puis s’étend à une exploration plus libre avec un minimum de contraintes
• La boucle complète suit une structure cyclique : formulation d’hypothèse → modification du code → entraînement → évaluation → commit ou retour en arrière → répétition
• Chaque expérience est limitée à environ 5 minutes afin de favoriser des itérations rapides et de limiter l’overfitting
• L’agent peut modifier librement train.py dans la limite de temps impartie

• Sandbox

  • Pour éviter les risques liés à l’exécution de code arbitraire, la boucle d’entraînement s’exécute dans un environnement conteneurisé avec accès réseau bloqué
  • run.sh pilote l’ensemble du flux expérimental, et Claude Code ne peut modifier que train.py et program.md
  • L’exécution directe de Python, l’installation via pip, l’accès réseau, les git push, etc. sont tous interdits
  • L’implémentation correspondante est publiée sur GitHub

Jeu de données

• Comme le jeu de données de radiographies médicales utilisé dans l’étude d’origine n’était pas accessible, le jeu de données Ukiyo-eVG a été utilisé à la place
  • Il contient environ 11�0 images d’estampes japonaises sur bois ainsi que des annotations texte–boîtes englobantes
  • Les boîtes englobantes sont converties en heatmaps gaussiennes ajoutées en entrée du modèle, selon une approche similaire au mécanisme d’attention experte de l’article eCLIP original
• Les heatmaps guident le modèle pour qu’il se concentre sur des zones spécifiques

Configuration expérimentale avec Claude Code

• Claude Code a mis à niveau le code de recherche existant vers un environnement Python récent et a écrit le chargement du nouveau jeu de données ainsi que le scaffolding de la boucle d’expérimentation
• Il a également mis en place les splits de validation croisée, la logique d’évaluation et les idées initiales dans program.md
• La métrique d’évaluation utilisée était le Mean Rank, et le rapport final inclut aussi le Recall@K
  • Le Mean Rank a été retenu pour son interprétation intuitive, mais il est mentionné qu’un Median Rank aurait probablement été plus approprié car moins sensible aux valeurs extrêmes
• Configuration du modèle : backbone CLIP avec ViT-Small (22M) + DistilBERT (66M) + HeatmapProcessor, pour un total d’environ 90M de paramètres
  • Entraînement : 800 steps (environ 3 minutes par expérience sur une RTX 4090)
  • Évaluation : mesure du Mean Rank et du Recall@K sur un jeu de test de 1�0 images
  • Performance de référence : Val Mean Rank 344,68, img→txt R@1 17,2 %, txt→img R@1 16,5 %

Résultats expérimentaux

• Au total, 42 expériences ont été menées en une journée, dont 13 commits et 29 retours en arrière
  • Le Mean Rank a baissé de 344,68 à 157,43, soit 54 % de réduction
• Lors de l’entraînement final sur l’ensemble du jeu de données, les scores de test se sont révélés supérieurs aux scores de validation
  • Cela suggère que les expériences courtes de 800 steps étaient en situation d’underfitting
• Performance finale sur le test : Mean Rank 34,30, img→txt R@5 53,0 %, txt→img R@5 51,4 %

Principaux points d’amélioration

• Correction du clamp de temperature (-113 de Mean Rank)

  • Dans le code, le paramètre temperature entraînable était plafonné à 2 ; l’agent a assoupli cette contrainte, ce qui a fortement amélioré les performances
  • C’est l’effet unitaire le plus important parmi toutes les améliorations

• Optuna++ (-30 de Mean Rank)

  • Les améliorations suivantes proviennent principalement du tuning d’hyperparamètres
  • L’augmentation de la dimension de projection et le réajustement du taux d’apprentissage ont apporté 30 points supplémentaires de gain
  • L’agent exécute plus vite et plus systématiquement des tâches répétitives et fastidieuses qu’un humain ferait à la main

• Zone de rendements décroissants

  • À partir de la phase 4 (changements structurels), le taux de réussite des hypothèses du LLM chute fortement
  • Les modifications du mécanisme d’attention ou les tentatives d’idées audacieuses (moonshot) ont presque toutes échoué
  • Dans la seconde moitié de l’exploration, les essais sont devenus largement aléatoires

• Importance de la sandbox

  • Claude Code a parfois montré un comportement instable, oubliant ses permissions et tentant des appels bash incorrects, ou interrompant la boucle pendant l’attente de l’entraînement
  • L’exécution totalement autonome a donc encore des limites

Observations finales

• Sur l’ensemble du processus, les 90 % initiaux se sont déroulés sans accroc, tandis que les 10 % restants ont demandé beaucoup d’intervention
• Un agent LLM peut mener efficacement de la recherche en ML dans un espace de recherche clairement défini
• La boucle commit–retour en arrière d’Autoresearch est utile comme stratégie d’exploration structurée
• Mais dès qu’elle s’étend à des zones inconnues, la boucle d’optimisation devient instable
• La contrainte n’autorisant qu’une seule modification par expérience était peut-être trop stricte pour explorer des idées de grande ampleur
  • Parmi les pistes d’amélioration proposées figurent l’ajout d’une phase de planification ou l’introduction de sous-agents (subagents)
• Après la fin des expériences, la collaboration avec Claude Code s’est conclue par un retour au quotidien

Remerciements

• Jeu de données Ukiyo-eVG : environ 11K images d’estampes japonaises sur bois avec annotations texte–boîtes englobantes
• Autoresearch : basé sur l’idée originale d’Andrej Karpathy

[GN⁺]

Commentaires sur Hacker News

• Si le lien principal est lent, suggestion d’essayer la version archive.is

• J’utilise souvent les LLM pour explorer des recherches existantes ou réfléchir à un problème autrement 90 % des résultats ne correspondent pas à mon domaine, mais les 10 % restants sont assez utiles En revanche, avoir un agent qui essaie réellement tout ce que le LLM recommande coûte beaucoup trop cher ($$$) La liste de recommandations contient souvent des bibliothèques de niche qui ne sont plus maintenues Cela dit, les « consultants experts » de l’entreprise font souvent des propositions tout aussi absurdes, donc je préférerais encore qu’un agent s’en charge à leur place

  • La valeur d’un agent, c’est de pouvoir répéter automatiquement les expériences pendant que l’utilisateur se repose Mais cela n’a de sens que si chaque test est rapide. Dans mon travail, un seul test prend une demi-journée, donc difficile de faire tourner ça toute la nuit
  • Je suis curieux de savoir dans quel domaine tu travailles
  • Je trouve que les LLM sont utiles pour les phrases courtes qu’on n’a pas envie de mémoriser, ou pour les parties où une erreur n’est pas grave Quand je vois des gens configurer des choses comme des serveurs MCP ou AGENTS.md, j’y vois surtout la preuve que les LLM ne fonctionnent pas comme annoncé Bien réglés pour un workflow précis, ils peuvent être excellents, mais je doute que cela puisse passer à l’échelle Sans les financements massifs qui soutiennent l’entraînement et l’infrastructure, est-ce que cela peut vraiment devenir un modèle économique durable ?
  • Le coût est peut-être le vrai problème. J’utilise Claude Code assez légèrement, et même avec le forfait Max, je n’épuise presque jamais mes tokens

• La formule « l’agent s’est comporté comme un algorithme d’optimisation d’hyperparamètres » m’a marqué L’essentiel tient à un unique fichier de prompt système, program.md, avec une boucle du type « améliorer train.py → lancer l’entraînement → évaluer → consigner les résultats » Le reste n’est qu’un modèle de ML quelconque

• Donner du code en fonctionnement à un LLM et lui faire répéter correction de bugs, mesure des performances et évaluation de la couverture de tests est l’approche standard de notre équipe Utiliser un modèle différent à chaque itération donnait une impression agréable de nouveau point de vue

  • Je me demande si cette approche pourrait s’appliquer à l’entraînement de LLM locaux spécialisés pour un langage ou un framework donné

• Je me demandais pourquoi « Autoresearch » faisait autant parler de lui J’ai toujours pensé que les goulots d’étranglement en IA/ML étaient surtout la qualité des données ou les ressources de calcul, et je ne vois pas en quoi cela améliore ces points

  • En réalité, ce genre d’essai existe depuis longtemps. Le domaine de l’AutoML en est un exemple, et en pratique ça n’a pas vraiment marché Il y a eu des approches comme l’optimisation bayésienne ou les processus gaussiens, mais au final la recherche aléatoire faisait mieux Ce qui change avec les LLM, c’est qu’ils peuvent lire la littérature et faire des raisonnements de bon sens Ce n’est pas parfait, mais il est possible que ce soit meilleur que les méthodes existantes
  • La différence, c’est qu’on peut aller au-delà du simple réglage d’hyperparamètres et faire aussi des modifications structurelles non paramétriques Ce n’est pas un concept entièrement nouveau, mais l’idée semble être d’être moins brute-force
  • Il existe aussi des techniques plus anciennes comme la « swarm optimization », mais les LLM se distinguent par leur capacité à apprendre des recherches passées et à se concentrer sur les axes importants Autrement dit, le LLM peut réutiliser des travaux déjà réalisés par quelqu’un
  • Je ne suis pas d’accord avec l’idée que « les données ou le compute sont le goulot d’étranglement » Le cœur du ML, c’est de trouver une meilleure fonction de mapping pour la même entrée X Il ne suffit pas d’ajouter du compute pour régler le problème
  • Au fond, Autoresearch consiste à déléguer la réflexion elle-même au LLM

• Au final, ça a fonctionné. Le LLM a bien trouvé des bugs et optimisé certaines choses

  • Mais en pratique, la plupart des améliorations venaient surtout de corrections de bugs + tuning avec Optuna Ce genre de choses se fait aussi très vite avec Claude Code La vraie valeur d’Autoresearch se situerait sans doute dans l’exploration d’architecture Je me demande si quelqu’un l’a déjà utilisé pour du modélisation exploratoire

• En regardant l’historique des commits (lien GitHub), on voit que c’était surtout du tuning d’hyperparamètres À ce niveau-là, j’ai l’impression que le coût en tokens ($$$) ne vaut pas le coup

  • Ajouter à Autoresearch une estimation du coût et une étape de tri pour qu’un humain valide avant exécution pourrait être efficace On pourrait l’améliorer en donnant un feedback de coût via un adaptateur LoRa
  • En réalité, on peut déjà faire cela avec des outils open source comme Optuna ou skopt, même sans GPU

• L’article d’origine utilisait des données médicales de radiographie, mais faute d’accès ils les ont remplacées par Ukiyo-eVG (11 k estampes japonaises) Ça m’a semblé être un changement assez étrange. On trouve aussi beaucoup d’images médicales gratuites sur le Cancer Imaging Archive

  • C’est vrai. Cela dit, je n’étais pas très à l’aise à l’idée de confier des données médicales à un agent, et je voulais aussi expérimenter le transfert de domaine

• J’espérais que quelqu’un ferait ce genre d’expérience, donc j’étais content de voir que quelqu’un l’avait vraiment fait Le passage « j’en ai eu assez d’attendre la fin de l’entraînement et j’ai fermé la conversation » m’a fait rire Merci d’avoir partagé les résultats

  • Merci, réponse indiquant que la lecture était très agréable

• Cela ressemble moins à de la recherche automatisée qu’à des essais-erreurs structurés Au final, l’essentiel reste la qualité de la métrique d’évaluation. Si elle est faible, on ne fait qu’optimiser plus vite dans la mauvaise direction

  • Concevoir une bonne fonction de fitness a toujours été difficile
  • Certains estiment qu’au fond, c’est exactement cela, la méthode scientifique