¿Cuál es la forma más reciente (2026) de obtener una salida JSON estructurada confiable de LLMs locales en n8n?
Estoy usando modelos locales (a través de Ollama) en n8n y necesito una salida JSON consistente para cosas como enrutamiento y generación de SQL.
¿Cuál es la mejor práctica actual que la gente está usando en 2026?
¿Sigue la gente confiando en:
¿O existe un enfoque más nuevo y confiable?
No haría de esto un problema de una sola capa.
Para flujos de trabajo relacionados con enrutamiento o SQL, trataría JSON como un contrato de interfaz:
Específicamente para SQL, evitaría permitir que el modelo produzca SQL sin formato que se ejecute directamente. Un patrón más seguro es que el modelo genere intención estructurada, filtros y opciones de tabla/campo desde una lista permitida, y luego asignes eso a una plantilla de consulta que controles.
Entonces, la parte confiable no es solo «¿puede el modelo emitir JSON?» Es «¿qué sucede cuando el JSON falta, está mal formado, es válido pero incorrecto o no es seguro?»
Buena pregunta — he trabajado bastante con Ollama + n8n en esto. Aquí está lo que realmente funciona de forma confiable en 2026:
**1. Usa el parámetro nativo `format: json` de Ollama (capa más confiable)**
Cuando configures el nodo Ollama Chat Model, añade `format: json` en los campos adicionales / parámetros del modelo. Esto obliga a Ollama a limitar el muestreo de tokens solo a tokens JSON válidos — no es ingeniería de prompts, está aplicado a nivel del modelo. Modelos como `llama3`, `mistral` y `qwen2.5` lo soportan bien. Esto solo elimina ~80% de la salida malformada.
**2. Combínalo con el Structured Output Parser de n8n**
Combina Ollama format:json + el Structured Output Parser (con un JSON Schema). El esquema le dice al modelo qué campos esperas; el parser valida y extrae. Si haces enrutamiento, tu esquema podría ser tan simple como `{ “route”: { “type”: “string”, “enum”: [“billing”, “support”, “sales”] } }`.
**3. Nodo Code como red de seguridad**
Después del parser, añade un nodo Code que haga:
```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 }];
```
Esto bloquea los nodos posteriores para que nunca enrutes mal silenciosamente.
**4. Para SQL intent específicamente**
No le pidas al modelo que genere SQL. Pídele que genere intención estructurada: `{ “table”: “orders”, “filters”: [{“field”: “status”, “op”: “eq”, “value”: “pending”}], “limit”: 10 }`. Entonces tu nodo Code mapea eso a una consulta parametrizada. Mucho más seguro y confiable que SQL de forma libre.
**5. Bucle de reparación de un intento si es necesario**
Para esquemas complejos donde el modelo aún falla ocasionalmente, conecta un nodo IF que verifique errores de parseo → reenvía a Ollama con el mensaje de error añadido al prompt. Un reintentos atrapa la mayoría de casos rezagados. Si falla dos veces, enruta a un fallback/revisión humana en lugar de adivinar.
La combinación de format:json + esquema + validación Code es lo que uso en flujos de estilo producción. Funciona sin nodos pagados.
¡Bienvenido @osman1!
Una cosa que vale la pena añadir a la pila: n8n tiene un nodo “Auto-fixing Output Parser” que envuelve el Structured Output Parser. Si el modelo devuelve JSON malformado, automáticamente envía el error de vuelta al LLM para un único intento de auto-reparación - sin necesidad de lógica manual IF/retry. Para Ollama específicamente, también pasa format: "json" en las opciones de body del nodo Ollama Chat Model para restringir el muestreo de tokens a nivel de modelo, luego deja que el Auto-fixing Parser refuerce tu esquema encima. Esa configuración de dos capas (restricción de formato a nivel de modelo + reparación a nivel de parser) es el enfoque más confiable que he usado con modelos locales.
Las respuestas anteriores cubren bien la capa estructural. Una capa más que vale la pena añadir es la validación semántica — detectar JSON que se analiza correctamente pero contiene valores que no tienen sentido.
Algunos ejemplos: un campo de fecha que se analiza como una cadena pero no es una fecha válida. Un campo de estado con el tipo correcto pero un valor fuera de la enumeración permitida. Un campo de precio o cantidad con un formato plausible pero un rango implausible (0,0001 o 99999999). El analizador que se corrige automáticamente maneja el caso en que el modelo devuelve JSON malformado e intenta de nuevo una vez. Pero si el reintento tiene éxito estructuralmente, el resultado sigue fluyendo hacia abajo incluso si los valores no tienen sentido. La capa estructural no sabe que shipping_cost nunca debe ser negativo.
La solución es un nodo Code después del analizador que ejecuta comprobaciones explícitas: presencia de campos obligatorios, aserciones de tipo, pertenencia a enumeración y protecciones de rango. Si alguna comprobación falla, detén el elemento o enrútalo a una cola de revisión en lugar de dejar que datos incorrectos fluyan hacia adelante.
La parte que rinde beneficios con el tiempo es registrar cada fallo con la salida bruta del LLM, el campo que falló y una marca de tiempo. Dos cosas se hacen visibles en ese registro que no lo son de otra manera: qué campos fallan el 30 por ciento de las veces (un problema de prompt que vale la pena corregir) versus cuáles fallan el 1 por ciento de las veces (un caso extremo a manejar en el enrutamiento). Y cuando actualizas el modelo local, puedes comparar las tasas de fallo antes y después.
Las comprobaciones estructurales que Tony y pirateprentice describieron son la capa inicial correcta. La capa semántica es lo que convierte „se analiza