Muse Spark 1.3 gère des tâches plus longues avec moins d’appels d’outils

Meta lance Muse Spark 1.3 pour la programmation et les agents chargés de missions longues, mais son mode de raisonnement le plus performant et les poids promis ne sont pas encore largement disponibles.

Un agent reçoit des données de simulation et un fichier de conception 3D, analyse leur contenu, rédige un rapport d’ingénierie aéronautique, organise les mesures dans des tableaux puis exporte le résultat en PDF. Meta utilise cet exemple pour présenter Muse Spark 1.3, un modèle conçu pour poursuivre des missions complexes sans perdre les exigences formulées au départ.

Lancé le 2 septembre, Muse Spark 1.3 succède à la version 1.2 après seulement quelques semaines. Il est disponible dans Muse Code, l’environnement de programmation de Meta, ainsi qu’à travers la Meta Model API. Cette mise à jour porte autant sur la manière de conduire une tâche que sur la qualité de la réponse finale.

Meta affirme que Muse Spark 1.3 peut gérer plusieurs flux de travail dans une même conversation prolongée. Le modèle doit rattacher chaque nouvelle instruction à la bonne mission, y compris lorsque l’utilisateur interrompt une demande en cours, revient sur un travail antérieur ou modifie les priorités de plusieurs projets.

Face à un objectif ouvert, il peut utiliser des outils pour constituer son propre contexte à partir de documents et de sources parfois incomplets ou contradictoires. Il est également entraîné à repérer les lacunes de son plan, conserver les informations déjà obtenues et réviser son approche avant de produire le livrable demandé.

L’entreprise a particulièrement travaillé les échanges entre l’agent et son utilisateur. Lorsqu’une demande demeure ambiguë, Muse Spark 1.3 doit poser une question de clarification. S’il rencontre une difficulté qu’il ne sait pas résoudre, il peut demander de l’aide plutôt que prétendre avoir terminé. Il est aussi censé obtenir une confirmation avant une opération importante ou difficilement réversible.

Ces comportements ne signifient pas que le modèle peut déterminer correctement les conséquences de chaque action. Sa décision de réclamer une validation dépend toujours de son interprétation de la situation, des instructions définies par l’application et des autorisations accordées à ses outils. Une intégration doit donc continuer à limiter l’accès aux systèmes externes et à faire vérifier séparément les opérations sensibles.

Le suivi peut s’adapter aux préférences de l’utilisateur. Muse Spark 1.3 peut transmettre des nouvelles régulières pendant une mission longue ou travailler plus discrètement jusqu’à l’obtention d’un résultat. Cette possibilité concerne notamment les tâches comportant de nombreuses recherches, des transformations de fichiers, des commandes dans un terminal ou plusieurs cycles de correction.

Meta annonce également une meilleure fidélité aux instructions longues. Le modèle devrait moins souvent abandonner une règle de mise en forme, oublier un fichier attendu ou s’éloigner du processus demandé après plusieurs étapes intermédiaires.

Les démonstrations couvrent différents métiers. Dans l’une d’elles, le modèle reçoit les résultats préliminaires d’une simulation de mécanique des fluides et un fichier STEP représentant une aile expérimentale. Il prépare ensuite un rapport décrivant l’environnement de simulation, les conditions aux limites, les mesures de performance, les conséquences aérodynamiques et plusieurs recommandations.

D’autres exemples portent sur la correction d’erreurs dans une piste de basse, la préparation d’une présentation destinée à un conseil départemental et la synthèse de commentaires publics enregistrés dans une feuille de calcul. Meta indique explicitement qu’il s’agit de prototypes d’agents et non de produits commercialisés. Ces scénarios montrent des flux de travail possibles, mais l’entreprise ne publie ni taux de réussite détaillé ni quantité d’interventions humaines nécessaires avant leur présentation.

La programmation reste l’un des principaux usages de Muse Spark. La version 1.3 a été entraînée sur davantage de missions d’ingénierie logicielle de longue durée et doit éviter certaines interactions inutiles. Lors de comparaisons menées par les équipes de Meta, elle aurait utilisé environ 20 % d’appels d’outils et 25 % de tokens en moins que Muse Spark 1.2.

Ces réductions pourraient raccourcir l’exécution et diminuer les coûts lorsqu’un agent doit parcourir un dépôt, modifier des fichiers, lancer des tests puis corriger ses erreurs. Elles restent cependant issues de mesures internes. Meta ne précise pas le nombre de projets testés, leur difficulté, les configurations de raisonnement employées ni le protocole permettant de reproduire ces économies.

Les mesures indépendantes montrent également que l’efficacité dépend de la nature du travail. Artificial Analysis estime que la configuration xhigh actuellement disponible revient à environ 0,55 dollar par tâche sur son Intelligence Index, contre 0,40 dollar pour Muse Spark 1.2.

Ce résultat ne contredit pas directement la comparaison de Meta, limitée à des flux de programmation internes. L’évaluation indépendante couvre un ensemble plus large de tâches de raisonnement et d’utilisation d’outils. Elle montre néanmoins qu’une réduction des appels dans un contexte précis ne garantit pas une consommation inférieure dans toutes les applications.

La principale réserve concerne la configuration utilisée pour les benchmarks. Le tableau affiché dans l’annonce de Meta repose principalement sur Muse Spark 1.3 avec le niveau de raisonnement max. Celui-ci n’était pas largement disponible au lancement. Les modes déjà proposés, dont xhigh, peuvent être utilisés immédiatement, tandis que max doit arriver après des tests de sécurité supplémentaires.

La différence entre les deux configurations devient importante sur certaines évaluations. Meta annonce un indice Elo de 1 754 pour max sur GDPVal-AA v2, un test portant sur la production de livrables professionnels. La configuration xhigh accessible au public obtient 1 709. Sur JobBench, leurs résultats respectifs atteignent 64,9 et 61,2.

L’écart se creuse sur OSWorld 2.0, où un agent doit manipuler un environnement informatique graphique. Max obtient 66,9, contre 57,2