Cuando el código lee la respuesta de un modelo, «casi con la forma correcta» es un error. El prompting de salida estructurada es el conjunto de prácticas que hacen que un modelo devuelva datos que tu programa pueda analizar siempre: un formato definido, restricciones explícitas y validación.
Tres niveles de fiabilidad
| Nivel | Cómo | Garantía |
|---|---|---|
| Solo prompt | Describir el formato en el prompt | Ninguna. Normalmente acierta, a veces no |
| Modo JSON | Pedir a la API una respuesta JSON | JSON válido, pero no tu esquema |
| Salida restringida por esquema | Proporcionar un JSON Schema a la API | La salida se ajusta al esquema |
Usa el nivel más fuerte que ofrezca tu proveedor. OpenAI, Anthropic y Google ofrecen todos una forma de restringir una respuesta a un esquema o al esquema de entrada de una herramienta. El prompt sigue importando en todos los niveles, porque un esquema controla la forma de la salida y el prompt controla su contenido.
Escribir restricciones de salida en el prompt
Indica el formato, los campos, los tipos y los valores permitidos. Después di qué no debe aparecer.
Extract the order details from the email in the tags.
Return a JSON object with exactly these fields:
- "order_id": string, as written in the email
- "items": array of {"name": string, "quantity": integer}
- "total": number, without currency symbol
- "currency": one of "USD", "EUR", "GBP"
If a field is not present in the email, use null.
Return only the JSON object, with no explanation and no code fence.
<email>
{{email}}
</email>
Cuatro detalles de ese prompt evitan la mayoría de los fallos:
- «Exactamente estos campos» impide que el modelo añada extras bienintencionados.
- Los valores permitidos de
currencyevitan «US dollars» y «$». - Una regla de nulo da al modelo una forma correcta de decir «no encontrado», para que no invente un valor.
- «Devuelve solo el JSON» elimina la frase de comentario que rompe
JSON.parse.
Diseña el esquema para el modelo
Un esquema forma parte del prompt. El modelo lee los nombres y las descripciones de los campos como instrucciones.
- Nombra los campos por lo que contienen.
shipping_addresses mejor queaddr2. - Añade descripciones a los campos cuyo significado no sea obvio, incluidas la unidad y el formato: «fecha ISO 8601, UTC».
- Usa enumeraciones siempre que un campo tenga un conjunto fijo de valores.
- Mantenlo plano. El anidamiento profundo aumenta los errores. Divide una extracción muy compleja en prompts encadenados.
- Pon el razonamiento antes de la respuesta. Si quieres una explicación y un veredicto, ordena los campos
"reasoning"y luego"verdict". Un modelo escribe los campos en orden, así que el razonamiento escrito primero puede informar el veredicto.
Más allá de JSON
La salida estructurada no es solo JSON.
- Markdown con encabezados fijos sirve para respuestas que leen las personas: «Usa exactamente estos encabezados: Resumen, Riesgos, Próximos pasos».
- Las etiquetas de estilo XML son fáciles de extraer con una expresión regular y toleran texto libre en su interior:
<answer>…</answer>. - Un solo token es el formato más fiable de todos. Para la clasificación, pide solo la etiqueta.
- CSV o tablas sirven para datos pequeños y regulares; las reglas de comillas se vuelven frágiles con texto libre.
Elige el formato más sencillo que transporte la información.
Restricciones de longitud y contenido
Las restricciones de salida también cubren el tamaño y el estilo:
- At most 3 bullet points, each under 20 words.
- Use only facts from the document. If the document does not say, write "not stated".
- Write in the present tense.
Da los tamaños como números. «Breve» no es una restricción en la que puedan apoyarse un analizador ni un diseño.
Valida siempre
Incluso con salida restringida por esquema, valida antes de usar los datos.
- Analiza y comprueba el esquema de cada respuesta. Una respuesta puede cortarse al alcanzar el límite de tokens de salida, lo que deja un JSON truncado.
- Comprueba la semántica que el esquema no puede expresar: el total es igual a la suma de los elementos, la fecha no está en el futuro.
- Decide la vía de fallo. Reintenta una vez incluyendo en el prompt el error de validación y luego recurre a una alternativa o márcalo para revisión.
- Nunca ejecutes la salida estructurada a ciegas. Un campo que se convierte en una cláusula SQL, una ruta de archivo o un argumento de shell necesita la misma sanitización que la entrada de un usuario. Consulta la seguridad de prompts.
Modos de fallo comunes
| Fallo | Causa | Corrección |
|---|---|---|
| Texto antes o después del JSON | Falta la instrucción «solo» | Añádela, o usa el modo JSON |
| Envuelto en un bloque de código | Costumbre del modelo | Di «sin bloque de código», o quítalo en el código |
| Valores inventados | Sin regla para datos que faltan | Añade una regla de nulo o «no indicado» |
| Campos adicionales | Redacción abierta | Di «exactamente estos campos»; prohíbe propiedades adicionales |
| Salida truncada | Se alcanzó el límite de salida | Sube el límite o divide la tarea |
| Ortografía inconsistente de las enumeraciones | Valores sin enumerar | Enumera los valores permitidos |
Revisar el prompt antes de ejecutarlo
Un formato de salida ausente es el hallazgo más frecuente en los prompts que alimentan código. El analizador de prompts de PromptFlowEngine lo señala, junto con la falta de indicación de longitud y las variables sin delimitar. La plantilla de extracción JSON es un ejemplo completo que supera todas las comprobaciones.
Para ver cómo encaja esto en el código de una aplicación, consulta la ingeniería de prompts para desarrolladores.