ThinkingBox entraîne les agents à réussir plus souvent. Réussir une fois ne suffit pas
Microsoft et Hugging Face publient ThinkingBox Training. Sur un test synthétique, Qwen réussit plus régulièrement mais couvre un peu moins de tâches.
Un agent peut annoncer qu’il a terminé tout en laissant une mauvaise ligne dans une base de données. ThinkingBox part de ce décalage. Le 22 octobre 2026, Microsoft et Hugging Face présentent une méthode qui transforme le contrôle du résultat en récompense d’entraînement. Leur expérience améliore la régularité d’un modèle Qwen. Elle montre aussi qu’un meilleur score peut cacher un compromis.
Vérifier ce qui a changé plutôt que la réponse finale
L’annonce de ThinkingBox Training décrit des épisodes complets avec des outils et un service applicatif isolé. Un autre modèle joue le rôle de l’utilisateur. À la fin, des contrôles examinent l’état de la base et les effets des actions. La plupart rendent un verdict déterministe. Une minorité fait appel à un modèle juge pour une exigence étroite que la base ne suffit pas à évaluer.
Le principe autorise plusieurs chemins vers un même résultat correct. L’agent n’a pas à reproduire exactement une séquence de clics ou d’appels. Il doit laisser les bons enregistrements et respecter les effets attendus. Une modification manquante ou une action indue peut faire échouer l’épisode. Une réponse convaincante ne compense donc pas un mauvais état final.
Trois résultats qui ne racontent pas la même histoire
Les auteurs évaluent Qwen3.8-27B sur les 507 tâches de ThinkingBox-Bench v1.0. Chaque tâche est tentée vingt fois. Après cinquante étapes d’apprentissage par renforcement, la réussite moyenne passe de 51,70 % à 60,78 %. Le nombre de tâches réussies lors des vingt essais passe de 38 à 107. Il s’agit des résultats rapportés par l’équipe du projet et non d’une reproduction indépendante menée ici.
Le troisième indicateur recule légèrement. Le nombre de tâches réussies au moins une fois passe de 453 à 446. Le modèle devient donc plus régulier sur davantage de tâches sans élargir sa couverture globale. Ces mesures répondent à des questions différentes. Pouvoir trouver une solution de temps en temps n’équivaut pas à la reproduire de façon constante.
Vingt réussites observées ne garantissent pas la vingt et unième
Le protocole fournit un échantillon d’exécutions. Il ne démontre pas une fiabilité parfaite en production. Les clients et les processus du benchmark sont synthétiques. Les tâches de test restent séparées des tâches d’entraînement mais partagent le même cadre technique et un style similaire. Le transfert observé ne suffit donc pas à prédire le comportement dans n’importe quelle entreprise.
Choisir les tâches qui peuvent encore apprendre quelque chose au modèle
L’équipe teste d’abord le modèle de départ pour estimer la difficulté des exercices. Elle retient des tâches dont les résultats varient assez pour fournir un contraste. Un exercice toujours réussi apporte peu de différence entre les essais. Un exercice toujours raté peut aussi manquer de signal utile. Le groupe retenu reste ensuite fixe pendant l’entraînement.
L’expérience décrite utilise 187 tâches et vingt-quatre GPU H100 pour ajuster l’ensemble des paramètres du modèle. La documentation d’évaluation précise une campagne de 10 140 essais. Elle fixe notamment une température de 1 pour l’échantillonnage. Les erreurs de l’infrastructure sont traitées séparément des échecs de l’agent. Ces conditions font partie du résultat publié.
Le code est ouvert mais le groupe d’entraînement n’est pas entièrement public
Le dépôt ThinkingBox Training publie les composants de préparation et d’entraînement sous licence MIT. Ses exemples permettent de vérifier l’intégration. La liste publique de développement contient 39 tâches. Elle ne correspond pas au groupe privé de 187 tâches utilisé pour les chiffres annoncés. Télécharger le dépôt ne suffit donc pas à reproduire toute l’expérience à l’identique.
Le point intéressant tient à la façon de définir la réussite. Ça ramène l’évaluation vers l’état laissé dans les outils. Notre article sur les preuves de sécurité produites par Claude décrit une autre démarche de vérification. Un test répété et une preuve formelle ne fournissent pas le même type de garantie. Dans les deux cas, l’affirmation de l’agent ne suffit pas à elle seule.