Bei der Verwendung eines Output-Parsers in einer LLM-Kette mit dem Gamma-4-Modell erhalte ich jedes Mal diesen Fehler
@Mukul_Rai dieser Fehler bedeutet, dass der Parser den Text des Modells nicht als JSON validieren konnte, das deinem Schema entspricht, und kleinere Modelle stolpern ständig darüber, sie packen das JSON in Prosa oder Markdown oder lassen Felder weg. zwei Lösungen, die einfachste ist, es mit dem Auto-fixing Output Parser zu umhüllen, er führt einen zweiten LLM-Pass durch, um die Ausgabe vor dem Parsing zu reparieren. die zuverlässigere ist, zu einem Modell zu wechseln, das solide bei strukturierter Ausgabe ist (Gemini Flash, GPT-4o-mini, Claude Haiku), schwächere Modelle können das Schema einfach nicht einhalten. und verschärfe den Prompt, um zu sagen, dass nur gültiges JSON zurückgegeben wird, kein Markdown oder zusätzlicher Text.
@Mukul_Rai
Das ist zu erwarten, das Gemma-4-Schema entspricht nicht dem OpenAI-Format. Wenn du es selbst hostest, kannst du es möglicherweise trotzdem über LiteLLM proxyfähig machen.
Dieser Fehler kommt vom strukturierten/Output Parser, der eine strikte Schema-Validierung auf die Antwort des Modells anwendet — und die Antwort stimmt nicht überein (normalerweise zusätzliche Prosa, Markdown ```json-Fences oder leicht malformed JSON). Der Hinweis „Change On Error in the root node
Der obige Parser-/Auto-Fix-Rat ist richtig. Ich würde dies auch als ein Überwachungsproblem betrachten, nicht nur als ein Prompt-Problem.
In der Produktion sollte ein KI-Schritt, der manchmal die falsche Form zurückgibt, nicht einfach so weiterlaufen dürfen, als hätte der Workflow erfolgreich abgeschlossen. Ich würde unmittelbar nach dem Modell-Schritt ein Validierungs-Gate einbauen:
- Prüfen, dass die Antwort gültiges JSON ist.
- Prüfen, dass alle erforderlichen Felder vorhanden sind.
- Prüfen, dass Felder nicht leer sind und innerhalb erwarteter Bereiche liegen.
- Ungültige Ausgaben zur Wiederholung, Auto-Fix oder manuellen Überprüfung leiten.
- Das Validierungsergebnis mit der Ausführungs-ID und dem Eingabetyp protokollieren.
Die Hauptunterscheidung ist technischer Erfolg versus geschäftlicher Erfolg. Der Workflow kann grün beendet werden, während die Ausgabe unbrauchbar ist. Bei Client-Workflows möchte ich, dass diese Validierungsfehler zu sichtbaren Problemen werden, denn sonst bemerkt der Client es erst später, wenn schlechte Daten in ein CRM, eine E-Mail, eine Tabelle oder einen Bericht gelangen.
Der Parser/Auto-Fix-Hinweis oben ist richtig. Ich würde das aber auch als Monitoring-Problem behandeln, nicht nur als Prompt-Problem.
In der Produktion sollte ein KI-Schritt, der manchmal die falsche Form zurückgibt, nicht erlaubt sein, so zu tun, als würde der Workflow erfolgreich abgeschlossen. Ich würde unmittelbar nach dem Modell-Schritt ein Validierungs-Gate einbauen:
- Überprüfen, dass die Antwort gültiges JSON ist.
- Überprüfen, dass alle erforderlichen Felder vorhanden sind.
- Überprüfen, dass Felder nicht leer sind und innerhalb erwarteter Bereiche liegen.
- Ungültige Ausgaben zur Wiederholung, zum Auto-Fix oder zur manuellen Überprüfung weiterleiten.
- Das Validierungsergebnis mit der Ausführungs-ID und dem Eingabetyp protokollieren.
Die wichtigste Unterscheidung ist technischer Erfolg versus geschäftlicher Erfolg. Der Workflow kann grün beendet werden, während die Ausgabe unbrauchbar ist. Bei Client-Workflows möchte ich, dass diese Validierungsfehler zu sichtbaren Problemen werden, denn sonst bemerkt der Client das Problem erst später, wenn fehlerhafte Daten in ein CRM, eine E-Mail, ein Sheet oder einen Report gelangen.