Salida estructurada: obtener JSON fiable de los modelos

Un modelo de lenguaje que escribe un párrafo agradable es útil para un humano. Un modelo de lenguaje que alimenta a otro programa necesita hacer algo más difícil: devolver datos en una forma que tu código pueda analizar, cada vez, sin sorpresas. En el momento en que dejas de leer la salida tú mismo y empiezas a pasársela a json.parse, la prosa se convierte en un lastre y la estructura se convierte en un requisito. Esta guía trata de cerrar la brecha entre "el modelo normalmente devuelve algo parecido a JSON" y "mi canalización puede depender de la salida del modelo", porque en producción "normalmente" es lo mismo que "roto de forma programada".

Por qué la prosa no basta

Cuando un modelo responde a una persona, las pequeñas imperfecciones se desvanecen en la flexibilidad humana. A un lector no le importa si la respuesta abre con "Claro, aquí lo tienes:" o envuelve los datos en un bloque de código o etiqueta los campos con palabras ligeramente distintas a la vez anterior. A un analizador le importa todo eso. Una sola frase suelta antes de los datos, una coma final, un campo que a veces es un número y a veces la palabra "desconocido": cualquiera de ellos convierte una canalización en funcionamiento en una traza de error.

El problema central es que un modelo está entrenado para producir texto plausible, y el texto plausible no es lo mismo que datos estructurados válidos. A su libre albedrío, un modelo derivará hacia ser útil y conversacional exactamente cuando lo necesitas rígido y legible por máquina. Obtener una salida estructurada fiable es el trabajo de eliminar esa deriva. Hay varias palancas, y se acumulan.

Palanca uno: pide con precisión

La mejora más barata es también la que más se omite: dile al modelo exactamente qué forma quieres, y muéstrasela. Las instrucciones vagas producen estructura vaga. Una petición de "devuelve los detalles como JSON" deja que el modelo invente nombres de campos, anidamiento y tipos, y los inventará de forma distinta en cada llamada.

En su lugar, especifica el esquema de forma concreta. Nombra cada campo, indica su tipo, di si es obligatorio y —esta es la parte que la gente omite— muestra un ejemplo completo de una respuesta válida. Los modelos son extraordinariamente buenos emparejando patrones con un ejemplo, y una sola muestra bien formada hace más por fijar el formato que un párrafo de descripción. Indica también las reglas que importan de forma explícita: que la salida debe ser solo el JSON sin texto alrededor, que un valor ausente debe representarse de una manera específica en lugar de omitirse o adivinarse, y que el conjunto de campos es fijo. La precisión en la petición es el cimiento sobre el que se construye todo lo demás. Omítela y las palancas posteriores estarán parcheando un problema que creaste tú.

Palanca dos: usa las funciones de salida estructurada del modelo

Pedir con amabilidad ayuda, pero las instrucciones por sí solas dejan margen para que el modelo divague. La mayoría de los proveedores serios de LLM ofrecen ahora funciones específicas para la salida estructurada, y usarlas supone un gran salto respecto al simple prompting.

Estas funciones vienen en un par de variedades. La forma más ligera es un modo que restringe la salida a JSON válido: se impide que el modelo emita cualquier cosa que no esté sintácticamente bien formada, lo que elimina toda la categoría de fallos del tipo "añadió una frase" y "usó un bloque de código". La forma más fuerte te permite suministrar un esquema al que la salida debe ajustarse, de modo que el resultado no es solo JSON válido sino JSON válido de la forma exacta que pediste, con los campos y tipos correctos.

Donde existan estas funciones, prefiérelas al prompting artesanal. Trasladan la garantía de "se le pidió al modelo que" hacia "el sistema lo impone", y ese cambio lo es todo. Consulta la documentación de tu proveedor para saber qué hay disponible y cómo invocarlo, porque los detalles difieren, pero el principio es constante: deja que la plataforma imponga la estructura en lugar de confiar en la buena voluntad del modelo.

Palanca tres: valida antes de confiar

Incluso con el mejor prompting y la función de salida estructurada más fuerte, trata la salida del modelo como no fiable hasta que la hayas comprobado. Esto no es paranoia; es la misma disciplina que aplicarías a cualquier entrada externa. La validación tiene dos capas, y quieres ambas.

• La validación estructural confirma que la salida se analiza y coincide con el esquema: los campos correctos están presentes, los tipos son correctos, los valores obligatorios no faltan. Esto captura las respuestas mal formadas que se cuelan por todo lo anterior.
• La validación semántica confirma que el contenido tiene sentido para tu dominio: una fecha es una fecha real, una categoría es uno de tus valores permitidos, una cantidad está en un rango plausible, un identificador referenciado existe de verdad. Una respuesta puede ser JSON perfectamente válido y aun así ser un sinsentido, y solo las comprobaciones de dominio lo capturan.

Ejecuta la validación como una compuerta, no como una idea tardía. La salida que falla la compuerta nunca debería llegar al resto de tu sistema como si estuviera bien. Lo que haces en la compuerta es el tema de la siguiente palanca.

Palanca cuatro: maneja los fallos que aun así tendrás

Ninguna combinación de lo anterior es perfecta, así que diseña para los fallos residuales en lugar de fingir que no ocurrirán. Cuando la validación falla, tienes unas cuantas opciones sensatas, aproximadamente en orden de preferencia.

La primera es un reintento acotado. Muchos fallos de salida estructurada son puntuales, y simplemente volver a preguntar —idealmente diciéndole al modelo qué estuvo mal en su intento anterior— funciona. Acota los reintentos para que un fallo persistente no entre en bucle eternamente. La segunda, para problemas menores y predecibles, es la reparación: recortar un bloque de código suelto, arreglar un formato obvio, forzar un casi-acierto a la forma esperada. Mantén la reparación estrecha y conservadora, porque la corrección automática agresiva oculta problemas reales y puede corromper datos. La tercera, cuando se agotan los reintentos y la reparación, es un fallo limpio y registrado: enruta el caso a una ruta de respaldo o a revisión humana en lugar de pasar datos malos aguas abajo, y regístralo para que puedas ver patrones. Un campo que falla la validación constantemente te está diciendo que arregles tu prompt o tu esquema, no que añadas otra regla de reparación.

Mantén el esquema tan simple como la tarea permita

Una palanca más silenciosa, digna de su propia mención: la complejidad de lo que pides afecta directamente a la fiabilidad con que lo obtienes. Los objetos profundamente anidados, las largas listas de campos opcionales y las estructuras condicionales elaboradas son todos más difíciles de producir de forma consistente para un modelo que una forma plana, pequeña y solo con campos obligatorios. Antes de recurrir a un prompting ingenioso para lidiar con un esquema barroco, pregúntate si el esquema necesita ser tan barroco. A menudo puedes dividir una extracción complicada en dos sencillas, o aplanar una estructura que estaba anidada por pulcritud más que por necesidad. La salida estructurada más fiable es la estructura que no complicaste de más.

En resumen

Un JSON fiable de un modelo es una pila de hábitos que se refuerzan, no un único truco. Pide con precisión y muestra un ejemplo. Usa las funciones de salida estructurada de tu proveedor para que la plataforma imponga la forma en lugar de que el modelo meramente la pretenda. Valida cada respuesta —estructural y semánticamente— y trátala como no fiable hasta que la supere. Diseña para los fallos que queden con reintentos acotados, reparación estrecha y respaldos limpios. Y mantén el esquema no más complejo de lo que la tarea requiere. Haz todo esto junto y cruzas la línea que importa en producción: de un modelo que normalmente devuelve datos analizables a una canalización que realmente puede depender de ello.