Dati sintetici per LLM: come generarli e validarli

Documentazione dei fornitori e condizioni d'uso degli output verificate il 22 ottobre 2026. Gli esempi di ticket di assistenza e le dimensioni del progetto pilota riportati di seguito sono stati ideati per illustrare il procedimento: non sono i risultati di un esperimento su un modello.

Che cosa sono i dati sintetici e come si generano?

Generare dati sintetici significa creare record o esempi artificiali per uno scopo preciso. Per chi sviluppa con un modello linguistico di grandi dimensioni, o LLM, si tratta di solito di produrre testi — richieste di assistenza, coppie domanda-risposta, esempi di estrazione o conversazioni — partendo da una specifica e da un piccolo insieme di esempi approvati.

Il paragone è quello con un simulatore di guida. Permette di esercitarsi più volte su un incrocio difficile, senza aspettare di incontrare la stessa situazione su strada. Superare la prova al simulatore, però, non dice quanto spesso quell'incrocio ricorra nel traffico, né dimostra di saper affrontare qualsiasi strada. I dataset sintetici offrono la stessa utile distinzione tra copertura delle esercitazioni e riscontri sul mondo reale.

Il metodo conta. Un generatore basato su regole segue istruzioni come mantenere il totale di un ordine uguale alla somma delle sue voci. Un sintetizzatore di dati tabellari apprende le regolarità tra le colonne. Un LLM genera linguaggio in funzione del prompt e del contesto fornito. I metodi si possono combinare: il codice crea un ordine valido e l'LLM scrive il reclamo del cliente relativo a quell'ordine.

I dati sintetici sono anche diversi dai record mascherati. Sostituire il nome di un cliente lascia intatto il resto della sua storia. L'aumento dei dati, o data augmentation, modifica un esempio esistente, per esempio parafrasando una domanda; le varianti restano legate alla fonte. Nessuna delle due operazioni rende automaticamente un record rispettoso della privacy o produce prove indipendenti.

Valutazioni: creare prove con risposte verificate in modo indipendente

Per chi sviluppa un'applicazione, le valutazioni sintetiche sono particolarmente utili per verificare modalità di errore note: informazioni mancanti, istruzioni in conflitto, richieste non supportate e formulazioni insolite. Una valutazione, o eval, è un test ripetibile del comportamento del sistema.

Se un assistente per il supporto deve chiedere chiarimenti quando un problema con l'account è ambiguo, conviene generare appositamente richieste ambigue. Una persona deve poi verificare che l'azione attesa rispetti le regole. La risposta del generatore non deve diventare la soluzione di riferimento solo perché è formulata con sicurezza.

Quando possibile, conservare un insieme di valutazione separato, ricavato da interazioni reali che si è autorizzati a usare. Se non si possono usare interazioni reali, affidare a una persona competente sul compito la stesura indipendente dei casi. Questo permette di verificare la specifica, ma non di stabilire l'accuratezza sull'intera popolazione servita in produzione.

Fine-tuning: insegnare un comportamento preciso

Per chi adatta un modello, gli esempi sintetici possono mostrare un formato, una regola di classificazione o uno stile di risposta poco rappresentati nei dati disponibili. Il fine-tuning consiste nell'aggiornare un modello addestrandolo su esempi.

Si parte da un errore osservabile: il modello continua a indirizzare i ticket ambigui alla fatturazione. Si aggiungono casi ambigui revisionati e si confronta il modello adattato con quello di riferimento su esempi mai usati nello sviluppo. Un file di addestramento più grande non è, di per sé, una misura del successo.

Il percorso di fine-tuning è indicato quando il compito e l'insieme di accettazione sono stabili. Se il problema è la mancanza di informazioni fattuali o il loro continuo cambiamento, occorre prima correggere il contesto fornito all'applicazione, invece di provare a insegnare quei fatti attraverso risposte generate.

Generare dati sintetici per i test software

Per chi sviluppa software, la generazione di dati sintetici di test deve mettere alla prova le regole dell'applicazione: campi mancanti, invii duplicati, testi di lunghezza insolita, transizioni di stato non valide e record correlati nel database.

