JSONSchemaBench: La complejidad de los esquemas del mundo real rompe las garantías de salida estructurada de los LLM

La mayoría de los equipos tratan la decodificación restringida como un problema resuelto: añadir un esquema JSON y obtener un JSON válido. JSONSchemaBench (arXiv:2501.10868) es el primer intento sistemático de poner a prueba esa suposición frente a 9.558 esquemas del mundo real, y los resultados son menos alentadores de lo que el marketing sugiere.

El artículo

Saibo Geng, Hudson Cooper, Michał Moskal y sus colegas en Microsoft Research presentan JSONSchemaBench, un benchmark de 9.558 esquemas extraídos de fuentes de producción reales: firmas de llamadas a funciones de GlaiveAI, repositorios de GitHub estratificados por complejidad desde trivial hasta ultra, configuraciones de API de Kubernetes, esquemas de análisis de eventos de Snowplow y la colección JSONSchemaStore. Evalúan seis frameworks de decodificación restringida (Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs y Gemini) en tres ejes: cobertura (qué fracción de esquemas puede manejar el framework), eficiencia (sobrecarga de tokens por segundo frente a la generación sin restricciones) y calidad (precisión en tareas posteriores). La cuadrícula de evaluación también incluye la suite de pruebas oficial de JSON Schema, que documenta 45 categorías de características que cualquier motor compatible debería soportar.

La afirmación central es que la complejidad del esquema es la variable decisiva que separa a los frameworks capaces de los frágiles, y que ningún framework domina en los tres ejes.

Ideas clave

• La cobertura colapsa bajo la complejidad de los esquemas. En esquemas simples de GlaiveAI, todos los frameworks obtienen puntuaciones superiores al 86%. Pero en los esquemas "GitHub-Hard" (anidamiento de múltiples niveles, definiciones recursivas, restricciones de patrones complejas), Guidance cae al 41%, Llamacpp al 39%, XGrammar al 28% y Outlines a un catastrófico 3%. OpenAI alcanza solo el 9% en GitHub-Hard, y Gemini no produce ninguna salida válida en esquemas de complejidad media o superior.
• Kubernetes expone una debilidad específica en XGrammar. A pesar de las promesas de velocidad de XGrammar, solo logra un 7% de cobertura en esquemas de Kubernetes, probablemente porque esos esquemas dependen de patrones dependientes del contexto que el pre-cómputo independiente del contexto de XGrammar no puede manejar. La cobertura frente a un benchmark que incluya configuraciones de Kubernetes no es opcional para los agentes en producción.
• La restricción insuficiente es más peligrosa que el fallo de compilación. XGrammar presenta 38 fallos de restricción insuficiente frente a la suite de pruebas de JSON Schema, lo que significa que emite un JSON que viola el esquema declarado mientras informa silenciosamente de un éxito. Guidance tiene solo 1 fallo de este tipo. Para un agente de escritura, un error de compilación se detecta en tiempo de diseño; un fallo de restricción insuficiente corrompe los datos en tiempo de ejecución sin ninguna señal.
• El avance rápido de Guidance ofrece una mejora real de velocidad del 50%. Cuando hay secuencias deterministas largas presentes (por ejemplo, nombres de campos en una estructura de objeto fija), Guidance puede avanzar múltiples tokens por paso de decodificación. En un Llama-3.1-8B en una A100, Guidance funciona a 6–9 ms por token de salida, mientras que la generación sin restricciones funciona a 15–16 ms. Outlines es más lento que la generación sin restricciones, con 30–46 ms, debido principalmente a que la compilación previa de su autómata tarda entre 3 y 8 segundos por esquema.
• La decodificación restringida mejora modestamente la precisión del razonamiento. En GSM8K (matemáticas), Guidance eleva la precisión del 80,1% (sin restricciones) al 83,8%. En "Last Letter" y "Shuffle Objects", las ganancias están en el rango de 1 a 3 puntos. Esto contradice la preocupación ampliamente citada de que forzar el formato JSON degrada la calidad de la respuesta, aunque el tamaño del efecto es lo suficientemente pequeño como para que la elección del formato no deba determinar la selección del framework.
• Ningún framework cubre las 45 categorías de características de JSON Schema. Guidance cubre 13, Llamacpp y XGrammar cubren 1 cada uno, y Outlines cubre 0. La implicación práctica es que cualquier esquema que utilice if/then/else, unevaluatedProperties o definiciones $ref recursivas se comportará de forma impredecible dependiendo del motor que se utilice.

