AutoSynthData di ServiceNow trasforma gli errori degli agenti in preziose risorse formative

AutoSynthData di ServiceNow trasforma gli errori degli agenti in preziose risorse formative

In breve: AutoSynthData di ServiceNow CoreAI trasforma gli errori degli agenti e i successi dei formatori in attività SFT sintetiche validate, quando le aziende necessitano di competenze ambientali, non solo di punteggi di benchmark generici. Il sistema colma le lacune trasformandole in schede di specifiche di capacità, moltiplica il lavoro verificabile e poi controlla la qualità prima della messa a punto. Secondo quanto riportato dall'autore, EnterpriseOps Gym mantiene la validità se la competenza del formatore, la qualità del verificatore e la fedeltà dell'ambiente sono allineate.

Punti chiave:

Schede di funzionalità: anonimizzare i guasti nelle schede in modo che i generatori non vedano mai gli ID originali.

Verificabilità del verificatore: preferire i controlli sullo stato finale SQL che rifiutano i risultati errati modificati.

Livello di difficoltà: Allena solo compiti che il target risolve raramente e che l'insegnante di solito corregge.

Revisione umana: Mantenere la revisione umana sulle politiche ad alto rischio e sulle azioni irreversibili prima di riqualificare il personale.

Frontiera in movimento: dopo SFT, rivalutare e spostare la fase target verso le lacune rimanenti.

Gli agenti di intelligenza artificiale aziendali raramente falliscono per mancanza di conoscenze generali. Falliscono perché l'ambiente è specifico: politiche di ticketing, peculiarità dello schema, contratti con gli strumenti, database precompilati, articoli della knowledge base e flussi di lavoro inter-sistema che non corrispondono agli esempi da manuale. Un modello che ottiene buoni risultati nei benchmark aperti può comunque bloccarsi quando il passaggio successivo deve rispettare una finestra di modifica, una relazione con un CMDB o un verificatore che controlla lo stato finale anziché una chat fluida.

ServiceNow CoreAI / ServiceNow-AI ha pubblicato AutoSynthData per colmare direttamente questa lacuna. L'autore principale, Esakkivel Esakkiraja, descrive una pipeline che converte gli errori di un agente target, insieme ai successi di un insegnante più esperto, in attività di training sintetiche validate e personalizzate per gli ambienti aziendali. L'obiettivo non è raccogliere più log di chat, bensì moltiplicare il lavoro rigoroso e verificabile che esercita la stessa capacità in nuove condizioni, in modo che la messa a punto supervisionata possa colmare le lacune specifiche dell'ambiente.

Questo articolo illustra l'idea centrale, l'astrazione dei compiti, il ciclo di generazione e controllo qualità, l'architettura condivisa e i risultati riportati dagli autori su EnterpriseOps Gym in contesti ibridi e ITSM. Si attiene a quanto descritto dalla ricerca: un curriculum dinamico di compiti sintetici, non la pretesa che qualsiasi problema aziendale venga improvvisamente risolto.

Perché la competenza ambientale è più importante della capacità generale

Le aziende necessitano di agenti che operino nel loro ambiente: i loro sistemi, le loro regole e lo stato dei dati. Una vasta capacità non è sinonimo di competenza ambientale. Un agente può conoscere il funzionamento standard della gestione dei servizi IT e tuttavia non essere a conoscenza della policy locale che vieta determinate transizioni, o dello strumento che aggiorna una tabella correlata solo dopo l'esistenza di un record prerequisito.

I singoli fallimenti sono informativi, ma rappresentano una quantità esigua di dati di addestramento. Una singola traiettoria interrotta evidenzia una debolezza, ma non fornisce le decine di situazioni simili che permetterebbero al modello di adattarsi alle variazioni. I team hanno bisogno di molti nuovi compiti che mettano alla prova la stessa capacità in modi diversi, che siano completabili all'interno dell'ambiente, che risultino realistici in base alle richieste dell'utente e che siano verificabili tramite controlli dei risultati.

Questa è la pressione progettuale alla base di AutoSynthData. Gli errori diventano segnali per le schede di competenza. Le schede diventano generatori di nuovi compiti. Un insegnante più competente dimostra percorsi di successo. Filtri e verificatori decidono cosa entra nel set di fine-tuning supervisionato. Dopo l'addestramento, la valutazione sposta la frontiera verso le lacune rimanenti. Il ciclo è strutturato in base al curriculum, non si tratta di un semplice riversamento di dati una tantum.

Per chi lavora nel settore, la definizione del problema è fondamentale. Se si memorizzano solo i prompt che non hanno funzionato, si rischia di incorrere in un overfitting specifico per quelle entità e formulazioni. Se invece si generano solo richieste sintetiche non vincolate, si rischia di creare attività impossibili, irrealistiche o non verificabili. AutoSynthData si colloca tra questi due estremi: ripulisce ciò che non ha funzionato trasformandolo in una specifica di capacità, quindi rigenera attività che mantengono il nucleo essenziale, modificandone al contempo la forma e le dimensioni controllabili.

La forma pratica del compito: sistema, richiesta, verificatore

Un'astrazione praticabile per il lavoro degli agenti è la seguente: compito equivale a specifica di sistema, richiesta all'utente e verificatore. Ogni elemento è soggetto a vincoli che mantengono i dati sintetici fondati e affidabili.

La specifica del sistema comprende vincoli, politiche e stato iniziale, ad esempio i valori iniziali del database e gli articoli di conoscenza. Deve rimanere compatibile con gli strumenti e lo stato disponibili. Vincoli di difficoltà arbitrari che ignorano i contratti tra strumenti o il realismo dei valori iniziali tendono a creare attività fragili che insegnano la lezione sbagliata.

