Transformer la notation des bases de données en récompenses par RL : agents post-trainés avec ThinkingBox

C’est la suite de notre premier article de blog. L’agent a dit que c’était fait. La base de données a protesté. ThinkingBox-Training est maintenant disponible GitHub.

Nous avons créé ThinkingBox pour évaluer le travail d’un agent en comparant l’état final de la base de données avec le résultat attendu. Ensuite, nous avons utilisé le même type de signal exécutable comme récompense pour les tâches d’entraînement en dehors de ThinkingBox-Bench. Pour Qwen3.8-27B, le taux moyen de succès est passé de 51,70 % à 60,78 %, tandis que le nombre de tâches réussies correctement sur toutes les vingt tentatives a augmenté de 38 à 107 avec 50 étapes GRPO.

Figure 1. ThinkingBox transforme les vérifications exécutables de l’état de la base de données du terminal en récompenses pour les agents après formation, dans des tâches extérieures à ThinkingBox-Bench.

C’est un blog conjoint entre Microsoft et Hugging Face, merci spécialement à Mirco Milletari et Xiang Jiang de Microsoft, Sergio Paniego de Hugging Face et à notre ancien stagiaire Zhuochun Li (Université de Pittsburgh) pour leurs efforts de co-écriture et de révision.

Nous avons créé ThinkingBox pour repérer les agents qui prétendent avoir terminé alors qu’ils ne l’ont pas fait.

Chacune de ses 507 tâches dans ThinkingBox-Bench (notre ensemble de données d’évaluation) donne à un agent un backend réel et une série d’outils, le permettant de travailler, puis vérifie ce qui a vraiment changé dans la base de données. Dans le premier article, nous avons constaté qu’un modèle clôturait une demande cliente comme étant résolue, alors que l’exception liée au transporteur était encore ouverte. Neuf appels d’outils qui semblaient compétents, une erreur dans une ligne de base de données.

Ensuite, nous avons remarqué ce que nous avions construit. Pour la plupart des tâches, une vérification exécutable peut retourner 1 ou 0 directement à partir de l’état du base de données final. Ce n’est pas simplement un évaluateur. Ce peut être une fonction de récompense.⁺

Ainsi, nous avons créé un pool de formation à partir de tâches au format ThinkingBox en dehors du benchmark, et avons utilisé leurs résultats exécutables comme récompenses. Le problème était de choisir quelle tâche convient pour l’entraînement de l’agent : la plupart des tâches sont soit déjà résolues, soit inaccessibles pour le modèle, et aucune ne lui enseigne rien.

La difficulté est relative à la politique : une tâche est difficile pour le modèle actuel uniquement jusqu’à ce que ce modèle l’apprenne.

Nous appelons cela difficulté relative à la politique hors ligne. Nous avons estimé la probabilité de succès de chaque tâche une fois, en utilisant la politique de base avant l’entraînement, et nous avons maintenu le groupe d’entraînement choisi fixe tout au long du processus.

Qu’est-ce qui s’est passé après l’entraînement

Nous avons utilisé la difficulté relative à la politique hors ligne pour construire le pool de formation, puis nous avons affiné Qwen3.8-27B avec GRPO pendant 50 étapes. Pour résumer, nous avons évalué chacune des 507 tâches de benchmark 20 fois. pass@1 mesure la succès moyen sur l’ensemble des 10 140 tentatives. pass@20 mesure la part des tâches résolues au moins une fois. 20/20 mesure la part des tâches qui réussissent à chaque tentative enregistrée.

Table 1. Résultats Qwen3.8-27B avant et après 50 étapes de GRPO sur l’ensemble de données d’entraînement sélectionné en ligne.

L’entraînement a fortement augmenté les succès répétables, avec une légère diminution de la couverture au moins une fois. Le reste du post explique comment nous avons choisi les tâches d’entraînement, construit le cycle de récompense et mesuré cet équilibre.

