¿Por qué no basta con una prosa bonita?
Porque lo que quieres hacer con ella normalmente no es leerla. Quieres meterla en una hoja de cálculo, pegarla en un correo, cargarla en un sistema, sumarla. Desde un texto corrido eso es trabajo manual; desde una tabla es copiar.
La petición de formato es la corrección más barata que puedes hacerle a un prompt: una frase, y la salida pasa a ser utilizable. Por eso La anatomía de un prompt que funciona cuenta el formato entre las cinco piezas básicas.
Primer nivel: se lo pides
En una interfaz de chat esto es todo lo que hay, y para la mayoría de las tareas basta.
Indica la forma, el tamaño y los campos:
Devuélvelo en tabla. Columnas: concepto, cantidad, precio neto, plazo. Si un valor no aparece en el material, pon un guion.
Si además quieres una justificación junto a los campos, de eso trata Chain-of-thought , un artículo aparte. La frase importante, sin embargo, es la última. Sin ella el modelo se inventa algo para el valor que falta, porque la forma de una tabla exige que ahí haya algo. Es la alucinación en su forma más traicionera: no aparece en la prosa, aparece en una celda, justo donde no la buscas.
Lo que sí funciona de forma fiable en este nivel es la estructura. Cuántas columnas, en qué orden, lista o párrafos. Lo que no: un número exacto de palabras, porque el modelo no sabe de antemano dónde va a acabar cuando empieza.
Segundo nivel: JSON, para que lo lea una máquina
Si el resultado no lo vas a leer tú, sino otro programa, hace falta JSON — un formato sencillo, legible por máquina, en el que cada dato tiene nombre.
También puedes pedirlo en una interfaz de chat, y funcionará más o menos. Hay dos problemas típicos.
El modelo lo rodea de palabras. «Por supuesto, aquí tienes el JSON que pediste:» — y el programa que iba a procesarlo se cae. La solución: di explícitamente que la respuesta debe ser solo el JSON, nada más.
A veces no es válido. Falta un corchete, o nombra un campo distinto de como lo nombró ayer. No es un fallo raro, es la variabilidad natural del mecanismo.
Esto último mejora mucho con la temperature baja. Si un proceso automatizado devuelve a veces los datos en el formato equivocado, bájala antes de ponerte a reescribir el prompt.
Tercer nivel: un esquema impuesto
Por API existe una posibilidad que la interfaz de chat no ofrece: puedes indicar la estructura de antemano y el sistema garantiza que la respuesta la respeta.
Conviene separar dos cosas distintas, porque los nombres se parecen:
- JSON mode — garantiza únicamente que la salida sea JSON válido. No que contenga tus campos.
- Structured output — tú das el esquema y la respuesta se ajusta a él: estos campos, con estos tipos, con esta forma.
De los dos, el útil es el segundo, y la recomendación de los propios proveedores es usarlo allí donde esté disponible. En la práctica la diferencia es que no hay que validar y reintentar después: si el esquema está, los campos estarán.
Este es el punto en el que el prompting se convierte en desarrollo. Pero conviene conocerlo aunque no vayas a construirlo tú — porque si le dices a un programador «a veces vuelve en el formato equivocado», esta será su respuesta.
Qué indicar, en el esquema o en la petición de formato
Cuatro cosas, en este orden:
- Nombre del campo. Exactamente como lo espera el otro sistema. No «precio» si allí se llama
precio_neto. - Tipo. Número, texto, fecha, sí/no. En las fechas, también el formato:
AAAA-MM-DD. - Valores permitidos, si la lista es cerrada. «categoría: facturación | envío | reclamación | otros» — sin esto el modelo se inventa una quinta categoría.
- Qué hacer con un valor que falta. Cadena vacía,
null, un guion — pero dilo.
Un ejemplo que muestra los tres niveles
La tarea: extraer datos de las facturas que llegan.
Primer nivel, en chat: «Lee de esta factura el número, la fecha de emisión, el importe neto y la fecha de pago. Devuélvelo en tabla. Lo que no se lea con claridad, márcalo [ilegible].» Perfecto para una o dos facturas.
Segundo nivel: lo mismo pedido en JSON para poder importarlo. Funciona con unas decenas al mes, pero cuenta con corregir a mano de vez en cuando.
Tercer nivel: un esquema, impuesto, con temperature baja. Con varios cientos al día es la única opción en la que no hay que revisarlo todo.
La respuesta no la decide la tecnología, sino el volumen. Esa es la cuarta pregunta de ¿Es la IA adecuada para esta tarea?, el método de un minuto.
Qué llevarte
Di la estructura, y di qué pasa cuando falta un dato. Esas dos frases hacen la mayor parte del trabajo. Un esquema impuesto es aún más fiable, pero solo hace falta cuando pasan por el proceso tantos elementos que revisarlos a mano ya no cabe.