La qualità dei prompt per l'utente si basa su tre parametri. La fattibilità si interroga sull'esistenza di una traiettoria valida. Il realismo si chiede se un utente farebbe plausibilmente una richiesta del genere. La difficoltà si chiede se il compito mette in luce una debolezza attuale dell'agente piuttosto che qualcosa che l'utente target risolve già in modo affidabile. Un prompt banale per l'utente target spreca risorse per la formazione; un prompt impossibile mina la fiducia nella valutazione.

La qualità del verificatore si basa su coerenza, correttezza e completezza. Un approccio troppo permissivo permette il superamento dei controlli anche per traiettorie deboli. Un approccio troppo restrittivo, che si limita a una singola traiettoria, non consente il superamento dei controlli per soluzioni alternative valide. Gli ambienti aziendali spesso preferiscono controlli basati su SQL o sullo stato, perché valutano il mondo dopo l'azione dell'agente, non il percorso esatto seguito dall'agente stesso.

AutoSynthData si basa su questa triade affinché il lavoro generato rimanga ancorato alla realtà. I ​​generatori non inventano quiz a caso. Producono attività che possono essere eseguite nell'adattatore dell'ambiente e valutate da verificatori che si preoccupano delle proprietà richieste nello stato finale.

Dalla valutazione diagnostica alle schede di specifica delle capacità

Il processo inizia con una valutazione diagnostica dell'agente target e di un insegnante più competente all'interno dell'ambiente. Le esecuzioni parallele rivelano dove il target fallisce e dove l'insegnante ha successo. Questi casi di confronto costituiscono la materia prima per la progettazione del curriculum.

Successivamente, si procede alla distillazione in schede di specifica delle capacità ripulite. Una scheda cattura la capacità da testare, gli strumenti o la struttura del flusso di lavoro pertinenti, i punti in cui il target fallisce e il docente ha successo, le proprietà dello stato finale richieste e le dimensioni che possono variare quando vengono inventati nuovi compiti. Fondamentalmente, il generatore non riceve i prompt originali, le entità, le traiettorie o i dettagli del verificatore, ma solo le schede.

Questa sanificazione è una mossa deliberata per evitare l'overfitting. Se il generatore vedesse i numeri esatti dei ticket falliti, gli ID degli articoli della knowledge base o le tracce degli insegnanti, sarebbe tentato di parafrasare lo stesso episodio. Le schede impongono l'astrazione: insegna la capacità in condizioni di variazione controllabile, non l'istanza memorizzata.

Una volta create le schede, il sistema genera nuovi compiti a partire da esse. L'insegnante quindi mostra percorsi di successo per una messa a punto supervisionata. Queste dimostrazioni non sono consigli generici, bensì successi concreti, basati sul contesto, che superano lo stesso tipo di verifica a cui il curriculum tiene.

La scala strutturale a due fasi. La fase target si concentra sui campioni principali verificati intorno alle lacune, ovvero le attività con il segnale più alto in prossimità del punto in cui l'agente debole si interrompe. La fase di moltiplicazione crea nuove varianti dei target accettati. I campioni moltiplicati non possono innescare ulteriori cicli di moltiplicazione, il che limita la deriva. Questa regola è piccola ma importante: una variazione ricorsiva illimitata può allontanarsi dalla capacità indicata dalla scheda.

Controller condiviso, adattatore ambientale e frontiera mobile

Dal punto di vista architetturale, AutoSynthData utilizza un controller condiviso e un adattatore di ambiente. Il controller orchestra la diagnosi, la creazione delle schede, la generazione, le dimostrazioni per gli insegnanti, i controlli di qualità e la revisione in batch. L'adattatore collega questi passaggi a un ambiente di test aziendale concreto (strumenti, stato, politiche e verificatori), in modo che lo stesso ciclo di controllo possa essere applicato a diversi ambiti senza dover riscrivere da zero la logica del curriculum.

Dopo la messa a punto supervisionata, il processo viene rivalutato. Il curriculum si sposta quindi verso le lacune rimanenti: una frontiera in movimento piuttosto che un insieme di dati statico. Gli esperimenti descritti nel lavoro si concentrano sulla messa a punto supervisionata. Lo stesso ciclo potrebbe supportare in seguito l'apprendimento per rinforzo; tale direzione è indicata come pianificata, non come già completata.

Per i team aziendali, la lezione architetturale è la modularità. I ​​controller non dovrebbero codificare in modo rigido un unico schema di ticket. Gli adattatori dovrebbero esporre uno stato e una fedeltà degli strumenti sufficienti affinché i verificatori possano essere significativi. Il curriculum dovrebbe considerare i risultati della valutazione come input successivo, non come un punteggio da assegnare una sola volta.

EnterpriseOps Gym è l'ambiente in cui questo approccio è stato illustrato. Si tratta di un banco di prova per agenti aziendali su larga scala con circa 1.150 attività curate da esperti in 8 domini, circa 512 strumenti, circa 164 tabelle di database, esecuzione containerizzata, verifica dei risultati basata su SQL, operazioni governate da policy, scenari ibridi tra domini diversi, test di non fattibilità e di rifiuto e traiettorie stateful a lungo termine. AutoSynthData non viene presentato come l'inventore di questa palestra; la palestra è il banco di prova per il ciclo di sintesi.

Controllo qualità a livello di campione che garantisce l'affidabilità delle attività di sintesi

