Su JSON es válido pero sus datos son incorrectos: cinco modos de falla que los resultados estructurados de LLM no detectarán

La decodificación restringida resolvió un problema real. Antes de los métodos basados ​​en gramática como Outlines y SGLang, obtener JSON válido de un modelo de lenguaje era un ciclo de reintento. Usted solicitó, analizó, captó la coma final, volvió a solicitar. La decodificación restringida terminó con eso: forzar la selección de tokens a través de una máquina de estados finitos y cada salida se analiza.

Los equipos lo adoptaron rápidamente. El cumplimiento del esquema alcanzó casi el 100%. Y luego una suposición silenciosa se deslizó en las bases de código de producción: si el JSON se valida con el esquema, los datos son correctos.

Los puntos de referencia de BAML dicen lo contrario. En tareas de llamada de funciones, la generación sin restricciones con análisis post hoc alcanzó una precisión del 93,63%; la decodificación restringida en el mismo modelo obtuvo una puntuación del 91,37%. El JSON siempre válido era menos preciso que el JSON a veces roto.

Comencé a rastrear esto después de que un canal de clasificación que construí comenzó a arrojar valores plausibles pero inventados en aproximadamente una de cada doce ejecuciones. El JSON siempre analizado. Pydantic nunca se quejó. Fueron necesarias semanas para darse cuenta, porque cada control posterior era estructural.

Siguen apareciendo cinco modos de falla. Todos producen resultados válidos para el esquema que interrumpen su canalización silenciosamente:

Alucinación de enumeración: enumeración válida, significado incorrecto

Fabricación segura: valores plausibles en campos de texto libre

Contradicción entre campos: campos válidos individualmente, imposibles juntos

Colapso distributivo: convergencia hacia los impagos seguros

Alucinación de matrices: entradas fabricadas en lugar de matrices vacías

Decodificación restringida: el problema que realmente resolvió

La salida estructurada solía significar esperar que el modelo se comportara. La decodificación restringida se creó para solucionar eso, y lo hizo, pero no fue todo el problema.

La progresión fue real. JSON de preguntar y orar, donde agregaba “responder en formato JSON” y cruzaba los dedos, dio paso a la generación guiada por expresiones regulares (LMQL) y luego a la decodificación restringida basada en gramática.

XGrammar, ahora el backend predeterminado para vLLM y TensorRT-LLM, agrega una sobrecarga casi nula por token. El problema de sintaxis está resuelto.

Pero resolver la sintaxis creó un punto ciego. La validación del esquema verifica si un campo está escrito correctamente: una cadena es una cadena, un número es un número. No dice nada sobre si esa cadena o número es correcto.

Una cerradura en un archivador mantiene los cajones organizados. No dice nada sobre si los documentos que contiene son exactos. La validación del esquema funciona de la misma manera.

La razón por la que esto es importante: forzar un modelo a un formato de salida estricto le cuesta algo. Tiene que dedicar parte de su atención a permanecer dentro del formato, en lugar de gastar toda su atención en obtener la respuesta correcta.

Lee y cols. midió ese costo directamente. En los modelos de peso abierto, forzar formatos de salida estructurados produjo una caída en la precisión de 3 a 9 puntos porcentuales. Específicamente en las tareas de razonamiento matemático, donde lograr el razonamiento correcto es más importante que el formato, la brecha superó los 15 puntos porcentuales.

Tam et al. Encontré el mismo patrón desde un ángulo diferente: cuanto más estrictas eran las reglas de formato, peor se volvía el razonamiento. El formato no es gratuito y la mayoría de los equipos no tienen en cuenta ese costo.

Cinco modos de falla: lo que sobrevive a su esquema

La validación del esquema detecta errores de tipo. No detecta estos cinco modos de falla, porque cada uno produce resultados que son estructuralmente válidos y sustancialmente incorrectos.

Alucinación enum. El modelo elige un valor de enumeración válido que es semánticamente incorrecto para la entrada. Considere una enumeración prioritaria de [“low”, “normal”, “high”, “urgent”]: la gramática garantiza uno de esos cuatro valores, pero no los pondera según el contexto de entrada. El modelo puede devolver “urgente” en una solicitud de rutina o “bajo” en una crítica, y el esquema aceptará ambas.

Fabricación segura. Los campos de texto libre devuelven datos plausibles pero inventados. BAML demostró esto enviando una foto de un elefante como recibo: la decodificación restringida devolvió un informe de gastos completo y con un esquema válido en lugar de rechazarlo. La decodificación restringida elimina la capacidad del modelo para rechazar o expresar incertidumbre. El esquema requiere un valor; el modelo proporciona uno, ya sea que la entrada lo admita o no.

