🤖 AI

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

Questo articolo presenta una prova di concetto che dimostra come l'Apprendimento per Rinforzo con Ricompense Verificabili (RLVR) migliori significativamente la capacità dei piccoli modelli linguistici di eseguire chiamate a strumenti complessi e multi-step in ambienti sintetici Atlassian (Jira e Confluence), raggiungendo tassi di successo quasi perfetti nella maggior parte degli scenari senza fare affidamento su API dal vivo o feedback umani.

Autori originali: Karthikeya Aditya Vissa, Sankalp Mane, Ananya Mantravadi, Harshit Rajgarhia, Abhishek Mukherji

Pubblicato 2026-07-03

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Karthikeya Aditya Vissa, Sankalp Mane, Ananya Mantravadi, Harshit Rajgarhia, Abhishek Mukherji

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di avere un bibliotecario molto intelligente e colto (l'IA), che è bravissimo a prevedere la parola successiva in una frase. Se gli chiedi: "Il cielo è...", con sicurezza dirà "blu". Ma se gli chiedi di fare effettivamente qualcosa in un complesso sistema d'ufficio — come "Crea un nuovo ticket di progetto e collegalo a una pagina specifica" — spesso inciampa. Potrebbe conoscere le parole da dire, ma sbaglia i dettagli, come inserire il numero ID sbagliato nella casella errata o dimenticare di controllare se la casella esiste prima di procedere.

Questo articolo riguarda l'insegnare a quel bibliotecario come svolgere davvero il proprio lavoro, non solo parlarne, utilizzando un metodo di addestramento specifico chiamato RLVR (Reinforcement Learning with Verifiable Rewards - Apprendimento per Rinforzo con Ricompense Verificabili).

Ecco la scomposizione del loro esperimento in termini quotidiani:

1. Il Problema: L' "Autopilota" vs. Il "Pilota"

I Grandi Modelli Linguistici (LLM) sono addestrati per essere come autopiloti che prevedono la parola successiva. Sono eccellenti nello scrivere storie o email. Ma in un ufficio aziendale (specificamente utilizzando gli strumenti Atlassian come Jira e Confluence), il successo non consiste nello scrivere una bella frase; consiste nell'intercettare esattamente i pulsanti giusti, nell'ordine giusto e con i dati giusti.

Il Vecchio Modo: Chiedi all'IA di "Creare un sotto-task". L'IA potrebbe dire: "Ok, creerò un sotto-task", ma dimentica di assegnarlo a una persona o usa il codice progetto errato. Sembra fluida, ma il compito fallisce.
L'Obiettivo: Gli autori volevano vedere se potevano addestrare l'IA a smettere di "indovinare la parola successiva" e iniziare a "agire come un pilota" che controlla gli strumenti prima di volare.

2. La Soluzione: Un Campo di Addestramento a "Videogioco"

Inveve di lasciare che l'IA si eserciti sui server reali e attivi dell'azienda (il che è rischioso e lento), gli autori hanno costruito un gemello digitale perfetto (una versione videogioco dei sistemi Jira e Confluence).

Il Simulatore: Questo "gioco" sembra e si comporta esattamente come il software reale, ma è sicuro. Se l'IA commette un errore, nulla si rompe.
L'Arbitro (Il Sistema di Ricompensa): Questa è la salsa segreta. Di solito, serve un essere umano per valutare il lavoro dell'IA. Qui, hanno costruito un arbitro automatizzato e rigoroso.
- Se l'IA inserisce i dati corretti nella casella giusta? Punti.
- Se l'IA controlla se una pagina esiste prima di provare a modificarla? Punti bonus.
- Se l'IA prova a usare uno strumento che non esiste o dimentica un passaggio obbligatorio? Punti penalità.
- Fondamentalmente: L'arbitro non ha bisogno che un essere umano guardi lo schermo. Controlla solo la matematica e il codice.

3. L'Addestramento: Tentativo ed Errore

Hanno preso due versioni di un'IA (un modello più piccolo da 1.7B e uno più grande da 4B) e le hanno fatto giocare in questo simulatore migliaia di volte.

L'IA prova a completare un compito (come "Creare una pagina").
Fallisce, riceve un punteggio basso dall'arbitro e riprova.
Impara lentamente: "Oh, ho ottenuto punti quando ho controllato prima la pagina genitore. Ho perso punti quando ho dimenticato il codice del progetto".
Questo è l'Apprendimento per Rinforzo: l'IA impara ricevendo ricompense per i comportamenti corretti e penalità per quelli errati.

4. I Risultati: Da "Ok" a "Perfetto"

Hanno testato l'IA prima e dopo questo addestramento su cinque diversi compiti d'ufficio.

Prima dell'Addestramento: L'IA era discreta nei compiti semplici ma terribile in quelli complessi. Ad esempio, nella creazione di una nuova pagina Confluence, l'IA non addestrata otteneva solo circa il 35% dei punti. Continuava a commettere piccoli errori costosi.
Dopo l'Addestramento: L'IA addestrata è diventata quasi perfetta. Nello stesso compito di creazione pagina, è balzata al 100%.
La Grande Vittoria: L'addestramento è stato più efficace sui compiti più difficili (quelli con più regole e campi dati). L'IA ha imparato a seguire il rigoroso schema "controlla-poi-esegui" richiesto da questi sistemi.

5. Il Limite (Limitazioni)

Gli autori sono molto onesti su ciò che questo non fa ancora:

Non è magia per tutto: Hanno dovuto creare manualmente le "regole dell'arbitro" per questi compiti specifici. Non puoi semplicemente collegare questo sistema a qualsiasi software nel mondo senza costruire un nuovo arbitro per esso. È come avere un coach che è fantastico nell'insegnare il calcio, ma non ha ancora imparato il basket.
Un compito era troppo facile: Per un compito specifico (cambiare lo stato di un ticket), l'IA era già perfetta prima dell'addestramento, quindi l'addestramento non ha aggiunto alcun valore lì.

In Breve

Questo articolo dimostra che puoi prendere una IA standard, metterla in un ambiente d'ufficio simulato e sicuro, e usare un arbitro automatizzato e rigoroso per insegnarle come seguire regole complesse. Trasforma l'IA da un "bot chiacchierone" che suona bene ma fallisce nei dettagli, in un "lavoratore affidabile" che svolge il compito perfettamente. Tuttavia, questo richiede la costruzione di una "palestra di addestramento" personalizzata per ogni specifico tipo di software che si desidera utilizzare.

Riepilogo Tecnico: Oltre la predizione del prossimo token: Una prova di concetto di RLVR per agenti di tool-use su workflow Atlassian

Problema
I Large Language Models (LLM) sono fondamentalmente ottimizzati per la predizione del prossimo token su testi su scala internet, un obiettivo che non è allineato con i requisiti dei flussi di lavoro specialistici delle applicazioni SaaS aziendali. In questi ambienti, il successo dipende dall'esecuzione di chiamate API specifiche con argomenti nidificati precisi in un ordine rigoroso. Il documento sostiene che questo disallineamento degli obiettivi si manifesta come "fallimenti silenziosi" negli agenti di tool-use: omissione di campi obbligatori, allucinazione di strumenti inesistenti o terminazione prematura dopo una singola operazione di lettura. Mentre la letteratura esistente affronta l'invocazione di strumenti tramite fine-tuning supervisionato o Reinforcement Learning (RL) su benchmark web aperti o agentici ampi, manca un focus su workflow aziendali ristretti e ricchi di schemi, dominati da pattern "check-then-mutate" (verifica-e-modifica).

Metodologia
Gli autori propongono una prova di concetto che utilizza il Reinforcement Learning con Verifiable Rewards (RLVR) applicato direttamente su copie sintetiche e fedeli allo schema degli ambienti target. L'approccio elimina la necessità di API live, giudici di ricompensa appresi o etichettatura umana (human-in-the-loop).

Ambienti Sintetici: Il team ha costruito cinque ambienti sintetici che emulano le API Jira REST v3 e Confluence v2. Questi ambienti mantengono la fedeltà dello schema (corrispondendo ai contratti pubblici), sono stateful ma resettabili tra i rollout per evitare contaminazioni, e sono completamente deterministici.
Funzioni di Ricompensa Verificabili: Invece di fare affidamento su un modello di ricompensa appreso, la correttezza è determinata da controllori programmatici che ispezionano la traccia delle chiamate agli strumenti (tool-call trace). La funzione di ricompensa ( $R \in [0, 1]$ $R \in [0, 1]$ ) è scomposta in tre componenti additive:
1. Correttezza per argomento (R1): Costanti piccole assegnate per il corrispondere ai valori degli argomenti attesi (ad esempio, chiavi di progetto specifiche, ID genitore).
2. Bonus strutturali (R2): Ricompense per l'adesione al pattern validate–mutate–verify (ad esempio, eseguire una chiamata get_* prima di una chiamata create_*).
3. Penalità (R3): Sottrazioni per comportamenti distruttivi, come l'omissione di chiamate obbligatorie, forme di payload non valide, chiamate duplicate, nomi di strumenti allucinati o superamento dei budget di chiamata.
Ciclo di Addestramento: Gli autori impiegano il Group Relative Policy Optimization (GRPO) su modelli Qwen3-1.7B e Qwen3.5-4B. Il ciclo di addestramento prevede la generazione di molteplici rollout per ogni prompt, la valutazione rispetto alle funzioni di ricompensa verificabili e l'aggiornamento dei parametri della policy. L'addestramento avviene su hardware modesto (una o due GPU Nvidia RTX PRO 6000) e utilizza l'early stopping basato sulla convergenza della ricompensa.

Contributi Chiave

Suite Atlassian Sintetica: Un set di cinque ambienti fedeli allo schema che coprono transizioni di ticket Jira, creazione di sub-task, creazione di pagine Confluence, etichettatura di pagine e uno scenario cross-prodotto.
Design della Ricompensa: Un framework per scomporre la correttezza dell'uso degli strumenti in segnali programmatici verificabili (corrispondenza argomenti, ordine strutturale e imposizione delle penalità) computabili interamente dalle tracce delle chiamate agli strumenti.
Baseline e Risultati dell'Addestramento: Una valutazione completa che confronta le baseline indotte da prompt (Qwen3-1.7B e Qwen3.5-4B) con le policy addestrate tramite RLVR utilizzando gli stessi controllori di ricompensa.
Ricetta di Addestramento: Una ricetta di addestramento GRPO end-to-end che raggiunge la convergenza in decine o poche centinaia di batch di generazione su modelli piccoli.

Risultati
Lo studio valuta le prestazioni su cinque scenari, notando che lo scenario "ticket-transition" è un controllo di trasparenza in cui la funzione di ricompensa satura (il modello 4B indotto da prompt raggiunge già un punteggio perfetto).

Guadagni di Prestazione: Negli quattro scenari non degeneri, la policy addestrata con RL supera significativamente le baseline indotte da prompt.
- Creazione Pagina Confluence: Il miglioramento più drammatico, salendo da una baseline di 0.35 a 1.00 (+0.65).
- Etichettatura Pagina Confluence: Migliorata da 0.52 a 0.95 (+0.43).
- Creazione Sub-task Jira: Migliorata da 0.68 a 1.00 (+0.32).
- Cross-Product (Jira + Confluence): Migliorata da 0.92 a 1.00, chiudendo il gap residuo per raggiungere il successo perfetto del rollout su tutti i 12 prompt di valutazione.
Dinamiche di Addestramento: I modelli hanno raggiunto una ricompensa media $\ge 0.95$ entro 100 batch di generazione per gli scenari partendo da zero. La varianza della ricompensa (min/max attraverso il gruppo di generazione) si è contratta durante l'addestramento man mano che la policy smetteva di emettere rollout a bassa ricompensa.

Significatività e Limitazioni
Il documento posiziona questo lavoro come una prova di concetto preliminare che dimostra come modelli piccoli ottimizzati per l'outcome possano essere addestrati per API enterprise di nicchia utilizzando substrati sintetici economici e ricompense verificabili.

Gli autori evidenziano esplicitamente due limitazioni per temperare le aspettative:

Scalabilità del Design della Ricompensa: La creazione manuale di ricompense verificabili non scala attualmente verso l'intera superficie delle API pubbliche di Atlassian o verso ecosistemi enterprise più ampi; è efficace solo per la manciata di endpoint riportati.
Saturazione della Ricompensa: Uno scenario (ticket-transition) possiede una forma di ricompensa troppo semplice, che permette al modello 4B indotto da prompt di massimizzare immediatamente, rendendo l'RL non necessario per quel compito specifico.

Gli autori concludono che, sebbene la ricetta funzioni su questo specifico substrato, non stabilisce ancora una soluzione generalizzabile per tutti i compiti di tool-use enterprise senza un significativo ingegneria manuale delle ricompense.