Comment cette amélioration se manifeste-t-elle dans une tâche spécifique ? Un voyageur demande un réduction de chambre, mais la politique de l’entreprise exige d’abord l’approbation du manager. Avant la formation, l’agent a modifié la réservation et a effectué des remboursements sans approbation en 15 des 20 tentatives. Après le ajustement par RL, il a conservé l’état de la réservation et du paiement dans toutes les 20 tentatives.

Figure 2. Une tâche de réservation d’hôtel d’entreprise, 20 tentatives par modèle. Le modèle de base Qwen3.8-27B a modifié la réservation sans l’approbation nécessaire du manager en 15 tentatives. Le modèle RL affiné a conservé l’état de réservation et de paiement dans toutes les 20 tentatives ; tous les enregistrements attendus étaient conformes en 19.

Contenus

1. Ce que le benchmark a trouvé en soixante secondes
2. Résultats : la colonne de fiabilité a été déplacée
3. Où les gains se sont produits
4. Quels sont les coûts de fiabilité
5. Le cycle de formation
6. Difficulté relative de la politique hors ligne
7. Qu’est-ce qui rapporte une récompense
8. Exécuter l’stack de formation
9. Les prochaines étapes

En urgence ? Le résultat principal est indiqué ci-dessus. La mise en œuvre se fait via exécuter l’stack de formation.

Ce que le benchmark a découvert, en soixante secondes

ThinkingBox-Bench évalue les agents en fonction des enregistrements que ces derniers laissent derrière eux. Chacune de ses 507 tâches initie un backend réel, fournit à l’agent une série d’outils MCP et un utilisateur LLM simulé avec un contexte privé, puis effectue des vérifications exécutables sur l’état de la base de données via le terminal. Les vérifications se basent sur l’enregistrement du backend qui doit être correct, et non sur les appels spécifiques aux outils. Cela incite le modèle à découvrir de nouvelles voies de solution, plutôt que de « redécouvrir » une solution soutenue par l’humain, qui pourrait être suboptimal mais correcte.

Dans notre premier article, nous avons exécuté dix-huit modèles à travers cette évaluation vingt fois chacun, et nous avons constaté une différence que l’exactitude de titre masque. Kimi-K3 a résolu 93,89 % des tâches au moins une fois, mais n’a réussi que 68 sur 507 tâches (13,41 %) dans toutes les vingt tentatives enregistrées. Claude Opus 5 a fait la même chose : couverture plus étroite, mais beaucoup plus de cohérence.

Et le modèle plus grand ou meilleur n’a pas réussi à le fermer. Claude Opus 5.5 a obtenu 0,66 point de pourcentage de plus que Claude Opus 5 sur pass@1, mais a réussi exactement le même nombre de tâches, 241, lors de vingt tentatives. Cette amélioration en précision de résultat n’a apporté aucune fiabilité supplémentaire.

Si vous choisissez un modèle pour un travail qui touche aux enregistrements de la base de données de production, pass@1 ne doit pas être lu seul. Observed 20/20 indique quelles tâches réussissent à chaque tentative, ce qui est plus proche de ce que la fiabilité de la production exige.

Le verdict de l’état de terminal exécutable était également la récompense d’entraînement. Avant de décompresser le cycle d’entraînement, voici ce qui a changé sur la métrique scellée.

Résultats : la colonne de fiabilité a été déplacée

Après l’entraînement de Qwen3.8-27B, nous avons évalué le point de contrôle step-50 sélectionné sur le benchmark de 507 tâches sur lequel il n’a jamais été entraîné. Les 507 tâches représentent un ensemble de test hors distribution : leurs domaines, bases de données et la plupart des outils MCP n’ont jamais été rencontrés pendant l’entraînement par réseau de neurones récurrent.

Table 2. ThinkingBox-Bench pass@1 (%) par domaine, pour les modèles sélectionnés à partir de notre première blogueuse Table 2 et notre modèle affiné pour différents domaines et en général. Les chiffres 20/20 observés se situent au-dessus de la moyenne de l’ensemble du benchmark avec 507 tâches. Chaque modèle est évalué sur toutes les 507 tâches pour 20 essais répétés. Les caractères en gras indiquent le leader de la colonne ; les caractères en souligné indiquent le deuxième meilleur.

