Salidas estructuradas: JSON garantizado

Qué muestra esta lección

La decodificación restringida solo permite tokens siguientes válidos, así que el JSON siempre se analiza correctamente.

La pregunta con la que abre

Tu código necesita JSON limpio, pero el modelo a veces agrega prosa o rompe el schema.

El recorrido, en palabras de la propia lección

• Avanza el modelo por el riel: elige el siguiente token. Los tokens ilegales están bloqueados.
• Desactiva la restricción y mira cómo el mismo riel descarrila en JSON inválido.
• Parseable por construcción, pero igual revisa que los valores tengan sentido.
• Forma válida ≠ valor correcto. Esto coincide con el schema a la perfección, pero 450 °C no es real. La estructura está garantizada; el contenido no.
• Después de parsear, valida igual los valores: rangos, enums, reglas de negocio o una segunda pasada del modelo. La forma y la verdad son dos problemas distintos, y por eso la puerta de despliegue de 7.12 corre ambos chequeos: los parse checks atrapan una forma rota, y solo los evals atrapan un valor erróneo.
• Los tokens ilegales reciben probabilidad cero antes del sampleo, así que la salida solo puede ser JSON válido. Parsea siempre.
• Sin enmascarar, cualquier token puede ganar el sorteo, incluidos los que producen texto. El mismo riel descarrila y el software receptor se atraganta.
• El softmax de 3.3 convierte los scores en probabilidades del siguiente token. El constrained decoding pone a cero todos los tokens que romperían el schema antes de ese sorteo y luego renormaliza a los sobrevivientes para que sumen 1, así que solo se pueden samplear los válidos.
• En cada paso el decoder se enmascara para dejar solo los tokens siguientes válidos según el schema, así que el JSON siempre parsea. Pero una forma válida puede contener igual un valor erróneo. La misma idea que viste en 7.1: obtén una estructura fiable del modelo y luego verifica tú mismo la sustancia.
• La restricción es gratis al decodificar, enmascarar tokens ilegales no cuesta nada. Pero el orden de los campos importa: si el schema exige la respuesta antes de un campo de razonamiento, el modelo debe comprometerse antes de haber pensado, y la precisión cae. La solución es el diseño del schema: pon el campo de razonamiento primero.
• Conectas un LLM a un software que necesita JSON limpio, pero a veces agrega una frase antes del JSON y el parser se rompe. ¿Qué hace que esto sea confiable?
• Structured outputs: restringir el decoding a un schema para que el modelo solo pueda emitir JSON válido, en vez de confiar en que un prompt lo mantenga ordenado. Cualquier función de IA que alimenta a otro sistema (formularios, function calls, pipelines) se apoya en esto para ser fiable.
• "string" significa cualquier texto, "number" cualquier número; el | significa que sky tiene que ser una de estas tres palabras (un "enum" = una lista fija de valores permitidos).
• Cada token del riel fue válido según el schema, así que la cadena parsea por construcción.
• El software receptor la lee sin error, sin red de seguridad. El constrained decoding la forzó a cumplir.
• El software no puede actuar sobre un párrafo bien escrito; necesita respuestas que las máquinas puedan leer de forma fiable, con la misma forma cada vez. El schema funciona como un portero con un reglamento (llamado gramática): en cada posición solo deja entrar tokens que mantienen la salida válida. Prueba primero un token gris: mira por qué el portero lo bloquea. Luego emite el válido.

La idea clave

Puedes hacer que las salidas sean parseables por construcción, sin dejar de comprobar que los valores tengan sentido.

Qué puedes hacer después de esta lección

Puedes explicar la decodificación restringida / salidas estructuradas, y por qué una forma válida igual necesita validar los valores.

Adónde lleva: Ya puedes construirlo y lanzarlo, pero ¿cómo lees las puntuaciones que dicen que un modelo supera a otro?

Este es el resumen escrito. La lección en sí es interactiva: arriba predices, arrastras y operas el mecanismo, y la revelación te responde.