Raciocínio orientado por esquemas e 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 esquemas (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 da fonte, 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 esquema
Saída limitada por um esquemaUma resposta que segue o esquema suportado, quando a geração é concluída com sucessoQue os valores são verdadeiros
Esquema 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 esquemas como uma lista de verificação do trabalho devolvido pelo modelo. Numa configuração alojada em infraestrutura própria, os structured outputs do vLLM podem impor JSON Schema através de um backend de descodificação como o XGrammar. Definir um modelo Pydantic apenas em Python não ativa o constrained decoding no servidor.

Verifique o subconjunto de esquemas suportado pelo fornecedor selecionado e o estado da conclusão. Uma recusa, uma resposta truncada ou um pedido falhado precisam de um tratamento 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 esquema 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 intermédios ajudam

O SGR é útil quando uma resposta errada precisa de um diagnóstico mais preciso. Por exemplo, um classificador de documentos pode devolver uma passagem da fonte 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. A saída adicional consome tokens e uma explicação convincente pode continuar a ser falsa.

Compare o esquema pequeno com o esquema de SGR nos mesmos casos anotados e com o mesmo modelo. Avalie a decisão final separadamente da confirmação pelas fontes e da validade dos campos. Mantenha os campos intermédios se melhorarem a decisão ou tornarem a revisão suficientemente útil para justificar a saída adicional. Não presuma um aumento da exatidão com base no nome do esquema.

Leitura adicional