Le résultat principal est la ligne observée-20/20 dans le Tableau 1. Un modèle de 27B qui initialement réussissait 38 (7,5 %) des tests ThinkingBox-Bench sur chaque tentative, réussit maintenant 107 (21,1 %) sur chaque tentative, presque trois fois plus. En comparaison, l’observée 20/20 pour Kimi-K3 est de 68, pour GPT-5.4 de 128, pour GPT-6 Astra de 231, et pour Claude Opus 5.5 de 241.

Le taux de succès moyen et la reproductibilité produisent des ordres différents. Dans le Tableau 2, on constate que GPT-5.6 Sol obtient un score légèrement plus élevé sur pass@1 par rapport au RL fine-tuned Qwen3.8-27B (61,91 % contre 60,78 %), mais il réussit moins de tâches lors de toutes les 20 tentatives enregistrées : 82 contre 107. Claude Sonnet 4.6 obtient un score plus faible sur pass@1, à 59,19 %, mais réussit presque autant de tâches chaque fois, à 102. Aucun des deux indicateurs ne reflète entièrement la situation.

Le modèle observé est cohérent avec l’affinement : la réussite répétable a augmenté, tandis que la couverture d’au moins une fois a diminué légèrement. Cela correspond à les travaux précédents. Une explication possible est que la distribution de probabilités s’est orientée vers des trajectoires qui fonctionnent régulièrement, tandis que certaines trajectoires à faible probabilité ont disparu.

D’un point de vue général, le modèle n’est pas devenu plus large. Il est devenu plus reproductible. La prochaine question est de savoir où se situent ces gains.

Où les gains se sont réalisés

Figure 3. Scores de base au niveau du domaine, scores RLFT et variations en pourcentage. Les cellules de changement vert indiquent des gains, tandis que les cellules rouges indiquent des pertes ; le dégradé bleu montre le niveau de score pour chaque indicateur.

Pass@1 et observé 20/20 ont augmenté dans les cinq domaines. Pass@20 était mixte : il a augmenté dans les neobanques et les conseils en investissement, mais a diminué dans le commerce de détail, les voyages et l’assurance automobile. L’assurance automobile a subi la plus grande perte en amplitude (−7,0 points), tandis que le commerce de détail a enregistré la plus grande augmentation observée-20/20 (+24,5 points).

Quels sont les coûts de fiabilité

premier post : cohérence des prix utilisant une simple mathématique : diviser le coût estimé de la campagne de 20 runs complète par le nombre de tâches que le modèle a réussi à accomplir chaque fois.

Coût par tâche fiable = coût estimé de la campagne 507 × 20 ÷ tâches atteignant 20/20

En appliquant la même calculatrice de coûts au taux d’utilisation des tokens mesuré pour le point de contrôle affiné :

Table 3. Coût d’évaluation estimé et fiabilité pour la version de base et la version RL affinée de Qwen3.8-27B. Le coût par tentative réussie est obtenu en divisant le coût total estimé de l’opération (507 x 20) par le nombre d’essais réussis.

À 8,00 $ par tâche fiable, le modèle affiné est proche de GPT-5.4 (6,80 $), GPT-6 Astra (7,45 $) et Claude Opus 5.5 (7,80 $) dans la comparaison associée.

La perspective du seul essai

Figure 4 : coût par essai réussi contre pass@1.

Figure 4. L’arrow dorée trace la position de coût Pareto de base Qwen3.8-27B vers RLFT (diamond) : pass@1 passe de 51,70 % à 60,78 %, tandis que le coût estimé pour chaque tentative réussie diminue de $0,177 à $0,139. Les cercles entourés marquent la frontière de coût Pareto.

Le changement place le point de contrôle ajusté près de GPT-5.6 Sol, bien que GPT-5.6 Sol reste moins cher et légèrement supérieur sur pass@1. Quatre modèles dont les prix se trouvent dans notre article échappent à la plage étudiée.

Les valeurs en dollars représentent un indice de service comparatif, et non des factures de facture ou de cloud. Le service du point de contrôle affiné serait identique au modèle de base. Le calcul inclut le coût d’inférence du modèle, et exclut les coûts liés aux essais de politique pour la création de l’ensemble de données d’entraînement.