La generazione senza criteri di controllo è il motivo per cui i dati degli agenti sintetici risultano errati. AutoSynthData descrive il controllo di qualità a livello di campione con diversi controlli complementari.

Un filtro di difficoltà per il risolutore indirizza l'insieme verso compiti difficili per il target e risolvibili per l'insegnante. La configurazione descritta privilegia i compiti che il target risolve in al massimo una prova su tre, mentre l'insegnante riesce in almeno due prove su tre. Questa fascia è quella in cui le dimostrazioni supervisionate possono insegnare qualcosa che il modello debole non possiede ancora.

La verifica positiva richiede che una traiettoria di riferimento superi il controllo del verificatore. La verifica negativa richiede che i risultati errati, ottenuti tramite mutazione, non vengano superati. Insieme, questi due elementi mettono alla prova sia il lato di accettazione che quello di rifiuto del sistema di verifica. Se vengono controllati solo i risultati positivi, un verificatore permissivo può ammettere risultati spazzatura. Se vengono controllati solo i risultati negativi, un verificatore troppo restrittivo può rifiutare un lavoro valido.

Un ciclo di critica e riparazione, con un limite di tentativi, cerca di correggere le attività che non superano le fasi di verifica, anziché scartare immediatamente ogni tentativo quasi riuscito. I limiti di tentativi sono importanti: una riparazione infinita può generare vincoli sempre più artificiali solo per superare una checklist.

La meta-analisi a livello di batch esamina quindi l'intero set per verificarne la copertura, la diversità, la ridondanza e gli obiettivi non raggiunti. I controlli a campione mantengono validi i singoli elementi; la revisione a batch impedisce che il curriculum si concentri su una singola modalità di fallimento o che vengano clonati elementi quasi identici.

Questi controlli spiegano perché la pipeline può impiegare ore a produrre migliaia di campioni senza considerare il volume come un sostituto dell'adeguatezza. La velocità varia in base al dominio e alle dimensioni del gruppo di docenti, ma il processo di controllo qualità è sempre lo stesso: fascia di difficoltà, verifica positiva e negativa, correzione con limiti, e infine meta-revisione.

Errori grezzi vs schede vs set SFT convalidati

È utile confrontare a cosa serve ciascun artefatto. I log di errore grezzi sono diagnostici. Le schede di capacità sono contratti generativi. I set di fine-tuning supervisionati e convalidati sono quelli su cui ci si addestra nella pratica.

Artefatto Cosa contiene Forza Rischio se usato da solo
Registri degli errori non elaborati Suggerimenti, stati, traiettorie interrotte, contrasti con il successo dell'insegnante Individua le lacune reali nell'ambiente live Pochi campioni; facile sovradattare entità e frasi
Schede di specifiche di capacità Capacità, strumenti o flusso di lavoro, contrasto tra fallimento e successo, esigenze dello stato finale, dimensioni variabili Astrazione sanificata per i generatori senza originali che perdono Le schede senza controllo qualità possono comunque produrre risultati impossibili o banali
Set SFT convalidato da AutoSynthData Nuovi compiti e dimostrazioni per insegnanti che hanno superato i test di difficoltà, verifica e revisione Scala con verifiche di realismo, fattibilità e risultati Dipende ancora dalla competenza degli insegnanti, dalla qualità dei verificatori e dalla fedeltà all'ambiente

Nelle istantanee Hybrid e ITSM su EnterpriseOps Gym, le esecuzioni riportate dagli autori hanno utilizzato Gemma-4-26B-A4B-it come target. Hybrid ha abbinato tale target a Qwen3.8-27B come teacher e ha prodotto circa 2.000 campioni ibridi in circa 18 ore, con il checkpoint migliore all'epoca 5. Il Pass@1 medio è aumentato di 7,2 punti percentuali - circa il 35% in termini relativi - con il successo del verificatore passato dal 63,01% al 68,55%, colmando circa il 59% del divario Pass@1 rispetto al modello di riferimento.

ITSM ha abbinato lo stesso target con DeepSeek-V4.1-Flash come insegnante e ha prodotto circa 1.994 campioni in circa 66 ore, un tempo maggiore in parte a causa di un insegnante più grande e perché alcune ottimizzazioni della pipeline non erano ancora state implementate. La percentuale media di Pass@1 è passata dal 18,77% al 27,18%.

Dominio Bersaglio Insegnante Esempi e tempo di esecuzione Risultato riportato dall'autore
Ibrido Gemma-4-26B-A4B-it Qwen3.8-27B Circa 2.000 campioni in circa 18 ore; miglior checkpoint epoch 5 Media Pass@1 +7,2 pp (~35% relativo); successo del verificatore dal 63,01% al 68,55%; ~59% del divario Pass@1 rispetto al riferimento colmato
ITSM Gemma-4-26B-A4B-it DeepSeek-V4.1-Flash Circa 1.994 campioni in circa 66 ore Media di superamento@1 dal 18,77% al 27,18%

Considerate questi dati come risultati di una ricerca interna condotta dall'azienda su questa palestra per i domini testati, non come una replica indipendente da parte di terzi e non come una garanzia aziendale universale. I miglioramenti si riscontrano laddove la competenza degli insegnanti, la qualità dei verificatori e la fedeltà all'ambiente coincidono.

Cosa dovrebbero copiare i professionisti dal ciclo

