Structured Generation

Controlar la forma de un resultado

Structured Generation es el patrón de orientar y controlar la producción de una salida AI hacia una estructura explícita que un consumidor pueda interpretar bajo un contrato. Puede producir objetos, valores enumerados, documentos con una gramática o representaciones tipadas. El propósito inmediato es controlar forma y organización; no demostrar que el contenido sea verdadero, pertinente o autorizado.

Una aplicación puede necesitar una categoría y campos definidos en lugar de texto libre. Otra puede necesitar una expresión que respete una gramática. El patrón conecta expectativas, mecanismo de generación y comprobación de la salida. No exige que todo resultado sea JSON ni que una aplicación convierta todas las respuestas humanas en objetos rígidos.

LLM Fundamentals conserva modelado de lenguaje y decoding. Aquí se estudia una decisión de aplicación alrededor de ese cálculo: qué formas son admitidas, cómo se intenta producirlas y qué ocurre cuando la salida no cumple. Es posible utilizar el patrón dentro de un workflow fijo, sin un agente autónomo.

Solicitar un formato no equivale a imponerlo

Un prompt puede pedir «respondé únicamente con JSON» y ofrecer ejemplos. Eso expresa una expectativa que el modelo puede incumplir. Puede agregar explicación, omitir un campo o devolver un tipo inesperado. La instrucción por sí sola no demuestra enforcement de una estructura.

El patrón incorpora mecanismos sistemáticos: restricciones de decoding, generación guiada por gramática, componentes que producen objetos o validación y tratamiento explícito del resultado, según el sistema. Las garantías dependen del mecanismo y del contrato concreto. No toda API que acepta un schema aplica cada restricción durante la generación.

Pedir el formato puede seguir siendo útil dentro de esa composición. No se contrapone prompting y control como si fueran alternativas excluyentes. La diferencia es qué afirmación puede sostenerse: una solicitud informa qué se desea; un mecanismo implementado puede limitar ciertas salidas o detectar que el resultado no satisface el contrato.

Una aplicación también puede producir una salida estructurada mediante código convencional a partir de un resultado AI. En ese caso debe distinguirse qué parte fue inferida y qué parte construyó o verificó el programa. Un wrapper que siempre devuelve un objeto no demuestra que los campos contengan una interpretación correcta.

Schema-Constrained Outputs

Un schema expresa restricciones sobre una representación: campos, tipos, alternativas o relaciones que el lenguaje elegido pueda describir. Un sistema puede utilizarlo como guía de generación, como contrato de validación o para ambas responsabilidades. JSON Schema, tipos y gramáticas son ejemplos con alcances diferentes; no existe un lenguaje universal obligatorio.

La especificación JSON Schema Validation, draft 2020-12 describe un vocabulario para afirmar propiedades de instancias JSON. Ilustra la separación entre contrato e instancia. Su existencia no implica que cualquier proveedor de generación implemente todos sus vocabularios o interprete de la misma manera cada opción.

Un contrato útil hace explícitas las condiciones importantes para el consumidor, sin agregar campos por anticipación. Si un dato puede ser desconocido, conviene decidir cómo representarlo en lugar de obligar al modelo a inventar un valor para llenar la estructura. Elegir un campo obligatorio no crea la evidencia que falta para completarlo.

También interesa distinguir schema aceptado y schema efectivamente aplicado. Un servicio puede admitir un subconjunto o rechazar restricciones incompatibles. No corresponde asumir que un ejemplo reconocido por una biblioteca tendrá idéntica semántica en otro runtime. Esas diferencias son de implementación, no una identidad nueva del patrón.

Restricciones durante la generación

La generación guiada puede limitar continuaciones a aquellas compatibles con una estructura o gramática. Esto cambia el espacio de salidas disponibles, sin elegir automáticamente el contenido adecuado dentro de ese espacio. Una categoría válida puede seguir siendo la categoría equivocada para la entrada.