Ces résultats nous indiquent ce qui a été déplacé. Les sections suivantes expliquent le cycle d’entraînement et pourquoi la sélection des tâches appropriées est la plus importante.

Le cycle de formation

Figure 5. Les six étapes, maintenant dans leur contexte : les tâches candidates sont fournies, les trois premières s’exécutent une fois hors ligne, les trois dernières se répètent pour chaque groupe lors de l’exécution de l’entraînement. Le point de contrôle entraîné est évalué par rapport à ThinkingBox-Bench.

La sélection se fait une fois, en mode hors ligne, contre le modèle de politique de base, c’est-à-dire dans ce cas Qwen3.8 27B ; la formation utilise ensuite ce pool fixe qui a été préparé. La flèche ambrée en pointillés sur la figure 5 marque le chemin que nous n’avons pas suivi : la difficulté de re-probing pendant l’exécution de la formation.

Chaque déploiement constitue une émission complète, et non une complétion de texte. Il dispose d’un nouveau backend, d’une session MCP isolée, et de GPT-5 Chat en tant qu’utilisateur simulé. La plupart des récompenses proviennent de vérifications de l’état terminal déterministes ; une minorité de exigences spécifiques peuvent invoquer le juge configuré (GPT-5 Chat).

La formation et l’évaluation doivent interpréter les sorties de Qwen de manière identique. Cela inclut l’extraction des raisonnements, les appels aux outils, la saisie des arguments, la rendu, ainsi que l’état d’une tâche isolée. Sinon, les mesures de récompense ne correspondront pas à l’agent évalué. Le code d’interprétation partagé se trouve dans trainer/core/tb_interpret.py.

Pour la version de référence, nous avons exécuté le Qwen3.8-27B fine-tuné avec RL à paramètres complet sur 187 tâches en utilisant le token-mean GRPO. Chaque mise à jour générait 18 groupes de 8 rollouts, soit 144 épisodes, sur 24 H100s. L’entraînement s’est déroulé de manière synchronisée avec l’offload des paramètres et de l’optimiseur ; AdamW utilisait une tâche d’apprentissage de 1e-6 et aucune décroissance des poids. Nous avons exécuté l’entraînement pendant 50 étapes.

Les groupes à variance zéro ont été remplacés dans le style DAPO pendant l’entraînement. Les erreurs du système ont été traitées séparément : un timeout du backend ne constitue pas une erreur de l’agent, donc les groupes affectés ont été réapprovisionnés plutôt que notés comme des échecs.

Cela explique comment les tâches conservées ont été entraînées. La question restante est de savoir quelles tâches ont fait partie du groupe d’entraînement.

Difficulté relative de la politique hors ligne

Avant de se plonger dans la sélection des tâches d’entraînement, une explication :

Aucun task de ThinkingBox-Bench n’a été inclus dans la pile d’entraînement RL. Le benchmark a été réservé à l’évaluation.

ThinkingBox-Bench est hors de distribution par rapport au pool de formation par RL : ses domaines, bases de données, politiques et la plupart des outils n’ont pas été rencontrés pendant la formation par RL. Les deux ensembles partagent encore le cadre ThinkingBox, les machines utilisateur simulées, la notation des états terminaux exécutables, quelques outils communs et un style de tâche similaire. Ces éléments partagés limitent la portée de la revendication de transfert.

La importance de la sélection réside dans un fait arithmétique relatif au GRPO. Si toutes les huit déploiements échouent, le vecteur de récompense est [0, 0, 0, 0, 0, 0, 0, 0]. Si toutes les huit réussissent, il est [1, 1, 1, 1, 1, 1, 1, 1]. Dans tous les cas, le centrage au sein du groupe ne donne aucun avantage en termes de récompense pour la tâche, car aucune trajectoire ne se montre meilleure que l’autre.⁺⁺