Un test del processo di acquisto richiede relazioni valide tra ordini, clienti e pagamenti. Non serve un modello linguistico che inventi i calcoli. Questi vincoli vanno implementati nel codice; l'LLM va usato dove un linguaggio realistico aggiunge valore, per esempio in una nota di consegna che contraddice l'indirizzo di spedizione.

Chi acquista un dataset dovrebbe chiedere a quale di queste attività sia destinato. Un dataset adatto a una demo non è necessariamente utile per l'addestramento, e un corpus di addestramento non è automaticamente un insieme di valutazione.

Un esempio pratico: dai casi iniziali ai candidati revisionati

Si comincia con un compito circoscritto, per il quale si possano spiegare le risposte corrette senza consultare il generatore. Questo procedimento crea esempi candidati per assegnare ticket di assistenza fittizi alle categorie billing, access o human_review.

La regola dell'esempio è semplice: i problemi di pagamento e fatturazione vanno alla fatturazione; quelli di accesso e password vanno alla gestione degli accessi; le richieste poco chiare o che combinano entrambi gli ambiti richiedono una revisione umana. Non si devono dedurre fatti che il cliente non ha fornito.

Esempi di dati sintetici: sei casi iniziali con etichette esplicite

Questi casi, scritti appositamente, mostrano il confine tra le categorie:

• «Mi hanno addebitato due volte l'importo sulla carta.» → billing
• «Questa fattura riporta il piano sbagliato.» → billing
• «Il link per reimpostare la password è scaduto.» → access
• «Non riesco ad accedere dopo aver reimpostato la password.» → access
• «Ho pagato, ma non riesco ad accedere.» → human_review
• «Continua a non funzionare.» → human_review

Gli ultimi esempi contano quanto quelli più ovvi. Insegnano al generatore che anche l'incertezza è un esito valido. La guida al few-shot prompting spiega come gli esempi comunichino regole che un'istruzione generale può lasciare poco chiare.

Un candidato ripulito potrebbe avere questo aspetto. È un record illustrativo, non un output acquisito da un'API:

{
  "case_id": "billing-frustrated-indirect-a",
  "text": "Another invoice with the wrong plan, seriously?",
  "proposed_label": "billing",
  "policy_reason": "The customer identifies an invoice problem."
}

Il risultato che conta è un caso tracciabile e revisionato. Che il generatore abbia restituito fin dall'inizio tutti i candidati richiesti è secondario. Non riempire mai una cella debole soltanto per raggiungere il numero previsto.

Strumenti per generare dati sintetici: cosa dichiara la documentazione

Gli strumenti vanno scelti in base alla parte del processo che gestiscono. L'API di un modello è l'interfaccia con cui il codice ne richiede gli output; il servizio batch ne programma l'esecuzione. Una libreria per dataset organizza generazione e feedback. Un sintetizzatore tabellare apprende le relazioni nei dati strutturati. Nessuna di queste funzioni sostituisce i criteri di accettazione.

IA generativa e dati sintetici: le API batch

OpenAI API offre Batch per richieste asincrone inviate in un file JSONL, cioè con un oggetto JSON per riga. La documentazione richiede un custom_id univoco e avverte che l'ordine degli output può differire da quello degli input. Associare i risultati tramite l'identificativo, quindi controllare errori e generazioni incomplete prima di analizzare i candidati. Documentazione di OpenAI Batch.

Claude API di Anthropic offre Message Batches per richieste Messages indipendenti. I risultati distinguono le richieste riuscite, con errore, annullate e scadute; custom_id collega ciascun risultato al relativo input. Il limite da considerare è operativo: l'accettazione di un batch non prova che ogni esempio sia stato completato. Riprovare il lavoro mancante usando gli identificativi, invece di rigenerare l'intero dataset. Documentazione dei batch di Claude.

