Saída Estruturada Vence o Parsing Esperto
Ainda extrai JSON do texto do modelo com regex? Pare. Saídas estruturadas do Bedrock aplicam um JSON Schema na decodificação, então a resposta já nasce válida.

Se sua aplicação ainda extrai JSON da prosa do modelo com regex e um loop de retry, você está resolvendo um problema que o Amazon Bedrock agora resolve na camada de decodificação. As saídas estruturadas, disponíveis de forma geral no Bedrock desde fevereiro de 2026, restringem o modelo a um JSON Schema enquanto ele gera tokens, então a resposta segue seu formato por construção, não por esperança. O regex nunca foi a solução. Era o sintoma de pedir para um modelo "por favor retorne JSON" e depois limpar a bagunça quando ele não retornava.
A abordagem de parsing falha de formas irritantes justamente porque são raras. Algo como noventa e poucos por cento das respostas fazem parse corretamente. O resto envolve o JSON em uma cerca de markdown, adiciona uma frase amigável antes, deixa uma vírgula sobrando, ou alucina um campo. Seu parser então lança uma exceção em produção, na entrada que você não testou, na pior hora. A decodificação restrita remove essa classe inteira de falha porque o token inválido nunca chega a ser emitido.
Três formas de obter estrutura, em ordem de robustez
Peça e reze
Você pede JSON no system prompt, talvez dê um exemplo, e faz parse do texto. Isso funciona até não funcionar. Não há garantia, não há aplicação forçada, e a taxa de falha é exatamente a cauda que nunca aparece em uma demo. Cada hora gasta blindando o parser é uma hora gasta em um problema que a plataforma pode eliminar.
Tool use como schema
Bem antes das saídas estruturadas nativas, o truque confiável era definir uma ferramenta cujo schema de entrada é o formato desejado, e então ler os argumentos da chamada de ferramenta em vez do texto da mensagem. O modelo preenche as entradas da ferramenta, e você obtém um objeto estruturado. Esse ainda é um bom padrão quando a mesma chamada também precisa efetivamente invocar ferramentas. No Bedrock, agora você pode adicionar strict: true a uma definição de ferramenta para que o nome da ferramenta e suas entradas sejam validados contra o schema em vez de apenas sugeridos por ele.
Saídas estruturadas nativas
A rota direta é declarar o formato da resposta como um JSON Schema e deixar o Bedrock aplicá-lo durante a geração. Ele usa JSON Schema Draft 2020-12 e decodificação restrita, então o modelo fisicamente não consegue emitir um token que quebraria o schema. Na Converse API, o campo é outputConfig.textFormat, e o schema precisa de um name. Está disponível em Converse, ConverseStream, InvokeModel e InvokeModelWithResponseStream para Anthropic Claude 4.5 e um conjunto de modelos de peso aberto.
// 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
}
}
}
}O que a aplicação forçada compra para você
O ganho óbvio é que a saída faz parse. O ganho maior é o que você pode deletar: o loop de retry em caso de invalidez, a biblioteca de reparo de JSON, o re-prompt defensivo que diz "você retornou JSON inválido, tente novamente", e o alerta que dispara quando tudo isso ainda falha. Cada um desses estava compensando uma saída probabilística. Uma vez que o schema é aplicado durante a decodificação, a compensação vira código morto. Menos retries também significa menos tokens e menor latência, porque você não está pagando por uma segunda chamada para corrigir a primeira.
Defina additionalProperties: false e marque campos como required para manter o schema rígido. Um schema frouxo que permite chaves extras devolve parte da garantia que você acabou de comprar, porque o modelo ainda pode anexar campos que seu código não espera.
Onde isso não se aplica
Saída estruturada serve para respostas legíveis por máquina: extração, classificação, roteamento, argumentos de função, qualquer coisa que um sistema downstream consome. É a ferramenta errada para prosa que um humano lê, onde um schema rígido atrapalha o objetivo. E ela restringe formato, não verdade. Um schema garante que total_cents é um inteiro, não que é o inteiro correto. A validação de valores, faixas e regras de negócio ainda é seu trabalho. O schema remove o modo de falha de parsing. Ele não remove a necessidade de checar se o modelo acertou a resposta.
A conclusão
Parsing esperto é esforço gasto contornando uma garantia que o modelo nunca deu a você. As saídas estruturadas do Bedrock movem a garantia para o decodificador: declare um JSON Schema, e a resposta já nasce válida por construção. Use saídas estruturadas nativas para dados puros, schemas de tool use quando a mesma chamada também age, e mantenha a validação em nível de valor de qualquer forma. Depois delete o regex, o reparo e o retry. Eram andaimes para um problema que você não tem mais.
Leia isso a seguir
- Stop Fine-Tuning. You Need RAG, a Cache, and Better Prompts, sobre resolver formato e comportamento com prompting e recursos de plataforma em vez de treinamento.
- Streaming Responses Are a UX Decision, Not a Performance One, sobre por que streaming e saída estruturada puxam em direções opostas.
Para o lado de plataforma e entrega de fazer isso com confiabilidade, as notas de campo sobre cloud estão em ercan.cloud, e o hub está em ercanermis.com.
Mais de Ercan
Mais dois sites, mesmo autor, terreno diferente.
Cloud, AWS, EKS, Terraform, engenharia de plataforma.
Notas de campo de sistemas em produção. EKS, IAM, Terraform em escala organizacional, observabilidade, otimização de custos.
Visitar ercan.cloud →O hub. Sobre, consultoria, contato.
Hub pessoal para as duas trilhas de escrita. Quem sou eu, como funciona a consultoria, como me contatar.
Visitar ercanermis.com →