Un groupe mixte tel que [0, 0, 0, 1, 1, 1, 1, 1] fournit le contraste dont GRPO peut apprendre. Cette distinction est coûteuse pour un agent à état : chaque déploiement crée un backend isolé, exécute une session d’outil réelle et fait appel à un modèle distinct pour interagir avec l’utilisateur.

La question qui a guidé ce travail n’était donc pas seulement quel modèle ou optimiseur ?, mais plutôt : quelles tâches candidates devraient entrer dans l’ensemble de formation fixe ?

Nous avons utilisé un filtre de taux de passage hors ligne sur le poster pour sélectionner le groupe d’entraînement. Il estime quelles tâches sont susceptibles de produire des récompenses terminales contrastées sous la politique de base.

Ainsi, nous procédons à des tests. Chaque tâche candidate est exécutée de manière répétée contre le modèle de policy de base. La règle en langue simple est simple : les tâches que le modèle échoue toujours sont peu susceptibles de l’apprendre ; les tâches qu’il réussit toujours ont déjà été apprises ; les tâches qu’il résout parfois constituent des points de contraste possibles dans les résultats.

Estimation de la difficulté à partir de probes limitées

Chaque tâche candidate est exécutée n fois, produisant k succès. Nous modélisons sa probabilité de succès latente avec la probabilité postérieure de Jeffreys :

Probabilité de succès | k succès en n essais ~ Beta(k + ½, n − k + ½)

Figure 6. La difficulté relative à la politique hors ligne est estimée à partir de plusieurs vérifications de base de politique répétées, et elle est utilisée pour conserver les tâches qui peuvent produire des récompenses contrastées.

Nous partageons l’intervalle unitaire en cinq buckets ayant pour limites 0,08 ; 0,40 ; 0,60 et 0,90, choisies comme hyperparamètres pour ces essais. Chaque tâche est assignée au bucket contenant la plus grande masse postérieure :

• Très rarement résolu [0, 0.08) : chute
• Difficile [0.08, 0.40) : maintenir
• Intermédiaire [0,40, 0,60) : maintenir
• Problèmes souvent résolus [0,60 ; 0,90) : garder pour RLFT à paramètres complets
• Presque toujours résolu [0,90, 1] : abaisser

D’autres détails se trouvent dans l’Appendice C.4 de notre article ThinkingBox.

Une tâche, en entier.

Figure 7. En zoomant, une tâche passe par les six étapes : tri par GPT-5.4, essais de modèle de base, classification de difficulté, groupe de déploiement, évaluation à l’état final, et mise à jour du GRPO.

Figure 7 suit une tâche candidate qui peut potentiellement entrer dans la base de formation. Pour la base de paramètres complète Qwen3.8 27B, GPT-5.4 a servi d’écran de détermination de la solvabilité. La politique de base a alors réussi sur quelques échantillons, par exemple 3 sur 8, produisant une posterior Beta(3.5, 5.5). Sa masse la plus importante, soit 54.0 %, se situe dans la catégorie difficile.

Lors de l’échantillonnage pour l’entraînement, la tâche produisait le groupe de récompenses mixte [0, 0, 0, 0, 1, 1, 1, 1]. Les trajectoires réussies recevaient donc un avantage supérieur à la moyenne, tandis que les trajectoires échouées recevaient un avantage inférieur à la moyenne, ce qui permet à GRPO de s’en inspirer. Un modèle de politique différent pourrait placer la même tâche dans une bande de difficulté différente.

Le groupe d’entraînement curaté final Qwen3.8-27B contenait 187 tâches.

Qu’est-ce qui rapporte une récompense

Rien concernant la trajectoire. La récompense est le jugement exécutable de la tâche elle-même.

Lorsqu’une époque se termine, le sandbox extrait ce qui a vraiment changé en back-end et exécute les vérifications déterministes de la tâche par rapport à l’état terminal. Toute trajectoire qui produit l’état final correct passe. Les effets secondaires incorrects, manquants ou supplémentaires échouent. La récompense est 1 ou 0.

Dans le benchmark, le juge de base de données peut être considéré comme l’« examinateur » : il repère les agents qui rapportent un succès mais laissent une trace erronée. Dans l’entraînement, ce même type de vérification peut être perçu comme le « enseignant » sur un ensemble de tâches différent et disjoint.

