Salidas estructuradas

Una salida estructurada obliga a que la respuesta siga un schema: campos, tipos, valores permitidos y relaciones básicas. Es la diferencia entre integrar texto que «parece JSON» y recibir datos que tu programa puede procesar con un contrato conocido.

Pedir JSON no basta

Un bloque JSON puede ser sintácticamente válido y aun así:

• omitir un campo obligatorio;
• devolver una fecha o enum inventado;
• usar texto donde esperabas un número;
• incluir claves no permitidas;
• violar una regla de negocio.

Cuando la plataforma ofrece structured outputs o tool calling con schema, úsalo. El modelo queda limitado a una gramática compatible y reduces fallos de parseo. Aun así, la corrección semántica requiere validación.

Diseña schemas para el modelo y para tu código

• usa nombres claros y descripciones breves;
• marca explícitamente campos obligatorios;
• prefiere enums a variantes libres cuando el catálogo sea cerrado;
• representa ausencia de forma intencional, por ejemplo con un campo opcional o estado «sin_evidencia»;
• limita longitudes y rangos cuando el contrato lo permita;
• evita schemas gigantes con muchas ramas en una sola llamada;
• versiona el schema si otros componentes dependen de él.

Un ejemplo de contrato

El schema garantiza forma. No garantiza que la confianza esté bien calibrada ni que la evidencia respalde la decisión.

Estrategia de errores

1. valida la respuesta en el límite de tu aplicación;
2. si el error es reparable, devuelve al modelo el fallo exacto;
3. limita los reintentos;
4. registra el caso para la suite de evaluación;
5. usa fallback o revisión humana si sigue inválido.

No parses con expresiones regulares un párrafo esperando encontrar JSON en medio. Tampoco ejecutes directamente código o argumentos generados.

Temas relacionados

El schema nace de Prompts e instrucciones, se protege con Validación y también es el contrato de una tool.