Donnez à un agent IA tout l'atelier d'entraînement d'un modèle, et regardez ce qu'il fait. Dans l'expérience des auteurs d'AutoSFT, il tourne 33 fois pendant 11 heures, consomme 94 % de sa fenêtre de contexte, et ne rédige jamais une seule ligne. Il rééquilibre des proportions. Encore et encore. Le papier qui en découle, 21 auteurs et quatre institutions, corrige ça en séparant les rôles. Résultat : +6,5 points sur IFEval, pour environ 1 900 dollars la campagne.
Le problème : 33 tours, zéro exemple écrit
Le papier AutoSFT, soumis le 15 octobre 2026, part d'une observation simple et vérifiable. Un agent qui dispose de toute la pile d'entraînement finit par faire du SFT, le fine-tuning supervisé, et passe l'essentiel de son effort à réviser les données. Le problème n'est pas qu'il choisit la mauvaise méthode. C'est qu'il n'exploite qu'une fraction de l'espace des actions possibles.
Les auteurs formalisent cet espace en six familles d'actions qu'un ingénieur données expérimenté utilise réellement : ajuster les proportions entre catégories, élaguer des lignes, réparer des réponses, remplacer les réponses trop longues, écrire des exemples pour les capacités absentes, et ordonner les données. Les systèmes existants n'en offrent qu'une.
Le diagnostic du mode d'échec est la partie la plus instructive. Un agent unique qui analyse, propose, exécute et interprète les journaux dans la même session voit l'exécution entrer en concurrence avec l'analyse pour l'espace de contexte. La trace condensée est édifiante : 33 tours sur 11,5 heures, 877 appels au modèle, 94,74 % d'une fenêtre de 258 400 tokens consommés avant la dixième compaction.
Sur ces 33 tours, l'agent n'a jamais édité une ligne. Jamais remplacé une réponse. Jamais écrit un exemple. Il a réajusté les proportions, encore et encore, en compactant son contexte à dix reprises. Le papier relève même qu'il ne mentionne jamais le temps. Quiconque a fait tourner un agent long sur une tâche ouverte reconnaîtra le tableau.
La solution : séparer l'exécution de l'analyse
AutoSFT répond par une séparation des rôles. Un agent méta possède chaque tour et délègue à trois familles de sous-agents.
L'exécuteur lance l'entraînement, la conversion et l'évaluation séparément, puis renvoie des chemins de fichiers avec un court rapport de statut. Ça libère le contexte du méta pour l'analyse. Les sous-agents d'analyse lisent le même tour sous quatre angles complémentaires : les données, les échecs, les signaux d'entraînement et les tours précédents, chacun rendant une action proposée. Un sous-agent de synthèse écrit de nouvelles données pour les capacités que le pool couvre mal. Tous partagent un pool de candidats et une bibliothèque de compétences.
L'évaluation est méthodologiquement propre, et il faut le souligner parce que c'est rare. Chaque comparaison repart du même point de contrôle de base, avec le même script d'entraînement, le même budget de tokens et la même évaluation. L'effet de chaque composant est donc attribuable, au lieu qu'on empile les changements et qu'on attribue le tout au dernier.
Les gains, composant par composant
Les résultats, enchaînés un composant à la fois, sont les suivants. L'exécuteur seul divise par deux la perte de contexte. Les sous-agents d'analyse portent le meilleur IFEval à +6,5 points. La synthèse ajoute +3,4 IFEval et +2,9 IFBench.
Dans l'expérience de synthèse complète, le meilleur IFEval atteint 81,58 contre 78,15 pour la campagne de base, et l'IFBench 51,95 contre 49,02. La boucle s'arrête quand IFEval atteint 80 et IFBench 50, deux seuils fixés à l'avance.
En code, sans taxonomie de capacités toute faite, l'analyse ajoute +3,7 MBPP+ sur un pool de 742 842 paires Python, alors que l'agent unique ne progresse pas. C'est le résultat le plus convaincant du papier, parce que le système doit construire sa propre taxonomie au lieu d'optimiser contre une mesure qu'on lui a donnée.
Le tout sur un modèle de base volontairement petit, Qwen3-1.7B-Base. Ce choix est à la fois une contrainte de coût et une décision méthodologique : à 1,7 milliard de paramètres, on peut refaire l'entraînement depuis la base à chaque tour, ce qui rend l'attribution des gains possible. Sur un modèle de 70 milliards, la même étude serait financièrement hors de portée.
Le prix du point de benchmark
Le coût est documenté avec une honnêteté inhabituelle. Un tour d'entraînement prend environ 0,8 heure d'horloge sur huit H800, soit environ 6,4 heures GPU par tour, et l'évaluation 0,15 heure GPU. Une campagne de vingt tours atteint donc environ 130 heures GPU. L'agent de recherche et le backend de génération consomment environ 2,6 × 10⁸ tokens par tour, soit près de 95 dollars d'API par tour, et environ 1 900 dollars sur la campagne.
Le papier rapporte une dizaine de campagnes et quelques centaines de tours, pour un ordre de grandeur total de 10³ heures GPU et 10⁴ dollars.
Posons la question que personne ne pose : à quel moment l'automatisation de la recherche sur les données devient-elle rentable ? 1 900 dollars et 130 heures GPU pour gagner 3 à 6 points sur un modèle de 1,7 milliard. Rapporté au coût d'un appel API à un modèle frontalier, le calcul n'est pas évident. L'argument des auteurs est que la méthode est transférable et que le coût marginal baisse avec l'échelle. Le papier ne le démontre pas, puisqu'il ne teste qu'un seul modèle.
Et c'est là qu'AutoSFT touche au vif. « Recherche automatisée » ne veut pas dire gratuite. Ça déplace le coût de l'annotateur humain vers le calcul et l'API. Et ça crée un risque nouveau : des modèles entraînés sur des données générées par des modèles, avec une boucle de plus en plus courte entre l'évaluation et la génération. Le papier ne traite pas ce risque.
Une semaine, quatre étages de la fabrique
AutoSFT n'est pas seul. La même semaine, trois autres papiers ont automatisé trois autres étages de la fabrique à modèles. Mosaic s'attaque à la trajectoire en RL agentique, et montre que les sessions multiples cassent les méthodes à session unique. Self-Evolving Agent Harness pousse la logique jusqu'au harnais logiciel de l'agent, prompts, mémoire et workflows compris, avec des bornes de généralisation et de rétention. MAI-Gym apporte l'infrastructure manquante pour les agents GUI : 20 000 environnements en parallèle, dix benchmarks, et un RL qui transfère sur un vrai téléphone.
Et face à cette débauche d'infrastructure, Palmyra x6 défend la thèse inverse : 626 trajectoires vérifiées, une seule époque, un faible taux d'apprentissage, une ancre KL vers le modèle gelé. Résultat, le meilleur score BFCL Core de sa cohorte. La recette conservatrice à petite dose reste compétitive face à l'automatisation à grande échelle.
Le débat n'est pas tranché, et c'est tant mieux.
Les limites, sans langue de bois
La première limite, c'est le dépôt vide. Le GitHub Thinking-Space/AutoSFT, créé le 15 octobre, tient en 25 octets de README : « Source code coming soon ». Douze étoiles, zéro fork, une issue ouverte. Dans un domaine où la reproductibilité est la monnaie de la crédibilité, annoncer un système multi-agents sans code revient à demander au lecteur de croire les courbes.
La deuxième, c'est le benchmark lui-même. Le pool de candidats est un jeu public construit pour ressembler à IFEval, et la boucle s'arrête quand IFEval atteint 80 et IFBench 50. Autrement dit, l'agent optimise directement contre la mesure qui sert à le juger, sur un pool qui contient des données de forme identique. Le gain de 3 points est réel dans ce cadre. Il ne dit rien de la généralisation à un benchmark tenu à l'écart.
La troisième est assumée par les auteurs : tous les résultats viennent d'un seul modèle de base à une seule échelle. Les effets rapportés peuvent ne pas tenir ailleurs.
La quatrième est statistique. Chaque comparaison repose sur une seule recherche par configuration. Un +6,5 peut donc être en partie un coup de chance dans l'espace des recettes.
La cinquième est la nature du gain. La synthèse améliore le score agrégé en comblant des capacités apprenables que le pool sous-alimente. Elle ne fait pas progresser les capacités que le modèle ne sait pas encore suivre. Un modèle qui ne sait pas raisonner ne le fera pas mieux parce qu'on lui ajoute des exemples bien rédigés. AutoSFT optimise la couverture, pas la compétence.
Enfin, le silence. Au 19 octobre, aucune discussion Hacker News pertinente, et 37 votes sur Hugging Face pour toute trace de traction. Pour un papier à 21 auteurs et quatre institutions, c'est un silence notable.
Verdict
AutoSFT est un papier solide, au positionnement honnête, qui documente un échec aussi précieux que sa solution. La trace du single agent, ses 33 tours, ses 877 appels, ses dix compactages, vaut à elle seule la lecture : c'est la meilleure illustration concrète que je connaisse de ce qu'est la pression de contexte et de pourquoi un agent long dérive.
Mais il ne faut pas en faire une révolution. Le dépôt est vide, le benchmark est circulaire, le modèle de base est minuscule. Ce qu'on a, c'est un mécanisme, pas une promesse.
Le mécanisme, le voici : un agent seul s'enferme dans la seule action qu'il sait faire. Séparez l'exécution de l'analyse, et l'espace des actions s'ouvre. C'est une leçon d'ingénierie qui dépasse le SFT, et qui s'applique à n'importe quel système d'agents qu'on laisse tourner trop longtemps avec trop de contexte et trop peu de structure.
Sources
- arXiv — AutoSFT: An Agentic System for Automated Data Research in SFT
- GitHub — Thinking-Space/AutoSFT
- Hugging Face — page Papers du modèle
- Hugging Face — dataset argilla/ifeval-like-data
- arXiv — Mosaic, RL agentique multi-session
- arXiv — Self-Evolving Agent Harness
- arXiv — MAI-Gym, plateforme d'évaluation agents GUI
- arXiv — Palmyra x6
Auteur
Krugz
Développeur fullstack
Développeur fullstack qui tente, tant bien que mal, de suivre l'actualité de l'IA au milieu d'une marée d'informations imbuvables et des milliers d'outils et de modèles qui sortent chaque jour.