Deux voies de récompense, un verdict binaire

• Vérification de l'exécution (la grande majorité). Lorsque l'outcome requis se manifeste dans un état terminal ou des effets secondaires, un test déterminist le valide ou le rejette ; aucune appelation de jugement par un LLM n'est nécessaire.
• Vérification assistée par juge (une minorité). Lorsqu’une exigence spécifique ne peut pas être déterminée clairement à partir de l’état de la base de données, le LLM juge configuré répond à une question basée sur une échelle binaire utilisée par l’examen exécutif.

Exécuter l’stack de formation

Nous publions les données de sélection, la mise en œuvre, les récompenses et l’intégration Verl utilisées pour entraîner Qwen3.8-27B dans microsoft/thinkingbox-training. Le README du repository est le point d’entrée. Les guides détaillés se trouvent :

• docs/data-preparation.md pour l’hydratation des tâches, les vérifications de politique, l’exclusion des benchmarks et la division en entraînement/validation ;
• docs/reference-q38-run.md pour la configuration validée 24-H100 Qwen3.8;
• docs/evaluation.md pour fusionner un point de contrôle et exécuter ThinkingBox-Bench 507 x 20.

Avant de commencer

Testé sur Linux et WSL avec Python 3.12 et uv. Il est nécessaire d’utiliser des GPU NVIDIA équipées d’une stack CUDA/NCCL compatible, d’un point de stockage local Qwen3.8-27B, ainsi que d’endpoints compatibles avec OpenAI pour l’utilisateur simulé et le juge. La configuration de référence validée utilise 3 nœuds x 8 GPU H100 ; les configurations personnalisées plus petites dépendent de la taille du modèle, de la longueur du contexte et de la concurrence des applications.

La liste d’exercices de tâche publique teste l’interface. Ce n’est pas le pool privé de formation de 187 tâches utilisé pour l’exécution rapportée. Fournissez une source de formation autorisée qui reste indépendante du benchmark public.

Installer

Maintenez les trois repositories côte à côte :

mkdir -p ~/thinkingbox-workspace
cd ~/thinkingbox-workspace

git clone https://github.com/microsoft/thinkingbox.git
git clone https://github.com/microsoft/thinkingbox-data.git
git clone --branch main https://github.com/microsoft/thinkingbox-training

git -C thinkingbox checkout 892964e7226044e5463ad188da119df838f4bec1
git -C thinkingbox-data checkout thinkingbox-bench-v1.0

Créer l’environnement validé

La version publiée cible Linux, Python 3.12, Verl 0.9.0, et le paquet lock fixe :

cd ~/thinkingbox-workspace/thinkingbox-training

uv venv --python 3.12
source .venv/bin/activate

uv sync --frozen --extra fast --extra tracking --extra eval-proxy
uv pip install -e ../thinkingbox
uv pip install --config-settings editable-mode=compat \
  -e ../thinkingbox-data/servers/thinkingbox_tools
uv pip install --config-settings editable-mode=compat \
  -e ../thinkingbox-data/servers/tb_business_ops_servers_202606

python scripts/prepare_verl.py --dest .deps/verl --install
python scripts/verify_verl_install.py
uv pip check

Les deux dernières commandes doivent indiquer qu’une correction est validée pour le Checkout Verl, et que aucun requirement ne est cassé. Ne lancez pas de nouveau synchronisation automatique des packages : cela pourrait remplacer l’installation source corrigée par la version classique de Verl.

Préparez les données d’entraînement

Commencez avec les exemples fournis publiquement, ou ajoutez votre propre jeu de données autorisé en format ThinkingBox. Ensuite, exécutez le script de préparation du répository :

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
python data/prepare_data.py --help

Le script regroupe les vérifications de politique, applique des filtres de difficulté relative à la politique hors ligne et des exclusions pour les benchmarks, puis écrit les fichiers sélectionnés train.yaml et test.yaml. Les documents docs/data-preparation.md décrivent les champs d’entrée, le contrat du chargeur et l’ensemble des commandes.

