Cea mai mare provocare în automatizarea fluxurilor cu LLM-uri este imprevizibilitatea formatului: chiar dacă ceri modelului să răspundă doar în JSON, acesta tinde să adauge comentarii de introducere (‘Iată datele tale:’) sau blocuri Markdown de tip „`json, care blochează execuția nodurilor ulterioare de baze de date.
Nodul Structured Output Parser (sau Auto-fixing Output Parser) din suita n8n AI rezolvă această problemă la nivel arhitectural. Utilizatorul definește schema dorită folosind standardul JSON Schema sau Zod. Modelul este constrâns prin funcția nativă de Structured Outputs a furnizorului de API să respecte structura cu acuratețe matematică.
Dacă modelul generează un format invalid, nodul ‘Auto-fixing’ interceptează automat eroarea, retrimite schema către LLM împreună cu eroarea de parsare și solicită remedierea instantanee înainte de a transmite datele mai departe către PostgreSQL sau HubSpot.
Sintaxă, opțiuni și concepte cheie
| Opțiune / Concept | Descriere practică |
|---|---|
JSON Schema Definition |
Structura ierarhică ce definește tipul proprietăților: `string`, `number`, `boolean`, `array`. |
Required Fields |
Lista câmpurilor obligatorii fără de care obiectul este respins. |
Auto-fixing Parser |
Mecanismul de re-încercare automată în caz de eroare sintactică. |
Direct DB Mapping |
Posibilitatea de a mapa direct proprietățile JSON pe coloanele tabelelor SQL din nodurile următoare. |
Strict Mode |
Activarea constrângerilor stricte de gramatică la nivel de provider (ex. OpenAI Structured Outputs). |
Exemple practice și configurații
Exemplul 1: Extragerea structurată a detaliilor dintr-o factură primită pe email
Definirea schemei JSON pentru parsarea automată a datelor contabile.
Schema JSON configurată în nodul Structured Output Parser:
{
"type": "object",
"properties": {
"furnizor": { "type": "string" },
"cui": { "type": "string" },
"numar_factura": { "type": "string" },
"total_tva": { "type": "number" },
"total_plata": { "type": "number" },
"moneda": { "type": "string", "enum": ["RON", "EUR", "USD"] }
},
"required": ["furnizor", "numar_factura", "total_plata", "moneda"]
}
Rezultatul curat returnat direct la ieșirea nodului:
{
"furnizor": "Cloud Hosting SRL",
"cui": "RO12345678",
"numar_factura": "INV-2025-99",
"total_tva": 19.0,
"total_plata": 119.0,
"moneda": "RON"
}Rezultat & Impact
Datele sunt inserate direct în PostgreSQL printr-un nod standard SQL cu zero linii de cod suplimentar.Greșeli frecvente și bune practici
- Definirea unor scheme prea rigide cu proprietăți imbricate inutile care cresc latența și consumul de tokeni de raționament.
- Neconfigurarea opțiunii de tratare a erorilor pe nodul parser, cauzând oprirea workflow-ului la prima factură scanată neclară.