Anche se il tuo stack non è la pipeline di ricerca di ServiceNow, il modello è trasferibile. Inizia con una valutazione comparativa di un target simile alla produzione e di un modello più robusto in un ambiente sandbox affidabile. Converti i fallimenti di confronto in schede di capacità che rimuovono identificatori e traiettorie. Genera attività che variano le dimensioni consentite preservando le proprietà richieste dello stato finale. Fai in modo che il modello dimostri i successi. Applica criteri di difficoltà, verifica positiva e negativa, riparazione limitata e revisione della diversità dei batch. Affina, rivaluta e sposta la frontiera.

Presta particolare attenzione alla progettazione del verificatore. I controlli dei risultati SQL in stile EnterpriseOps Gym e le operazioni governate da policy illustrano perché le rubriche di chat da sole sono inadeguate per il lavoro con stato. Se il tuo verificatore non è in grado di distinguere i risultati errati modificati dai risultati finali corretti, la scalabilità sintetica amplificherà il rumore.

Rispettate inoltre lo spirito della regola della moltiplicazione: le varianti degli obiettivi accettati non dovrebbero generare all'infinito altre varianti senza tornare ai nuclei collaudati. La deriva è silenziosa. Un curriculum che inventa lentamente vincoli più esotici potrebbe comunque superare filtri superficiali, lasciando però la capacità originale sottosviluppata.

Infine, considerate il lavoro ibrido interdominio come un caso di stress di prim'ordine. Gli utenti di tutti i giorni non rimangono confinati in un unico ambiente di sviluppo. Le attività ibride, le traiettorie a lungo termine e i test di rifiuto o di non fattibilità sono i contesti in cui la competenza nell'ambiente di lavoro si manifesta – o fallisce clamorosamente.

Avvertenze, limiti e un'attenta lettura dei guadagni

I risultati riportati dagli autori su EnterpriseOps Gym sono da intendersi come segnali informativi e non come una garanzia assoluta. I vantaggi pubblicati per Hybrid e ITSM si applicano ai domini e alle combinazioni di modelli descritti. Altri domini, modelli meno performanti, verificatori meno affidabili o una minore fedeltà all'ambiente possono ridurre o annullare i benefici.

La qualità dipende da tre pilastri che nessuna strategia di marketing può ignorare. La competenza degli insegnanti definisce il livello massimo per le dimostrazioni. La qualità dei verificatori determina l'affidabilità di etichette e filtri. La fedeltà all'ambiente determina se i comportamenti appresi permangono a contatto con i sistemi di produzione, le regole e lo stato dei dati.

Gli esperimenti di AutoSynthData pongono l'accento sulla messa a punto supervisionata. L'apprendimento per rinforzo è indicato come un possibile utilizzo successivo dello stesso ciclo, pianificato ma non implementato nel lavoro descritto. I lettori non devono confondere un motore di dati pronto per l'uso in ambito didattico con un addestramento per rinforzo completo.

I lettori non devono confondere la pipeline di sintesi con il banco di prova stesso. EnterpriseOps Gym fornisce attività, strumenti, tabelle, containerizzazione e infrastruttura di verifica accuratamente selezionati. AutoSynthData utilizza questo tipo di ambiente per trasformare gli errori in preziose opportunità di formazione. È importante riconoscere correttamente il valore di entrambi gli elementi: la palestra mette alla prova gli agenti; la pipeline moltiplica le attività di apprendimento a partire dalle lacune diagnosticate.

Non ci sono pasti gratis nemmeno per quanto riguarda il tempo di calcolo e il tempo di calendario all'interno della sandbox. La sintesi ibrida è stata completata nell'ordine di ore per circa duemila campioni; ITSM ha richiesto più tempo con un insegnante più pesante e una forma della pipeline precedente. I team dovrebbero prevedere un budget per l'inferenza dell'insegnante, i tentativi in ​​fase di critica o riparazione e la rivalutazione dopo ogni fase del curriculum.

Riflessioni sul curriculum per i team di agenti aziendali

L'idea fondamentale di AutoSynthData è di natura curriculare piuttosto che puramente generativa. Gli errori vengono diagnosticati. Le schede astraggono. La generazione moltiplica. Il controllo qualità convalida. SFT aggiorna l'obiettivo. La rivalutazione sposta la frontiera. Questa sequenza considera il miglioramento dell'agente come una serie di lezioni basate sull'ambiente, anziché come un singolo dump offline di tracce.

Un approccio più orientato al curriculum cambia il modo in cui i leader allocano gli sforzi. Invece di chiedere solo più ticket o più annotazioni umane, è opportuno chiedersi quali capacità continuano a fallire in presenza di variazioni, se tali capacità presentano proprietà di stato finale chiare e se un insegnante più competente può dimostrarle in modo affidabile. Se l'insegnante non riesce a ottenere risultati con sufficiente frequenza, l'SFT sintetico insegnerà comportamenti inaffidabili. Se le proprietà dello stato finale sono ambigue, i verificatori contesteranno le strategie valide.

Cambia anche il modo in cui si parla di successo. Ridurre parzialmente il divario di Pass@1 rispetto a un modello di riferimento su Hybrid, o portare ITSM Pass@1 da percentuali intorno al 15% a percentuali intorno al 25% nelle analisi riportate dagli autori, rappresenta un progresso nella competenza misurata dell'ambiente. Non è la prova che ogni flusso di lavoro, ogni policy o ogni caso di rifiuto siano stati risolti. Mantenete il linguaggio della frontiera in continua evoluzione: i divari rimanenti diventano la fase Target successiva, non una diapositiva da aggiungere in un secondo momento.

