Un nuovo benchmark di 12 API di modelli linguistici di grandi dimensioni (LLM) rivela che quasi ogni servizio restituisce un JSON conforme allo schema richiesto, ma una parte significativa restituisce valori fattualmente errati. Il costo in token dello stesso schema oscilla da poche decine a quasi cinquemila. Gli sviluppatori che costruiscono pipeline di estrazione o agenti basati sui dati non possono più considerare la "validità dello schema" come sinonimo di "correttezza".

Perché il test è importante

I fornitori di API hanno promosso l' "output strutturato" come un modo per eliminare gli errori di parsing. La promessa è semplice: fornisci al modello uno schema JSON e lui compilerà i campi senza che tu debba scrivere fragile codice di post-elaborazione. In pratica, molti sistemi di produzione si affidano già a questa garanzia per evitare crash e mantenere pulite le pipeline di analisi a valle. Quando la garanzia si rivela solo parzialmente vera, i bug si insinuano silenziosamente e i calcoli dei costi basati sull'uso dei token sballano completamente.

La buona notizia: gli schemi sono ormai quasi sempre applicati

  • La maggior parte dei modelli nella suite di test ha prodotto JSON che ha superato un validatore rigoroso.
  • Decodifica vincolata (Constrained decoding) – i modelli che bloccano il decoder sullo schema non possono emettere caratteri estranei, quindi i payload malformati sono praticamente estinti.
  • Tassi di errore di parsing – gli sviluppatori non devono più racchiudere ogni chiamata in blocchi try-catch per errori di sintassi JSON.

La cattiva notizia: validità ≠ accuratezza

Una struttura valida non garantisce un valore valido. Quattro dei dodici modelli — DeepSeek V4, Qwen e GLM-5.2 (questi ultimi due appaiono con due nomi diversi nel report) — hanno prodotto JSON perfettamente formattati che contenevano numeri errati quando la modalità "thinking" (o chain-of-thought) era attiva.

  • Sul modello Qwen, un'estrazione aritmetica semplice è passata da 1 risposta corretta su 16 con il ragionamento abilitato a 8 corrette su 8 quando il ragionamento era disabilitato.
  • DeepSeek V4 Pro ha mostrato un'oscillazione simile: l'accuratezza dell'estrazione è salita da 1/8 a 7/8 una volta che il modello ha smesso di cercare di spiegare i propri passaggi.

Il passaggio di ragionamento extra interferisce con il decoder vincolato, permettendo al modello di scivolare nell'allucinazione pur rispettando le parentesi esterne.

Il lato oscuro: sorprese sui costi dei token e parametri ignorati

  • Formato di risposta di Claude – quando viene accessato tramite endpoint compatibili con OpenAI, Claude ignora completamente il flag response_format, restituendo uno 0% di output conforme allo schema. Il modello supporta le chiamate strutturate, ma solo tramite l'interfaccia nativa di tool-call di Anthropic.
  • Inflazione dei token dello schema – uno schema modesto da 12 KB costa 30 token su DeepSeek, eppure lo stesso payload ha consumato 4.959 token su Claude.
  • Incoerenze di fatturazione – alcuni fornitori contano lo schema come parte del prompt, addebitando ogni token consumato; altri lo trattano come un overlay gratuito. Su larga scala, il costo dello schema può superare quello del contenuto generato dal modello.

Cosa dovrebbero fare gli sviluppatori ora

  1. Validare i valori, non solo le strutture – un validatore di schemi non rileverà una risposta numerica errata anche se rientra nel tipo previsto. Aggiungi controlli specifici per il dominio (intervallo, unità, coerenza tra i campi).
  2. Disattivare la chain-of-thought per l'estrazione su DeepSeek, Qwen e GLM quando è necessario un riempimento dei campi affidabile. Il passaggio di ragionamento extra è opzionale, non richiesto per la correttezza.
  3. Monitorare l'uso dei token – registra quanti token consuma ogni richiesta, inclusa la parte relativa allo schema, e confronta le fatture tra i diversi fornitori prima di impegnarti in implementazioni su larga scala.
  4. Testare la portabilità – uno schema che funziona su OpenAI potrebbe essere ignorato silenziosamente su Gemini o Claude. Esegui un rapido controllo di sanità su ogni piattaforma di destinazione prima di distribuire il codice.

La controargomentazione dei fornitori

Alcuni fornitori sostengono che la modalità "thinking" sia una scelta dello sviluppatore, destinata a compiti in cui la spiegazione è più importante dell'accuratezza dell'estrazione pura. Claude ignora il flag response_format e suggerisce invece di utilizzare le chiamate native di Anthropic. Queste spiegazioni sono tecnicamente corrette, ma spostano l'onere sugli sviluppatori, che devono sapere quale modalità scegliere e come prevedere i costi dei token nascosti.

In sintesi

Uno schema JSON non è più una rete di sicurezza; è solo una struttura. Assicurati che i dati all'interno corrispondano alla realtà, tieni d'occhio i costi nascosti dei token e ricorda che il "ragionamento" di un modello può corrompere anche l'output dall'aspetto più pulito.