Introducción de outputs estructurados en la API

El año pasado, en DevDay, presentamos el modo JSON, un componente útil para los desarrolladores que desean crear aplicaciones fiables con nuestros modelos. Mientras que el modo JSON mejora la fiabilidad del modelo para generar outputs JSON válidos, no garantiza que la respuesta del modelo se ajuste a un esquema particular. Hoy, presentamos los outputs estructurados en la API, una nueva característica diseñada para garantizar que los outputs generados por el modelo coincidan exactamente con los esquemas JSON proporcionados por los desarrolladores.

Generar datos estructurados a partir de datos de entrada no estructurados es uno de los principales casos de uso de la IA en las aplicaciones actuales. Los desarrolladores utilizan la API de OpenAI para crear asistentes potentes capaces de recuperar datos y responder a preguntas mediante la solicitud de funciones⁠(se abre en una ventana nueva), extraer datos estructurados para la entrada de datos y crear flujos de trabajo agénticos de varios pasos para que los LLM realicen acciones. Los desarrolladores llevan mucho tiempo sorteando las limitaciones de los LLM en esta área mediante herramientas de código abierto, prompts y constantes reintentos de solicitudes para garantizar que los outputs del modelo coincidan con los formatos necesarios para interoperar con sus sistemas. Los outputs estructurados resuelven este problema al obligar a los modelos de OpenAI a coincidir con los esquemas proporcionados por los desarrolladores y entrenar nuestros modelos para que comprendan mejor los esquemas complicados.

En nuestras evaluaciones de esquemas JSON complejos, nuestro nuevo modelo gpt-4o-2024-08-06 con outputs estructurados obtiene una puntuación perfecta del 100 %. En comparación, gpt-4-0613 obtiene una puntuación inferior al 40 %.

Con los outputs estructurados, gpt-4o-2024-08-06 logra un 100 % de fiabilidad en nuestras evaluaciones y coincide perfectamente con los esquemas de outputs.

Hemos introducido los outputs estructurados en dos formatos en la API: 

1. Solicitud de funciones: los outputs estructurados a través de herramientas están disponibles configurando strict: true en la definición de su función. Esta característica funciona con todos los modelos que admiten herramientas, incluidos todos los modelos gpt-4-0613, gpt-3.5-turbo-0613 y posteriores. Cuando los outputs estructurados están habilitados, las salidas del modelo coinciden con la definición de herramienta proporcionada.

2. Una nueva opción para el parámetro response_format: los desarrolladores ahora pueden proporcionar un esquema JSON a través de json_schema, una nueva opción para el parámetro response_format. Esto resulta útil cuando el modelo no realiza una solicitud de herramienta, sino que responde al usuario de forma estructurada. Esto funciona con nuestros modelos GPT‑4o más nuevos: gpt-4o-2024-08-06, lanzado hoy, y gpt-4o-mini-2024-07-18. Cuando se proporciona un response_format con strict: true, los outputs del modelo coinciden con el esquema proporcionado.

La seguridad es una prioridad absoluta para OpenAI: la nueva función de outputs estructurados cumplirá con nuestras políticas de seguridad existentes y seguirá permitiendo que el modelo rechace una solicitud que plantee un problema de seguridad. Para simplificar el desarrollo, hay un nuevo valor de cadena refusal en las respuestas de la API que permite a los desarrolladores detectar mediante programación si el modelo ha generado un rechazo en lugar de un output que coincida con el esquema. Si la respuesta no incluye un rechazo y la respuesta del modelo no se ha interrumpido prematuramente (indicado por finish_reason), entonces la respuesta del modelo producirá de manera fiable un JSON válido que coincida con el esquema proporcionado.

Nuestros SDK de Python y Node se han actualizado con compatibilidad nativa para outputs estructurados. Proporcionar un esquema para herramientas o como formato de respuesta es tan fácil como proporcionar un objeto Pydantic o Zod. Nuestros SDK se encargarán de convertir el tipo de datos a un esquema JSON compatible, deserializar la respuesta JSON en la estructura de datos escrita automáticamente y analizar los rechazos si se dan.

Los siguientes ejemplos muestran la compatibilidad nativa con outputs estructurados con solicitud de funciones.

La compatibilidad con outputs estructurados nativos también está disponible para response_format.

