IA 360
Actualidad

OpenAI fuerza respuestas JSON exactas con Structured Outputs

OpenAI incorpora Structured Outputs a su API para que GPT-4o y GPT-4o mini respondan conforme a un esquema JSON definido por el desarrollador. La función reduce un problema habitual al conectar modelos con aplicaciones y bases de datos.

4 min de lectura Generado con IA Read in English
OpenAI fuerza respuestas JSON exactas con Structured Outputs

El 6 de agosto de 2024, OpenAI presentó Structured Outputs para exigir que una respuesta de la API se ajuste a un esquema JSON declarado. El anuncio y guía técnica documenta modelos compatibles, modos de uso, evaluaciones y límites: la función controla la forma de la salida, pero no garantiza que los valores sean verdaderos.

La novedad está disponible en los modelos GPT-4o-2024-08-06 y GPT-4o mini-2024-07-18. Según OpenAI, sus pruebas internas sitúan a GPT-4o con Structured Outputs en el 100% de cumplimiento de esquemas complejos, frente a menos del 40% de GPT-4-0613 con los mecanismos anteriores. Fuente primaria.

Del JSON válido al JSON utilizable

JSON es un formato de texto muy usado para intercambiar datos entre programas. Una tienda, por ejemplo, puede necesitar que un modelo extraiga de una consulta el nombre de un producto, una categoría, un precio máximo y una lista de filtros. No basta con que el modelo responda en JSON: debe usar exactamente esos campos, con los tipos de datos previstos y sin inventar otros.

Hasta ahora, los desarrolladores podían pedir una respuesta JSON o describir el formato en el mensaje enviado al modelo. Eso reducía errores, pero no los eliminaba. El modelo podía omitir un campo obligatorio, devolver una cifra como texto o añadir una explicación antes del objeto JSON. Cualquiera de esos fallos obliga a crear validaciones, reintentos y reglas adicionales en el software que recibe la respuesta.

Structured Outputs permite definir un esquema mediante JSON Schema, una especificación que describe qué datos son admisibles: campos obligatorios, valores posibles, objetos anidados o listas. Para esquemas compatibles y solicitudes que no sean rechazadas, la API busca que la respuesta se ajuste a esa definición cuando se activa la opción strict: true.

Dos vías para usar la función

OpenAI ha integrado esta capacidad en dos partes de la API. La primera son las llamadas a funciones o herramientas: el desarrollador describe una acción que el modelo puede solicitar, como consultar un catálogo, reservar una cita o buscar un pedido. Con el modo estricto, los argumentos de esa llamada deben seguir el esquema declarado.

La segunda es el formato de respuesta. En lugar de pedir simplemente JSON, la aplicación puede enviar un esquema bajo el formato json_schema y recibir una salida preparada para ser procesada por código.

Esto no significa que el modelo pase a saber datos que no conoce ni que deje de cometer errores de razonamiento. Garantiza la forma de la respuesta, no la verdad de su contenido. Si se le pide clasificar una reclamación o extraer datos de un documento ambiguo, todavía puede interpretar mal el texto; la diferencia es que entregará esa interpretación en una estructura previsible.

Menos trabajo de integración

La mejora tiene especial valor en usos donde el modelo es una pieza dentro de un proceso mayor, no un chatbot aislado. Sirve para transformar facturas en registros, convertir conversaciones en formularios, extraer información de contratos, generar interfaces a partir de instrucciones o alimentar sistemas de atención al cliente.

También reduce la distancia entre un prototipo y un producto. Un desarrollador puede enseñar una demostración con respuestas libres en minutos, pero desplegarla requiere tratar excepciones: campos ausentes, formatos inválidos y resultados que rompen una automatización. Forzar el esquema no sustituye las comprobaciones de negocio —por ejemplo, verificar que un importe existe realmente en una base de datos—, pero elimina una clase frecuente de fallos de formato.

OpenAI mantiene el soporte para JSON Schema dentro de un subconjunto de la especificación, una restricción razonable para que el sistema pueda garantizar el cumplimiento. La documentación también contempla las negativas por seguridad: si el modelo rechaza una petición, la aplicación puede distinguir esa negativa de una respuesta estructurada normal.