Nella progettazione dei programmi, è opportuno affiancare a questo ciclo la revisione umana laddove la posta in gioco è alta (politiche di sicurezza, azioni irreversibili, dati regolamentati), lasciando che i controlli automatizzati gestiscano il volume in base a verifiche di stato ben definite. I dati sintetici funzionano al meglio quando l'ambiente può rispondere sì o no con una chiarezza simile a quella di SQL. Hanno difficoltà quando il successo è una questione di gusto soggettivo.

Note di progettazione su difficoltà, realismo e rifiuto

La definizione del livello di difficoltà merita una seconda valutazione. Privilegiare compiti che l'utente risolve al massimo un terzo delle volte evita che la formazione si riduca a semplici attività di routine. Richiedere che l'insegnante abbia successo almeno due terzi delle volte evita che le dimostrazioni si basino sul caso. Questo intervallo rappresenta un compromesso pratico tra sfida e facilità di apprendimento.

Il realismo rimane un criterio meno rigido, ma comunque essenziale. Gli utenti aziendali richiedono soluzioni adatte ai loro ruoli e sistemi. I generatori guidati unicamente dalla difficoltà possono inventare complessi puzzle con vincoli multipli che nessun operatore richiederebbe mai. Le schede delle capacità che elencano le dimensioni variabili sono utili, ma è comunque necessario l'intervento umano o di un meta-revisore per individuare le richieste irrealistiche.

I test di rifiuto e di non fattibilità, presenti nella progettazione più ampia di EnterpriseOps Gym, ricordano ai team che la competenza include anche la capacità di dire di no. Una pipeline ottimizzata solo per le attività completabili può non fornire una formazione adeguata in materia di rifiuto. Quando si estendono i cicli in stile AutoSynthData, è opportuno includere schede in cui la proprietà finale corretta sia un rifiuto sicuro in base alle policy, e non solo una mutazione riuscita dello stato del database.

Le traiettorie di stato a lungo termine sollevano un'ulteriore questione di progettazione. Le dimostrazioni per gli insegnanti devono rimanere coerenti attraverso numerose chiamate di strumenti. I verificatori che controllano solo l'ultima riga della tabella potrebbero non rilevare violazioni intermedie delle policy. La completezza nella progettazione dei verificatori significa coprire le proprietà che definiscono realmente il successo di quella funzionalità, inclusi i vincoli che devono rimanere validi per tutta la durata del processo, non solo alla fine.

Riepilogo conclusivo

AutoSynthData, di ServiceNow CoreAI / ServiceNow-AI e descritto pubblicamente da Esakkivel Esakkiraja, è una pipeline che trasforma i fallimenti degli agenti target e i successi degli insegnanti in attività di training sintetiche validate per ambienti aziendali. Astrae i fallimenti in schede di specifiche di capacità ripulite, genera nuove attività senza divulgare i prompt o le traiettorie originali, raccoglie le dimostrazioni degli insegnanti e applica il controllo qualità a livello di campione e di batch prima della messa a punto supervisionata.

Il modello mentale pratico è il compito come specifica di sistema, richiesta all'utente e verificatore, con fattibilità, realismo e difficoltà tenuti in tensione, e con verificatori che non sono né troppo permissivi né vincolati a un unico percorso. Le fasi Target e Multiply, una regola senza ulteriore seed per i campioni moltiplicati, controller condiviso più adattatore ambientale e rivalutazione post-SFT creano una frontiera mobile sulle lacune rimanenti.

Su EnterpriseOps Gym, i risultati ibridi riportati dall'autore con Gemma-4-26B-A4B-it e Qwen3.8-27B mostrano circa duemila campioni in circa diciotto ore e significativi miglioramenti di Pass@1 e successo del verificatore, colmando una grande parte del divario rispetto a un modello di riferimento. ITSM con DeepSeek-V4.1-Flash come insegnante mostra un aumento di Pass@1 dal 18,77% al 27,18% su circa 1.994 campioni in un'esecuzione più lunga. Considerate questi dati come segnali di ricerca su domini specifici, dipendenti dall'insegnante, dal verificatore e dalla fedeltà dell'ambiente, e tenete l'apprendimento per rinforzo come un'estensione pianificata del ciclo, non come un'affermazione definitiva.

Se dovete ricordare una frase: gli operatori aziendali migliorano quando gli errori vengono astratti, moltiplicati e trasformati in lezioni verificate all'interno dei sistemi che devono gestire quotidianamente, non quando i team si limitano a riprodurre lo stesso problema.

Esempio pratico: espansione di casi ITSM complessi a partire da un set di errori predefinito in stile palestra

Scenario

Un team di una piattaforma aziendale britannica, ad esempio un gruppo operativo di medie dimensioni nel settore dei servizi finanziari che utilizza un sistema ITSM in stile ServiceNow con finestre di modifica, relazioni con CMDB e transizioni guidate da policy, ha un agente simile a quello di produzione che continua a inciampare nello stesso tipo di attività: aggiornamenti tra tabelle che devono rispettare un prerequisito di approvazione, ricerche di articoli della knowledge base che entrano in conflitto con i blocchi delle modifiche locali e richieste ibride che coinvolgono sia l'ITSM che strumenti operativi adiacenti.

Congelano una suite privata in stile EnterpriseOps Gym (sandbox containerizzata, controlli dei risultati SQL, tabelle precompilate, regole di policy) in modo che i punteggi siano comparabili di settimana in settimana. Le esecuzioni diagnostiche mostrano che l'agente target fallisce laddove un insegnante più forte ha successo. La dirigenza desidera più segnali di addestramento senza riprodurre gli stessi numeri di ticket e ID di entità. AutoSynthData (o un ciclo equivalente di sintesi dai fallimenti se la pipeline di ricerca è bloccata nel loro stack) è il candidato: trasformare i fallimenti di contrasto in schede di specifiche di capacità sanificate, generare nuove attività, raccogliere demo dell'insegnante e quindi - cosa fondamentale - revisionare umanamente le tracce sintetiche prima di qualsiasi riaddestramento.