Contradicción entre campos. La validación del esquema verifica cada campo de forma aislada. Nunca comprueba si los campos coinciden entre sí. Un extractor de sentimientos puede devolver {“sentiment”: “positive”, “score”: 0.1}, una etiqueta positiva con una puntuación cercana a cero, que debería significar negativa. Un analizador de fechas puede devolver {“start”: “2026-03-15”, “end”: “2026-03-10”}, una fecha de finalización anterior a la fecha de inicio.

Ambas salidas pasan la validación de cada campo individual. Ninguno de los dos tiene sentido una vez que se observa el registro en su conjunto, y no se ha creado ningún validador de campo único para detectarlo, porque la restricción se encuentra entre campos, no dentro de ninguno de ellos.

Colapso distributivo. El modelo converge en valores genéricos y seguros a través de diferentes entradas. Los sesgos de decodificación restringidos hacia tokens de alta probabilidad dentro del conjunto válido y los valores predeterminados “seguros” (0,95, “medio”, “general”) conllevan una probabilidad base más alta que los valores específicos del contexto.

Me di cuenta de esto cuando las puntuaciones de confianza en un proceso de clasificación se mantuvieron estables en 0,98 durante tres semanas. Collin Wilkins documenta un caso similar en el que la confianza era de 0,99 en todos los resultados, incluidos los galimatías. Cada registro tenía tipos válidos, enumeraciones correctas y números razonables. La distribución había dejado de moverse y nada alarmaba porque cada producción individual era estructuralmente correcta.

Alucinación de matriz. Los modelos se resisten a devolver matrices vacías. Bajo decodificación restringida, [] es una secuencia de tokens de baja probabilidad porque la gramática pondera las rutas de producción de objetos más que la ruta de matriz vacía. Cuando un esquema requiere un campo de elementos de tipo matriz, el modelo fabrica entradas en lugar de devolver nada.

En las tareas de extracción, esto produce resultados fantasmas: su canalización informa “encontró 3 coincidencias” cuando la respuesta correcta es cero.

Cinco modos de falla asignados a sus señales observables, causas fundamentales y estrategias de detección.

La trampa de la validación: por qué más reglas no solucionarán este problema

El primer instinto es escribir más reglas de validación. Para patrones conocidos, eso funciona. Un model_validator de Pydantic detecta fecha_inicio> fecha_finalización. Una verificación personalizada señala discrepancias en la puntuación de sentimiento. Puede crear restricciones entre campos para cada falla que ya haya visto.

El problema son los fallos que no has visto. La corrección estructural está cerrada: puede enumerar todas las formas JSON válidas para un esquema determinado. La corrección semántica es abierta. No puedes escribir una regla para una respuesta incorrecta que aún no has encontrado. En producción, el modelo encuentra nuevas formas de equivocarse más rápido de lo que usted escribe validadores, y cada nuevo validador solo cubre el último error.

Hay un argumento contrario a favor del remuestreo en lugar de la restricción que merece consideración aquí. En lugar de forzar la salida del modelo a una gramática a medida que se genera, déjelo escribir libremente y luego verifique el resultado: un analizador valida la salida con respecto al esquema y, si falla, el modelo simplemente se genera nuevamente. Esto es un remuestreo. La generación de forma libre permite que el modelo razone sin presión de formato; la verificación de formato ocurre después, no durante. Los puntos de referencia de BAML muestran que el análisis y reintento supera a la decodificación restringida en más de 2 puntos porcentuales en el mismo modelo.

Cambia el éxito del análisis del primer paso garantizado por una mayor precisión cuando la salida se analiza. Aún es una cuestión abierta si esa compensación se mantiene en un volumen alto, donde los reintentos aumentan la latencia.

Pero el problema más profundo atraviesa ambos enfoques. La producción estructurada oculta la incertidumbre. Cuando el esquema requiere un valor, el modelo lo completa. Un campo de puntuación de riesgo siempre obtiene un número, incluso cuando el modelo no tiene base para la evaluación. Un campo de resumen siempre obtiene texto, incluso cuando la entrada no contiene nada que resumir.

No existe un mecanismo estándar para que el modelo exprese “No sé” o “este campo no se aplica a esta entrada”. El esquema es una función forzada y las respuestas incorrectas surgen con la misma confianza que las correctas.