Gemini API di Google offre Batch con oggetti di richiesta inseriti direttamente oppure con un file JSONL caricato. Le richieste basate su file includono una key che identifica il risultato corrispondente. Per dataset offline più grandi, usare l'invio tramite file; il tempo di elaborazione documentato è un obiettivo, quindi evitare che un flusso interattivo dipenda dal completamento immediato. Documentazione di Gemini Batch.

Questi sono i limiti dei batch che incidono sulla suddivisione del lavoro, verificati nella documentazione collegata. Non limitano la dimensione totale del dataset costruibile con più esecuzioni.

Una richiesta batch e un esempio candidato sono unità diverse. Se ogni richiesta riuscita restituisce più candidati, tenere traccia di entrambi i conteggi. Registrare errori di parsing, rifiuti e output troncati insieme agli errori di trasporto. Una risposta HTTP riuscita, da sola, non produce una riga utilizzabile per l'addestramento.

Distilabel: organizzare generazione e feedback

Distilabel è un framework per dati sintetici e feedback dell'IA che combina in pipeline le fasi di generazione, valutazione e gestione dei dati. La documentazione descrive impieghi per classificazione, estrazione, dialogo e generazione di istruzioni. È utile quando uno script nato per un singolo uso si è trasformato in un processo con più fasi di generazione e filtraggio. Documentazione di Distilabel.

Il progetto usa la licenza Apache-2.0. Il repository segnala anche che gli autori originali sono passati ad altro e che la manutenzione è affidata a collaboratori della comunità. Fissare e validare la versione adottata. Il limite pratico resta il valutatore: organizzare il giudizio di un modello non lo rende indipendente o corretto. Repository di Distilabel.

Faker: creare fixture senza un modello linguistico

Faker è un pacchetto Python che genera dati fittizi tramite provider, con supporto per le impostazioni locali e per il seed del generatore casuale. È utile per creare fixture applicative quando servono campi controllati anziché ragionamento in linguaggio naturale. Il repository indica la licenza MIT. Documentazione di Faker, repository di Faker.

Le relazioni di business vanno comunque codificate a parte. Indirizzi, date e transazioni generati indipendentemente non costituiscono una cronologia realistica del cliente. Usare, quando possibile, identificativi e domini riservati ai test e impedire che le fixture generate attivino messaggi o altre azioni in produzione.

Synthetic Data Vault: modellare tabelle e relazioni

Synthetic Data Vault, o SDV, offre sintesi tabellare e valutazione statistica, con approcci documentati per tabelle singole, dati sequenziali e tabelle correlate. I sintetizzatori vengono addestrati sui dati forniti; questo non elimina la necessità di un dataset sorgente che si è autorizzati a usare. Documentazione di SDV.

In SDV, GaussianCopulaSynthesizer usa metodi statistici classici per apprendere distribuzioni e relazioni tra le colonne. CTGANSynthesizer usa una rete generativa avversaria, un modello addestrato attraverso un generatore e un discriminatore in competizione. Entrambi ricevono dati e metadati che ne descrivono la struttura. Sono sintetizzatori tabellari, non modelli di chat generalisti. Documentazione di Gaussian Copula, documentazione di CTGAN.

Il limite da verificare è la fedeltà rispetto al compito. Distribuzioni delle colonne apparentemente simili non dimostrano che siano preservate combinazioni rare, regole tra tabelle o comportamento di un modello a valle. Validare le relazioni su cui si basa l'applicazione, comprese le chiavi esterne che collegano i record figli ai record genitori.

Scegliere il generatore in base a ciò che manca

Usare l'API di un modello quando manca la varietà linguistica. Aggiungere Distilabel quando un'orchestrazione ripetibile di generazione e feedback giustifica la dipendenza aggiuntiva. Scegliere Faker quando le fixture richiedono valori controllati. Considerare SDV quando contano le relazioni statistiche tra tabelle e si dispone di dati sorgente che si è autorizzati a modellare.

Non acquistare un generatore più grande per risolvere regole di etichettatura poco chiare. Quel problema viene prima di tutti gli strumenti descritti qui.

Cosa prevedono le condizioni dei fornitori sull'addestramento con gli output