Configurer et examiner le lancement

Suivez docs/reference-q38-run.md pour démarrer Typesense et les serveurs MCP, configurer l’utilisateur simulé et le juge, définir le modèle, la liste de tâches, le point de contrôle et les variables de topologie, et préparer le cluster Ray. Conservez les identifiants dans une injection secrète en temps de exécution plutôt que dans les fichiers d’enregistrement ou l’histoire du shell.

Avant d’allouer une tâche de formation, utilisez le commande de simulation du guide :

DRY_RUN=true ./scripts/run_train.sh \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

Il doit se terminer sans aucun départ de Ray ni allocation de GPU. Lisez la commande python -m verl.trainer.main_ppo émise et toutes les modifications personnalisées avant de lancer l’exécution.

Entraîner

Le launcher configure l’entraînement ; il ne fournit pas les hôtes. Dans une topologie de trois nœuds, exportez le même environnement sur chaque nœud, placez CHECKPOINT_DIR à la même chemin absolu, puis lancez Ray :

# head node
ROLE=head NODE_IP="$HEAD_IP" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh

# each worker node
ROLE=worker NODE_IP="$WORKER_IP" \
  HEAD_ADDRESS="$HEAD_IP:6379" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh

Après que ray status indique tous les 24 GPU, lancez-le une fois depuis le nœud central :

export RAY_ADDRESS=auto
export GPUS=0,1,2,3,4,5,6,7

./scripts/run_train.sh \
  trainer.project_name=thinkingbox-training \
  trainer.experiment_name=q38-full-rlft \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

Évaluer le point de contrôle via OpenEnv

la première publication de ThinkingBox aborde Typesense, le MCP Session Proxy et l’installation OpenEnv. Fusionnez le checkpoint entraîné suivant docs/evaluation.md, puis servez-le avec vLLM.

Depuis le répertoire racine du dépôt OpenEnv, fixez MERGED_MODEL dans le dossier du modèle fusionné et THINKINGBOX_DATA dans le fichier de récupération du benchmark. L’évaluation du point de contrôle historique a utilisé cette configuration de service A100 à huit unités :

vllm serve "$MERGED_MODEL" \
  --served-model-name q38-rlft \
  --host 127.0.0.1 \
  --port 8001 \
  --tensor-parallel-size 8 \
  --dtype bfloat16 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.85 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 8192 \
  --language-model-only \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml

Dans un terminal séparé, lancez le proxy compatible OpenEnv pour le modèle de chat Qwen depuis le check-out de ThinkingBox Training. Il écoute sur le port 8014 et transmet les messages vers vLLM sur le port 8001.

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
bash scripts/launch_sysmerge.sh

Gardez-le en fonctionnement pendant l’évaluation. Depuis un autre terminal, vérifiez son état de prêleance :

curl --fail http://127.0.0.1:8014/readyz

Mettre à jour la entrée de l’agent dans le fichier thinkingbox.yaml existant ; conserver sa configuration MCP, utilisateur simulé et juge :

orchestrator:
  agent_model:
    type: aoai
    endpoint_url: http://127.0.0.1:8014/v1/chat/completions
    deployment: q38-rlft
    credential:
      type: api-key
      api_key: <your_api_key>
    is_reasoning: true
    temperature: 1.0
    top_k: 20
    top_p: 0.95
    max_completion_tokens: 8192
    timeout: 1800

Commencez OpenEnv comme indiqué dans le premier post, en faisant pointer OPENENV_TB_CONFIG sur ce fichier thinkingbox.yaml et en faisant pointer OPENENV_TB_DATASET sur $THINKINGBOX_DATA. Lorsque /ready réussit, exécutez le protocole complet comprenant 507 tâches × 20 essais :

uv run --project envs/thinkingbox_env --frozen \
  thinkingbox-eval \
  --config "$PWD/thinkingbox.yaml" \
  --base-url http://127.0.0.1:8000 \
  --dataset "$THINKINGBOX_DATA" \
  --output q38-rlft-full.jsonl \
  --errors-output q38-rlft-full-errors.jsonl \
  --repeat 20 \
  --coverage-profile full \
  --aggregate-output q38-rlft-full-aggregate.json \
  --message-timeout 1800