Después de la tercera vez que detecté un resultado con un esquema válido pero incorrecto en producción, dejé de tratar la validación del esquema como una puerta de calidad y comencé a superponer comprobaciones semánticas. El cumplimiento del esquema es el piso, no el techo.

Defensa de tres capas: esquema, semántica e incertidumbre

Capa 1: Esquema y validación estructural. Esto es lo que ya tienes: Pydantic, JSON Schema, Zod. Detecta errores tipográficos, campos faltantes y valores de enumeración sintácticamente no válidos. Guárdalo. Resuelve bien el problema de sintaxis.

Capa 2: Validadores semánticos. Funciones de restricción entre campos que codifican la lógica empresarial: “si el sentimiento es positivo, la puntuación debe exceder 0,5”. Monitores de distribución que rastrean la entropía del valor del campo a lo largo del tiempo. Cuando la entropía cae por debajo de un umbral, se detecta un colapso distributivo antes de que las métricas posteriores se desvíen.

Las auditorías de muestra periódicas sobre resultados de entradas ambiguas o extremas detectan una fabricación confiable. Esta capa requiere conocimiento del dominio y mantenimiento continuo, pero cubre la mayoría de los cinco modos de falla, porque verifica el significado, no la forma.

Capa 3: La incertidumbre emerge. Agregue un campo de confianza opcional junto a cada valor extraído, para que el modelo pueda expresar lo que no sabe. El punto de referencia CONSTRUCT de Cleanlab muestra que la puntuación de confiabilidad por campo detecta errores en resultados estructurados de GPT-5 y Gemini con mayor precisión que las estimaciones de confianza a nivel de solicitud.

Para campos de alto riesgo, agregue la verificación LLM como juez: una segunda llamada de modelo que evalúa si el valor extraído es compatible con la entrada. El costo es la latencia. La recompensa es detectar fallas antes de que lleguen a su canalización.

La mayoría de los equipos solo tienen la Capa 1. Agregar la Capa 2 detecta la mayoría de las fallas silenciosas. La capa 3 es para campos donde una respuesta incorrecta cuesta más que la latencia adicional.

Tres señales: cuando su canalización falla silenciosamente

No detectará estos fallos inspeccionando salidas individuales. Las señales son estadísticas.

La entropía de salida está cayendo. Si un campo que debería variar según las entradas comienza a agruparse alrededor de uno o dos valores, el modelo está colapsando a valores predeterminados seguros. Trazar distribuciones de valor semanalmente.

Ninguna salida está nunca vacía. Si un campo de matriz que a veces debería estar vacío nunca regresa []el modelo está fabricando entradas. Verifique la tasa de matriz vacía con su tasa base esperada.

Las métricas descendentes varían sin cambios ascendentes. Si las métricas de su negocio cambian pero la versión del modelo, el mensaje y el esquema no han cambiado, es posible que la precisión semántica del modelo se haya degradado mientras que el cumplimiento estructural se mantuvo perfecto. Esta es la señal más difícil de atribuir y, a menudo, es la primera.

Conclusión: el esquema es el suelo, no el techo

El valor predeterminado es la decodificación restringida para mayor confiabilidad del análisis. Cree las comprobaciones semánticas para las que nunca fue diseñado.

La validación del esquema nunca le dirá que los datos son correctos. Le indica que los datos tienen la forma correcta. La brecha entre esas dos afirmaciones es donde viven estos cinco modos de falla.

Lectura adicional

Los resultados estructurados crean una falsa confianza (punto de referencia de BAML sobre la degradación de la precisión en condiciones de decodificación restringida)

¿Déjame hablar libremente? (Estudio EMNLP 2024 sobre la disminución del razonamiento bajo restricciones de formato)

El impuesto de formato (que mide el costo de precisión de 3 a 9 páginas de los formatos de salida estructurados)

JSONSchemaBench (10.000 esquemas del mundo real en seis marcos de decodificación restringida)

Cleanlab CONSTRUCT (puntuación de confiabilidad por campo para resultados estructurados de LLM)

De la alucinación a la bola de nieve estructural (cómo la decodificación restringida desencadena trampas de formato durante la autocorrección)

···

Gracias por leer. Soy Mostafa Ibrahim, fundador de Codecontent, una agencia de contenido técnico centrada en los desarrolladores. Escribo sobre sistemas agentes, RAG e IA de producción. Si desea mantenerse en contacto o discutir las ideas de este artículo, puede encontrarme en LinkedIn aquí.