Strukturierte LLM-Ausgaben: Output Parser

Der Output Parser Node in n8n erzwingt strukturierte JSON-Ausgaben aus LLM-Antworten, statt sich auf freien Fließtext zu verlassen: Er definiert ein Schema, an das sich das Sprachmodell halten soll, und die Basic LLM Chain oder der KI-Agent liefert das Ergebnis anschließend in genau diesem Format zurück. Für Unternehmen, die LLM-Antworten automatisiert in CRM, ERP oder Datenbanken weiterleiten wollen, ist das der Unterschied zwischen zuverlässig auswertbaren Feldern und mühsamem manuellem Nacharbeiten von Textantworten. Stand: Juli 2026.

Warum reiner Freitext in Automatisierungen scheitert

Ein Sprachmodell liefert ohne weitere Vorgaben Antworten in natürlicher Sprache. Für eine Chat-Oberfläche ist das gewünscht, für einen Workflow-Schritt, der die Antwort in ein nachfolgendes System einspeisen soll, ist es ein Problem. Ohne feste Struktur muss man mit Textbausteinen, Regex oder zusätzlichen Zwischenschritten arbeiten, um einzelne Werte herauszulösen, und jede kleine Formulierungsänderung des Modells kann diese Extraktion brechen. Der Output Parser Node setzt genau hier an: Er gibt dem Modell ein Schema vor und sorgt dafür, dass die Antwort als valides JSON mit klar benannten Feldern zurückkommt, direkt weiterverarbeitbar in den folgenden Nodes.

Der Structured Output Parser: JSON-Schema erzwingen

Laut der n8n-Dokumentation zum Structured Output Parser gibt der Node Felder basierend auf einem JSON-Schema zurück und strukturiert die LLM-Ausgabe entsprechend. Für die Schema-Definition stehen zwei Wege zur Verfügung:

• Generate from JSON Example: Sie geben ein Beispiel-JSON ein, und der Node leitet daraus automatisch das Schema ab. Dabei werden nur die Objekteigenschaftstypen und -namen verwendet, die tatsächlichen Werte im Beispiel spielen keine Rolle. Alle Felder gelten in diesem Modus als erforderlich.
• Define using JSON Schema: Sie erstellen das Schema manuell. Die Dokumentation weist ausdrücklich darauf hin, dass Referenzen mit `$ref` in diesem Schema nicht unterstützt werden.

Wichtig für die praktische Nutzung: Sub-Nodes wie dieser Output Parser verarbeiten Ausdrücke anders als reguläre Nodes. Bei mehreren Eingabe-Items wird ein Ausdruck laut Dokumentation immer nur zum ersten Item aufgelöst, nicht zu jedem Item einzeln. Das kann bei Batch-Verarbeitung mehrerer Datensätze zu unerwarteten Ergebnissen führen und sollte vorab getestet werden.

Anbindung an Basic LLM Chain oder KI-Agent

Damit ein Output Parser überhaupt greift, muss im entsprechenden Root-Node, etwa der Basic LLM Chain, die Option „Require Specific Output Format" aktiviert werden. Erst danach erscheint der Anschlusspunkt, an den Sie den Structured Output Parser, den Item List Output Parser oder den Auto-fixing Output Parser anhängen können. Für KI-Agenten gibt die Dokumentation eine offene Einschränkung mit: Strukturiertes Output-Parsing ist bei Agents oft unzuverlässig. Als Alternative wird empfohlen, eine separate LLM-Chain zu verwenden, die die Rohdaten vom Agenten entgegennimmt und erst dort in das Zielformat bringt. Für Zwischenschritte innerhalb eines Agenten-Workflows rät die Dokumentation ohnehin davon ab, den Parser einzusetzen, und empfiehlt stattdessen, die gewünschte Formatierung direkt in der System Message zu beschreiben. Wer solche Agenten-Workflows plant, findet dazu mehr unter KI-Agenten.

Fehlerbehandlung: Wenn das LLM kein valides JSON liefert

Kein Sprachmodell hält sich garantiert zu hundert Prozent an ein vorgegebenes Schema, gerade bei komplexeren Strukturen oder langen Antworten kommt es vor, dass ein Feld fehlt, ein Anführungszeichen falsch gesetzt ist oder zusätzlicher Text um das JSON herum steht. Für genau diesen Fall gibt es laut n8n-Dokumentation zum Auto-fixing Output Parser eine eigene Lösung: Der Node fungiert als Wrapper um einen bestehenden Output Parser. Schlägt der erste Parsing-Versuch fehl, ruft n8n automatisch ein zusätzliches LLM auf, das die fehlerhafte Ausgabe korrigiert und erneut in das gewünschte Format bringt. Das erhöht die Zuverlässigkeit deutlich, ersetzt aber keine Fehlerbehandlung im Workflow selbst. Wer auf Nummer sicher gehen will, sollte im Anschluss an den Parser trotzdem eine Prüfung einbauen, etwa einen Error-Trigger-Pfad oder eine Bedingung, die greift, wenn auch der Korrekturversuch scheitert. Eine Automatisierung, die stillschweigend mit leeren oder falschen Feldern weiterläuft, richtet mehr Schaden an als ein sauber protokollierter Fehlerfall.

Häufige Fragen zu strukturierten LLM-Ausgaben in n8n

Was ist der Unterschied zwischen Structured Output Parser und Auto-fixing Output Parser?

Der Structured Output Parser definiert das Zielschema und prüft die Antwort dagegen. Der Auto-fixing Output Parser legt sich als zusätzliche Sicherheitsschicht darüber: Er nutzt einen anderen Parser, etwa den Structured Output Parser, und ruft bei einem fehlgeschlagenen Parsing-Versuch ein weiteres LLM auf, um die Ausgabe zu korrigieren.

Kann ich mehrere Items gleichzeitig strukturiert parsen lassen?

Technisch ja, praktisch mit Einschränkung. Da Sub-Nodes wie der Output Parser Ausdrücke nur zum ersten Eingabe-Item auflösen, sollten Sie bei mehreren Datensätzen genau testen, ob das Ergebnis für jedes Item wie erwartet aussieht, statt sich blind auf eine Batch-Verarbeitung zu verlassen.

Garantiert der Output Parser zu hundert Prozent valides JSON?

Nein. Er erhöht die Wahrscheinlichkeit einer strukturierten, validen Antwort erheblich und der Auto-fixing Parser fängt viele Fehler zusätzlich ab, aber eine hundertprozentige Garantie gibt kein Sprachmodell. Ein sauberer Fehlerpfad im Workflow bleibt deshalb sinnvoll.

Funktioniert der Output Parser auch zuverlässig bei KI-Agenten?

Laut n8n-Dokumentation weniger zuverlässig als bei einer einfachen LLM-Chain. Für Agenten-Workflows wird empfohlen, die Formatierung entweder über die System Message zu steuern oder die Rohantwort an eine separate, nachgeschaltete LLM-Chain mit Output Parser zu übergeben.