Microsoft et Hugging Face entraînent Qwen3.8-27B sur l'état de la base de données : de 38 à 107 tâches

Microsoft, avec Hugging Face, a publié ThinkingBox-Training, la suite du benchmark qui piège les agents annonçant un succès alors que l'écriture en base est erronée. L'idée est simple : si la vérification de l'état final de la base renvoie 1 ou 0, on tient déjà une fonction de récompense. Après 50 pas de GRPO, Qwen3.8-27B a fait passer son taux de réussite moyen (pass@1) de 51,70% à 60,78%. Le nombre de tâches résolues sur les vingt tentatives est monté de 38 à 107, soit de 7,5% à 21,1% des 507 tâches de ThinkingBox-Bench.

Une récompense tirée de l'état de la base, pas du texte de la réponse

Chaque tâche ThinkingBox lance un véritable backend, fournit à l'agent un jeu d'outils MCP et un utilisateur simulé dont le contexte reste fermé. À la fin, des vérifications exécutables examinent les enregistrements présents dans la base. La séquence d'appels n'est pas évaluée : le modèle peut donc trouver un chemin absent de l'annotation de référence. La plus grande partie des récompenses est déterministe, et une petite part de rubriques étroites est confiée à un juge GPT-5 Chat.

Un exemple parlant : la réservation d'hôtel professionnelle. Un employé veut rétrograder sa chambre, mais la politique exige l'accord d'un manager. Le modèle de base modifiait la réservation et émettait des remboursements sans validation dans 15 tentatives sur 20. Après le RL, la réservation et l'état du paiement sont restés intacts dans les 20 tentatives, et tous les enregistrements attendus correspondaient dans 19 d'entre elles.

Pourquoi la sélection des tâches compte plus que l'optimiseur

GRPO se heurte à une limite arithmétique. Si les 8 rollouts échouent tous ([0,0,0,0,0,0,0,0]) ou réussissent tous, le centrage intra-groupe annule l'avantage et le gradient disparaît. Il faut des groupes mixtes, comme [0,0,0,1,1,1,1,1]. Pour un agent à état, ces groupes vides coûtent cher : chaque rollout exige un backend isolé, une session MCP active et un modèle distinct pour le rôle de l'utilisateur.

Les auteurs ont introduit une policy-relative difficulty hors ligne. La probabilité de succès de chaque tâche candidate est estimée une seule fois sur la politique de base, puis le pool est figé pour toute la durée de l'entraînement. Ils ont délibérément renoncé à resonder la difficulté pendant l'entraînement. Aucune tâche de ThinkingBox-Bench n'est entrée dans l'entraînement. Les domaines, les bases, les politiques et la plupart des outils du test sont nouveaux, même si le cadre général, le simulateur d'utilisateur et le style des tâches sont les mêmes, ce qui limite la portée des conclusions sur le transfert.

Configuration de l'entraînement de référence : RL à paramètres complets sur 187 tâches, GRPO token-mean, 18 groupes de 8 rollouts, soit 144 épisodes par pas, sur 24 H100. L'entraînement est synchrone, avec offloading des paramètres et de l'optimiseur, AdamW, lr 1e-6, weight decay nul. Les groupes à variance nulle étaient remplacés selon le schéma DAPO. Les erreurs système, comme un timeout du backend, n'étaient pas comptées comme un échec de l'agent : le groupe était régénéré. Le code d'interprétation des sorties de Qwen est commun à l'entraînement et à l'évaluation (trainer/core/tb_interpret.py) ; sinon, la récompense mesurerait un autre agent.

Tableau : réussite moyenne contre répétabilité

Pass@1 sur les 507 tâches et nombre de tâches 20/20 :

• Claude Opus 5.5 — 67,16%, 241 tâches (47,53%) • Claude Opus 5 — 66,50%, 241 (47,53%) • GPT-5.4 — 65,36%, 128 (25,25%) • GPT-5.6 Sol — 61,91%, 82 (16,17%) • Qwen3.8-27B après RL — 60,78%, 107 (21,10%) • Claude Sonnet 4.6 — 59,19%, 102 (20,12%) • GPT-6 Astra — 58,31%, 231 (45,56%) • Kimi-K3 — 57,37%, 68 (13,41%) • Qwen3.8-27B de base — 51,70%, 38 (7,50%)

GPT-5.6 Sol fait mieux en pass@1, mais résout de façon stable 25 tâches de moins. Opus 5.

5 devance Opus 5 de 0,66 point de pourcentage en moyenne, mais les deux sont à égalité en fiabilité. Le pass@1 et le 20/20 ont progressé dans les cinq domaines ; le plus forte hausse du 20/20 revient au retail (+24,5 pts). Le pass@20 a reculé de 453 à 446 tâches : il a augmenté en néobanque et en conseil, et baissé en retail, en voyage et en assurance auto (−7,0 pts dans ce dernier cas).

Les auteurs décrivent cet effet comme du sharpening : la distribution se déplace vers les trajectoires qui fonctionnent à tous les coups, tandis que les chemins rares disparaissent.

L'économie de la tâche fiable

Le coût de la campagne 507×20 est passé de $925,80 à $855,58 (−7,6%), et le prix d'une tentative réussie de $0,177 à $0,139 (−21,4%). La métrique « coût par tâche résolue de façon fiable » (coût de la campagne divisé par le nombre de tâches 20/20) a diminué de $24,36 à $8,00 (−67,2%). À titre de comparaison : GPT-5.4 — $6,80, GPT-6 Astra — $7,45, Claude Opus 5.5 — $7,80. C'est un indice comparatif de service, pas une facture cloud. Il inclut l'inférence, mais pas l'entraînement ni le sondage des tâches, et la taille du modèle au déploiement reste la même.

Pour les équipes qui construisent des agents au-dessus de bases de production, la conclusion est pratique. Si vous disposez d'un vérificateur d'état exécutable, il sert à la fois de métrique et de récompense. Commencez par la sélection des tâches : celles que le modèle résout toujours ou jamais gaspillent des heures de GPU et des backends. Évaluez au 20/20, pas au pass@1. Si la couverture des scénarios rares compte pour vous, tenez compte du prix à payer : la répétabilité a coûté une partie du pass@20.