autoresearch — Agents IA qui modifient leur propre code d'entraînement LLM¶

Resume¶

Projet Karpathy (58k stars, 36 commits, MIT) : donner à un agent IA un setup d'entraînement LLM réel mais miniature, et le laisser expérimenter autonomement. L'agent modifie train.py (modèle + boucle d'entraînement), entraîne 5 minutes, évalue val_bpb (validation bits per byte — plus bas = meilleur), itère. prepare.py est hors-scope (non modifiable). program.md oriente les objectifs de l'agent. Forks pour macOS, Windows, AMD existants.

Analyse critique¶

Ce qui est conceptuellement important :

C'est le premier projet grand public où un agent IA modifie le code qui produit des systèmes IA similaires. Ce n'est pas de l'auto-amélioration au sens strict (l'agent ne s'améliore pas en temps réel), mais la première démonstration accessible de ML research automatisé par agent.

La durée fixe à 5 minutes est la bonne décision de design : chaque run est comparable, l'agent ne peut pas "tricher" en laissant tourner plus longtemps. C'est exactement le pattern d'évaluation court et reproductible qui rend possible l'automatisation.

Ce qui est exagéré dans la couverture :

58k stars pour 36 commits = explosion de hype sans maturité proportionnelle. C'est un démonstrateur de concept, pas un outil de production. Karpathy lui-même présente ça comme expérimental.

Ce qui manque :

Pas de mécanisme structural pour limiter l'agent à train.py. La frontière "ce que l'agent peut modifier" est documentaire (instructions dans program.md), pas technique. Un agent mal guidé peut modifier des fichiers hors-scope.

Pertinence ProbatioVault¶

Impact modéré. Signal de direction intéressant.

Ce qui résonne avec notre workflow :

Notre step 6b est déjà une forme d'autoresearch limitée : agents produisent du code, gates évaluent, on itère jusqu'à GO. autoresearch généralise ce pattern au niveau de l'entraînement LLM lui-même.

Expérimentation possible à terme :

Un mini-autoresearch sur les prompts de governance : un agent modifie un prompt de gate, on évalue la qualité des verdicts (métriques existantes dans metrics.jsonl), on itère. Cycle court (une gate ≈ 5 min), métrique claire (score conformité), frontière nette (un seul fichier template modifiable).

Horizon réaliste : 6-12 mois, une fois le workflow stabilisé. À surveiller pour son évolution.