¿Por qué los modelos locales pequeños alucinan más al generar JSON?

Los modelos locales pequeños alucinan más durante la generación de JSON porque deben resolver la tarea y, al mismo tiempo, preservar un esquema rígido y una sintaxis válida.

Un flujo de trabajo de IA doméstico puede pedirle a un modelo compacto que extraiga nombres de archivo, fechas, etiquetas, estados de dispositivos o argumentos de automatización y los devuelva como JSON legible por máquinas. El modelo no realiza una sola tarea. Debe identificar los datos correctos, asignarlos a los campos previstos, respetar los tipos y enumeraciones obligatorios, recordar la puntuación y la anidación, y detenerse sin añadir comentarios. Cuando la capacidad del modelo es limitada, estas restricciones compiten con el razonamiento necesario para mantener los valores fundamentados en la información de origen.

El JSON convierte la corrección en un problema de dos capas

La respuesta debe ser semánticamente correcta y estructuralmente válida al mismo tiempo. Una respuesta de formato libre puede expresar incertidumbre o explicar que falta un valor, mientras que un contrato JSON suele exigir que el modelo elija un valor de campo incluso cuando las pruebas son débiles.

La investigación sobre el equilibrio entre validez y corrección muestra por qué estas mediciones deben mantenerse separadas: unas restricciones de salida más estrictas pueden mejorar la validez del esquema, mientras que los valores seleccionados se vuelven menos precisos.

La presión es más visible en un modelo local pequeño porque tiene menos capacidad disponible para seguir instrucciones, extraer información y serializarla. Un modelo más grande también puede inventar un campo, pero un modelo compacto alcanza antes el punto en el que el cumplimiento del formato desplaza la calidad de la respuesta.

Un objeto válido aún puede contener una respuesta alucinada

La decodificación restringida puede impedir que se emita una llave ilegal, una clave desconocida o una enumeración no válida. No puede demostrar que el ID de cliente, la fecha, la ruta o el estado elegido aparezcan en el material de origen.

vLLM describe las restricciones de esquema JSON como una forma de limitar la estructura de la salida generada. El decodificador reduce los tokens que pueden aparecer legalmente a continuación, pero el modelo sigue aportando el significado que transmiten esos tokens legales.

Esto crea un modo de fallo peligroso para la automatización: el objeto se analiza correctamente, por lo que el código posterior confía en él, pero uno de los campos es inventado. Valida las reglas de negocio y las pruebas de origen después de validar el esquema, en lugar de tratar el análisis exitoso como una prueba de corrección factual.

Los esquemas anidados aumentan las ramificaciones y el seguimiento del estado

Cada propiedad obligatoria, ramificación opcional, matriz anidada, campo anulable y enumeración añade un estado que el modelo debe seguir durante la generación. Los nombres de clave similares o las formas de objeto repetidas facilitan colocar un valor correcto en la ubicación equivocada.

La guía de llama.cpp sobre el JSON restringido por gramática distingue entre la gramática de salida permitida y el mensaje que explica qué significan los campos. Una gramática puede imponer la estructura, pero el esquema aún necesita instrucciones semánticas claras.

Reduce el número de decisiones simultáneas. Aplana los objetos profundamente anidados, elimina los campos opcionales que no utilices, emplea nombres de clave distintos y divide una extracción grande en objetos más pequeños cuando el modelo local intercambie repetidamente campos o rellene campos no relacionados.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Los mensajes que exigen solo JSON pueden suprimir razonamientos útiles

Una instrucción estricta como «devuelve solo JSON» empuja al modelo a empaquetar una respuesta de inmediato. En una extracción difícil, esto puede provocar que elija un campo demasiado pronto, antes de comparar pasajes contradictorios o resolver una fecha ambigua.

Las evaluaciones de Hugging Face muestran la sensibilidad al formato del mensaje: cambiar la estructura esperada y el espacio disponible para razonar puede cambiar el rendimiento de la tarea incluso cuando la pregunta subyacente es la misma.

No expongas cadenas de pensamiento privadas, pero separa la resolución interna de la tarea de la serialización final. El flujo de trabajo puede extraer primero un registro compacto de pruebas o realizar una búsqueda determinista y, después, pedirle al modelo que renderice únicamente los campos verificados.

El JSON indicado en el mensaje y la decodificación restringida fallan de forma diferente

El JSON solicitado únicamente mediante el mensaje puede añadir bloques de código, comentarios, claves duplicadas, comas finales o un objeto sin terminar. La decodificación restringida elimina muchos fallos de sintaxis, pero puede obligar al modelo a elegir entre valores válidos cuando no se permitía «desconocido».

Fireworks explica cómo las opciones de tokens restringidas por esquema mantienen la generación dentro de un contrato de salida, aunque el mensaje todavía debe describir con precisión los datos previstos.

Registra ambas familias de fallos. Mide los errores de análisis del formato obtenido solo mediante el mensaje y, después de habilitar la decodificación restringida, mide los campos incorrectos pero válidos, los valores predeterminados no deseados y la falsa certeza.

El muestreo y el truncamiento amplifican los errores pequeños

Una temperatura más alta puede variar la elección de claves y los valores de los campos, mientras que un presupuesto insuficiente de tokens puede truncar matrices o llaves de cierre. Una temperatura más baja reduce la variación, pero no convierte en verdadero un valor sin fundamento.

Una revisión práctica de un flujo de trabajo de salidas estructuradas local demuestra por qué la validación y la generación restringida son componentes separados, no un único truco de instrucciones.

Reserva suficientes tokens de salida para el objeto legal más grande, limita la longitud de las matrices y reintenta solo la parte que haya fallado. Regenerar el objeto completo puede sustituir campos que ya eran correctos por nuevas alucinaciones.

Usa un flujo de trabajo local de JSON en dos etapas

Primero, resuelve la tarea en un registro tipado mínimo: el fragmento exacto de origen, la fecha normalizada, el identificador seleccionado, el estado de confianza y cualquier valor ausente explícito. Esta etapa debe poder rechazar la solicitud en lugar de inventar datos obligatorios.

Después, renderiza ese registro mediante un decodificador restringido por esquema, analízalo y ejecuta comprobaciones semánticas, como la existencia del archivo, el intervalo de fechas, la compatibilidad con la enumeración y la coherencia entre campos. Un validador debe devolver errores específicos que identifiquen el campo que debe corregirse.

La explicación de ZimaSpace sobre por qué un modelo más pequeño puede ser más fiable establece el límite: los modelos compactos funcionan mejor cuando la tarea, el contexto, el conjunto de herramientas y el contrato de salida son lo bastante reducidos como para poder verificarlos.

Preguntas frecuentes

¿El JSON válido significa que el modelo no alucinó?

No. El JSON válido demuestra que el objeto cumple las reglas de sintaxis o del esquema. No demuestra que los valores de los campos procedan del origen ni que coincidan con el estado real del sistema.

¿Establecer la temperatura en cero resolverá las alucinaciones en JSON?

No. Puede hacer que la salida sea más repetible, pero un valor sin fundamento seleccionado de forma constante sigue siendo una alucinación.

¿La decodificación restringida es suficiente para la automatización?

No. Úsala junto con la extracción fundamentada en el origen, el análisis del esquema, la validación semántica y una ruta segura de rechazo para los datos ausentes o ambiguos.