ThinkingBox transforme l’évaluation de bases de données en récompense RL

Présentation

ThinkingBox est un cadre développé conjointement par Microsoft et Hugging Face pour vérifier l’état final d’une base de données après l’exécution d’un agent. Le benchmark ThinkingBox‑Bench comporte 507 tâches réelles : chaque tâche démarre un backend, fournit à l’agent un jeu d’outils MCP et un simulateur d’utilisateur LLM, puis compare les enregistrements terminaux avec les résultats attendus. Cette comparaison binaire (1 ou 0) constitue à la fois un grade et, comme le montre le nouveau projet ThinkingBox‑Training, une fonction de récompense exploitable en apprentissage par renforcement (RL).

Méthodologie d’entraînement

Les auteurs ont d’abord évalué chaque tâche avec le modèle de base Qwen3.8‑27B afin d’estimer une probabilité de succès « offline ». Les tâches dont la probabilité était intermédiaire – ni déjà résolues, ni irréalisables – ont été sélectionnées pour former un pool d’entraînement fixe. Le modèle a ensuite été affiné pendant 50 pas de Gradient‑Reward‑Policy‑Optimization (GRPO), chaque itération recevant comme signal de récompense le résultat exécutable (1 ou 0) de la tâche correspondante. Cette approche, qualifiée de « offline policy‑relative difficulty », garantit que le modèle ne s’entraîne que sur des exemples susceptibles d’influencer son comportement actuel.

Résultats et analyse

Après 50 pas de GRPO, le taux de succès moyen (pass@1) est passé de 51,70 % à 60,78 %. Plus significatif, le nombre de tâches résolues de façon fiable sur les 20 exécutions (observed 20/20) a triplé, passant de 38 tâches (7,5 %) à 107 tâches (21,1 %). Cette hausse de la répétabilité s’accompagne d’une légère baisse de la couverture « au moins une fois » (pass@20), illustrant le compromis habituel entre consistance et diversité des trajectoires apprises.

Une étude de cas – la modification d’une réservation d’hôtel nécessitant une approbation managériale – montre que le modèle de base modifiait la réservation dans 15 sur 20 essais, alors que le modèle affiné respectait la politique dans les 20 essais, avec 19 enregistrements parfaitement conformes. Cette amélioration indique que le signal de récompense basé sur l’état terminal pousse l’agent à internaliser les contraintes de la base de données plutôt qu’à reproduire simplement les appels d’outils humains.

Limitations et perspectives

Le gain de répétabilité ne s’accompagne pas d’une meilleure généralisation sur l’ensemble du benchmark : le modèle affiné reste inférieur à des modèles plus grands (Claude Opus 5.5, GPT‑6 Astra) sur le critère observed 20/20. De plus, la sélection du pool d’entraînement repose sur une estimation initiale de succès qui peut devenir obsolète si le modèle progresse rapidement, limitant la capacité d’adaptation en ligne. Enfin, l’étude ne fournit pas de métriques de latence ou de coût de calcul liés à l’exécution des vérifications de base de données, facteurs critiques pour le déploiement en production.

Les auteurs suggèrent d’explorer des stratégies de mise à jour dynamique du pool d’entraînement et d’intégrer des récompenses pondérées par la sévérité des erreurs de base de données. Une telle évolution pourrait concilier la haute fiabilité observée avec une couverture plus large, répondant ainsi aux exigences de robustesse des systèmes de production.