autoresearch : quand le modèle embauche un ingénieur ML

Contexte technique

J’aime ce genre de choses non pas pour le buzz, mais pour la forme du cycle. Dans autoresearch, Karpathy a construit un circuit très concret : l’agent lit le dépôt et program.md, modifie le script d’entraînement, exécute un court passage, regarde la métrique et soit valide le changement, soit le rétablit via git.

Au fond, ce n’est plus un « assistant de code » mais un modèle de automatisation par IA pour une équipe ML. L’humain fixe l’objectif et les contraintes, et le modèle prend en charge la partie mécanique de l’implémentation IA : hypothèse, modification, exécution, vérification, rollback.

Ce qui m’a particulièrement frappé ici, c’est que l’interface de contrôle n’est pas un tableau de bord lourd, mais une spécification en markdown. On ne met pas les mains dans train.py à chaque fois ; on décrit ce qui compte comme succès, ce qu’on peut toucher, le budget de l’expérience et comment journaliser les tentatives.

Le circuit public actuel est assez rigide : un budget court d’environ 5 minutes par passage, la métrique principale est val_bpb où moins c’est mieux, et la comparaison se fait dans des conditions identiques. C’est crucial : l’agent n’« entraîne pas magiquement un modèle », il itère des modifications dans un bac à sable formalisé.

D’après les résultats publiés, l’idée ne fonctionne pas comme un grand saut, mais comme une série de petits coups réussis. Des dizaines ou des centaines de passages produisent quelques améliorations réelles, et ce sont elles qui, avec le temps, améliorent la qualité ou la vitesse d’entraînement.

Et oui, les métriques mineures peuvent facilement chuter. Si vous optimisez un seul KPI, l’agent poussera exactement dans ce sens. Sans un ensemble correct de garde-fous, un tel système trouvera aussi vite un mauvais maximum local qu’une bonne piste.

Ce que cela change pour le business et l’automatisation

Le premier effet est simple : le cycle d’expérimentation devient moins cher. Si votre équipe passe des heures sur des passages répétitifs, ce pattern peut être intégré comme une boucle interne d’intégration IA en R&D, et les personnes se concentrent sur la conception expérimentale, pas sur la routine.

Le deuxième point concerne l’architecture. Ceux qui fragmentent l’entraînement en itérations courtes et mesurables avec une métrique claire en sortiront gagnants. Les projets où tout dépend de longs passages, de KPI flous et d’accords à l’amiable en chat en pâtiront.

La troisième nuance me semble la plus importante : ce n’est pas un remplacement de l’ingénieur ML, mais un amplificateur de la bonne discipline d’ingénierie. Chez Nahornyi AI Lab, nous résolvons régulièrement ce type de problèmes pour nos clients : d’abord nous construisons une métrique objective et des contraintes, puis nous mettons en place l’automatisation avec IA ; sinon, l’agent ne fait qu’automatiser le chaos.

Si l’entraînement de vos modèles, le réglage des prompts ou vos expériences internes s’enlisent dans des répétitions manuelles, on peut démonter cela au niveau processus. Chez Nahornyi AI Lab, je vous aiderai à assembler un développement de solutions IA adapté à votre workflow réel, pour que l’agent ne joue pas à la science mais économise aux gens des semaines de travail.

Nous avons déjà analysé la méthode Simple Self-Distillation, qui améliore la qualité de la génération de code en utilisant les propres prédictions du modèle sans vérificateurs externes ni apprentissage par renforcement complexe. Cette approche montre en pratique comment l’IA peut optimiser ses résultats de manière autonome — exactement l’idée que Karpathy met à l’échelle dans autoresearch.