Lo que se sostiene — y lo que no

La contribución más fuerte del benchmark es la obtención de esquemas. Las evaluaciones anteriores utilizaban esquemas de juguete o colecciones de una sola fuente. Incluir configuraciones de Kubernetes junto con firmas de llamadas a funciones es el tipo correcto de diversidad adversaria. La estratificación de la complejidad (de trivial a ultra) también ofrece a los profesionales una curva de calibración: si sus esquemas se parecen a las llamadas a funciones de GlaiveAI, tanto XGrammar como Guidance están bien; si se parecen a los manifiestos de Kubernetes, sus opciones se reducen rápidamente.

La principal debilidad es la evaluación codiciosa de una sola muestra. Medir la cobertura con una sola generación por esquema subestima la capacidad real: un framework podría fallar el 20% de las veces pero tener éxito en un reintento. El artículo lo reconoce, pero no informa de los números de pass@k con muestreo por temperatura, lo cual sería importante para sistemas de producción que reintentan tras un fallo.

La comparación también mezcla modelos incomparables. Los frameworks de código abierto (Guidance, Outlines, Llamacpp, XGrammar) se prueban con Llama-3.2-1B, mientras que OpenAI y Gemini ejecutan sus propios modelos no revelados. La cobertura del 9% de OpenAI en GitHub-Hard puede reflejar tanto la capacidad del modelo como la arquitectura de decodificación restringida. Una comparación justa requeriría un acceso controlado al modelo, algo que los autores obviamente no pueden forzar a los proveedores propietarios.

Por qué esto es importante para la IA financiera

Cada agente de escritura de Beancount genera una salida estructurada. Si el agente emite directivas de Beancount como JSON antes de convertirlas a la sintaxis .beancount, o si llama a herramientas a través de esquemas JSON, la fiabilidad de esa generación de JSON no es un detalle; es todo el juego. El artículo de FinTrace mostró que los modelos de vanguardia fallan al razonar sobre las salidas de las herramientas; JSONSchemaBench revela un problema ortogonal: incluso antes del razonamiento, la capa de formato puede emitir silenciosamente una salida no conforme.

El resultado de Kubernetes es particularmente revelador para Beancount. Los esquemas de libros mayores no son simples bolsas de clave-valor planas. Las jerarquías de cuentas, los metadatos de las transacciones y las estructuras de etiquetas crean patrones recursivos anidados similares a los objetos de la API de Kubernetes. Un framework que obtiene un 7% en Kubernetes no está preparado para esquemas de libros mayores complejos, independientemente de lo rápida que sea su sobrecarga por token.

El modo de fallo por restricción insuficiente es el que me quitaría el sueño. Un agente de Beancount que use XGrammar podría emitir una transacción que pase el control de validación interno del framework pero que viole el esquema real, y el agente no tendría motivos para reintentarlo. La corrupción silenciosa es peor que el fallo visible.

Qué leer a continuación

• XGrammar (arXiv:2411.15100, Dong et al.): el artículo técnico detrás de uno de los frameworks más rápidos probados, que explica la división de tokens independientes/dependientes del contexto y por qué los esquemas de Kubernetes lo ponen a prueba.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024): muestra que el enmascaramiento de tokens en la decodificación restringida puede distorsionar la distribución de probabilidad del modelo y propone un algoritmo de muestreo corregido; la base teórica para las preocupaciones de calidad que el benchmark mide solo indirectamente.
• XGrammar-2 (arXiv:2601.04426): una continuación que extiende XGrammar a esquemas dinámicos en entornos agénticos donde el esquema mismo cambia durante una sesión de varios turnos, directamente relevante para los agentes de Beancount que adaptan su formato de salida según los tipos de cuenta activos.