ServiceNow trasforma i fallimenti degli agenti in dati di addestramento

Ogni team che ha distribuito un agente AI in un sistema aziendale reale conosce lo stesso dolore. Il modello è ampiamente capace, poi incontra i tuoi strumenti specifici, le tue policy specifiche, il tuo specifico disordine di macchina a stati, e inciampa.

Il braccio di ricerca di ServiceNow, CoreAI, ha rilasciato un sistema che cerca di trasformare quegli inciampi in una risorsa. Si chiama AutoSynthData, e la sua premessa è che i fallimenti di un modello sono la materia prima più preziosa che hai per addestrarlo.

La mossa centrale

La pipeline inizia eseguendo un modello target e un modello insegnante più forte sugli stessi compiti diagnostici in un ambiente reale. Dove il modello target fallisce e l'insegnante riesce, c'è un divario di capacità. AutoSynthData distilla quel divario in quelle che il team chiama schede di specifica delle capacità: descrizioni sanificate degli strumenti, dei flussi di lavoro, degli stati finali e delle variazioni ammissibili coinvolte, ripulite dai prompt di valutazione originali e dai dettagli delle entità.

Quelle schede alimentano la generazione di nuovi compiti. Fondamentalmente, il generatore non vede mai le traiettorie di valutazione originali, quindi i dati risultanti testano la competenza di fondo anziché sequenze memorizzate. Il framework scala questo in due fasi. Una fase target crea compiti core in parallelo. Una fase di moltiplicazione prende i compiti verificati e genera varianti con nuove formulazioni, nuove configurazioni di entità e nuovi stati iniziali. Una regola impedisce ai dati di andare alla deriva: un campione moltiplicato non può mai alimentare un'altra moltiplicazione.

Tre condizioni per un compito che valga la pena generare

ServiceNow è esplicito sul fatto che una richiesta dall'aspetto plausibile non basta. Un compito generato deve soddisfare tre cose contemporaneamente.

Deve essere fattibile, cioè deve esistere almeno un percorso eseguibile attraverso l'ambiente che completa la richiesta rispettando le regole. Deve essere realistico, cioè deve rispecchiare un lavoro che un utente reale chiederebbe davvero, anziché un'azione tecnicamente valida che nessuno farebbe. E deve essere difficile, cioè deve mirare a una debolezza genuina. Un compito banale non insegna nulla, e uno impossibile insegna la lezione sbagliata.

Ogni compito arriva con un verificatore, e il verificatore deve soddisfare un proprio standard. Deve essere coerente con il prompt e lo stato del sistema, abbastanza solido da respingere violazioni dei vincoli, e abbastanza completo da accettare qualsiasi soluzione funzionante anziché insistere su un unico percorso di riferimento.

I cancelli di qualità sono il vero prodotto

La parte di questo che merita attenzione non è la generazione dei compiti. È il controllo.

Ogni candidato supera due cancelli. Un cancello positivo esegue la soluzione di riferimento all'interno dell'ambiente per confermare che la risposta prevista soddisfi effettivamente il verificatore, il che intercetta discrepanze tra il prompt, lo stato iniziale e i criteri di successo. Un cancello negativo poi modifica deliberatamente lo stato finale per confermare che gli esiti sbagliati vengano effettivamente respinti. Quel secondo cancello è quello che intercetta i verificatori sotto-specificati, quelli che premerebbero volentieri una traiettoria dell'agente malformata.

Quando un candidato fallisce, un critico diagnostica il guasto, individuando riferimenti rotti o stati contraddittori, e indirizza una riparazione limitata anziché scartare il lavoro del tutto. Al di sopra del livello del campione, una revisione dei lotti osserva l'aggregato: quali cluster di compiti sono sovrarappresentati, quali dimensioni mancano, quali schemi di generazione continuano a bloccarsi. Il controllore poi indirizza il lotto successivo verso le lacune che rimangono.

Perché chiunque abbia bisogno di dati sintetici