Nessun prodotto viene spedito singolarmente con Gym Pass@1. I dati di sintesi sono trattati come materiale didattico candidato, non come verità assoluta.

Di cosa ha bisogno l'assistente

  • Accesso all'adattatore per l'ambiente Gym congelato: strumenti, stato iniziale, policy e verificatori SQL (o equivalenti basati sullo stato).
  • Registri di valutazione appaiati: fallimenti del target a confronto con successi dell'insegnante negli stessi compiti.
  • Uno schema a schede che cattura capacità, forma degli strumenti/flussi di lavoro, contrasto tra successo e fallimento, proprietà richieste dello stato finale e dimensioni di variazione consentite, senza prompt originali, entità, traiettorie o dettagli interni del verificatore.
  • Regole di verifica dei dati personali e delle policy (ID ticket, nomi utente, nomi CI, campi regolamentati) prima che qualsiasi elemento esca dalla sandbox o entri in un prompt del generatore.
  • Una coda di revisione umana per compiti sintetici campionati e tracce degli insegnanti (fattibilità, realismo, correttezza del verificatore, casi di rifiuto/non fattibilità).
  • Condizioni di arresto chiare: fasi Target e Multiply; i campioni moltiplicati non vengono utilizzati come seme per ulteriori cicli di moltiplicazione.

Esempio di istruzione

Porta di accesso alla piattaforma per l'operatore del curriculum (o per un assistente di orchestrazione che si occupa solo di redigere schede e pacchetti di revisione - non si occupa di riqualificazione o promozione dei modelli):

"Eseguire la diagnostica Pass@1 sulle sezioni ITSM e Hybrid congelate rispetto al nostro target attuale e all'insegnante designato. Per ogni contrasto in cui il target fallisce e l'insegnante ha successo almeno due delle tre prove, redigere una scheda di specifica della capacità sanificata: nominare la capacità, elencare gli strumenti pertinenti, indicare le proprietà dello stato finale richieste ed elencare le dimensioni controllabili (fascia di priorità, classe CI correlata, flag finestra di modifica, tipo di conflitto di conoscenza). Rimuovere i numeri di ticket, gli identificatori utente, i nomi CI e le traiettorie grezze. Generare un batch di nuove attività della fase Target solo da queste schede. Far dimostrare i successi all'insegnante. Applicare la fascia di difficoltà (target ≤1/3, insegnante ≥2/3), la verifica positiva e negativa e la critica/riparazione limitata. Produrre un pacchetto di revisione del 5% di campioni stratificati più ogni scheda di rifiuto/non fattibilità. Non iniziare SFT finché due revisori non firmano il pacchetto e i controlli di pulizia PII non vengono superati. Dopo SFT su un checkpoint candidato, rivalutare sulla suite congelata e su un set di corrispondenza esatta di test che non abbiamo mai usato per generazione. Rapporto sulla copertura per classe di guasto e tasso di regressione rispetto al checkpoint di produzione precedente. Non promuovere solo in base al punteggio Gym."

Come testarlo

  1. Blocco di base: registrare i tassi di successo di Pass@1 e di verifica sulla suite congelata per classe di errore (ordinamento dei prerequisiti, rifiuto della finestra di modifica, ibrido cross-tool, conflitto di conoscenze). Mantenere la suite e i seed immutabili per il ciclo.
  2. Verifica delle schede: eseguire un controllo a campione per assicurarsi che i generatori non ricevano mai prompt originali, entità o tracce dell'insegnante, ma solo schede.
  3. Controllo qualità di esempio: Confermare che le traiettorie positive superino i verificatori e che i risultati errati mutati falliscano. Rifiutare i compiti che sono banali per il target o che richiedono un lancio di moneta per l'insegnante.
  4. Revisione umana: i revisori classificano ciascun campione come da conservare/correggere/eliminare in base a fattibilità, realismo e sicurezza delle politiche. Monitorano la concordanza tra i revisori su un sottoinsieme condiviso.
  5. Corrispondenza esatta del set di test: dopo il test SFT del candidato, valuta un set di test di compiti reali (o precedentemente congelati) che non sono mai stati utilizzati come input per la creazione delle schede o la generazione. Valuta separatamente le parafrasi approssimative dei compiti di training per rilevare la memorizzazione superficiale.
  6. Blocco di regressione: qualsiasi classe di errore che peggiori rispetto al checkpoint di produzione precedente blocca la promozione fino a quando non viene spiegata o risolta.

Risultato

Non inventate qui le percentuali di cottura. Utilizzate un piano di misurazione e indicate i dati di ricerca pubblicati come "AFFERMAZIONE DELL'ARTICOLO" quando li citate.

Piano di misurazione (cosa questo team dovrebbe riportare):

  • Copertura delle classi di errore: quota delle classi di lacune diagnosticate che hanno prodotto ≥N attività accettate nella fase target dopo il controllo qualità (definire N in anticipo, ad esempio 20 attività accettate per classe).
  • Corrispondenza esatta del set di test: Pass@1 / successo del verificatore sul set di test non modificato prima vs dopo l'SFT del candidato (stessi seed, stesso verificatore).
  • Tasso di regressione: conteggio delle classi di errore in cui Pass@1 non supera il checkpoint di produzione precedente; blocco se si verifica una regressione in una qualsiasi classe critica per la sicurezza.
  • Rendimento della revisione: mantenere/riparare/abbassare i tassi sul pacchetto di revisione umana; se il tasso di abbandono aumenta vertiginosamente, mettere in pausa Moltiplica e correggere le carte o i verificatori.
  • Errori di pulizia: numero di campioni che non superano i controlli PII/politiche prima della firma della revisione (obiettivo: zero fughe nel set SFT).

