Welche ist die aktuelle Methode (2026), um zuverlässige strukturierte JSON-Ausgaben von lokalen LLMs in n8n zu erhalten?
Ich verwende lokale Modelle (über Ollama) in n8n und benötige konsistente JSON-Ausgaben für Dinge wie Routing und SQL-Generierung.
Welche Best Practice verwenden die Leute derzeit 2026?
Verlassen sich die Leute immer noch auf:
Oder gibt es einen neueren, zuverlässigeren Ansatz?
Ich würde dies nicht als einschichtiges Problem behandeln.
Für Routing- oder SQL-bezogene Workflows würde ich JSON als Schnittstellen-Vertrag behandeln:
Für SQL speziell würde ich vermeiden, das Modell rohes SQL produzieren zu lassen, das direkt ausgeführt wird. Ein sichereres Muster besteht darin, das Modell strukturierte Absicht, Filter, Tabellen-/Feldauswahl aus einer Allowlist ausgeben zu lassen und diese dann einer Abfragevorlage zuzuordnen, die du kontrollierst.
Also ist der zuverlässige Teil nicht nur „kann das Modell JSON ausgeben?
Gute Frage — ich habe das mit Ollama + n8n ziemlich intensiv durchgearbeitet. Hier ist, was 2026 wirklich zuverlässig funktioniert:
**1. Nutze Ollamás nativen `format: json`-Parameter (zuverlässigste Ebene)**
Wenn du den Ollama Chat Model-Node konfigurierst, füge `format: json` in den zusätzlichen Feldern/Modellparametern hinzu. Das zwingt Ollama, sein Token-Sampling auf gültige JSON-Token zu beschränken — das ist keine Prompt-Engineering, es wird auf Modellebene erzwungen. Modelle wie `llama3`, `mistral` und `qwen2.5` unterstützen das gut. Das allein eliminiert etwa 80% fehlerhafter Ausgaben.
**2. Kombiniere es mit n8ns Structured Output Parser**
Stapele Ollama format:json + den Structured Output Parser (mit einem JSON Schema). Das Schema sagt dem Modell, welche Felder du erwartest; der Parser validiert und extrahiert sie. Wenn du Routing machst, könnte dein Schema so einfach sein wie `{ “route”: { “type”: “string”, “enum”: [“billing”, “support”, “sales”] } }`.
**3. Code-Node als dein Sicherheitsnetz**
Füge nach dem Parser einen Code-Node hinzu, der das macht:
```js
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 }];
```
Das blockiert nachgelagerte Nodes, damit du niemals versehentlich falsch routest.
**4. Speziell für SQL-Intent**
Ask das Modell nicht, SQL auszugeben. Frag es, strukturierte Intent auszugeben: `{ “table”: “orders”, “filters”: [{“field”: “status”, “op”: “eq”, “value”: “pending”}], “limit”: 10 }`. Dann mapped dein Code-Node das zu einer parametrisierten Query. Viel sicherer und zuverlässiger als freies SQL.
**5. Eine-Shot-Repair-Loop, falls nötig**
Bei komplexeren Schemas, wo das Modell noch gelegentlich scheitert, verbinde einen IF-Node, der auf Parse-Fehler prüft → sende erneut an Ollama mit der Fehlermeldung an den Prompt angehängt. Ein Retry fängt die meisten Nachzügler. Wenn es zweimal scheitert, route zu einem Fallback/zur manuellen Überprüfung, statt zu raten.
Die Kombination aus format:json + Schema + Code-Validierung ist das, was ich in produktionsähnlichen Workflows nutze. Funktioniert ohne kostenpflichtige Nodes.
Willkommen @osman1!
Eine Sache, die es sich lohnt zum Stack hinzuzufügen: n8n hat einen „Auto-fixing Output Parser
Die obigen Antworten decken die strukturelle Ebene gut ab. Eine weitere Ebene, die es wert ist, hinzugefügt zu werden, ist semantische Validierung – das Erfassen von JSON, das sauber analysiert wird, aber Werte enthält, die keinen Sinn ergeben.
Einige Beispiele: Ein Datumsfeld, das als String analysiert wird, aber kein gültiges Datum ist. Ein Statusfeld mit dem richtigen Typ, aber einem Wert außerhalb der zulässigen Enumeration. Ein Preis- oder Zählfeld mit plausiblem Format, aber implausiblem Bereich (0,0001 oder 99999999). Der automatische Parsing-Reparaturmechanismus behandelt den Fall, in dem das Modell malformed JSON zurückgibt, und versucht es erneut. Aber wenn der erneute Versuch strukturell erfolgreich ist, fließt die Ausgabe weiterhin downstream, auch wenn die Werte unsinnig sind. Die strukturelle Ebene weiß nicht, dass shipping_cost niemals negativ sein sollte.
Die Lösung ist ein Code-Node nach dem Parser, der explizite Überprüfungen durchführt: Anwesenheit erforderlicher Felder, Typ-Assertions, Enum-Mitgliedschaft und Range Guards. Wenn eine Überprüfung fehlschlägt, stoppe das Element oder leite es in eine Review-Warteschlange um, anstatt es zuzulassen, dass schlechte Daten weiterfließen.
Das Teil, das sich im Laufe der Zeit auszahlt, ist das Protokollieren jedes Fehlers mit der rohen LLM-Ausgabe, dem Feld, das fehlgeschlagen ist, und einem Zeitstempel. Zwei Dinge werden in diesem Protokoll sichtbar, die sonst nicht sichtbar sind: Welche Felder 30 Prozent der Zeit fehlschlagen (ein Prompt-Problem, das es wert ist, behoben zu werden) versus welche 1 Prozent der Zeit fehlschlagen (ein Edge Case, das bei der Weiterleitung behandelt werden muss). Und wenn du das lokale Modell upgradest, kannst du die Fehlerquoten vor und nach dem Upgrade vergleichen.
Die strukturellen Überprüfungen, die Tony und pirateprentice beschrieben haben, sind die richtige erste Ebene. Die semantische Ebene ist das, was „es analysiert