Cómo hacer que un LLM siga instrucciones de formato concretas

Uno de los mayores quebraderos de cabeza al integrar un LLM en un flujo de trabajo es conseguir que su output tenga un formato consistente. No me refiero a la creatividad de la respuesta, sino a que genere un JSON válido, una lista con el separador correcto o una estructura de datos predefinida. Es un problema común que veo en producción y que requiere más que un prompt bien redactado.

Un formato incorrecto paraliza automatizaciones y genera errores.

La inconsistencia del output en producción

Cuando dependes del resultado de un modelo de lenguaje para alimentar otro sistema — sea una base de datos, una API o un paso en n8n — la inconsistencia es un error crítico. Un JSON mal formado, una lista que no usa el delimitador esperado o un campo faltante, rompe la cadena de automatización. Esto es lo que me llega con frecuencia cuando un cliente ha intentado integrar un modelo de IA por su cuenta y el sistema falla de forma esporádica.

La diferencia entre un prototipo de IA que funciona en una demo y una solución robusta en producción reside en el manejo de estos detalles. Un LLM es un modelo de lenguaje, no un validador de esquemas infalible.

Estrategias de Prompt Engineering para un formato predecible

Mi regla es clara: el prompt debe ser lo más explícito posible. No basta con pedir “un JSON”. Tienes que describir la estructura del JSON, los tipos de datos esperados y, si es posible, dar un ejemplo.

Un buen prompt para obtener JSON incluye el esquema en el propio texto, marcando claramente dónde empieza y termina la estructura. Esto ayuda al modelo a entender no solo el contenido, sino también la forma que debe seguir.

# Ejemplo de prompt para JSON
prompt = """
Genera un JSON con la siguiente estructura para el siguiente texto: '{texto_a_procesar}'.
El JSON debe contener los siguientes campos:
- "titulo": (string) El título principal del texto.
- "palabras_clave": (array de strings) Una lista de 3 a 5 palabras clave relevantes.
- "resumen": (string) Un resumen conciso de no más de 50 palabras.

Ejemplo de formato esperado:
```json
{
  "titulo": "Título de ejemplo",
  "palabras_clave": ["ejemplo", "formato", "json"],
  "resumen": "Este es un resumen conciso del texto que se ha proporcionado, con un máximo de cincuenta palabras."
}

Asegúrate de que el output sea un JSON válido y esté envuelto en un bloque de código markdown. """

## Validación externa del output en producción

Por muy bueno que sea tu `prompt`, no puedes confiar ciegamente en que el modelo siempre devolverá la estructura correcta. Las alucinaciones o errores son parte de la naturaleza de estos modelos, especialmente bajo carga o con inputs inesperados. La solución no es rezar, sino validar.

Después de que el modelo genere su respuesta, siempre implemento un paso de validación. Para JSON, esto significa intentar parsear la cadena y verificar que los campos esperados existen y tienen el tipo de datos correcto. Si la validación falla, el flujo debe tener una estrategia para manejar el error — ya sea reintentar la llamada al modelo de lenguaje, notificar al operador o usar un `fallback`. Esta capa de validación es crítica para la robustez de cualquier sistema que integre IA. En proyectos donde la fiabilidad es clave, la validación del resultado se convierte en una pieza más del [coste de mantener un flujo de IA en producción](/blog/coste-mantener-flujo-ia-produccion/).

```javascript
// Ejemplo de validación de JSON en JavaScript
function validarOutputJSON(jsonString) {
  try {
    const data = JSON.parse(jsonString);
    if (typeof data.titulo !== 'string' || !Array.isArray(data.palabras_clave) || typeof data.resumen !== 'string') {
      console.error("Estructura de JSON incorrecta o tipos de datos no esperados.");
      return null;
    }
    return data;
  } catch (e) {
    console.error("El output no es un JSON válido:", e);
    return null;
  }
}
// Uso:
// const outputDelLLM = "{\"titulo\": \"Mi Titulo\", \"palabras_clave\": [\"a\",\"b\"], \"resumen\": \"Un resumen.\"}"
// const datosValidados = validarOutputJSON(outputDelLLM);
// if (datosValidados) { /* continuar con el flujo */ }

Implicaciones de forzar el formato del output

Forzar la estructura del resultado en un modelo de lenguaje tiene sus beneficios, pero también añade complejidad al flujo general.

Ventajas:

• Fiabilidad del sistema: Reduce la probabilidad de errores en los pasos siguientes de tu automatización.
• Integración fluida: Los datos se adaptan directamente a las APIs o bases de datos sin transformaciones manuales adicionales.
• Depuración más sencilla: Si algo falla, sabes que el problema no es la estructura, sino el contenido o el prompt.

Desventajas:

• Prompts más largos y complejos: Describir el esquema añade longitud y detalle al prompt, lo que puede aumentar el coste por token.
• Validación adicional: Necesitas implementar lógica de validación extra en tu código o en tu herramienta de automatización (como n8n).
• Consumo de tokens: Los ejemplos de estructura y los esquemas JSON añaden tokens al prompt, aumentando el coste real de los LLM en proyectos.

Aspectos no negociables:

• Validación del output: Nunca asumas que el LLM ha generado el formato correcto. La validación es una barrera de seguridad necesaria.
• Manejo de errores: Tu flujo debe saber qué hacer si la validación falla. No puedes simplemente dejar que el sistema se caiga.

Para profundizar en la interacción con modelos de lenguaje, te recomiendo leer sobre prompts efectivos con IA. Para casos más avanzados donde el LLM necesita interactuar con herramientas externas, entender el function calling en LLM te abrirá nuevas posibilidades. Y, por supuesto, para asegurar la solidez de todo esto, la validación de output de LLM en producción es un paso necesario.