Controle a saída: conformidade com JSON Schema, constrained decoding e seleção de formato

O controle de saída opera em três níveis distintos — baseado em prompt, baseado em schema e constrained decoding — cada um oferecendo garantias de formato progressivamente mais fortes com compensações progressivamente maiores em relação à qualidade de raciocínio.

O formato baseado em prompt instrui o modelo por linguagem natural ("Retorne JSON com campos: nome, email, pontuação"). Isso funciona 80–95% das vezes, mas falha silenciosamente em casos extremos sem garantias de tipo, exigindo tratamento de erros para 5–20% de respostas malformadas. As abordagens baseadas em schema (function calling / tool use) definem a estrutura de saída formalmente com 95–99% de conformidade. O constrained decoding nativo usa máquinas de estados finita para mascarar tokens inválidos em tempo de geração, produzindo 100% de saídas válidas segundo o schema com certeza matemática.

A abordagem de duas etapas — deixar Claude Opus 4.8 ou GPT-5.5 raciocinar livremente na Etapa 1, depois alimentar a saída a um modelo especializado pequeno na Etapa 2 — alcança garantias de formato sem a penalidade de qualidade de raciocínio do constrained decoding.

Instruções explícitas de schema de saída — colocadas no início do prompt do sistema para Claude Opus 4.8 e imediatamente antes do conteúdo do usuário para GPT-5.5 — produzem taxas de conformidade de saída estruturada de 85–95% sem a penalidade de qualidade de raciocínio do constrained decoding nativo.

Claude Opus 4.8 responde melhor às instruções de formato de saída colocadas no início do prompt do sistema usando tags de seção estilo XML. GPT-5.5 funciona melhor quando o schema é colocado imediatamente antes do conteúdo do usuário usando regras de formato numeradas. Gemini 3.1 Pro produz a saída estruturada mais confiável quando o schema é repetido tanto no início quanto no final do prompt.

Prompt deficiente — sem estrutura, sem especificação de formato:

Bom prompt — Claude Opus 4.8

O prompt estruturado com XML ancora o contrato de formato de saída enquanto preserva o raciocínio livre dentro do bloco `<task>`. Não é necessário constrained decoding — Claude Opus 4.8 está em conformidade em mais de 93% das chamadas de produção com essa estrutura.

Bom prompt — GPT-5.5

Cada LLM principal tem preferências estruturais distintas para a conformidade do formato de saída:

Temperature (T), Top-P, Top-K, max_tokens, frequency_penalty e presence_penalty são seis parâmetros independentes que determinam conjuntamente o comprimento, a aleatoriedade e a repetição da saída.

Temperature (T) escala a distribuição softmax de saída: com T = 0,0 o modelo sempre seleciona o token de maior probabilidade (determinístico); com T = 2,0 a distribuição é quase plana. Top-P (amostragem de núcleo) seleciona do conjunto mínimo de tokens cuja probabilidade acumulada alcança P. Top-K restringe a geração aos K tokens de maior probabilidade em cada etapa.

Regra crítica: Não configure Temperature e Top-P em valores altos simultaneamente. Temperature escala primeiro a distribuição completa; depois Top-P amostra da massa de probabilidade superior já escalada. Combinar T = 1,5 e Top-P = 0,95 produz saída mais errática do que qualquer parâmetro sozinho.

Forçar JSON por constrained decoding reduz a precisão do modelo em 2,26 pontos percentuais em benchmarks de function calling — o parsing alinhado com schema do BAML alcançou 93,63% de precisão no BFCL vs. 91,37% para o constrained decoding estrito da OpenAI no mesmo benchmark.

A solução pronta para produção para sistemas que exigem tanto profundidade de raciocínio quanto garantias de formato: (1) Etapa 1 — Envie para GPT-5.5 ou Claude Opus 4.8 sem restrições: "Analise isso, raciocine passo a passo, explique sua lógica." (2) Etapa 2 — Alimente a saída da Etapa 1 a um modelo especializado pequeno: "Extraia os dados principais desta análise e retorne-os neste schema JSON exato."

Testado no PromptQuorum — 30 prompts de controle de saída despachados a três modelos: Claude Opus 4.8 alcançou 93% de conformidade JSON usando instruções de formato com tags XML sem constrained decoding. GPT-5.5 alcançou 89% de conformidade usando regras de formato numeradas. Gemini 3.1 Pro alcançou 91% de conformidade com o schema indicado tanto no início quanto no final.

As stop sequences — tokens que encerram imediatamente a saída do modelo ao serem gerados — são o mecanismo de controle de saída mais determinístico.

Usos comuns em produção:

As restrições negativas no corpo do prompt — "Não inclua explicações", "Sem markdown" — reduzem os padrões de saída indesejados mas não podem garantir a conformidade da forma que as stop sequences fazem.

JSON é o formato de saída dominante para pipelines LLM de produção porque mapeia diretamente para objetos de API, arrays e dados tipados.

Empresas europeias que constroem pipelines LLM que processam dados pessoais devem aplicar o Artigo 25 do RGPD (privacidade por design) ao design do schema de saída.

Para equipes da UE que exigem inferência on-premise com controle de saída estruturada, a Mistral AI (França) suporta constrained decoding baseado em vLLM com parâmetros JSON guiados — habilitando conformidade garantizada com JSON Schema completamente dentro da infraestrutura da UE.

Empresas brasileiras que processam dados pessoais de brasileiros devem seguir a LGPD ao projetar schemas de saída — saídas que expõem campos de dados pessoais requerem base legal adequada.