Qual é a forma mais recente (2026) de obter saída JSON estruturada confiável de LLMs locais no n8n?
Estou usando modelos locais (via Ollama) no n8n e preciso de saída JSON consistente para coisas como roteamento e geração de SQL.
Qual é a melhor prática atual que as pessoas estão usando em 2026?
As pessoas ainda estão confiando em:
Ou existe uma abordagem mais nova e confiável?
Eu não trataria isso como um problema de uma única camada.
Para fluxos de trabalho relacionados a roteamento ou SQL, eu trataria JSON como um contrato de interface:
Especificamente para SQL, evitaria deixar o modelo produzir SQL bruto que seja executado diretamente. Um padrão mais seguro é fazer o modelo produzir intenção estruturada, filtros, escolhas de tabela/campo de uma lista permitida, e então mapear isso para um modelo de consulta que você controla.
Então a parte confiável não é apenas “o modelo consegue emitir JSON?” É “o que acontece quando o JSON está faltando, malformado, válido mas incorreto, ou inseguro?”
Boa pergunta — já trabalhei bastante com Ollama + n8n nesse assunto. Aqui está o que realmente funciona de forma confiável em 2026:
1. Use o parâmetro nativo format: json do Ollama (camada mais confiável)
Ao configurar o nó Ollama Chat Model, adicione format: json nos campos adicionais / parâmetros do modelo. Isso força o Ollama a restringir a amostragem de tokens apenas a tokens JSON válidos — não é engenharia de prompt, é imposto no nível do modelo. Modelos como llama3, mistral e qwen2.5 suportam isso muito bem. Apenas isso elimina ~80% da saída malformada.
2. Combine com o Structured Output Parser do n8n
Combine Ollama format:json + o Structured Output Parser (com um JSON Schema). O schema diz ao modelo quais campos você espera; o parser valida e extrai. Se você está fazendo roteamento, seu schema pode ser tão simples quanto { "route": { "type": "string", "enum": ["billing", "support", "sales"] } }.
3. Nó Code como sua rede de segurança
Depois do parser, adicione um nó Code que faz:
const out = $input.first().json;
if (!out.route || !['billing','support','sales'].includes(out.route)) {
throw new Error('Invalid route: ' + JSON.stringify(out));
}
return [{ json: out }];
Isso bloqueia nós posteriores para que você nunca roteie errado silenciosamente.
4. Para intenção SQL especificamente
Não peça ao modelo para gerar SQL. Peça para gerar intenção estruturada: { "table": "orders", "filters": [{"field": "status", "op": "eq", "value": "pending"}], "limit": 10 }. Então seu nó Code mapeia isso para uma consulta parametrizada. Muito mais seguro e confiável do que SQL livre.
5. Loop de reparo de uma tentativa se necessário
Para schemas complexos onde o modelo ainda falha ocasionalmente, conecte um nó IF verificando erros de análise → reenvie para o Ollama com a mensagem de erro anexada ao prompt. Uma nova tentativa captura a maioria dos casos restantes. Se falhar duas vezes, roteie para um fallback/revisão humana em vez de adivinhar.
A combinação de format:json + schema + validação Code é o que uso em fluxos de trabalho estilo produção. Funciona sem nenhum nó pago.
Bem-vindo @osman1!
Uma coisa que vale a pena adicionar à stack: o n8n tem um nó “Auto-fixing Output Parser” que envolve o Structured Output Parser. Se o modelo retornar um JSON malformado, ele automaticamente envia o erro de volta para a LLM para uma única tentativa de auto-reparo - nenhuma lógica manual de IF/retry necessária. Para o Ollama especificamente, também passe format: "json" nas opções de body do nó Ollama Chat Model para restringir a amostragem de tokens no nível do modelo, depois deixe o Auto-fixing Parser aplicar seu schema por cima. Essa configuração de duas camadas (restrição de formato no nível do modelo + reparo no nível do parser) é a abordagem mais confiável que usei com modelos locais.
As respostas acima cobrem bem a camada estrutural. Uma camada adicional que vale a pena adicionar é a validação semântica — detectar JSON que é analisado corretamente, mas contém valores que não fazem sentido.
Alguns exemplos: um campo de data que é analisado como uma string, mas não é uma data válida. Um campo de status com o tipo correto, mas um valor fora do enum permitido. Um campo de preço ou contagem com um formato plausível, mas um intervalo implausível (0.0001 ou 99999999). O analisador com correção automática lida com o caso em que o modelo retorna JSON malformado e tenta novamente uma vez. Mas se a nova tentativa for bem-sucedida estruturalmente, a saída ainda flui para o próximo estágio mesmo que os valores sejam sem sentido. A camada estrutural não sabe que shipping_cost nunca deve ser negativo.
A solução é um nó de Código após o analisador que executa verificações explícitas: presença de campo obrigatório, asserções de tipo, associação ao enum e guarda de intervalo. Se alguma verificação falhar, pare o item ou o encaminhe para uma fila de revisão em vez de deixar dados ruins fluírem adiante.
A parte que compensa ao longo do tempo é registrar toda falha com a saída bruta do LLM, o campo que falhou e um timestamp. Duas coisas se tornam visíveis naquele log que não são visíveis de outra forma: quais campos falham 30 por cento do tempo (um problema de prompt que vale a pena corrigir) versus quais falham 1 por cento do tempo (um caso extremo para lidar no roteamento). E quando você atualiza o modelo local, você pode comparar as taxas de falha antes e depois.
As verificações estruturais que Tony e pirateprentice descreveram são a primeira camada correta. A camada semântica é o que transforma „ele é analisado