¿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.