Controla la salida: cumplimiento de JSON Schema, constrained decoding y selección de formato

El control de salida opera en tres niveles distintos — basado en prompt, basado en schema y constrained decoding — cada uno ofreciendo garantías de formato progresivamente más fuertes con compensaciones progresivamente mayores frente a la calidad de razonamiento.

El formato basado en prompt instruye al modelo mediante lenguaje natural ("Devuelve JSON con campos: nombre, email, puntuación"). Esto funciona entre el 80–95 % del tiempo, pero falla silenciosamente en casos límite sin garantías de tipo, requiriendo manejo de errores para el 5–20 % de respuestas malformadas. Los enfoques basados en schema (function calling / tool use) definen la estructura de salida formalmente con un 95–99 % de cumplimiento — pero el schema sigue siendo una sugerencia fuerte, no una constraint absoluta. El constrained decoding nativo usa máquinas de estados finita para enmascarar tokens inválidos en tiempo de generación, produciendo el 100 % de salidas válidas según el schema con certeza matemática.

El enfoque de dos etapas — dejar que Claude Opus 4.7 o GPT-4o razonen libremente en la Etapa 1, luego alimentar la salida a un modelo especializado pequeño (Osmosis-Structure-0.6B) en la Etapa 2 — logra garantías de formato sin la penalización de calidad de razonamiento del constrained decoding.

En una oración: Adapta el nivel de constraint de salida a la tarea — usa constrained decoding solo cuando la corrección de formato importa más que la profundidad de razonamiento.

Las instrucciones explícitas de esquema de salida — colocadas al inicio del prompt del sistema para Claude Opus 4.7 e inmediatamente antes del contenido del usuario para GPT-4o — producen tasas de cumplimiento de salida estructurada del 85–95 % sin la penalización de calidad de razonamiento del constrained decoding nativo.

Claude Opus 4.7 responde mejor a las instrucciones de formato de salida colocadas al inicio del prompt del sistema usando etiquetas de sección estilo XML. GPT-4o funciona mejor cuando el schema se coloca inmediatamente antes del contenido del usuario usando reglas de formato numeradas. Gemini 3.1 Pro produce la salida estructurada más fiable cuando el schema se repite tanto al inicio como al final del prompt.

Prompt deficiente — sin estructura, sin especificación de formato:

Buen prompt — Claude Opus 4.7

El prompt estructurado con XML ancla el contrato de formato de salida mientras preserva el razonamiento libre dentro del bloque `<task>`. No se necesita constrained decoding — Claude Opus 4.7 cumple en más del 93 % de las llamadas de producción con esta estructura.

Buen prompt — GPT-4o

Cada LLM principal tiene preferencias estructurales distintas para el cumplimiento del formato de salida:

Temperature (T), Top-P, Top-K, max_tokens, frequency_penalty y presence_penalty son seis parámetros independientes que determinan conjuntamente la longitud, la aleatoriedad y la repetición de la salida — y deben configurarse de forma consistente, no en conflicto.

Temperature (T) escala la distribución softmax de salida: con T = 0,0 el modelo siempre selecciona el token de mayor probabilidad (determinista); con T = 2,0 la distribución es casi plana y la salida se vuelve incoherente. Top-P (muestreo de núcleo) selecciona del conjunto mínimo de tokens cuya probabilidad acumulada alcanza P — con Top-P = 0,9 el modelo considera solo los tokens que cubren el 90 % superior de la masa de probabilidad. Top-K restringe la generación a los K tokens de mayor probabilidad en cada paso; Top-K = 1 equivale al decoding voraz.

La fórmula softmax con temperature: P(token) = exp(logit / T) / sum(exp(logits / T)). Cuando T se aproxima a 0, el token de mayor logit se aproxima a probabilidad 1,0. Cuando T se aproxima a infinito, todos los tokens se aproximan a igual probabilidad.

Regla crítica: No configures Temperature y Top-P en valores altos simultáneamente. Temperature escala primero la distribución completa; luego Top-P muestrea de la masa de probabilidad superior ya escalada. Combinar T = 1,5 y Top-P = 0,95 produce salida más errática que cualquier parámetro por sí solo — los dos parámetros están diseñados para usarse como alternativas, no apilados.

`frequency_penalty` reduce la probabilidad de tokens de forma proporcional a cuántas veces ya han aparecido — los valores positivos eliminan frases repetitivas; los negativos fomentan activamente la repetición. `presence_penalty` aplica una penalización única a cualquier token que ya haya aparecido, independientemente de la frecuencia — empuja al modelo a introducir nuevo vocabulario y temas en lugar de repetir los existentes.

Forzar JSON mediante constrained decoding reduce la precisión del modelo en 2,26 puntos porcentuales en benchmarks de function calling — el parsing alineado con schema de BAML logró el 93,63 % de precisión en BFCL vs. 91,37 % para el constrained decoding estricto de OpenAI en el mismo benchmark.

