Saída do modelo não atende ao formato exigido

Perguntas
1

image
image1216×1542 40.1 KB

Ao usar um analisador de saída em uma cadeia llm com o modelo gama 4, isso ocorre toda vez

2

@Mukul_Rai esse erro significa que o parser não conseguiu validar o texto dos modelos como JSON correspondendo ao seu schema, e modelos menores tropeçam nisso constantemente, eles envolvem o JSON em prosa ou markdown ou descartam campos. duas soluções, a mais fácil é envolvê-lo no Auto-fixing Output Parser, ele executa um segundo passe de LLM para reparar a saída antes de fazer parsing. a mais confiável é mudar para um modelo que é bom em saída estruturada (gemini flash, gpt-4o-mini, claude haiku), modelos mais fracos simplesmente não conseguem manter o schema. e aperte o prompt para dizer que retorne apenas JSON válido, sem markdown ou texto extra.

3

@Mukul_Rai
Isso é esperado, o schema do gemma 4 não está em conformidade com o formato Open AI. Se você fizer auto-hospedagem, ainda poderá fazer proxy dele através do LiteLLM

4

Esse erro vem do analisador de saída/estruturado fazendo uma verificação de esquema rigorosa na resposta do modelo — e a resposta não correspondendo (geralmente texto extra, cerca de markdown ```json, ou JSON ligeiramente malformado). A dica “mudar On Error no nó raiz” apenas evita que a execução falhe; não corrige a saída real, então eu trataria isso como último recurso, não como a solução.

O verdadeiro causador aqui é quase certamente o modelo. Se “gamma 4” é o Gemma do Google rodando localmente, modelos abertos menores são notoriamente fracos em saída estruturada rigorosa e chamadas de função em comparação com GPT-4o / Claude — eles tendem a envolver JSON em cerca de código ou adicionar texto explicativo, o que quebra o analisador toda vez. Algumas coisas que resolvem isso, em ordem de impacto:

  1. Envolva-o no Analisador de Saída com Auto-correção. O n8n tem um analisador que, quando a primeira análise falha, alimenta automaticamente a saída incorreta mais o erro de volta ao modelo e pede que ele corrija o formato. Isso sozinho resolve a maioria dos casos de modelo mais fraco — maior ganho pelo menor esforço.

  2. Aperte o prompt. Diga explicitamente ao modelo: “Retorne APENAS JSON válido correspondendo ao esquema — sem markdown, sem cerca de código, sem explicação.” Modelos pequenos adoram adicionar cerca de código e prosa; dizer isso claramente remove a maioria das falhas.

  3. Abaixe a temperatura para 0-0,2 para o passo estruturado. Temperatura mais alta aumenta a variação de formato.

  4. Simplifique o esquema. Objetos profundamente aninhados com muitos campos obrigatórios falham muito mais em modelos pequenos. Achate-o, mantenha os campos obrigatórios mínimos e adicione uma breve descrição a cada campo para que o modelo saiba exatamente o que produzir.

  5. Se a precisão importa e você conseguir, use um modelo mais forte em JSON / chamadas de ferramenta para o passo de análise — até mesmo outro local como qwen2.5-instruct lida com saída estruturada muito melhor que Gemma na minha experiência, e um modelo de API (um pequeno GPT-4o-mini ou Claude Haiku) oferece conformidade próxima de 100%.

Eu enfrentei exatamente isso rodando modelos locais para extração estruturada — o analisador com auto-correção mais uma instrução explícita “apenas JSON, sem cerca” geralmente transforma de falhar toda vez para confiável. Comece aí e veja até onde vai chegar.

5

O conselho sobre parser/correção automática acima está correto. Eu também trataria isso como um problema de monitoramento, não apenas um problema de prompt.

Em produção, uma etapa de IA que às vezes retorna a forma errada não deve ser permitida continuar como se o fluxo de trabalho tivesse tido sucesso. Eu colocaria um gate de validação imediatamente após a etapa do modelo:

  1. Verificar que a resposta é um JSON válido.
  2. Verificar que todos os campos obrigatórios existem.
  3. Verificar que os campos não estão vazios e estão dentro dos intervalos esperados.
  4. Rotear a saída inválida para retry, correção automática ou revisão manual.
  5. Registrar o resultado da validação com o ID de execução e tipo de entrada.

A distinção chave é sucesso técnico versus sucesso nos negócios. O fluxo de trabalho pode terminar verde enquanto a saída é inutilizável. Para fluxos de trabalho de clientes, eu gostaria que essas falhas de validação se tornassem problemas visíveis, porque caso contrário o cliente só percebe depois quando dados ruins chegam a um CRM, email, planilha ou relatório.

6

O conselho sobre parser/auto-fix acima está certo. Eu também trataria isso como um problema de monitoramento, não apenas de prompt.

Em produção, uma etapa de IA que às vezes retorna a estrutura errada não deve ser permitida continuar como se o fluxo de trabalho tivesse sucesso. Eu colocaria uma porta de validação imediatamente após a etapa do modelo:

  1. Verificar se a resposta é um JSON válido.
  2. Verificar se todos os campos obrigatórios existem.
  3. Verificar se os campos não estão vazios e estão dentro dos intervalos esperados.
  4. Encaminhar a saída inválida para retentativa, auto-correção ou revisão manual.
  5. Registrar o resultado da validação com a ID de execução e tipo de entrada.

A distinção-chave é sucesso técnico versus sucesso comercial. O fluxo de trabalho pode terminar com status verde enquanto a saída é inutilizável. Para fluxos de trabalho de clientes, eu gostaria que essas falhas de validação se tornassem problemas visíveis, porque caso contrário o cliente só percebe depois quando dados ruins chegam a um CRM, email, planilha ou relatório.