Raciocínio orientado por schemas vs structured outputs para LLMs

Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Use structured outputs quando o seu programa precisar de campos com uma estrutura definida. Adicione raciocínio orientado por schemas (SGR) quando o programa ou um revisor também precisar de registos intermédios, como evidências de fontes e uma decisão proposta. O SGR usa structured output para expressar esses passos; não é uma garantia independente de que a resposta está correta.

Se o consumidor precisar apenas de uma categoria e de um ID de origem, mantenha esses campos. Adicione campos de análise apenas quando conseguir explicar como serão verificados ou utilizados.

Última revisão: 2026-09-08.

O que cada camada faz

CamadaO que forneceO que não pode estabelecer
Prompt de formatação JSONInstruções para devolver JSONQue a resposta segue um schema
Output condicionado por schemaUma resposta que segue o schema suportado, quando a geração é concluída com sucessoQue os valores são verdadeiros
Schema de SGRCampos intermédios nomeados e uma decisão propostaQue um campo foi corretamente derivado de outro
Verificações da aplicaçãoTestes das evidências de fontes, dos cálculos e das ações permitidasFactos que a aplicação nunca verifica

A descrição de SGR de Rinat Abdullin usa schemas como uma checklist do trabalho devolvido pelo modelo. Numa configuração self-hosted, os structured outputs do vLLM podem impor JSON Schema através de um backend de decoding como o XGrammar. Definir um modelo Pydantic apenas em Python não ativa o constrained decoding no servidor.

Verifique o subconjunto de schemas suportado pelo provider selecionado e o estado da conclusão. Uma recusa, uma resposta truncada ou um pedido falhado precisam de um caminho de erro próprio. O guia de structured outputs do Gemini também salienta a limitação principal: uma estrutura JSON correta não garante que os valores dos campos estejam corretos.

Uma proposta de desconto mostra a diferença

Suponha que uma ferramenta de suporte possa oferecer, no máximo, um desconto de 10%. Uma resposta estruturada mínima poderia conter discount_percent e customer_message. Se um revisor interno precisar de evidências, uma resposta SGR poderia também conter policy_source_id e eligibility_evidence.

Esses campos adicionais dão ao revisor algo para inspecionar. Não tornam válida uma proposta de desconto de 15%. Mesmo um schema que limite a percentagem a 10 não pode provar que este cliente é elegível.

Antes de utilizar a oferta, o código da aplicação tem de carregar a política aplicável e o registo do cliente, verificar a elegibilidade e calcular o montante permitido. Trate a explicação do modelo como uma afirmação a verificar. Se um passo posterior do modelo precisar de factos aprovados, valide-os antes de fazer essa chamada. A ordem dos campos num único objeto JSON não cria um passo de validação.

Quando os campos adicionais justificam o seu lugar

O SGR é útil quando uma resposta errada precisa de um diagnóstico mais preciso. Por exemplo, um classificador de documentos pode devolver uma passagem de origem e uma categoria. Os revisores podem então distinguir uma escolha inadequada da passagem de uma categoria errada perante evidências adequadas.

É menos útil quando todos os resultados recebem uma explicação longa que ninguém lê ou avalia. O output adicional consome tokens e uma explicação convincente pode continuar a ser falsa.

Compare o schema pequeno com o schema de SGR nos mesmos casos anotados e com o mesmo modelo. Avalie a decisão final separadamente do suporte da fonte e da validade dos campos. Mantenha os campos intermédios se melhorarem a decisão ou tornarem a revisão suficientemente útil para justificar o output adicional. Não presuma um aumento de accuracy com base no nome do schema.

Leitura adicional