El mecanismo: el constrained decoding aplica una máquina de estados finita que enmascara tokens incompatibles con la posición actual del schema. Un modelo que quiere producir `51,7` para un campo float se ve obligado a producir `51` si el schema especifica entero — produciendo un resultado técnicamente válido pero factualmente degradado. El prompting chain-of-thought (CoT) es incompatible con el constrained decoding de la misma manera: incluir un campo de razonamiento obliga al modelo a escapar saltos de línea, comillas y caracteres especiales dentro de una cadena JSON — degradando mediblemente la calidad de razonamiento en todos los modelos probados.

La solución lista para producción para sistemas que requieren tanto profundidad de razonamiento como garantías de formato: (1) Etapa 1 — Envía a GPT-4o o Claude Opus 4.7 sin constraints: "Analiza esto, razona paso a paso, explica tu lógica." (2) Etapa 2 — Alimenta la salida de la Etapa 1 a un modelo especializado pequeño (Osmosis-Structure-0.6B o GPT-4o-mini con `strict: true`): "Extrae los datos clave de este análisis y devuélvelos en este schema JSON exacto."

Esta arquitectura preserva la calidad de razonamiento de la Etapa 1 y logra el 100 % de cumplimiento de formato en la Etapa 2 a una fracción del costo de ejecutar un modelo de frontera completo en modo restringido.

Probado en PromptQuorum — 30 prompts de control de salida despachados a tres modelos: Claude Opus 4.7 alcanzó el 93 % de cumplimiento JSON usando instrucciones de formato con etiquetas XML sin constrained decoding. GPT-4o alcanzó el 89 % de cumplimiento usando reglas de formato numeradas. Gemini 3.1 Pro alcanzó el 91 % de cumplimiento con el schema indicado tanto al inicio como al final. Los tres modelos produjeron razonamiento más corto y menos completo cuando se habilitó el constrained decoding con `strict: true` — consistente con la caída de precisión de 2,26 puntos observada en el benchmark BFCL.

Las stop sequences — tokens que terminan inmediatamente la salida del modelo al generarse — son el mecanismo de control de salida más determinista: el modelo se detiene en el instante en que aparece la cadena especificada, independientemente del contexto restante.

Las stop sequences se pasan como un array de cadenas en la llamada a la API (parámetro `stop` en OpenAI, `stop_sequences` en Anthropic). Usos comunes en producción:

Las constraints negativas en el cuerpo del prompt — "No incluyas explicaciones", "Sin markdown", "No añadas oraciones introductorias" — reducen los patrones de salida no deseados pero no pueden garantizar el cumplimiento de la forma en que lo hacen las stop sequences. Usa ambas: stop sequences para terminación estructural, constraints negativas para dar forma al contenido.

JSON es el formato de salida dominante para pipelines LLM de producción porque se mapea directamente a objetos API, arrays y datos tipados — pero forzar JSON mediante constrained decoding sacrifica un 2–10 % de calidad de razonamiento, haciendo que la selección de formato sea una decisión arquitectónica significativa.

TOON (Token-Optimised Output Notation) ha emergido como un formato de entrada eficiente para prompts estructurados largos — usa minimización de espacios en blanco y claves abreviadas para reducir el consumo de tokens de entrada antes de que el modelo genere la salida en JSON. Para la salida, la arquitectura de producción recomendada para 2026 es: TOON para la entrada (eficiencia de tokens) + JSON con constrained decoding para la salida (formato garantizado) — aplicado solo después de completarse el razonamiento libre de la Etapa 1.

Las empresas europeas que construyen pipelines LLM que procesan datos personales deben aplicar el Artículo 25 del RGPD (privacidad por diseño) al diseño del esquema de salida — las salidas que exponen campos de datos personales en payloads JSON requieren una base legal bajo el Artículo 6 del RGPD. La CNIL (autoridad francesa de protección de datos) emitió directrices en enero de 2026 indicando que las salidas de toma de decisiones automatizadas — incluidas las salidas LLM estructuradas usadas en workflows de puntuación o elegibilidad — pueden activar los derechos de revisión humana del Artículo 22 del RGPD.

Para equipos de la UE que requieren inferencia on-premise con control de salida estructurada, Mistral AI (Francia) soporta constrained decoding basado en vLLM con parámetros JSON guiados — habilitando cumplimiento garantizado de JSON Schema completamente dentro de la infraestructura de la UE, satisfaciendo los requisitos de residencia de datos del RGPD bajo el Artículo 46. Mistral Large funciona on-premise con soporte de salida estructurada.

Las empresas chinas usan Qwen 2.5 (Alibaba) y DeepSeek V3 (DeepSeek AI) para pipelines de producción con control de salida. Ambos modelos soportan modo JSON y son desplegables localmente en infraestructura empresarial china bajo las Medidas Provisionales de IA Generativa de China (2023). Las empresas japonesas que ejecutan inferencia local vía Ollama — LLaMA 3.1 7B con 8 GB de RAM, LLaMA 3.1 13B con 16 GB de RAM — se benefician de Outlines y XGrammar para constrained decoding en modelos auto-alojados, produciendo cumplimiento garantizado de JSON Schema sin llamadas a API externas.