La función llega sin un precio específico adicional: se utiliza con las tarifas de los modelos compatibles. GPT-4o cuesta 5 dólares por millón de tokens de entrada y 15 dólares por millón de tokens de salida; GPT-4o mini, 15 céntimos y 60 céntimos, respectivamente. Fuente primaria.

El movimiento muestra dónde se está librando una parte menos vistosa de la competencia entre modelos: no solo en responder mejor a una pregunta, sino en comportarse de forma suficientemente predecible para integrarse en programas reales. Para las empresas, esa fiabilidad de formato puede importar más que una mejora marginal en la calidad de una conversación.

Hay tres clases de validez

Una salida puede ser JSON válido y seguir incumpliendo el esquema; puede cumplir el esquema y contener un dato imposible; puede superar ambas capas y violar una regla del negocio. Structured Outputs actúa sobre la segunda frontera. La aplicación conserva validación semántica, permisos, consulta a la base real y confirmación antes de una acción irreversible.

Un campo de precio con tipo numérico evita recibir una frase, pero no impide un importe inventado. Un valor enumerado limita las etiquetas posibles, pero no demuestra que la clasificación sea correcta. El esquema reduce estados inesperados; no convierte la predicción en registro de verdad.

Diseñar un esquema que pueda fallar bien

Los campos obligatorios deben ser realmente obtenibles. Cuando un documento puede omitir un dato, conviene representar ausencia de forma explícita en vez de obligar al modelo a completarlo. También se separan “no encontrado”, “ambiguo” y “rechazado por seguridad”, porque cada estado conduce a una acción distinta.

La prueba incluye entradas vacías, contradictorias, enormes, multilingües y hostiles. Se comprueba que la negativa no se interprete como datos normales y que un corte por longitud no termine aceptado como objeto completo. Cada error se registra con esquema, modelo y versión; reintentar a ciegas puede multiplicar coste sin corregir la causa.

El contrato sirve a ambos lados

El equipo consumidor fija significado, unidades y ejemplos, mientras el equipo que llama al modelo versiona el esquema. Si se añade un campo o cambia una enumeración, la modificación se prueba como cualquier cambio de API. Una interfaz generada automáticamente no debe ocultar valores desconocidos ni ejecutar por defecto.

Las métricas útiles separan cumplimiento estructural, exactitud de campo, cobertura y tasa de revisión humana. Celebrar solo que el analizador ya no falla puede esconder una caída de calidad. Una muestra etiquetada y resultados por tipo de documento revelan dónde el sistema necesita otra fuente o un flujo manual.

En producción se guarda el objeto recibido antes de transformarlo, siempre que la política de datos lo permita. Eso facilita reproducir un error y distinguir si nació en el modelo, en la validación o en un mapeo posterior. Los registros omiten secretos y tienen retención definida; observabilidad no significa acumular contenido sensible sin límite.

El despliegue también necesita una ruta de compatibilidad. Si un modelo nuevo interpreta de otra forma la misma descripción, las pruebas contractuales deben detectarlo antes del cambio. Versionar instrucciones, esquema y modelo juntos permite volver a una combinación conocida sin mezclar causas.

Un ejemplo completo de frontera

En una factura, el esquema puede exigir proveedor, moneda y líneas, pero permitir que el número fiscal sea nulo. El modelo extrae candidatos; una regla suma importes y consulta el maestro de proveedores; una persona revisa si hay discrepancia. Ninguna capa pretende hacer el trabajo de las otras y cada rechazo deja un motivo procesable.

Si el documento contiene dos monedas o una nota manuscrita, la salida declara ambigüedad en vez de escoger. Esa decisión de diseño suele aportar más fiabilidad que endurecer todos los campos: permite que la automatización procese lo claro y envíe lo dudoso a la cola correcta.

La capacidad transferible es colocar el modelo dentro de un contrato verificable: esquema para la forma, reglas para el significado y autoridad externa para actuar. Con esas tres capas, Structured Outputs elimina pegamento frágil sin pedirle al formato que garantice la verdad.

Este artículo se ha elaborado con inteligencia artificial bajo supervisión editorial humana.

Compartir este artículo

Este sitio web utiliza cookies para mejorar la experiencia de navegación. Política de cookies.

↑↓ navegar ↵ abrir esc cerrar