Prima di scegliere un modello insegnante, cioè quello che genera gli esempi da cui un altro modello apprenderà, verificare le restrizioni sull'uso degli output. Le righe seguenti riassumono le condizioni standard dei tre fornitori di LLM ospitati citati sopra; non stabiliscono che uno specifico progetto di addestramento sia ammissibile.

• OpenAI: il Services Agreement limita l'uso degli output per sviluppare modelli di IA concorrenti. Prevede eccezioni esplicite per i modelli destinati principalmente a categorizzare, classificare o organizzare dati, purché non siano distribuiti o resi disponibili commercialmente a terzi, e per la personalizzazione di modelli tramite i servizi specificati da OpenAI. Contratto di servizio.
• Anthropic: le Commercial Terms vietano di accedere ai servizi per costruire prodotti o servizi concorrenti, compreso l'addestramento di modelli di IA concorrenti, salvo espressa approvazione di Anthropic. Condizioni commerciali.
• Google: le condizioni aggiuntive di Gemini API vietano di usare i servizi per sviluppare modelli concorrenti; le disposizioni su Google Search Grounding vietano separatamente l'addestramento su Grounded Results o Search Suggestions. Condizioni di Gemini API.

La licenza software di una libreria è una questione distinta dalle condizioni del modello che richiama, dalla licenza degli eventuali pesi del modello e dai diritti sugli esempi sorgente. La sola titolarità degli output non risolve tutte queste questioni.

Dati di test e privacy: serve una verifica dedicata

L'origine sintetica non garantisce la privacy. Se si copiano record riservati in un servizio di generazione non approvato, produrre poi sostituti dall'aspetto fittizio non annulla quella divulgazione.

La ricerca di Stadler, Oprisanu e Troncoso sulla pubblicazione di dati sintetici ha rilevato che i vantaggi per la privacy e l'utilità variavano tra i modelli valutati. La lezione pratica è valutare sia i dati rilasciati sia il processo di generazione, senza trattare la parola «sintetico» come un certificato di anonimato. Articolo di ricerca USENIX.

Quando basta per i test software, preferire esempi iniziali fittizi scritti a partire da uno schema e da regole approvati. Quando è necessario preservare regolarità statistiche reali, gestire le fonti in un ambiente approvato e valutare quali informazioni possa rivelare il dataset generato.

Controllare identificativi diretti, passaggi copiati, combinazioni rare e collegamenti con informazioni che qualcuno potrebbe già conoscere. Sostituire un nome conservando un episodio distintivo, il luogo e la data può lasciare riconoscibile la persona coinvolta. Per i rilasci sensibili, pochi controlli manuali a campione e una scansione dei duplicati non bastano: la valutazione della privacy deve essere adeguata alla minaccia e ai destinatari previsti.

Le politiche dei fornitori sull'addestramento rispondono a una domanda diversa da quella sul diritto dell'utente ad addestrare modelli con gli output. Per esempio, le condizioni dei servizi gratuiti di Gemini avvertono di non inviare informazioni sensibili, mentre quelle sull'uso dei dati per i servizi a pagamento dichiarano che prompt e risposte non vengono usati per migliorare i prodotti Google. Le condizioni estendono le regole sull'uso dei dati dei servizi a pagamento anche all'uso gratuito nel SEE, in Svizzera e nel Regno Unito. Condizioni Gemini sull'uso dei dati.

Né l'impegno del fornitore a non usare i dati per l'addestramento né l'esecuzione locale dimostrano che il dataset ottenuto sia sicuro da condividere. Mantenere associate al dataset le informazioni sulla provenienza e i controlli di accesso fino al completamento della revisione per il rilascio.

Quali promesse sui dati sintetici sono esagerate?

L'esagerazione principale è pensare che più righe generate risolvano la scarsità di riscontri. Possono ampliare l'esercitazione e far emergere errori, ma anche riprodurre su larga scala le stesse assunzioni.

Formulazioni diverse possono nascondere situazioni identiche