El trabajo académico Grammar-Constrained Decoding for Structured NLP Tasks without Finetuning, de 2023, ofrece un ejemplo primario de uso de gramáticas para controlar estructuras. Se cita como evidencia de un enfoque, no como una garantía uniforme de cualquier API que anuncie structured outputs.

La condición de terminación importa. Una salida interrumpida o truncada puede no constituir una instancia completa aunque sus prefijos fueran compatibles con la gramática. El sistema debe interpretar estado de ejecución y contrato, en lugar de enviar automáticamente texto parcial al consumidor como un resultado final válido.

Los nombres Structured Outputs, JSON mode, schema output o function calling pueden describir funciones de producto con alcances distintos. El Atlas conserva el patrón durable sin incorporar sintaxis de una API o un nombre comercial a su definición. Un cambio de proveedor necesita contrastar garantías concretas, no comparar solamente etiquetas.

Structural Validation

Structural Validation comprueba si el artefacto cumple el contrato estructural elegido. Puede intervenir durante la producción, después de recibir la salida o en ambos momentos. Parsing y validación tampoco son siempre equivalentes: poder interpretar JSON no demuestra que exista cada campo requerido ni que sus tipos o valores pertenezcan al conjunto admitido.

El resultado de validación debe corresponder a la versión del contrato que utiliza el consumidor. Un objeto válido según un schema antiguo puede ser incompatible con una actualización. Si generación, validador y código receptor evolucionan por separado, sus diferencias pueden parecer fallos del modelo aunque el problema sea schema drift.

Una comprobación puede ser determinista respecto de una instancia y un vocabulario fijados. Eso no vuelve determinista todo el workflow que seleccionó el contrato, generó el objeto o decidió cómo utilizarlo. probabilistic-vs-deterministic-software conserva esa composición de propiedades, sin trasladar garantías locales al sistema completo.

Conviene comunicar qué se comprobó realmente. «Se pudo parsear» y «cumple estas restricciones» aportan evidencias diferentes. «Recibimos un objeto tipado» también necesita conocer cómo se construyó o validó ese objeto. La forma del valor en memoria no certifica por sí sola su procedencia.

Estructura válida y significado incorrecto

Supongamos un contrato que exige un campo entero llamado quantity, sin otra condición. Este objeto puede satisfacerlo:

{
  "quantity": -2
}

Si quantity significa unidades a entregar y el negocio no permite cantidades negativas, falta una condición relevante. Puede expresarse parte de ella en un contrato más preciso, pero ningún schema descubre automáticamente qué regla comercial debería aplicarse. Codificar una restricción errónea puede hacer que validación y generación coincidan perfectamente en el error.

La conformidad tampoco demuestra que una referencia exista, que un importe provenga del sistema correcto o que una explicación refleje evidencia actual. Algunas reglas de dominio pueden representarse y comprobarse; otras requieren estado externo, interpretación o evidencia adicional. La distinción no afirma que un schema nunca exprese reglas de negocio, sino que solo verifica las condiciones efectivamente modeladas y aplicadas.

Verdad, relevancia, seguridad y autorización son preguntas separables. Una operación puede estar representada impecablemente y no estar autorizada para ese usuario. Un objeto puede describir correctamente un dato de otro tenant y seguir siendo inapropiado para la respuesta actual. Forma válida no concede derecho a utilizar el contenido.

Validación estructural y verificación de tarea

La validación estructural examina forma frente a un contrato. La verificación de tarea reúne evidencia sobre requisitos y consecuencias pertinentes al resultado concreto. Generated Code Verification desarrolla esa relación en cambios de software; no se redefine aquí como parsing de un artefacto generado.

Una validación puede ser necesaria para continuar y seguir siendo insuficiente para aceptar. Un consumidor puede comprobar tipos, consultar la existencia de una entidad y contrastar condiciones de negocio mediante mecanismos distintos. No hay que confundir esa composición con una única comprobación universal llamada válido.