Vale la pena fare un passo indietro per chiedersi perché questo conti. I dati di addestramento ideali per un agente aziendale sono un registro di persone reali che svolgono lavoro reale nel sistema reale, etichettato correttamente. Quei dati sono scarsi, sensibili e costosi da raccogliere, e gran parte di essi non può lasciare l'edificio per motivi di privacy o conformità.

La generazione sintetica è la via di fuga, ma comporta una modalità di fallimento nota. Se generi compiti da un modello, erediti i suoi punti ciechi, e i dati risultanti possono sembrare abbondanti mentre insegnano pochissimo. L'intero contributo di AutoSynthData è il meccanismo attorno alla generazione che mantiene onesti i dati: cancelli che respingono compiti scadenti, controlli di diversità che impediscono la ripetizione, e un curriculum che continua a mirare a ciò che l'agente non ha ancora padroneggiato. La generazione senza verifica è rumore. Questo è un tentativo di renderla segnale.

Cosa dicono i numeri, e cosa non dicono

Nei test su EnterpriseOps Gym, un ambiente open source per compiti di agenti aziendali, un modello basato su Gemma fine-tuned su 2.000 campioni AutoSynthData ha migliorato la sua metrica Pass@1 del 35 percento rispetto alla baseline in un dominio ibrido. Nel dominio ITSM, il fine-tuning supervisionato sintetico ha portato la Pass@1 media dal 18,77 percento al 27,18 percento.

Questi sono guadagni reali su un benchmark specifico, il che non equivale a un risultato generale. La dipendenza centrale della pipeline è onesta e vale la pena dichiararla chiaramente: richiede un modello insegnante significativamente più forte per dimostrare il comportamento corretto, e un ambiente di simulazione accurato in cui testare. In un'azienda senza un sandbox ad alta fedeltà e verificatori deterministici affidabili, costruire il livello di esecuzione è di per sé un serio progetto di ingegneria. AutoSynthData non elimina quel lavoro. Cambia per cosa serve il lavoro.

Il tranello del modello insegnante

C'è una dipendenza in questo design che merita una frase a sé. L'intera pipeline si basa sul divario tra un modello debole e uno forte. Negli esperimenti, l'insegnante era un modello molto più grande del target. Funziona quando hai un sistema di frontiera da cui prendere in prestito. Funziona meno bene quando sei tu la frontiera, o quando il compito è così specializzato che non esiste un modello più forte per dimostrarlo. In quel caso la pipeline non ha nulla da cui imparare, e il divario di capacità da cui dipende è semplicemente un muro. La ricerca sulla generazione di dati di addestramento arriva sempre prima o poi a questo punto: il metodo scala finché qualcuno, da qualche parte, ha già risolto il problema.

Perché questa è la forma dell'AI aziendale

La cosa interessante di questo rilascio è ciò che ammette su dove si trova davvero l'AI aziendale. Il collo di bottiglia non è più ottenere un modello capace. Il collo di bottiglia è far operare correttamente un modello capace all'interno di una particolare organizzazione, con i suoi particolari strumenti e regole, dove i fallimenti sono sottili e lo spazio degli stati è ampio.

Per anni la risposta è stata l'annotazione manuale, che è lenta, costosa e difficile da scalare. AutoSynthData è un argomento secondo cui i fallimenti stessi contengono il segnale, se riesci a estrarli, verificarli e diversificarli senza far trapelare il set di valutazione. La pipeline è disponibile per la ricerca su Hugging Face, e il team dice che il prossimo passo è il reinforcement learning con la stessa metodologia.

Se funziona ampiamente, l'implicazione è che la competenza scarsa nell'AI aziendale si sposta. Smette di riguardare l'acquisizione di dati e diventa la costruzione di ambienti abbastanza buoni da generare dati affidabili al loro interno. È un problema più difficile, e più duraturo, perché l'ambiente di un'azienda è la cosa che nessun concorrente può copiare.