RECHERCHE· 3 min de lecture

Comment Muse Spark 1.2 a été entraîné : co-entraînement, long horizon et boucle d'auto-amélioration

« Built for Muse Spark » n'est pas un slogan marketing — c'est la description d'une stratégie d'entraînement. Trois techniques tirées des notes de version de Meta expliquent pourquoi le modèle et l'agent sont meilleurs ensemble qu'avec un inconnu.

#muse-spark#training#co-training#self-improvement

Une mise à jour centrée code, à grande échelle

Muse Spark 1.2 est une mise à jour de la 1.1 tournée sans détour vers le code : génération, débogage complexe, compréhension de codebases, et workflows développeur de bout en bout. Meta a nettement augmenté le compute d’entraînement sur les tâches de code tout en élargissant la diversité des environnements d’entraînement — et a préservé les forces d’agent généraliste du modèle au lieu de les sacrifier. Le résultat mesurable, couplé à Muse Code : 82,9 % sur Terminal-Bench 2.1 et 59,3 % sur DeepSWE 1.1, au niveau des agents les plus forts de la catégorie.

Technique un : le co-entraînement avec le harnais

La plupart des agents de code sont un modèle générique habillé d’un wrapper : le harnais prompte le modèle, le modèle s’exécute, et les coutures se voient dans les retries et les outils mal utilisés. Meta a entraîné Muse Spark 1.2 avec Muse Code à la place. Le mélange d’entraînement incluait des trajectoires du harnais passées au rejection sampling — des runs d’agent complets, filtrés pour que seuls les runs réussis instruisent le modèle — plus des optimisations de recettes pour les objectifs, la compaction et les sous-agents, et l’intégration de l’outillage réel de Muse Code.

Conséquence : un modèle qui a déjà vu les situations dans lesquelles son harnais va le placer — quand distribuer du travail à un sous-agent, comment formuler un tool call que le runtime acceptera, à quoi ressemble un contexte compacté. L’affirmation de Meta — meilleur usage des outils, moins de retries, sortie de meilleure qualité qu’un wrapper générique — est une prédiction directe de ce montage.

Technique deux : l’entraînement long horizon

Muse Spark 1.2 a été massivement entraîné sur des tâches qui ne tiennent pas en une seule séance : génération de dépôts entiers, gros projets de bout en bout, auto-recherche. Trois capacités apprises tiennent ce genre de travail ensemble — la planification pour séquencer les étapes, le conditionnement sur l’objectif pour garder le cap sur des centaines de décisions, et la compaction de contexte pour retenir l’essentiel quand l’historique déborde même d’une fenêtre de 1M de tokens. Ce ne sont pas des fonctionnalités boulonnées après coup : elles affleurent directement dans le produit sous forme de /plan et /goal, et c’est ce qui a rendu possible le run de 24 heures sur les kernels.

Technique trois : le modèle qui a noté son successeur

Le détail le plus intéressant, c’est la boucle d’auto-amélioration. Meta a utilisé Muse Spark 1.1 pour générer des environnements de code exigeants et des gabarits de suivi de consignes, puis lui a fait noter des solutions candidates sur leur respect de ces exigences. La sortie notée est devenue un dataset d’entraînement scalable pour la 1.2 — la génération précédente fabriquant à la fois l’examen et le barème de la suivante. Meta attribue spécifiquement à cette boucle le fait que la 1.2 suit les consignes complexes plus précisément que sa devancière.

Pourquoi ça compte au-delà d’une release

Chaque technique amplifie les autres : le co-entraînement transforme le harnais en signal d’entraînement, l’entraînement long horizon rend les grosses tâches apprenables, et l’auto-amélioration rend tout le pipeline moins cher à faire passer à l’échelle la prochaine fois. Meta annonce des modèles plus grands et plus capables en chemin — et cette machinerie est vraisemblablement la façon dont ils seront construits. La méthodologie d’évaluation complète est publiée sur le site de recherche de Meta ; pour sentir ce que les chiffres donnent en pratique, commence par le guide de démarrage.

Poursuivre la lecture