Salidas de LLM estructuradas: Output Parser

El node Output Parser en n8n obliga a que las respuestas del LLM se entreguen como JSON estructurado, en lugar de depender de texto libre: define un esquema que el modelo de lenguaje debe seguir, y la Basic LLM Chain o el agente IA devuelve después el resultado exactamente en ese formato. Para empresas que quieren enviar automáticamente las respuestas del LLM a un CRM, un ERP o bases de datos, esa es la diferencia entre campos evaluables de forma fiable y un tedioso retrabajo manual de respuestas de texto. Fecha: julio de 2026.

Por qué el texto libre falla en las automatizaciones

Sin indicaciones adicionales, un modelo de lenguaje devuelve respuestas en lenguaje natural. Para una interfaz de chat eso es deseable, pero para un paso de flujo de trabajo que debe alimentar la respuesta a un sistema posterior, es un problema. Sin una estructura fija hay que trabajar con fragmentos de texto, expresiones regulares o pasos intermedios adicionales para extraer valores individuales, y cualquier pequeño cambio en la formulación del modelo puede romper esa extracción. Aquí es exactamente donde entra el node Output Parser: le da al modelo un esquema y garantiza que la respuesta vuelva como JSON válido con campos claramente nombrados, listos para procesarse directamente en los nodes siguientes.

El Structured Output Parser: imponer un esquema JSON

Según la documentación de n8n sobre el Structured Output Parser, el node devuelve campos basados en un esquema JSON y estructura la salida del LLM en consecuencia. Para la definición del esquema hay dos vías disponibles:

• Generate from JSON Example: Introduce un JSON de ejemplo, y el node deriva automáticamente el esquema a partir de él. Solo se usan los tipos y nombres de las propiedades del objeto; los valores reales del ejemplo no importan. En este modo, todos los campos se consideran obligatorios.
• Define using JSON Schema: Crea el esquema manualmente. La documentación señala expresamente que las referencias con `$ref` no se admiten en este esquema.

Importante para el uso práctico: los sub-nodes como este Output Parser procesan las expresiones de forma distinta a los nodes normales. Con varios items de entrada, según la documentación una expresión siempre se resuelve solo para el primer item, no para cada item por separado. Esto puede provocar resultados inesperados al procesar varios registros en lote y debe probarse de antemano.

Conexión con la Basic LLM Chain o el agente IA

Para que un Output Parser surta efecto, hay que activar la opción "Require Specific Output Format" en el node raíz correspondiente, por ejemplo la Basic LLM Chain. Solo entonces aparece el punto de conexión al que puede vincular el Structured Output Parser, el Item List Output Parser o el Auto-fixing Output Parser. Para agentes IA, la documentación incluye una advertencia abierta: el parseo estructurado de la salida suele ser poco fiable con agentes. Como alternativa, se recomienda usar una LLM Chain separada que reciba los datos brutos del agente y solo entonces los convierta al formato objetivo. Para pasos intermedios dentro de un flujo de trabajo de agente, la documentación de todos modos desaconseja usar el parser, y en su lugar recomienda describir el formato deseado directamente en el System Message. Quien planee este tipo de flujos de trabajo con agentes puede encontrar más información en Agentes IA.

Manejo de errores: cuando el LLM no entrega JSON válido

Ningún modelo de lenguaje sigue garantizado al cien por cien un esquema dado; especialmente con estructuras más complejas o respuestas largas, puede ocurrir que falte un campo, que una comilla esté mal colocada o que haya texto adicional alrededor del JSON. Para este caso exacto existe una solución propia según la documentación de n8n sobre el Auto-fixing Output Parser: el node actúa como un wrapper alrededor de un Output Parser existente. Si el primer intento de parseo falla, n8n llama automáticamente a un LLM adicional que corrige la salida errónea y la devuelve al formato deseado. Esto aumenta notablemente la fiabilidad, pero no sustituye el manejo de errores dentro del propio flujo de trabajo. Quien quiera ir sobre seguro debería, aun así, añadir una comprobación después del parser, por ejemplo una ruta de error-trigger o una condición que se active si también falla el intento de corrección. Una automatización que continúa en silencio con campos vacíos o incorrectos causa más daño que un caso de error registrado correctamente.

Preguntas frecuentes sobre salidas de LLM estructuradas en n8n

¿Cuál es la diferencia entre el Structured Output Parser y el Auto-fixing Output Parser?

El Structured Output Parser define el esquema objetivo y comprueba la respuesta frente a él. El Auto-fixing Output Parser se añade como una capa de seguridad adicional: usa otro parser, por ejemplo el Structured Output Parser, y llama a un LLM adicional cuando falla un intento de parseo, para corregir la salida.

¿Puedo parsear varios items de forma estructurada al mismo tiempo?

Técnicamente sí, en la práctica con una limitación. Como los sub-nodes como el Output Parser solo resuelven expresiones para el primer item de entrada, debería probar con cuidado, con varios registros, si el resultado tiene el aspecto esperado para cada item, en lugar de confiar ciegamente en el procesamiento por lotes.

¿Garantiza el Output Parser un JSON válido al cien por cien?

No. Aumenta considerablemente la probabilidad de una respuesta estructurada y válida, y el Auto-fixing Parser además atrapa muchos errores, pero ningún modelo de lenguaje da una garantía del cien por cien. Por eso sigue siendo útil una ruta de error limpia en el flujo de trabajo.

¿Funciona el Output Parser también de forma fiable con agentes IA?

Según la documentación de n8n, es menos fiable que con una LLM Chain simple. Para flujos de trabajo con agentes, se recomienda controlar el formato mediante el System Message o pasar la respuesta en bruto a una LLM Chain separada y posterior con Output Parser.