La salida estructurada es un método para forzar a los modelos de lenguaje a devolver datos en un formato predefinido (como JSON), lo que permite un análisis fiable, automatización e integración en sistemas de software. Se diferencia del texto libre al imponer nombres de campos estrictos, tipos de datos y esquemas que las herramientas posteriores pueden procesar sin limpieza manual.
Aquí hay un ejemplo sencillo de salida estructurada en formato JSON:
{
"task": "summarize",
"title": "Quick AI Guide",
"summary": "This article explains structured output and JSON mode.",
"key_points": ["JSON enforces format", "Reduces parsing errors", "Enables automation"],
"audience_level": "intermediate",
"confidence": 0.95
}Qué es la salida estructurada
La salida estructurada significa pedirle al modelo que siga un esquema fijo —como listas, tablas o JSON— para que las herramientas posteriores puedan analizar los resultados de forma fiable. En lugar de un párrafo libre, defines campos, tipos y valores permitidos.
La salida estructurada puede tomar varias formas:
- Listas con viñetas con un número fijo de elementos.
- Tablas Markdown con columnas específicas.
- Pares clave-valor para atributos simples.
- Objetos o arrays JSON completos con claves predefinidas.
El objetivo es siempre el mismo: convertir una descripción vaga ("algunas notas sobre la reunión") en una forma predecible ("título, fecha, asistentes, decisiones, riesgos").
Qué es el modo JSON
El modo JSON es una variante más estricta de la salida estructurada donde el modelo recibe instrucciones —o se configura— para devolver solo JSON válido. En modo JSON, todo lo que el modelo produce debe ser analizable como JSON sin limpieza adicional.
Un esquema JSON típico podría verse así:
{
"title": "string",
"summary": "string",
"tags": ["string"],
"priority": "low | medium | high"
}Reflejas ese esquema en tu prompt y luego pides al modelo que lo complete. Algunas plataformas también ofrecen configuraciones especiales o APIs que imponen respuestas solo JSON, reduciendo la probabilidad de comentarios extra.
Por qué importan la salida estructurada y el modo JSON
La salida estructurada y el modo JSON importan porque te permiten convertir los modelos de lenguaje en componentes de sistemas más grandes, no solo asistentes de chat. Cuando la salida es predecible, puedes:
- Alimentar resultados directamente a bases de datos, CRMs o herramientas de análisis.
- Activar automatizaciones basadas en campos como `priority`, `status` o `confidence`.
- Crear interfaces que muestren los resultados del modelo en tarjetas, tablas o dashboards sin formateo manual.
También facilitan la depuración de prompts. Si la estructura falla, sabes que el problema está en el prompt o el esquema, no en alguna dimensión vaga de "calidad".
Modo JSON vs llamada a funciones vs prompting con esquema
Existen tres métodos para obtener salida estructurada de los LLMs. Cada uno tiene diferentes fortalezas y debilidades:
- Modo JSON: el modelo solo devuelve JSON válido. Ideal para: extracción de datos, clasificación, resumen. Restricción: limitado al formato de salida, sin ejecución de herramientas.
- Llamada a funciones: el modelo selecciona qué función llamar y proporciona argumentos en JSON. Ideal para: integración de APIs, uso de herramientas, flujos de trabajo agénticos. Restricción: requiere esquemas de funciones predefinidos.
- Prompting con esquema: instrucciones explícitas + ejemplos pidiendo al modelo que siga un esquema. Ideal para: flexibilidad, modelos de código abierto, formatos personalizados. Restricción: ~80–85% de fiabilidad, sin garantía a nivel de API.
Ejemplo: texto libre vs JSON estructurado
La diferencia se hace evidente al comparar un prompt de texto libre con uno de JSON estructurado para la misma tarea. Aquí clasificamos y resumimos un email de cliente.
Prompt malo
"Lee este email de cliente y resume qué quieren."
Prompt bueno – modo JSON
"Eres un asistente de soporte al cliente. Lee el email del cliente a continuación y extrae la información clave en un objeto JSON. Requisitos: devuelve solo JSON válido, con claves entre comillas dobles y valores de cadena. No incluyas ninguna explicación ni texto extra fuera del JSON. Si falta un valor, usa una cadena vacía. Esquema JSON: { "issue_type": "string", "urgency": "low | medium | high", "summary": "string (máx. 25 palabras)", "customer_sentiment": "negative | neutral | positive" } Email del cliente: pega el texto del email aquí"
La versión "buena" define el esquema, los valores válidos y el requisito de solo JSON, haciendo que la salida sea fácil de analizar y usar en otros sistemas.
Mejores prácticas para la salida estructurada y el modo JSON
Para obtener salidas estructuradas fiables, debes ser explícito, consistente y estricto en tus prompts. Algunas prácticas ayudan mucho:
- Muestra el esquema exacto que esperas, incluyendo los valores permitidos para enumeraciones.
- Indica claramente que no debe devolverse nada excepto el JSON (o la estructura).
- Usa nombres de claves cortos y sin ambigüedad (por ejemplo, `issue_type`, `urgency`, `summary`).
- Añade ejemplos de salidas válidas cuando la tarea sea compleja o sensible.
- Para estructuras anidadas, constrúyelas paso a paso y prueba con entradas reales.
- Usa frameworks centrados en especificaciones como SPECS o RTF con restricciones de formato para codificar esquemas directamente en los prompts.
Si sigues viendo problemas de formato, puedes añadir una instrucción simple como "Si no estás seguro, deja el campo como cadena vacía en lugar de adivinar." La salida estructurada funciona mejor cuando se combina con RAG (Retrieval-Augmented Generation) para verificar datos extraídos. Cuando los datos extraídos deben mantenerse en infraestructura privada, los mismos patrones de modo JSON se conectan a un almacén vectorial local.
Comparación de modelos: cumplimiento JSON por proveedor
Diferentes modelos tienen diferentes niveles de soporte nativo para el modo JSON. A partir de abril de 2026, así se clasifican los principales proveedores:
| Modelo | Modo JSON nativo | Cumplimiento solo con prompt | Notas |
|---|---|---|---|
| OpenAI GPT-4o | Sí (impuesto) | No necesario | Estándar de la industria para el modo JSON; tasa de éxito > 99%. |
| Anthropic Claude 3.5 Sonnet | Sí (impuesto) | No necesario | Excelente cumplimiento JSON; admite estructuras anidadas complejas. |
| Google Gemini 2.0 | Sí (impuesto) | No necesario | Soporte JSON nativo; inferencia rápida. |
| Meta Llama 3.1 (70B) | Parcial | Muy recomendado | Código abierto; funciona bien con prompts detallados y ejemplos. |
| Mistral Large | Parcial | Recomendado | Buen comportamiento JSON; prueba con tu esquema específico. |
| GPT-3.5 antiguo, Claude 2 | No | Requerido | Requiere prompt engineering sólido; ~80–85% de tasa de éxito. |
| Modelos pequeños de código abierto (<13B) | No | Requerido con ejemplos | Necesitan esquemas detallados y múltiples ejemplos; ~60–70% de tasa de éxito. |
Salida estructurada en entornos regulados
La salida estructurada es especialmente valiosa en industrias reguladas porque impone una extracción de datos consistente, registros de auditoría y documentación de cumplimiento. Las diferentes regiones tienen diferentes requisitos:
- UE (RGPD, AI Act): la salida estructurada permite la clasificación sistemática de datos y el seguimiento del derecho de supresión. El modo JSON te permite etiquetar qué campos contienen datos personales, facilitando las EIPD y las auditorías de cumplimiento.
- Japón (Directrices IA de METI, APPI): la extracción estructurada con definiciones claras de esquemas apoya los requisitos de transparencia y responsabilidad. El cumplimiento del AI Act en Japón suele requerir documentar cómo se procesan los datos.
- China (Regulaciones CAC, Ley de Seguridad de Datos): la salida estructurada ayuda con la moderación de contenidos y el registro de residencia de datos. El modo JSON permite la clasificación sistemática de contenido sensible para el cumplimiento de los estándares CAC.
Errores comunes
Evita estos errores frecuentes al implementar salida estructurada y modo JSON:
- Esquemas ambiguos: decir "extrae los puntos clave" sin definir un esquema lleva a salidas inconsistentes. Siempre especifica nombres de campos, tipos y restricciones exactos.
- Falta de ejemplos: proporcionar solo una descripción del esquema sin ejemplos causa tasas de fallo del 20–30%. Siempre muestra 1–3 ejemplos de salida válida.
- No validar la salida: asumir que el modelo siempre devolverá JSON válido lleva a errores de análisis en producción. Siempre valida y maneja los fallos de análisis con gracia.
- No manejar casos límite: los campos que podrían faltar, ser ambiguos o estar fuera de rango deben tener un comportamiento de respaldo definido (null, cadena vacía o valor por defecto).
- Probar solo con entradas fáciles: los datos del mundo real son desordenados. Prueba tu esquema con casos límite: emails incompletos, caracteres especiales, idiomas mezclados, entradas muy largas.
Cuándo usar modo JSON vs alternativas
Elige el modo JSON cuando necesites imposición estricta del esquema y salida determinista. Evítalo cuando la creatividad y el razonamiento abierto son lo que importa.
- ✓ Usa el modo JSON: se requiere esquema estricto, pipelines de automatización, integración de APIs, extracción de datos, tareas de clasificación, salidas deterministas, sistemas de producción que requieren validación.
- ✗ Evita el modo JSON: escritura creativa, razonamiento abierto, lluvia de ideas, ensayos, generación de código (la llamada a funciones es mejor), preguntas filosóficas, contenido narrativo.
- Alternativa: usa llamada a funciones cuando necesites integración de herramientas y flujos de trabajo agénticos (el modelo selecciona qué función llamar).
- Alternativa: usa prompting con esquema cuando necesites flexibilidad, trabajes con modelos de código abierto o no necesites garantías a nivel de API.
¿Cuándo deberías usar salida estructurada?
La salida estructurada brilla en tres escenarios principales. Úsala cuando necesitas resultados deterministas y legibles por máquinas:
- APIs e integraciones: conecta la salida del LLM directamente a sistemas posteriores (bases de datos, CRMs, dashboards). La salida estructurada previene errores de análisis y limpieza manual. Ejemplo: extrae datos de clientes de emails y escribe en el CRM.
- Automatización y flujos de trabajo: activa acciones basadas en campos de salida del modelo (prioridad, urgencia, categoría). El modo JSON garantiza una extracción fiable de campos para lógica condicional. Ejemplo: enruta tickets de soporte por nivel de urgencia.
- Pipelines de datos: procesa datos en volumen (documentos, emails, registros) a escala. Los esquemas consistentes permiten el procesamiento por lotes, la validación y el manejo de errores. Ejemplo: extrae metadatos de 10.000 artículos de investigación en una base de datos con búsqueda.
Cómo usar la salida estructurada y el modo JSON
- 1Para extracción de datos y salidas legibles por máquinas, usa el modo JSON (disponible en OpenAI GPT-4o, Anthropic Claude, Google Gemini y otros). Esto garantiza que el modelo devuelva JSON válido, no prosa. Ejemplo: extrae información de producto como JSON con las claves: nombre, precio, descripción, valoración.
- 2Define tu esquema JSON de forma explícita, incluyendo nombres de campos, tipos de datos y restricciones. Ejemplo: { "name": string, "price": number (≥ 0), "in_stock": boolean, "tags": array de strings }.
- 3Proporciona un ejemplo de la estructura JSON exacta que quieres. Ejemplo: { "issue": "memory leak", "severity": "critical", "suggested_fix": "...", "code_snippet": "..." }. Los ejemplos son más potentes que las descripciones de esquemas.
- 4Para estructuras anidadas (objetos dentro de arrays), sé explícito sobre la jerarquía. Proporciona un ejemplo JSON completo, incluyendo arrays anidados.
- 5Valida la salida JSON antes de usarla en sistemas posteriores. Analiza el JSON devuelto y comprueba: (1) es sintaxis JSON válida, (2) todos los campos requeridos están presentes, (3) los tipos de datos coinciden con lo esperado. Maneja los errores de análisis con gracia.
Aquí hay un ejemplo JSON completo con arrays anidados, mostrando la jerarquía correcta:
{
"articles": [
{
"title": "string",
"author": "string",
"citations": [
{
"title": "string",
"year": "number"
}
]
}
]
}Lecturas relacionadas
Amplía tu conocimiento con estos temas relacionados de prompt engineering:
- Prompting con restricciones — impone formatos de salida específicos y presupuestos de tokens.
- Framework SPECS — prompts centrados en especificaciones para un comportamiento fiable del modelo.
- RAG explicado — combina extracción estructurada con recuperación de datos en tiempo real.
- Chain of Thought — razona paso a paso antes de devolver salidas estructuradas.
- Plantillas de prompts — patrones reutilizables para tareas comunes de salida estructurada.
- Zero-Shot vs Few-Shot — cuándo los ejemplos (few-shot) mejoran el cumplimiento JSON.
Preguntas frecuentes
¿Cuál es la diferencia entre salida estructurada y modo JSON?
La salida estructurada es la categoría más amplia de pedirle al modelo que devuelva datos en un formato fijo (listas, tablas, pares clave-valor o JSON). El modo JSON es una variante más estricta que impone una salida JSON válida, a menudo con garantías a nivel de API del proveedor del modelo.
¿Todos los LLMs admiten el modo JSON?
No. OpenAI GPT-4o, Anthropic Claude 3.5+ y Google Gemini admiten el modo JSON nativo. Los modelos más antiguos y los LLMs de código abierto pueden requerir aplicación basada en prompts.
¿Cómo fuerzo respuestas solo JSON sin modo JSON nativo?
Usa prompt engineering: (1) declara explícitamente "devuelve solo JSON válido", (2) proporciona un esquema detallado y ejemplos, (3) añade una instrucción como "No incluyas ningún texto fuera del JSON". Las tasas de éxito mejoran significativamente con buenos ejemplos.
¿Qué pasa si el modelo devuelve JSON inválido?
Valida el JSON de tu parte usando un analizador. Si falla, reintenta la solicitud con un prompt más claro o recurre a la extracción manual. Con un buen prompt engineering y ejemplos de esquemas, las tasas de fallo son bajas (generalmente < 5% para prompts bien diseñados).
¿Puedo usar salida estructurada para documentos complejos?
Sí. Divide las tareas complejas en pasos: primero extrae los campos clave, luego valida, luego opcionalmente transforma en sistemas posteriores. Dividir documentos grandes y procesarlos por separado suele mejorar la fiabilidad y reducir el uso de tokens.
¿Cómo manejo datos faltantes o ambiguos en salidas estructuradas?
Define el comportamiento de respaldo en tu esquema: usa cadenas vacías, valores null o un marcador especial como "desconocido". Añade la instrucción: "Si un valor es ambiguo o falta, usa null en lugar de adivinar."
¿El modo JSON está afectado por la conformidad regulatoria (RGPD, CCPA)?
El modo JSON en sí es neutro. Sin embargo, la salida estructurada es beneficiosa para la conformidad porque te permite rastrear sistemáticamente qué datos se extraen, transforman y registran, algo crítico para los registros de auditoría.
¿Cómo pruebo los prompts en modo JSON?
Prueba con entradas diversas: casos límite, datos ambiguos y ejemplos del mundo real. Analiza la salida y verifica: (1) JSON válido, (2) esquema correcto, (3) tipos de datos esperados. Apunta a una tasa de éxito ≥95% antes de desplegar en producción.
¿Puedo reutilizar esquemas de salida estructurada en diferentes modelos?
Sí, con precaución. Define tu esquema una vez y pruébalo en diferentes modelos; puede que necesites ajustar los prompts para modelos más antiguos o pequeños. Documenta cualquier diferencia específica del modelo y las tasas de éxito.
¿Cuál es el costo de rendimiento del modo JSON?
Mínimo. El modo JSON nativo (OpenAI, Anthropic, Google) tiene un impacto de rendimiento despreciable. La aplicación solo con prompt puede añadir un 5–10% de latencia debido a la sobrecarga de explicación del esquema, pero las ganancias en seguridad suelen justificarlo.
Fuentes
- Documentación del modo JSON de OpenAI — Guía oficial del modo JSON en la API de OpenAI.
- Guía de salida estructurada de Anthropic — Documentación de Anthropic para salida estructurada en Claude.
- API de Google Gemini – Salida estructurada — Soporte nativo del modo JSON de Google en Gemini 2.0.
- Especificación de JSON Schema — Especificación estándar para el diseño y validación de JSON Schema.