Des chercheurs d'IBM ont publié DRACO, une méthode d'apprentissage par renforcement destinée aux agents qui exécutent des tâches longues. Elle s'attaque à un problème classique : une trajectoire peut comporter des dizaines de décisions alors que la récompense n'arrive qu'à la fin. L'article a été soumis à arXiv le 3 septembre 2026 et IBM a publié sous licence Apache-2.0 le code d'entraînement, d'évaluation et d'analyse.
DRACO signifie Distributing Rubric-based Advantage for Credit Optimization. Au lieu d'appliquer uniformément à tous les tokens l'avantage calculé pour une trajectoire, la méthode s'appuie sur des critères générés pendant l'entraînement et sur les références du juge à des étapes précises. La quantité totale de signal attribuée à la trajectoire est conservée, mais sa répartition entre les étapes change.
Une note finale explique mal des dizaines de décisions
L'attribution du mérite devient difficile lorsqu'un agent agit pendant longtemps. Il peut se tromper au début, se reprendre, utiliser plusieurs outils correctement puis échouer sur la dernière action. Un simple indicateur de réussite ne dit pas quelles décisions antérieures méritent d'être renforcées.
DRACO construit des critères propres à la requête et à la trajectoire, élimine les doublons et retire ceux qui ne différencient pas les exécutions d'un même groupe. Un juge évalue ensuite la trajectoire achevée et associe chaque critère aux étapes concernées. Ces références deviennent des poids par étape, puis l'avantage normalisé par GRPO est redistribué en fonction de ces poids.
La méthode n'ajoute pas un modèle d'attribution entraîné séparément. La redistribution est calculée directement. La nouvelle dépendance se situe donc dans le circuit qui produit les critères et les jugements.
Les résultats sont prometteurs, mais un chiffre diverge
Le résumé de l'article annonce sur AppWorld un gain de 15,9 points par rapport au modèle de base et de 5,3 points par rapport à un GRPO entraîné avec une récompense réelle mais rare. Pour tau-bench, il indique également une amélioration de 5,3 points par rapport au modèle de base dans une configuration sans juge externe de pointe.
Le README du dépôt officiel d'IBM donne pourtant un autre chiffre pour tau-bench : 4,6 points. Cette différence ne suffit pas à invalider la méthode, mais elle doit être signalée puisque le dépôt constitue l'artefact de référence pour les équipes qui voudront reproduire le travail.
Aipolix considère donc ces performances comme des résultats annoncés par les auteurs. Aucune reproduction indépendante n'a été trouvée pendant cette analyse, et l'écart entre 5,3 et 4,6 points devrait être clarifié avant que ce résultat soit présenté comme établi.
Le juge devient une dépendance du processus d'entraînement
La conséquence d'ingénierie la plus importante est le rapprochement entre l'évaluateur et la boucle d'optimisation. Dans plusieurs configurations du dépôt, un modèle externe avancé génère ou note les critères. Dans d'autres, une instance du modèle en cours d'entraînement joue elle-même le rôle de juge. Une variante exige même l'accord de trois évaluations.
Cela change les exigences de reproductibilité. Une modification de l'instruction du juge, de sa version, de ses paramètres d'échantillonnage ou de sa manière de citer les étapes peut déplacer le signal de récompense, même si la note globale de la trajectoire reste proche. La dérive de l'évaluateur ne concerne donc plus seulement la qualité de la mesure : elle peut modifier directement l'apprentissage.
Les équipes qui expérimentent cette approche devraient versionner les instructions du juge, le modèle utilisé, la logique de génération des critères et les références produites, au même titre que les paramètres d'entraînement. Conserver les poids et la configuration de l'optimiseur ne suffit pas à reconstruire le chemin qui a déterminé l'attribution du mérite.
Le dépôt permet une inspection détaillée
Le dépôt IBM contient les configurations d'entraînement, les lanceurs, la documentation du calcul de la récompense, les formules d'attribution, les dispositifs d'évaluation pour AppWorld et tau-bench ainsi que le code d'analyse utilisé pour produire les résultats. Le README décrit huit configurations qui font varier la source de récompense, le juge et la distribution de l'avantage.
La plupart utilisent Qwen3.6-27B et une autre s'appuie sur Qwen2.5-32B-Instruct. La configuration DRACO principale associe des critères dynamiques à une redistribution par étape. Le dépôt indique que chaque configuration a été entraînée pendant 100 étapes, ce qui aide à apprécier la portée des résultats.
La publication du code rend la méthode testable, sans pour autant constituer une réplication. AppWorld et tau-bench restent des environnements contrôlés. Des agents déployés peuvent rencontrer des séquences plus longues, des pannes d'outils différentes et une observabilité moins complète.
Les tests à mener avant une adoption
Le premier test utile ne consiste pas seulement à vérifier si un score augmente. Il faut comparer l'attribution uniforme et l'attribution par étape en maintenant autant que possible constants le modèle, les trajectoires et le juge. Il faut ensuite changer le juge, les critères ou la distribution des tâches pour mesurer la stabilité du gain.
Un second test doit porter sur la sensibilité aux erreurs du juge. Puisque DRACO utilise ses références pour décider quelles étapes reçoivent davantage de signal, une équipe peut supprimer ou modifier volontairement certaines références et observer l'effet sur l'entraînement. Elle saura ainsi si l'agent apprend un comportement robuste ou s'adapte surtout au style d'attribution d'un évaluateur particulier.
Même si les chiffres évoluent après réplication, l'idée architecturale demeure intéressante : l'entraînement d'agents de longue durée a besoin d'une chaîne traçable entre les preuves d'évaluation et l'optimisation. DRACO rend cette chaîne explicite et montre que le juge doit être versionné et auditable comme toute autre dépendance critique du système d'entraînement.