Cos'è l'output strutturato di un LLM?

L'output strutturato è il vincolo di formato che impone a un modello linguistico di restituire una risposta conforme a uno schema JSON dichiarato in anticipo, non semplicemente richiesto nel prompt. La differenza è tecnica, non cosmetica: chiedere di rispondere in JSON nel testo del prompt lascia comunque al modello la libertà di sbagliare una virgola, omettere un campo obbligatorio o inventare un valore fuori dall'enum consentito; l'output strutturato, invece, vincola la decodifica a livello di runtime, filtrando token per token quali continuazioni sono ammesse dallo schema, cosicché il risultato è sintatticamente valido per costruzione, non per probabilità. Per chi deve integrare un LLM dentro un sistema software questo cambia la natura del problema: il campo di output diventa un contratto dati affidabile da cui un parser può leggere senza try/catch difensivi né logica di recupero per formati malformati. Non è però una garanzia di verità: uno schema rispettato non certifica che il contenuto sia corretto.

Come funziona

Il meccanismo tecnico prevalente è la decodifica vincolata (constrained decoding): lo schema JSON viene compilato in una grammatica formale e, a ogni passo di generazione, il modello può scegliere solo tra i token che restano coerenti con quella grammatica, escludendo a monte quelli che romperebbero la struttura. OpenAI ha introdotto questa garanzia nell'API con "Structured Outputs" nell'agosto 2024, dichiarando affidabilità del 100% sul rispetto dello schema per i modelli supportati. Anthropic ha portato la stessa garanzia su Claude Developer Platform in beta pubblica a dicembre 2025 (Sonnet 4.5 e Opus 4.1), passando a disponibilità generale con supporto esteso e senza header beta nei mesi successivi, includendo Haiku 4.5. In entrambi i casi lo schema può essere dichiarato come oggetto JSON diretto o come specifica di strumento (tool), e la garanzia riguarda la forma della risposta, non il suo contenuto.

Esempio enterprise

Un'azienda che estrae dati strutturati da migliaia di fatture o contratti scansionati passa da un parsing fragile, con regex e correzioni manuali per ogni variazione di formato di risposta del modello, a una pipeline dove il campo "importo", "data_scadenza" o "codice_fornitore" arriva sempre nel tipo e nella forma attesi dal sistema a valle (ERP, data warehouse, workflow di approvazione). Questo riduce drasticamente gli errori di integrazione, ma non elimina la necessità di validare che l'importo estratto sia effettivamente quello scritto sul documento: un JSON perfettamente valido può comunque contenere una cifra letta male o un fornitore identificato in modo errato.

Perché conta per chi decide

L'output strutturato riduce all'osso una classe intera di bug di integrazione, quelli dovuti a formati di risposta non prevedibili, e per questo è oggi la base tecnica su cui si costruisce l'affidabilità operativa di pipeline che collegano un LLM a sistemi esistenti. Ma resta un vincolo sintattico, non semantico: non sostituisce la validazione a valle del contenuto (regole di business, controlli di coerenza, evals sul risultato) né gli evals dedicati alla qualità delle risposte, e non impedisce le allucinazioni, riduce solo la superficie di errore dovuta al formato. Chi lo tratta come garanzia di correttezza, anziché di forma, rischia di spostare la fiducia mal riposta da "il modello scrive bene" a "il JSON è valido quindi è vero", un errore concettuale diverso ma della stessa gravità.