AFFERMAZIONE DELL'ARTICOLO (riportata dall'autore su EnterpriseOps Gym - non un risultato misurato da questo team): Le esecuzioni ibride con Gemma-4-26B-A4B-it come target e Qwen3.8-27B come teacher hanno prodotto circa 2.000 campioni in circa 18 ore, con una media di Pass@1 aumentata di circa 7,2 punti percentuali e un successo del verificatore passato dal 63,01% al 68,55%. ITSM con DeepSeek-V4.1-Flash come teacher ha portato la media di Pass@1 dal 18,77% al 27,18% su circa 1.994 campioni in un'esecuzione più lunga (~66 ore). Considerate questi dati come segnali di ricerca su domini e combinazioni specifici, non come una garanzia universale per uno stack di produzione nel Regno Unito.

Esempio di programma (basato su ipotesi, non su guadagni misurati): se il team accetta circa 2.000 campioni sottoposti a controllo qualità per un ciclo ITSM, prevede un budget per l'inferenza degli insegnanti e la revisione con un campionamento stratificato del 5%, e promuove solo quando il gruppo di controllo non registra regressioni nelle classi critiche per la sicurezza, il "risultato" che possono affermare con serietà è la maturità del processo: curriculum verificato, tracce ripulite e differenze comparabili tra le suite di test, non un aumento percentuale promesso.

Cosa può andare storto?

  • Trattare i dati sintetizzati come verità assoluta: saltare la revisione umana o la verifica negativa permette ai verificatori permissivi di ammettere spazzatura su larga scala.
  • Perdita di entità: Inserire nel generatore gli ID dei biglietti originali o le tracce degli insegnanti può causare un overfitting della parafrasi; le carte esistono proprio per evitarlo.
  • Moltiplicazione illimitata: consentire ai campioni moltiplicati di innescare ulteriori round si discosta dalla capacità denominata.
  • Spedizione punteggio palestra: Promozione perché il Pass@1 della suite congelata è aumentato mentre il traffico ombra di produzione o di attesa è peggiorato.
  • Limite di successo basso per l'insegnante: se l'insegnante non riesce a superare la soglia di successo di ≥2/3, SFT utilizza dimostrazioni inaffidabili.
  • Verificatori fuzzy: le rubriche di chat, anziché i controlli basati sullo stato, valutano come successo gli esami finali errati ma fluidi.
  • Rifiuto di sottoaddestramento: ottimizzare solo per le mutazioni completabili rende fragili i decrementi della finestra di cambiamento e della politica.
  • Fuga PII: Richieste sintetiche che reintroducono i veri nomi di CI o utenti dopo una pulizia superficiale.

Da portare via in modo pratico

Utilizza cicli in stile AutoSynthData - o un modello equivalente di sintesi da errori se la pipeline ServiceNow CoreAI non è disponibile nel tuo tenant - per moltiplicare casi ITSM concreti e verificabili a partire dalle lacune diagnosticate. Sanifica i dati in schede di capacità, applica criteri di difficoltà e verifica positiva/negativa, elimina i dati personali e sottoponi i campioni a revisione umana prima di SFT. Misura la copertura delle classi di errore, la corrispondenza esatta del set di test e il tasso di regressione. Cita i dati di Gym solo come contesto di ricerca esterno. I dati di sintesi sono materiale didattico, non una garanzia: verifica i campioni, mantieni la suite bloccata per un confronto equo e non basare mai le tue decisioni solo sul punteggio di Gym.

Domande frequenti

Cos'è AutoSynthData e quale problema si propone di risolvere?

AutoSynthData è una pipeline ServiceNow CoreAI / ServiceNow-AI, descritta da Esakkivel Esakkiraja, che combina gli errori di un agente target con i successi di un agente più esperto in attività di training sintetiche validate per ambienti aziendali. Si concentra sulle competenze specifiche dell'ambiente (politiche locali, schemi, strumenti e stato) piuttosto che su una conoscenza generale. L'obiettivo è moltiplicare il lavoro rigoroso e verificabile in modo che la messa a punto supervisionata possa colmare le lacune specifiche dell'ambiente, invece di ripetere lo stesso errore.

Perché la competenza ambientale è diversa dalla capacità di modellazione generale?

Gli agenti aziendali spesso incontrano difficoltà a causa delle peculiarità dell'ambiente stesso: policy dei ticket, anomalie dello schema, contratti degli strumenti, database preconfigurati e flussi di lavoro tra sistemi diversi. Un modello che appare robusto nei benchmark aperti può comunque bloccarsi in corrispondenza di una finestra di modifica, di una relazione con il CMDB o di un verificatore che ispeziona lo stato finale. Una capacità ampia non equivale alla conoscenza del comportamento di sistemi, regole e stato dei dati durante le transizioni governate da policy.

Qual è la forma pratica del compito utilizzata da AutoSynthData?

Una configurazione funzionale è data da un'attività composta da specifiche di sistema, richieste all'utente e verificatori. Le specifiche di sistema includono vincoli, politiche e stato iniziale, come i valori iniziali del database e gli articoli di conoscenza. Le richieste all'utente vengono valutate in base a fattibilità, realismo e difficoltà. Idealmente, i verificatori si basano su controlli di risultato basati su SQL o sullo stato, in modo da valutare il mondo dopo l'azione dell'agente, non solo il percorso esatto seguito dal token.

