🤖 AI

Beyond Next-Token Prediction: An RLVR Proof of Concept for Tool-Use Agents on Atlassian Workflows

Cet article présente une preuve de concept démontrant que l'apprentissage par renforcement avec récompenses vérifiables (RLVR) améliore considérablement la capacité des petits modèles de langage à exécuter des appels d'outils complexes et multi-étapes dans des environnements synthétiques Atlassian (Jira et Confluence), atteignant des taux de réussite quasi parfaits dans la plupart des scénarios sans dépendre d'API en direct ou de rétroaction humaine.

Auteurs originaux : Karthikeya Aditya Vissa, Sankalp Mane, Ananya Mantravadi, Harshit Rajgarhia, Abhishek Mukherji

Publié 2026-07-03

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Karthikeya Aditya Vissa, Sankalp Mane, Ananya Mantravadi, Harshit Rajgarhia, Abhishek Mukherji

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous ayez un bibliothécaire très intelligent et érudit (l'IA) qui est excellent pour prédire le mot suivant dans une phrase. Si vous lui demandez : « Le ciel est... », il dira avec assurance « bleu ». Mais si vous lui demandez d'effectuer réellement une tâche dans un système de bureau complexe — comme « Créer un nouveau ticket de projet et le lier à une page spécifique » — il trébuche souvent. Il peut connaître les mots à dire, mais il se trompe sur les détails, comme mettre le mauvais numéro d'ID dans la mauvaise case ou oublier de vérifier si la case existe d'abord.

Ce document traite de la manière d'apprendre à ce bibliothète comment réellement faire son travail, et non pas seulement en parler, en utilisant une méthode d'entraînement spécifique appelée RLVR (Apprentissage par renforcement avec récompenses vérifiables).

Voici la décomposition de leur expérience en termes courants :

1. Le Problème : L'« Autopilote » vs Le « Pilote »

Les grands modèles de langage (LLM) sont entraînés pour être comme des autopilotes qui prédisent le mot suivant. Ils sont excellents pour écrire des histoires ou des courriels. Mais dans un bureau d'entreprise (en utilisant spécifiquement les outils Atlassian comme Jira et Confluence), le succès ne consiste pas à écrire une jolie phrase ; il s'agit d'appuyer sur les bons boutons, dans le bon ordre, avec les données exactes.

L'ancienne méthode : Vous demandez à l'IA de « Créer une sous-tâche ». L'IA peut dire : « D'accord, je vais créer une sous-tâche », mais elle oublie de l'assigner à une personne ou utilise le mauvais code de projet. Elle semble fluide, mais la tâche échoue.
L'objectif : Les auteurs voulaient voir s'ils pouvaient entraîner l'IA à arrêter de simplement « deviner le mot suivant » et commencer à « agir comme un pilote » qui vérifie ses instruments avant de voler.

2. La Solution : Un terrain d'entraînement de type « Jeu Vidéo »

Au lieu de laisser l'IA s'entraîner sur les serveurs réels et en direct de l'entreprise (ce qui est risqué et lent), les auteurs ont construit un double numérique parfait (une version jeu vidéo) des systèmes Jira et Confluence.

Le Simulateur : Ce « jeu » ressemble et fonctionne exactement comme le vrai logiciel, mais il est sûr. Si l'IA fait une erreur, rien ne casse.
L'Arbitre (Le système de récompense) : C'est la recette secrète. Habituellement, il faut un humain pour évaluer le travail de l'IA. Ici, ils ont construit un arbitre automatisé et strict.
- Si l'IA met les bonnes données dans la bonne case ? Des points.
- Si l'IA vérifie si une page existe avant d'essayer de l'éditer ? Des points bonus.
- Si l'IA essaie d'utiliser un outil qui n'existe pas ou oublie une étape requise ? Des points de pénalité.
- Crucialement : L'arbitre n'a pas besoin qu'un humain regarde l'écran. Il vérifie simplement les calculs et le code.

3. L'Entraînement : Essais et Erreurs

Ils ont pris deux versions d'une IA (un modèle plus petit de 1,7 milliard et un modèle plus grand de 4 milliards) et les ont laissé jouer dans ce simulateur des milliers de fois.

L'IA essaie de réaliser une tâche (comme « Créer une page »).
Elle échoue, reçoit un score faible de l'arbitre et réessaie.
Elle apprend lentement : « Oh, j'ai obtenu des points quand j'ai vérifié la page parente d'abord. J'ai perdu des points quand j'ai oublié le code du projet. »
C'est l'Apprentissage par renforcement : l'IA apprend en recevant des récompenses pour les bons comportements et des pénalités pour les mauvais comportements.

4. Les Résultats : De « Correct » à « Parfait »

Ils ont testé l'IA avant et après cet entraînement sur cinq tâches de bureau différentes.

Avant l'entraînement : L'IA était correcte pour les tâches simples mais très mauvaise pour les tâches complexes. Par exemple, pour la création d'une nouvelle page Confluence, l'IA non entraînée n'obtenait qu'environ 35 % des points. Elle continuait de commettre de petites erreurs coûteuses.
Après l'entraînement : L'IA entraînée est devenue presque parfaite. Sur cette même tâche de création de page, elle est passée à 100 %.
La grande victoire : L'entraînement a été le plus efficace sur les tâches les plus difficiles (celles qui comportent le plus de règles et de champs de données). L'IA a appris à suivre le modèle strict de « vérifier puis faire » requis par ces systèmes.

5. Le Bémol (Limites)

Les auteurs sont très honnêtes sur ce que cela ne fait pas encore :

Ce n'est pas magique pour tout : Ils ont dû concevoir manuellement les « règles de l'arbitre » pour ces tâches spécifiques. On ne peut pas simplement brancher cela sur n'importe quel logiciel au monde sans construire un nouvel arbitre pour celui-ci. C'est comme avoir un entraîneur qui est excellent pour enseigner le football, mais qui n'a pas encore appris le basket-ball.
Une tâche était trop facile : Pour une tâche spécifique (changer le statut d'un ticket), l'IA était déjà parfaite avant l'entraînement, donc l'entraînement n'a pas apporté de valeur ajoutée là.

L'essentiel

Ce document prouve que vous pouvez prendre une IA standard, la placer dans un environnement de bureau simulé et sûr, et utiliser un arbitre automatisé strict pour lui apprendre à suivre des règles complexes. Cela transforme l'IA d'un « robot bavard » qui semble bien parler mais échoue dans les détails, en un « travailleur fiable » qui accomplit parfaitement sa tâche. Cependant, cela nécessite de construire une « salle de sport d'entraînement » personnalisée pour chaque type de logiciel que vous souhaitez qu'elle utilise.

Résumé Technique : Au-delà de la prédiction du prochain jeton : une preuve de concept de RLVR pour les agents d'utilisation d'outils sur les flux de travail Atlassian

Énoncé du problème
Les grands modèles de langage (LLM) sont fondamentalement optimisés pour la prédiction du prochain jeton (next-token prediction) sur du texte à l'échelle d'Internet, un objectif qui ne correspond pas aux exigences des flux de travail de niche des logiciels SaaS d'entreprise. Dans ces environnements, le succès dépend de l'exécution d'appels API spécifiques avec des arguments imbriqués précis selon un ordre strict. L'article soutient que ce décalage d'objectif se manifeste par des « échecs silencieux » chez les agents d'utilisation d'outils : omission de champs obligatoires, hallucination d'outils inexistants ou interruption prématurée après une seule opération de lecture. Alors que la littérature existante traite l'invocation d'outils via le réglage fin supervisé ou l'apprentissage par renforcement (RL) sur des benchmarks de l'internet ouvert ou des agents larges, il existe un manque de focalisation sur les flux de travail d'entreprise étroits et riches en schémas, dominés par des modèles de type « vérifier puis modifier » (check-then-mutate).

Méthodologie
Les auteurs proposent une preuve de concept utilisant l'apprentissage par renforcement avec récompenses vérifiables (RLVR - Reinforcement Learning with Verifiable Rewards) appliqué directement au sein de copies synthétiques et fidèles au schéma des environnements cibles. Cette approche élimine le besoin d'API en direct, de juges de récompense appris ou d'étiquetage par intervention humaine.

Environnements synthétiques : L'équipe a construit cinq environnements synthétiques émulant les API Jira REST v3 et Confluence v2. Ces environnements maintiennent la fidélité du schéma (correspondant aux contrats publics), sont dotés d'un état (stateful) mais réinitialisables entre les déploiements pour éviter la pollution, et sont entièrement déterministes.
Fonctions de récompense vérifiables : Au lieu de s'appuyer sur un modèle de récompense appris, la correction est déterminée par des vérificateurs programmatiques qui inspectent la trace de l'appel d'outil. La fonction de récompense ( $R \in [0, 1]$ $R \in [0, 1]$ ) est décomposée en trois composantes additives :
1. Exactitude par argument (R1) : Petites constantes attribuées pour la correspondance avec les valeurs d'arguments attendues (ex: clés de projet spécifiques, identifiants de parent).
2. Bonus structurels (R2) : Récompenses pour l'adhésion au modèle valider–modifier–vérifier (ex: effectuer un appel get_* avant un appel create_*).
3. Pénalités (R3) : Soustractions pour les comportements destructeurs, tels que l'omission d'appels obligatoires, des formes de charge utile (payload) invalides, des appels dupliqués, des noms d'outils hallucinés ou le dépassement des budgets d'appels.
Boucle d'entraînement : Les auteurs utilisent l'optimisation de groupe relative par politique (GRPO - Group Relative Policy Optimization) sur les modèles Qwen3-1.7B et Qwen3.5-4B. La boucle d'entraînement implique la génération de plusieurs déploiements (rollouts) par invite, leur évaluation par rapport aux fonctions de récompense vérifiables, et la mise à jour des paramètres de la politique. L'entraînement est réalisé sur du matériel modeste (un ou deux GPU Nvidia RTX PRO 6000) et utilise l'arrêt précoce basé sur la convergence de la récompense.

Principales contributions

Suite Atlassian synthétique : Un ensemble de cinq environnements fidèles au schéma couvrant les transitions de tickets Jira, la création de sous-tâches, la création de pages Confluence, l'étiquetage de pages et un scénario multi-produit.
Conception de la récompense : Un cadre pour décomposer la correction de l'utilisation d'outils en signaux programmatiques vérifiables (correspondance d'arguments, ordre structurel et application des pénalités) entièrement calculables à partir des traces d'appels d'outils.
Base de référence et résultats d'entraînement : Une évaluation complète comparant les bases de référence par incitation (prompted baselines) (Qwen3-1.7B et Qwen3.5-4B) aux politiques entraînées par RLVR utilisant les mêmes vérificateurs de récompense.
Recette d'entraînement : Une recette d'entraînement GRPO de bout en bout qui atteint la convergence en quelques dizaines à quelques centaines de lots de génération sur de petits modèles.

Résultats
L'étude évalue la performance sur cinq scénarios, notant que le scénario de « transition de ticket » est un contrôle de transparence où la fonction de récompense sature (le modèle 4B incité atteint déjà un score parfait).

Gains de performance : Sur les quatre scénarios non dégénérés, la politique entraînée par RL surpasse significativement les bases de référence par incitation.
- Création de page Confluence : L'amélioration la plus spectaculaire, passant d'une base de 0,35 à 1,00 (+0,65).
- Étiquetage de page Confluence : Amélioration de 0,52 à 0,95 (+0,43).
- Création de sous-tâche Jira : Amélioration de 0,68 à 1,00 (+0,32).
- Multi-produit (Jira + Confluence) : Amélioration de 0,92 à 1,00, comblant l'écart résiduel pour atteindre un succès de déploiement parfait sur les 12 invites d'évaluation.
Dynamique d'entraînement : Les modèles ont atteint une récompense moyenne de $\ge 0,95$ en moins de 100 lots de génération pour les scénarios partant de zéro. La variance de la récompense (min/max à travers le groupe de génération) s'est contractée au cours de l'entraînement à mesure que la politique cessait d'émettre des déploiements à faible récompense.

Signification et limites
L'article positionne ce travail comme une preuve de concept préliminaire démontrant que des petits modèles optimisés par les résultats peuvent être entraînés pour des API d'entreprise de niche en utilisant des substrats synthétiques peu coûteux et des récompenses vérifiables.

Les auteurs mettent explicitement en avant deux limites pour tempérer les attentes :

Scalabilité de la conception de la récompense : La création manuelle de récompenses vérifiables ne passe pas encore à l'échelle de l'ensemble de l'API publique d'Atlassian ou des écosystèmes d'entreprise plus larges ; elle n'est efficace que pour la poignée d'endpoints rapportés.
Saturation de la récompense : Un scénario (transition de ticket) possède une forme de récompense trop simple, permettant au modèle 4B incité de maximiser immédiatement, rendant le RL inutile pour cette tâche spécifique.

Les auteurs concluent que bien que la recette fonctionne sur ce substrat spécifique, elle n'établit pas encore une solution généralisable pour toutes les tâches d'utilisation d'outils en entreprise sans une ingénierie manuelle importante des récompenses.