Lorsque j’utilise un analyseur de sortie dans une chaîne llm avec le modèle Gamma 4, je reçois ceci à chaque fois
@Mukul_Rai cette erreur signifie que le parser n’a pas pu valider le texte du modèle en tant que JSON correspondant à votre schéma, et les modèles plus petits échouent constamment là-dessus, ils enveloppent le JSON dans du texte ou du markdown ou suppriment des champs. deux solutions, la plus simple est de l’envelopper dans l’Auto-fixing Output Parser, qui exécute une deuxième passe LLM pour réparer la sortie avant l’analyse. la plus fiable est de passer à un modèle qui est solide en sortie structurée (gemini flash, gpt-4o-mini, claude haiku), les modèles plus faibles ne peuvent tout simplement pas respecter le schéma. et resserrez le prompt pour dire retourner uniquement du JSON valide, pas de markdown ou de texte supplémentaire.
@Mukul_Rai
C’est prévisible, le schéma gemma 4 ne respecte pas le format OpenAI. Si vous l’auto-hébergez, vous pourriez toujours le proxifier via LiteLLM
Cette erreur provient de l’analyseur de sortie structuré qui effectue une vérification stricte du schéma sur la réponse du modèle — et la réponse ne correspond pas (généralement du texte supplémentaire, des délimiteurs markdown ```json, ou du JSON légèrement malformé). L’indice « change On Error in the root node » l’empêche simplement d’échouer l’exécution ; cela ne corrige pas la sortie réelle, je le traiterais donc comme un dernier recours, pas comme la solution.
Le vrai problème ici est presque certainement le modèle. Si « gamma 4 » est le Gemma de Google exécuté localement, les petits modèles open source sont notoirement faibles en matière de sortie structurée stricte et d’appel de fonctions comparés à GPT-4o / Claude — ils ont tendance à envelopper le JSON dans des délimiteurs de code ou à ajouter du texte explicatif, ce qui casse l’analyseur à chaque fois. Quelques solutions qui fonctionnent, par ordre d’impact :
-
L’envelopper dans l’Auto-fixing Output Parser. n8n dispose d’un analyseur qui, en cas d’échec du premier analyse, renvoie automatiquement la mauvaise sortie plus l’erreur au modèle et lui demande de corriger le format. À lui seul, cela corrige la plupart des cas avec des modèles plus faibles — le plus grand avantage pour le moins d’effort.
-
Resserrer l’invite. Dites explicitement au modèle : « Retournez UNIQUEMENT du JSON valide correspondant au schéma — pas de markdown, pas de délimiteurs de code, pas d’explication. » Les petits modèles adorent ajouter des délimiteurs de code et du texte explicatif ; le dire clairement élimine la plupart des défaillances.
-
Baissez la température à 0-0,2 pour l’étape structurée. Une température plus élevée augmente la dérive du format.
-
Simplifiez le schéma. Les objets profondément imbriqués avec de nombreux champs obligatoires échouent beaucoup plus souvent sur les petits modèles. Aplatissez-le, gardez les champs obligatoires au minimum, et ajoutez une brève description à chaque champ pour que le modèle sache exactement quoi produire.
-
Si la précision est importante et que vous le pouvez, utilisez un modèle plus fort en JSON / appel d’outils pour l’étape d’analyse — même un autre local comme qwen2.5-instruct gère beaucoup mieux la sortie structurée que Gemma selon mon expérience, et un modèle API (un petit GPT-4o-mini ou Claude Haiku) vous rapproche d’une conformité quasi complète.
J’ai rencontré exactement ce problème en exécutant des modèles locaux pour l’extraction structurée — l’analyseur auto-correcteur plus une instruction explicite « JSON uniquement, pas de délimiteurs » le fait généralement passer de défaillances constantes à la fiabilité. Commencez par là et voyez jusqu’où cela vous mène.
L’conseil du parser/auto-fix ci-dessus est juste. Je traiterais également cela comme un problème de monitoring, et non pas seulement comme un problème de prompt.
En production, une étape IA qui retourne parfois la mauvaise structure ne devrait pas être autorisée à continuer comme si le workflow avait réussi. Je mettrais une porte de validation immédiatement après l’étape du modèle :
- Vérifier que la réponse est un JSON valide.
- Vérifier que tous les champs requis existent.
- Vérifier que les champs ne sont pas vides et qu’ils se situent dans les plages attendues.
- Router la sortie invalide vers une nouvelle tentative, un auto-fix ou un examen manuel.
- Enregistrer le résultat de la validation avec l’ID d’exécution et le type d’entrée.
La distinction clé est le succès technique par rapport au succès métier. Le workflow peut se terminer correctement alors que la sortie est inutilisable. Pour les workflows clients, je voudrais que ces échecs de validation deviennent des problèmes visibles, car sinon le client ne les remarque que plus tard quand des données incorrectes arrivent dans un CRM, un e-mail, un tableau ou un rapport.
Le conseil du parser/auto-fix ci-dessus est juste. Je traiterais aussi cela comme un problème de monitoring, pas seulement comme un problème de prompt.
En production, une étape IA qui retourne parfois la mauvaise structure ne devrait pas être autorisée à continuer comme si le workflow avait réussi. Je mettrais une porte de validation immédiatement après l’étape du modèle :
- Vérifier que la réponse est du JSON valide.
- Vérifier que tous les champs obligatoires existent.
- Vérifier que les champs ne sont pas vides et se situent dans les plages attendues.
- Router les sorties invalides vers une nouvelle tentative, une correction automatique ou un examen manuel.
- Enregistrer le résultat de la validation avec l’ID d’exécution et le type d’entrée.
La distinction clé est entre le succès technique et le succès commercial. Le workflow peut se terminer en vert alors que la sortie est inutilisable. Pour les workflows client, je voudrais que ces échecs de validation deviennent des problèmes visibles, car sinon le client ne s’en aperçoit que plus tard lorsque les mauvaises données atteignent un CRM, un email, une feuille de calcul ou un rapport.