In che modo le schede di specifica delle capacità, opportunamente sanificate, prevengono l'overfitting?

Le sessioni diagnostiche mettono a confronto i casi in cui il target fallisce e l'insegnante ha successo, quindi sintetizzano tali casi in schede di specifiche di capacità ripulite. Una scheda registra la capacità, gli strumenti o la struttura del flusso di lavoro, il contrasto tra fallimento e successo, le proprietà dello stato finale richieste e le dimensioni che possono variare. Il generatore non vede mai i prompt originali, le entità, le traiettorie o i dettagli del verificatore, ma solo le schede, quindi i nuovi compiti si concentrano sul nucleo centrale senza parafrasare un episodio memorizzato.

Quali sono le fasi Target e Multiply nella pipeline?

La fase target si concentra su campioni chiave selezionati intorno alle lacune, ovvero i compiti con il segnale più forte in prossimità del punto in cui l'agente debole si guasta. La fase di moltiplicazione genera nuove varianti degli obiettivi accettati. I campioni moltiplicati non possono innescare ulteriori cicli di moltiplicazione, il che mantiene sotto controllo la deriva dalla capacità denominata. Dopo la messa a punto supervisionata, la rivalutazione sposta il curriculum verso le lacune rimanenti, considerandole come una frontiera in movimento piuttosto che come un deposito statico.

In che modo il controllo di qualità a livello di campione garantisce l'affidabilità dei compiti di sintesi?

Un filtro di difficoltà per il risolutore privilegia i compiti che il target risolve in al massimo in uno su tre tentativi, mentre l'insegnante riesce in almeno due su tre. La verifica positiva richiede una traiettoria di riferimento per essere superata; la verifica negativa richiede risultati errati mutati per fallire. Un ciclo di critica e riparazione con un limite di tentativi cerca di correggere i quasi-errori, e una meta-revisione a livello di batch controlla la copertura, la diversità, la ridondanza e i target fallimentari nell'intero set.

Quale architettura utilizza AutoSynthData nei diversi domini aziendali?

Abbina un controller condiviso a un adattatore di ambiente. Il controller gestisce la diagnosi, la creazione delle schede, la generazione, le dimostrazioni per gli insegnanti, i controlli di qualità e la revisione in batch. L'adattatore collega questi passaggi a un ambiente di test concreto (strumenti, stato, politiche e verificatori) in modo che lo stesso ciclo di controllo possa essere applicato a diversi ambiti senza dover riscrivere da zero la logica del curriculum.

Che ruolo riveste EnterpriseOps Gym in questo contesto di ricerca?

EnterpriseOps Gym è la piattaforma di test di stress su larga scala per agenti aziendali, con circa 1.150 attività curate da esperti in 8 domini, circa 512 strumenti, circa 164 tabelle di database, esecuzione in container, verifica dei risultati basata su SQL, operazioni governate da policy, scenari ibridi e traiettorie stateful a lungo termine. AutoSynthData non si propone di inventare questa palestra; la palestra mostra il ciclo di sintesi in azione.

Quali risultati, secondo quanto riportato dagli autori, emergono per le configurazioni ibride e ITSM?

Su EnterpriseOps Gym, le esecuzioni ibride con Gemma-4-26B-A4B-it come target e Qwen3.8-27B come teacher hanno prodotto circa 2.000 campioni in circa 18 ore, con una media di Pass@1 aumentata di circa 7,2 punti percentuali e un tasso di successo del verificatore passato dal 63,01% al 68,55%. ITSM con DeepSeek-V4.1-Flash come teacher ha portato la media di Pass@1 dal 18,77% al 27,18% su circa 1.994 campioni in un'esecuzione più lunga. Considerate questi risultati come segnali di ricerca su combinazioni specifiche, non come una garanzia di produzione universale.

Quali errori dovrebbero evitare i team quando utilizzano cicli di sintesi a partire da errori?

Non trattare i dati sintetici come verità assoluta né saltare la revisione umana e la verifica negativa. Evita di inserire ID di ticket originali o tracce degli insegnanti nel generatore, di utilizzare campioni moltiplicati per alimentare ulteriori round o di promuovere Gym Pass@1 da solo mentre il traffico di utenti non qualificati o di utenti non qualificati peggiora. Presta inoltre attenzione agli insegnanti con prestazioni insufficienti al di sotto della soglia di successo, alle rubriche di chat imprecise invece che ai controlli di stato, ai casi di rifiuto dovuti a formazione inadeguata e alla fuga di dati personali dopo una pulizia superficiale.

Riferimenti

  1. Faccia che abbraccia — AutoSynthData — huggingface.co
  2. EnterpriseOps Gym — enterpriseops-gym.github.io
  3. arXiv — arxiv.org
  4. GitHub — EnterpriseOps-Gym — github.com
Quiz
1. Qual è il problema principale a cui mira AutoSynthData di ServiceNow CoreAI?

2. Perché AutoSynthData sintetizza gli errori in schede di specifiche di capacità ripulite?

3. Quale fascia di difficoltà predilige il filtro di risoluzione descritto per le attività di addestramento?

4. Come è strutturato il ciclo di controllo di AutoSynthData nei diversi ambienti?

5. Su EnterpriseOps Gym Hybrid, quale modifica di Pass@1 segnalata dall'autore è citata per il target Gemma-4-26B-A4B-it?


Torna al blog