Los desarrolladores utilizan con frecuencia los modelos de OpenAI para generar datos estructurados para diversos casos de uso. Otros ejemplos incluyen:

Por ejemplo, los desarrolladores pueden utilizar outputs estructurados para crear aplicaciones que generen código o interfaces de usuario. Todos los ejemplos siguientes utilizan el mismo response_format y se pueden utilizar para generar distintas IU en función de los datos de entrada del usuario.

Puede resultar útil proporcionarle al modelo un campo aparte para la cadena de pensamiento con el fin de mejorar la calidad final de la respuesta.

Por ejemplo, indicarle al modelo que extraiga cosas como tareas pendientes, fechas de entrega y tareas de las notas de la reunión.

Adoptamos un enfoque de dos partes para mejorar la fiabilidad de los outputs del modelo que coinciden con el esquema JSON. En primer lugar, entrenamos nuestro modelo más nuevo, gpt-4o-2024-08-06, para que comprendiera esquemas complicados y la mejor manera de producir outputs que coincidieran con ellos. Sin embargo, el comportamiento del modelo es, esencialmente, no determinista: a pesar de las mejoras de rendimiento de este modelo (93 % respecto al punto de referencia), no alcanzó el nivel de fiabilidad que los desarrolladores necesitan para crear aplicaciones sólidas. Por lo tanto, también adoptamos un enfoque determinista basado en ingeniería para limitar los outputs del modelo y lograr una fiabilidad del 100 %.

Nuestro enfoque se basa en una técnica conocida como muestreo restringido o decodificación restringida. De forma predeterminada, cuando se muestrean modelos para producir outputs, no están restringidos en absoluto y pueden seleccionar cualquier token del vocabulario como el siguiente output. Esta flexibilidad es lo que permite que los modelos cometan errores; por ejemplo, generalmente pueden probar un token de llave en cualquier momento, incluso aunque no se produzca JSON válido. Para obligar a la obtención de outputs válidos, restringimos nuestros modelos a solo tokens que serían válidos según el esquema proporcionado, en lugar de todos los tokens disponibles.

Puede resultar complicado implementar esta restricción en la práctica, ya que los tokens válidos difieren a lo largo del output de un modelo. Pongamos que tenemos el siguiente esquema:

Los tokens que son válidos al comienzo del output incluyen cosas como {, {“, {\n, etc. Sin embargo, una vez que el modelo ya ha muestreado {“val, { ya no es un token válido. Por lo tanto, debemos implementar una decodificación dinámica restringida y determinar qué tokens son válidos después de generar cada token, en lugar de hacerlo al comienzo de la respuesta.

Para ello, convertimos el esquema JSON proporcionado en una gramática libre de contexto (CFG). Una gramática es un conjunto de reglas que definen un idioma, y ​​una gramática libre de contexto es una gramática que se ajusta a reglas específicas. Pongamos que JSON y el esquema JSON son lenguajes particulares con reglas para definir lo que es válido dentro del lenguaje. Así como en español no podemos tener una oración sin verbo, no es válido en JSON terminar con una coma.

Por lo tanto, para cada esquema JSON, calculamos una gramática que representa ese esquema y preprocesamos sus componentes para que sea fácilmente accesible durante el muestreo del modelo. Es por eso que la primera solicitud con un nuevo esquema genera una penalización de latencia: debemos preprocesar el esquema para generar este artefacto que podremos usar de manera eficaz durante el muestreo.

Mientras realizamos el muestreo, después de cada token, nuestro motor de inferencia determinará qué tokens son válidos para producirse a continuación en función de los tokens generados previamente y las reglas de la gramática que indican qué tokens son válidos a continuación. Después, usamos esta lista de tokens para enmascarar el siguiente paso del muestreo, lo que reduce la probabilidad de tokens no válidos a 0. Como hemos preprocesado el esquema, podemos usar una estructura de datos en caché para hacerlo de manera eficaz, con una latencia mínima.

Los enfoques alternativos a este problema suelen utilizar máquinas de estado finito (FSM) o expresiones regulares (generalmente implementadas con FSM) para la decodificación restringida. Funcionan de manera similar en el sentido de que actualizan dinámicamente qué tokens son válidos después de que se produzca cada token, pero tienen algunas diferencias clave con respecto al enfoque de CFG. En particular, las CFG pueden expresar una clase más amplia de lenguajes que las FSM. En la práctica, esto no importa para esquemas muy simples como el esquema de value mostrado anteriormente. Sin embargo, hemos observado que la diferencia es significativa para esquemas más complejos que involucran estructuras de datos anidadas o recursivas. Por ejemplo, las FSM generalmente no pueden expresar tipos recursivos, lo que significa que los enfoques basados ​​en FSM pueden tener dificultades para hacer coincidir los paréntesis en JSON muy anidado. El siguiente es un esquema recursivo de muestra compatible con la API de OpenAI con outputs estructurados, pero que no sería posible expresar con una FSM.

Es importante observar que cada elemento de la interfaz de usuario puede tener elementos secundarios arbitrarios que hagan referencia al esquema raíz de forma recursiva. Esta flexibilidad es algo que facilita el enfoque de CFG.

El uso de outputs estructurados tiene algunas limitaciones:

• Los outputs estructurados solo permiten un subconjunto del esquema JSON, que se detalla en nuestra documentación⁠(se abre en una ventana nueva). Esto nos ayuda a garantizar el mejor rendimiento posible.
• La primera respuesta de la API con un nuevo esquema generará latencia adicional, pero las respuestas posteriores serán rápidas, sin penalización de latencia. Esto se debe a que, durante la primera solicitud, procesamos el esquema como se ha indicado anteriormente, y luego almacenamos en caché estos artefactos para poder reutilizarlos de manera rápida más adelante. Los esquemas típicos tardan menos de 10 segundos en procesarse en la primera solicitud, mientras que los esquemas más complejos pueden tardar hasta un minuto.
• Es posible que el modelo no siga el esquema si decide rechazar una solicitud insegura. Si decide rechazarla, el mensaje de respuesta tendrá el valor booleano refusal en «true» para indicarlo. 
• Es posible que el modelo no siga el esquema si la generación alcanza max_tokens u otra condición de detención antes de finalizar. 
• Los outputs estructurados no evitan todos los errores del modelo. Por ejemplo, el modelo aún puede cometer errores en los valores del objeto JSON (por ejemplo, equivocarse en un paso en una ecuación matemática). Si los desarrolladores encuentran errores, recomendamos proporcionar ejemplos en las instrucciones del sistema o dividir las tareas en subtareas más sencillas.
• Los outputs estructurados no son compatibles con las solicitudes de funciones paralelas. Cuando se genera una solicitud de función paralela, es posible que no coincida con los esquemas proporcionados. Programa parallel_tool_calls: false para deshabilitar la solicitud de funciones paralelas.
• Los esquemas JSON proporcionados con outputs estructurados no son admisibles para la no retención de datos⁠(se abre en una ventana nueva) (ZDR).

Los outputs estructurados ya están disponibles para el público general en la API. 

Los outputs estructurados con solicitud de funciones están disponibles en todos los modelos que admiten solicitudes de funciones en la API. Esto incluye nuestros modelos más nuevos (gpt-4o y gpt-4o-mini) y todos los modelos posteriores a gpt-4-0613 y gpt -3.5-turbo-0613(ambos incluidos), así como cualquier modelo optimizado que admita solicitudes de funciones. Esta función está disponible en la API Chat Completions, la API Assistants y la API Batch. Los outputs estructurados con solicitud de funciones también son compatibles con los inputs de visión.

Los outputs estructurados con formatos de respuesta están disponibles en gpt-4o-mini, gpt-4o-2024-08-06 y cualquier optimización basada en estos modelos. Esta función está disponible en la API Chat Completions, la API Assistants y la API Batch. Los outputs estructurados con formatos de respuesta también son compatibles con los inputs de visión. 

Al cambiar al nuevo gpt-4o-2024-08-06, los desarrolladores ahorran un 50 % en datos de entrada (2,50 $/millón de tokens de entrada) y un 33 % en outputs (10,00 $/millón de tokens de salida) en comparación con gpt-4o-2024-05-13.

Para comenzar a utilizar los outputs estructurados, consulta nuestra documentación⁠(se abre en una ventana nueva). 

Los outputs estructurados están inspirados en el excelente trabajo de la comunidad de código abierto: a saber, las bibliotecas de outlines⁠(se abre en una ventana nueva), jsonformer⁠(se abre en una ventana nueva), instructor⁠(se abre en una ventana nueva), guidance⁠(se abre en una ventana nueva) y lark⁠(se abre en una ventana nueva).