Bedrock ora impone lo schema JSON durante la generazione

Garanzia per tutti i modelli Claude su Bedrock, cache 24 ore e vincolo sugli schemi.

Chiunque abbia messo in produzione un modello linguistico conosce quel blocco di codice: un try/except attorno a json.loads, un retry con un prompt più insistente («rispondi SOLO in JSON valido»), un validatore a valle che scarta quello che non torna. È scaffolding difensivo, scritto perché il formato dell’output era, in fondo, una speranza statistica. La scorsa settimana AWS ha annunciato che Amazon Bedrock supporta gli structured outputs per tutti i modelli Anthropic Claude, sugli endpoint bedrock-runtime e bedrock-mantle, dove il modello è disponibile. Non è uno scoop dell’ultima ora, ma è un cambiamento che va digerito nello stack: lo schema JSON non viene più chiesto al modello, viene applicato durante la generazione.

Il formato non si chiede, si impone

Cosa succede, allora, dentro il decoder quando gli si passa uno schema? Il meccanismo si chiama constrained decoding: secondo AWS, lo schema JSON viene fatto rispettare durante la generazione dei token, non dopo. La differenza è tutta qui. Un validatore classico è come un correttore di bozze che legge il testo finito e lo rimanda indietro se è sbagliato; il constrained decoding somiglia piuttosto a un modulo con campi a scelta obbligata, dove certe risposte semplicemente non si possono scrivere. A ogni passo il modello può scegliere solo tra le continuazioni compatibili con lo schema, e il risultato è che il formato dell’output diventa deterministico anziché probabilistico.

Per farlo, lo schema viene trasformato in una grammatica. E qui c’è un dettaglio di implementazione che fa piacere a chi guarda le latenze: le grammatiche compilate restano in cache per 24 ore, quindi le richieste successive con lo stesso schema sono più veloci. Il costo di compilazione si paga una volta, poi si ammortizza. Resta però la domanda scomoda: se il formato è garantito per costruzione, quanta parte del codice difensivo che abbiamo scritto serve ancora?

Lo scaffolding che si può cancellare

La risposta di AWS è netta. In un secondo approfondimento sul blog di Amazon, la società scrive che gli structured outputs eliminano lo scaffolding di validazione e retry nelle pipeline di dati e nelle applicazioni agentiche. Il contrasto con il modo di lavorare precedente è evidente: prima il contratto dati viveva nel codice applicativo, sparso tra parser, controlli di tipo e cicli di ritentativo; ora lo fa rispettare il motore di inferenza. Per un agente che concatena decine di chiamate, ogni JSON malformato era un punto di rottura potenziale. Toglierlo dall’equazione semplifica l’orchestrazione più di quanto sembri.

C’è poi un effetto meno ovvio, quello sulla bolletta. Come spiega la documentazione tecnica di Bedrock, le risposte contengono solo i campi definiti dallo schema, il che può ridurre i token di output e il costo dell’inferenza per i carichi ad alto volume. Niente preamboli cortesi, niente «Ecco il JSON richiesto:», niente campi inventati. Secondo AWS, i team che fanno girare carichi Claude ad alto volume su Bedrock potrebbero vedere un minor consumo di token di output e costi di inferenza inferiori, oltre a meno richieste fallite e meno retry. Il condizionale è d’obbligo: il risparmio dipende da quanto era “verboso” il comportamento precedente e da quanti retry si facevano davvero.

La funzione è pensata per scalare. Gli structured outputs funzionano con la batch inference, per elaborare grandi volumi di richieste in modo asincrono continuando a ricevere output conformi allo schema; sull’endpoint bedrock-runtime funzionano anche con l’inferenza cross-Region, utilizzabile tra le Region AWS senza configurazioni aggiuntive. È la combinazione che serve a chi processa milioni di documenti in notturna e non vuole scoprire al mattino che una frazione dei record va rielaborata.

Il punto strategico, però, è l’ampiezza della copertura. Nell’annuncio pubblicato nella sezione What’s New, AWS sottolinea che gli output strutturati permettono di automatizzare attività affidabili e conformi a schema in settori come finanza, sanità ed e-commerce, e che l’estensione da Claude 4.5 a tutti i modelli Claude su Bedrock allarga l’accesso proprio a questi casi d’uso regolamentati e ad alto volume. Tradotto: chi ha pipeline validate su modelli precedenti non è costretto a migrare per ottenere la garanzia di formato. Ma ogni garanzia ha un prezzo, e Bedrock ne chiede uno preciso a chi scrive gli schemi.

additionalProperties: false, e il resto del mercato

Il prezzo è una riga. Per usare gli structured outputs bisogna impostare additionalProperties: false su tutti gli oggetti dello schema: senza, lo schema non viene accettato. Una piccola formalità, verrebbe da dire, se non fosse che molti schemi in circolazione sono permissivi per scelta o per pigrizia, e andranno riscritti oggetto per oggetto, annidamenti compresi. È un vincolo sensato, perché una grammatica chiusa è più facile da compilare e da far rispettare, ma è non negoziabile.

Sul fronte concorrenza, il confronto più diretto è con Google Cloud: Gemini Enterprise Agent Platform supporta gli output strutturati per tutti i modelli Anthropic Claude 4.5 e successivi, mentre Bedrock ora li estende a tutti i modelli Claude. Il concetto, del resto, non è un’esclusiva: anche OpenAI descrive i suoi Structured Outputs come una funzionalità che garantisce risposte sempre aderenti allo JSON Schema fornito. Resta da capire se la copertura dei modelli diventerà un criterio concreto per scegliere su quale cloud far girare Claude, o se resterà una nota a piè di pagina nelle matrici di confronto.

Per chi costruisce, intanto, il contratto dati si sposta: lo schema JSON non è più documentazione, è una specifica eseguibile applicata dal motore di inferenza. Il consiglio pratico è doppio. Rivedere gli schemi con rigore, chiudendoli con additionalProperties: false ovunque. E cancellare il codice di retry e validazione superfluo prima che si trasformi in debito tecnico: quello che non serve più, in produzione, tende comunque a rompersi.