Se la tua applicazione estrae ancora JSON dalla prosa del modello con una regex e un ciclo di retry, stai risolvendo un problema che Amazon Bedrock ora risolve a livello di decodifica. Gli structured output, disponibili in generale su Bedrock da febbraio 2026, vincolano il modello a uno JSON Schema mentre genera i token, così la risposta si conforma alla tua struttura per costruzione anziché per speranza. La regex non è mai stata la soluzione. Era il sintomo di chiedere a un modello "per favore restituisci JSON" e poi ripulire quando non lo faceva.

L'approccio basato sul parsing fallisce in modi fastidiosi proprio perché rari. Il novanta e passa percento delle risposte va a buon fine con il parsing. Il resto avvolge il JSON in un blocco markdown, aggiunge una frase amichevole prima, lascia una virgola in coda, o inventa un campo. Il tuo parser allora esplode in produzione, sull'input che non hai testato, nel momento peggiore. La decodifica vincolata elimina l'intera classe di guasto perché il token non valido non viene mai emesso in primo luogo.

Tre modi per ottenere struttura, in ordine di robustezza

Chiedi e spera

Chiedi il JSON nel system prompt, magari fornisci un esempio, e fai il parsing del testo. Funziona finché non funziona più. Non ha garanzie, nessuna applicazione forzata, e il suo tasso di errore è esattamente la coda che non si presenta mai in una demo. Ogni ora spesa a rinforzare il parser è un'ora spesa su un problema che la piattaforma può eliminare.

Tool use come schema

Molto prima degli structured output nativi, il trucco affidabile era definire un tool il cui schema di input è la forma desiderata, e poi leggere gli argomenti della chiamata al tool invece del testo del messaggio. Il modello riempie gli input del tool, e ottieni un oggetto strutturato. Questo resta un buon pattern quando la stessa chiamata deve anche invocare effettivamente dei tool. Su Bedrock puoi ora aggiungere strict: true a una definizione di tool così che il nome e gli input del tool vengano validati contro lo schema anziché semplicemente suggeriti da esso.

Structured output nativi

La via diretta è dichiarare la forma della risposta come JSON Schema e lasciare che Bedrock la imponga durante la generazione. Usa JSON Schema Draft 2020-12 e decodifica vincolata, quindi il modello non può fisicamente emettere un token che romperebbe lo schema. Sulla Converse API il campo è outputConfig.textFormat, e lo schema richiede un name. È disponibile su Converse, ConverseStream, InvokeModel e InvokeModelWithResponseStream per Anthropic Claude 4.5 e un insieme di modelli open-weight.

// Converse: enforce the shape instead of parsing for it
outputConfig: {
  textFormat: {
    jsonSchema: {
      name: "extraction",
      schema: {
        type: "object",
        properties: {
          invoice_id: { type: "string" },
          total_cents: { type: "integer" },
          currency: { type: "string", enum: ["USD", "EUR", "GBP"] }
        },
        required: ["invoice_id", "total_cents", "currency"],
        additionalProperties: false
      }
    }
  }
}

Cosa ti compra l'applicazione forzata

Il vantaggio ovvio è che l'output va a buon fine con il parsing. Il vantaggio più grande è ciò che puoi eliminare: il ciclo di retry sull'invalido, la libreria di riparazione JSON, il re-prompt difensivo che dice "hai restituito JSON non valido, riprova", e l'allarme che scatta quando anche tutto questo fallisce. Ognuno di questi elementi compensava un output probabilistico. Una volta che lo schema è imposto durante la decodifica, la compensazione è codice morto. Meno retry significa anche meno token e latenza più bassa, perché non paghi per una seconda chiamata che corregge la prima.

Imposta additionalProperties: false e marca i campi come required così lo schema è rigoroso. Uno schema permissivo che ammette chiavi extra restituisce parte della garanzia che hai appena acquistato, perché il modello può comunque attaccare campi che il tuo codice non si aspetta.

Dove non si applica

L'output strutturato è per risposte leggibili da macchina: estrazione, classificazione, instradamento, argomenti di funzione, qualsiasi cosa consumata da un sistema a valle. È lo strumento sbagliato per la prosa letta da un umano, dove uno schema rigido va contro lo scopo. E vincola la forma, non la verità. Uno schema garantisce che total_cents sia un intero, non che sia l'intero corretto. La validazione di valori, intervalli e regole di business resta compito tuo. Lo schema rimuove la modalità di guasto del parsing. Non rimuove la necessità di verificare che il modello abbia dato la risposta giusta.

Il punto chiave

Il parsing ingegnoso è sforzo speso ad aggirare una garanzia che il modello non ti ha mai dato. Gli structured output di Bedrock spostano la garanzia nel decoder: dichiara uno JSON Schema, e la risposta è valida per costruzione. Usa gli structured output nativi per dati puri, gli schemi tool-use quando la stessa chiamata deve anche agire, e mantieni comunque la validazione a livello di valore. Poi elimina la regex, il ciclo di riparazione e il retry. Erano impalcature per un problema che non hai più.

Da leggere ora

Per il lato piattaforma e delivery del rendere tutto questo affidabile, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.