Un dataset può contenere frasi distinte e ripetere comunque un insieme molto ristretto di situazioni. Dopo il filtraggio, misurare la copertura degli scenari: quali regole di business, ambiguità e modalità di errore restano rappresentate?

Nell'esempio dei ticket, una serie di reclami sulle fatture non compensa l'assenza di richieste che combinano problemi di fatturazione e accesso. Revisionare gli esempi più vicini per similarità e controllare sia quelli scartati sia quelli accettati. Un filtro di qualità troppo severo può eliminare senza darlo a vedere proprio i casi difficili che si volevano aggiungere.

I bias possono sopravvivere alla riscrittura

Non presumere che parafrasare un esempio iniziale distorto ne elimini le assunzioni. Verificare le scelte di etichettatura al variare dello stile linguistico, del dialetto, della correttezza ortografica e degli eventuali gruppi di utenti rilevanti. Una richiesta frustrata o piena di errori non dovrebbe essere instradata diversamente, a meno che le regole non giustifichino la distinzione.

Chiedere ai revisori di confrontare coppie di casi in cui cambia soltanto un attributo irrilevante. Se cambiano le etichette, esaminare insieme esempio iniziale, prompt e filtro. Un generatore e un giudice possono rafforzare lo stesso errore.

Un modello che valuta i propri compiti può sembrare convincente

Zheng e colleghi hanno documentato nei giudici LLM bias di posizione, verbosità e preferenza per le proprie risposte. Un modello può premiare la formulazione o la presentazione anziché la proprietà che si intendeva misurare. Ricerca su LLM-as-a-judge.

Usare controlli deterministici ogni volta che la risposta è verificabile meccanicamente. Per i controlli soggettivi, calibrare il giudice sulle decisioni umane, nascondere quando possibile l'identità del generatore e revisionare i disaccordi. Cambiare il fornitore del giudice può ridurre una dipendenza condivisa; non garantisce che gli errori siano indipendenti.

La guida a LLM-as-a-judge spiega come verificare il valutatore prima di fidarsi del suo punteggio. Nella generazione sintetica, questa verifica deve precedere la decisione del giudice su quali esempi diventeranno riferimenti per l'addestramento.

Il collasso del modello è un rischio specifico, non una condanna universale

Shumailov e colleghi hanno studiato l'addestramento ricorsivo su dati generati e mostrato come possano scomparire le parti meno comuni della distribuzione originale. Questo invita alla cautela nel sostituire ripetutamente i riscontri delle fonti con dati derivati dal modello stesso. Non dimostra che ogni fine-tuning sintetico, revisionato e mirato a un compito, debba fallire. Articolo di ricerca su Nature.

Conservare i riscontri originali che si è autorizzati a usare, preservare intenzionalmente i casi rari e confrontare il comportamento a valle con un riferimento mantenuto intatto. Non esiste un rapporto universale tra dati sintetici e reali che possa sostituire questa valutazione.

Cosa cambiare nel lavoro di lunedì

Partire subito se si sa indicare un caso mancante, descriverne il comportamento corretto e revisionare i candidati generati rispetto a una regola stabile. Cominciare dalla piccola griglia di copertura, poi ampliare soltanto le celle che aggiungono casi utili.

Rimandare il fine-tuning se i revisori non concordano sulle etichette obiettivo o manca un insieme di accettazione indipendente. Risolvere prima il problema delle regole e della valutazione.

Usare fixture ordinarie se il compito consiste nel popolare un database, verificare valori limite o controllare l'integrità delle transazioni. Aggiungere linguaggio generato soltanto dove mette alla prova comportamenti che dati più semplici non riescono a sollecitare.

Prima del rilascio successivo, confrontare il sistema di riferimento e quello modificato sugli stessi casi mai usati nello sviluppo. Per il classificatore dei ticket, esaminare per categoria gli instradamenti errati e i mancati passaggi alla revisione umana. Conservare i dati sintetici soltanto se migliorano il comportamento desiderato senza regressioni inaccettabili altrove.

Domande frequenti sui dati sintetici

Iscriviti alla newsletter per guide pratiche su come costruire e valutare sistemi di IA.