La revisión humana también puede aportar evidencia y compartir supuestos erróneos. Un reviewer que solo observa que el objeto tiene campos no confirma su contenido. La entrega debería permitir distinguir qué condiciones se validaron, cuáles se verificaron por otra vía y qué incertidumbres siguen abiertas.

Tool Calling y controles de política

Tool Calling organiza una solicitud estructurada de invocación y su resultado. Puede utilizar argumentos con schema, pero no toda salida estructurada solicita una acción. Un objeto para mostrar una clasificación al usuario y un objeto destinado a ejecutar una escritura tienen consecuencias diferentes aunque compartan tipos.

Structured Generation tampoco equivale a AI Guardrails. Controla representación; los controles de comportamiento o política necesitan actuar en la frontera correspondiente. Un schema puede participar de un control cuando se integra con una decisión efectiva, pero no debe presentarse automáticamente como seguridad completa.

Las responsabilidades pueden componerse sin formar una pila obligatoria. Una aplicación sin herramientas puede necesitar estructuras; otra puede utilizar herramientas con mecanismos que no exponen el mismo formato. El contrato útil describe qué se admite y qué significa continuar, sin deducir agencia o autorización del uso de JSON.

Fallos, reparación y continuidad

Campos ausentes, tipos inesperados o alternativas no admitidas pueden revelar un incumplimiento estructural. Un schema incompatible, una característica no soportada o un resultado parcial requieren diagnósticos distintos. También puede haber estructura válida con significado incorrecto, que no se resuelve ajustando únicamente el parser.

Una reparación puede intentar completar o transformar el resultado, pero puede cambiar su significado o inventar contenido. Debe quedar claro qué evidencia justifica la transformación. Volver a generar con un error concreto puede ser útil; repetir indefinidamente hasta recibir algo aceptado por el validador puede ocultar una condición imposible o un contrato mal diseñado.

Los reintentos necesitan límites y una respuesta cuando no resuelven el problema. Retry conserva el mecanismo general y coding-agent-failure-modes-and-recovery aporta ejemplos situados de ejecución y evidencia. No se crean nuevas microtácticas de fiabilidad para cada fallo de estructura.

Si el objeto genera efectos externos, validarlo otra vez no demuestra que una acción previa no ocurrió. La aplicación debe distinguir producción del artefacto y ejecución de sus consecuencias. Una reparación del texto no revierte una escritura ni autoriza repetirla.

Ejemplo de integración y trade-offs

Una aplicación extrae una propuesta de actualización de catálogo. El contrato describe campos y alternativas admitidas; el sistema genera y valida una instancia. Después necesita comprobar identidad del producto, vigencia de los datos y permisos antes de cualquier modificación. Si no existe evidencia de un precio, un campo obligatorio no autoriza inventarlo.

Una estructura más restrictiva puede facilitar integración y reducir ambigüedad. También puede excluir respuestas útiles, crecer en complejidad o acoplar consumidores a detalles que cambian. Demasiado texto libre dificulta procesamiento; demasiados campos obligatorios pueden incentivar respuestas artificialmente completas. El diseño depende de la tarea y de cómo se tratarán incertidumbre y evolución.

Context Management organiza información suministrada a la inferencia; Structured Generation organiza la forma de su salida. Mejorar una dimensión no resuelve automáticamente la otra. Un contexto equivocado puede producir un objeto perfectamente estructurado y una entrada correcta puede producir una representación incompatible si el contrato no está bien integrado.

Fuentes y alcance

Fuentes consultadas el 2026-10-30: JSON Schema Validation, draft 2020-12 y Geng et al., Grammar-Constrained Decoding, 2023. Se utilizan como referencias de contrato estructural y un enfoque de generación restringida. Los ejemplos y fronteras de aplicación son síntesis del Atlas. No se fijan campos de APIs actuales, subconjuntos universales de schemas ni sintaxis de un proveedor; no se materializan Guardrails o evaluación general.