Saida Estruturada
A saida estruturada (structured output) e um recurso que forca um LLM a retornar respostas em conformidade com um schema especificado, normalmente um schema JSON. Em vez de torcer para que o modelo produza um JSON parseavel, o motor de inferencia restringe a amostragem de tokens para que a saida tenha validacao garantida.
A saida estruturada (structured output) e um recurso que forca um LLM a retornar respostas em conformidade com um schema especificado, normalmente um schema JSON. Em vez de torcer para que o modelo produza um JSON parseavel, o motor de inferencia restringe a amostragem de tokens para que a saida tenha validacao garantida.
Por que importa
LLMs que retornam texto em formato livre sao dificeis de consumir de forma programatica. Mesmo quando recebem a instrucao "retorne JSON", os modelos ocasionalmente adicionam prosa, omitem campos ou alucinam tipos. Isso quebra o codigo subsequente e forca uma analise defensiva. A saida estruturada resolve o problema na camada de decodificacao: voce obtem um JSON valido 100% das vezes, e nao 95%. OpenAI, Anthropic, Google e motores de codigo aberto como vLLM e Outlines agora oferecem suporte nativo, tornando-a a forma padrao de construir pipelines de LLM confiaveis.
Como funciona
Decodificacao restrita: a cada etapa de geracao, o modelo so pode amostrar tokens que mantenham a saida compativel com o schema. Tokens que violariam o schema sao mascarados com probabilidade zero.
Especificacao de schema: voce fornece um schema JSON (ou modelo Pydantic, schema Zod, tipo TypeScript) que descreve os campos obrigatorios, os tipos e os enums.
Analise sem validacao: quem chama pode fazer JSON.parse no resultado sem try/catch em torno de saidas malformadas.
Modo JSON vs Saida Estruturada
| Aspecto | Modo JSON | Saida Estruturada |
|---|---|---|
| Garantia | Sintaxe JSON valida | JSON valido que corresponde ao seu schema |
| Imposicao do schema | Nenhuma | Total |
| Presenca dos campos | Nao garantida | Garantida |
| Campos alucinados | Possivel | Impossivel |
| Sobrecarga de latencia | ~0 | Pequena (compilacao da restricao) |
O modo JSON apenas garante que a saida e parseavel. A saida estruturada garante que ela e parseavel e corresponde a forma exata de que voce precisa. Para sistemas em producao, use sempre a saida estruturada quando disponivel.
Quando usar
Extrair dados de texto: obter nomes, datas e enderecos de entradas nao estruturadas.
Construir agentes que chamam ferramentas: os argumentos da chamada de ferramenta precisam corresponder exatamente ao schema de parametros da ferramenta.
Classificar em enums: forcar o modelo a escolher um de um conjunto fixo de rotulos.
Gerar respostas com varios campos: titulos, resumos, tags e pontuacoes em uma unica passagem.
Em qualquer lugar onde voce hoje analisa a saida do modelo com regex: isso e um bug esperando para acontecer.
Trade-offs
Leve sobrecarga de latencia: o decodificador precisa rastrear o estado da gramatica. Geralmente desprezivel.
Criatividade reduzida: restricoes de schema pesadas podem deixar a geracao com cara de mecanica. Para escrita criativa, prefira o formato livre.
O design do schema importa: schemas excessivamente rigidos (obrigatorio: todos os 20 campos) forcam o modelo a alucinar valores. Torne opcional o que e genuinamente opcional.
Nem todos os modelos oferecem suporte: modelos mais antigos e alguns modelos de codigo aberto ainda nao tem suporte nativo. Outlines e bibliotecas semelhantes conseguem adapta-lo.
Exemplo
Schema:
{
"type": "object",
"properties": {
"title": { "type": "string" },
"tags": { "type": "array", "items": { "type": "string" } },
"sentiment": { "enum": ["positive", "negative", "neutral"] }
},
"required": ["title", "tags", "sentiment"]
}
Saida garantida:
{ "title": "Launch recap", "tags": ["product", "Q2"], "sentiment": "positive" }
Sem erros de parse. Sem campos faltantes. Sem valores de enum inventados.
Fontes: