Introduzione
Le grandi imprese richiedono agenti intelligenti capaci di operare efficacemente nei propri ecosistemi IT, rispettando sistemi, regole e lo stato attuale dei dati. Anche i modelli più generali possono incontrare difficoltà specifiche: un workflow gestito in modo errato, una combinazione di strumenti mal utilizzata o un vincolo non rispettato. Queste debolezze devono essere colmate per garantire che l’agente sia realmente utile in ambito enterprise.
Da una debolezza a un dato di addestramento
Il problema principale è trasformare una singola falla in un set di dati sufficientemente ampio da permettere l’apprendimento. Un singolo errore indica una zona di miglioramento, ma per addestrare un modello occorrono numerosi nuovi compiti che esercitino la stessa capacità in contesti diversi. Tali compiti devono poter essere eseguiti nell’ambiente reale, somigliare a richieste che un utente potrebbe effettivamente fare e disporre di un metodo affidabile per verificare il successo dell’agente.
Cos’è AutoSynthData
AutoSynthData, sviluppato dal team ServiceNow CoreAI, automatizza la conversione di gap di capacità in dati di addestramento. Il sistema analizza i fallimenti del modello target e utilizza le soluzioni di un insegnante più forte per determinare cosa il modello deve apprendere successivamente, generando e convalidando nuovi compiti che mettono alla prova le capacità mancanti. Man mano che il modello migliora, il curriculum si adatta, concentrandosi su ciò che resta difficile. Il funzionamento è stato dimostrato con EnterpriseOps Gym (Malay et al., 2026), usando il dataset rilasciato in quella ricerca.
L’ambiente agentico e la definizione di task
Un ambiente agentico definisce il mondo in cui l’agente opera: lo stato osservabile e modificabile, gli strumenti e le API disponibili e le transizioni di stato prodotte dalle azioni. Un task è un’istanza di lavoro all’interno di questo ambiente e si articola secondo l’astrazione seguente:
- Specificazione di sistema: vincoli operativi, istruzioni di sistema, policy ambientali e, se necessario, inizializzazioni specifiche (ad esempio uno stato di database pre‑seedato o un insieme di articoli di knowledge base).
- Prompt utente: descrizione di ciò che l’utente vuole ottenere, con eventuali vincoli a livello utente.
- Verificatore: meccanismo che decide se la traiettoria prodotta completa correttamente il compito.
Caratteristiche di un task utile per l’addestramento
Un task generato deve soddisfare tre proprietà fondamentali:
Fattibilità
Deve esistere almeno una traiettoria nell’ambiente corrente che rispetti il prompt utente e la specificazione di sistema. Questo esclude compiti che richiedono strumenti non disponibili, conoscenza inaccessibile, transizioni di stato impossibili o azioni proibite dalle policy.
Realismo
Il prompt utente deve somigliare a una richiesta plausibile di un vero utente nell’ambiente target. Lo spazio di comportamenti eseguibili è di gran lunga più ampio di quello dei workflow realistici; il realismo filtra le richieste artificiali.
Difficoltà
Per l’addestramento, il task deve evidenziare una debolezza del modello corrente. Compiti già risolti in maniera affidabile offrono poco segnale di apprendimento. La zona utile è quindi costituita da task fattibili e realistici, ma non ancora risolti costantemente.
Il ruolo del verificatore
Il verificatore valuta se la traiettoria completata soddisfa il compito. Deve possedere tre proprietà:
- Coerenza: deve concordare con il prompt utente, la specificazione di sistema e lo stato ambientale specifico del task.
- Solidità: deve respingere le traiettorie che non soddisfano il compito o violano vincoli rilevanti.
- Completezza: deve accettare soluzioni valide senza vincolare l’output a un’unica traiettoria di riferimento.
Un verificatore troppo permissivo premia comportamenti errati; uno troppo restrittivo penalizza soluzioni corrette.
Flusso operativo di AutoSynthData
AutoSynthData inizia valutando il modello target nell’ambiente con compiti diagnostici, identificando pattern nei fallimenti. Un insegnante più forte (teacher) dimostra quali di questi compiti sono risolvibili e come appare un comportamento corretto. I gap di capacità così individuati vengono trasformati in nuovi task eseguibili, che vengono poi controllati nell’ambiente e, se accettati, inseriti nel dataset per il post‑training. Una successiva valutazione del modello aggiornato rivela i gap residui, guidando il ciclo successivo di generazione.
Generazione di task a partire dalle “capability cards”
Durante l’esperimento con EnterpriseOps Gym, sia il modello target sia il teacher vengono eseguiti su task di valutazione. Da queste esecuzioni si estraggono:
- Tipologie di fallimenti ricorrenti;
- Pattern di stato e di sequenza di strumenti coinvolti;
- Vincoli di policy frequentemente violati.
Queste informazioni sono sintetizzate in schede di capacità (capability specification cards), opportunamente sanificate. Le schede guidano la generazione di nuovi task, ma il generatore non riceve i prompt originali, le entità o i dettagli del verificatore; riceve solo le schede, che usa per creare varianti con nuovi prompt, stati e percorsi di soluzione.
Fase “Target”: creazione del nucleo di esempi
La prima fase, denominata “target”, produce il set fondamentale di esempi di addestramento basati sulle schede di capacità. Operatori (workers) generano task in parallelo, passando a una nuova scheda non appena completano una. Ogni candidato subisce:
- Validazione della fattibilità;
- Esecuzione in ambiente reale;
- Valutazione del solver (target e teacher);
- Eventuale riparazione;
- Accettazione finale.
Il risultato è un batch di esempi verificati, tutti focalizzati sulle lacune del modello.
Fase “Moltiplicazione”: espansione delle varianti
Una volta ottenuto il set target, la fase di moltiplicazione crea varianti plausibili di ciascun esempio accettato. Ogni variante