Le profil full valide toutes les 10 140 clés de tâche/repétition attendues avant l’agrégation.

Quel sera l’avenir de cela

La partie utile de ce travail n’est pas un point de contrôle Qwen3.8-27B. C’est le cycle d’entraînement et la sélection des données d’entraînement qui transforment les résultats exécutables en récompenses.

Si vous entraînez ou évaluez un agent qui interagit avec des enregistrements réels de base de données :

1. Étudiez la probabilité avant de entraîner. Prenez votre propre ensemble de tâches pour l’agent, appliquez la politique de base contre elle n fois, et examinez le histogramme de bande. D’après notre expérience, les équipes ne vérifient souvent pas cette distribution, et elle est généralement plus déséquilibrée que prévu.
2. Vérifiez votre parité. Répétez le même output du modèle enregistré via les parseurs de formation et d’évaluation, et assurez-vous que les deux extraient des noms d’outils et des arguments identiques. Sinon, la formation pourrait récompenser un comportement que l’évaluation interprète différemment.
3. Rapporter à la fois la couverture et la répétabilité. Indiquer combien de tâches sont passées au moins une fois en k essais et combien sont passées toutes les k. Un modèle qui trouve parfois une solution n’est pas nécessairement celui qui la répète de manière cohérente.

D'autres détails peuvent être trouvés sur les liens suivants :

• Environnement : envs/thinkingbox_env
• OpenEnv : Documentation de l’environnement ThinkingBox
• Framework : microsoft/thinkingbox · tutorial
• Benchmark : microsoft/thinkingbox-data · version 1.0
• Visualiseur de jeu de données : microsoft/ThinkingBox-Bench
• Article : arXiv:2608.19741 ou HF
• Entraînement RL : microsoft/thinkingbox-training
• Blog : L’agent a dit qu’il avait terminé. La base de données a objecté.

Citer le papier

@article{li2026thinkingbox,
  title   = {One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows},
  author  = {Li, Zhuochun and Ko, Youngmin and Keramati, Ali and Kundu, Tuhin and
             Tsai, Liang-Chun and Ferri, Nicola and Milletari, Mirco and Liu, Jiaxiang and
             Lopez Pelaez, Susana Palmaz and Wang, Yuepeng and Smolyakov, Vadim and
             Jiang, Xiang and Olafsson, Kjartan and Guy, Tommy},
  journal = {arXiv preprint arXiv:2608.19741},
  year    = {2026},
  url     = {https://arxiv.org/abs/2608.19741}
}

Le code ThinkingBox est sous licence MIT ; les données de benchmark sont CDLA-Permissive-2.0.

Disclaimer : chaque tâche dans l’évaluation publique est une reconstruction synthétique. Les processus et les politiques sont modélisés sur des modèles réels d’agents d’entreprise ; les clients ne sont pas réels.

ThinkingBox, ThinkingBox-Bench et ThinkingBox-Training sont développés par l’équipe Microsoft Copilot Studio en partenariat avec Toloka, avec la collaboration de collaborateurs de l’Université de Pittsburgh, de l’Université Northwestern, de l’Université Columbia et de l’UC Irvine qui ont travaillé chez Microsoft. Vous êtes bienvenue pour poser des questions dans la section des commentaires ci-dessous ou sur github, ou par courrier électronique à firstnamelastname@microsoft.com.

⁺ Une minorité de tâches comporte également des exigences de notation binaire étroites pour les résultats que la base de données ne peut pas capturer de manière claire ; ces vérifications peuvent faire appel au juge LLM configuré.

⁺⁺ Le problème de gradient zéro a une solution standard en temps de traitement : suréchant, éliminer les groupes dégénérés, remplir à nouveau. L’exécution avec tous les paramètres a fait exactement cela, similaire à DAPO, en remplaçant les groupes à variance zéro. Mais le remplissage continue de coûter le prix entier pour chaque rouleau gaspillé avant qu’on ne le jeter.