El mes pasado, realicé la misma tarea de extracción contra Claude Sonnet 3.5 dos veces. Primer intento: prompt no estructurado, 67% de precisión. Segundo intento: formato de salida estructurado con validación de esquema, 94% de precisión. Mismo modelo, mismos datos, cero ajuste fino. La única diferencia fue cómo pregunté.
El prompting estructurado no es un concepto nuevo. Pero la mayoría de la gente lo usa mal, o no lo usa en absoluto. Le piden a un modelo que «devuelva JSON» y se preguntan por qué la salida llega mal formada. Especifican un esquema pero olvidan restringir los campos. Añaden estructura al prompt sin igualarla en los requisitos de salida.
Este artículo cubre el framework que llevó a AlgoVesta de fallos constantes en el análisis de salida a sistemas de producción que funcionan sin supervisión durante semanas. No es magia. Es disciplina de ingeniería aplicada a cómo hablas con los LLM.
Qué es Realmente el Prompting Estructurado (y qué no lo es)
El prompting estructurado es una técnica donde defines el formato exacto, los campos, las restricciones y las reglas de validación que debe seguir tu salida, y luego incrustas esas reglas en el propio prompt.
Esto es diferente de:
- Pedir JSON: «Devolver JSON» sin detalles del esquema. Los modelos lo intentarán, pero de forma inconsistente.
- Usar llamada a función: La llamada a función es una herramienta para forzar la estructura de salida a nivel de API. El prompting estructurado es una técnica de prompt que funciona con o sin llamada a función.
- Plantillas de Prompt: Rellenar variables en una plantilla estática. Eso es inserción de datos, no estructura.
El prompting estructurado funciona porque los modelos razonan mejor cuando las restricciones son explícitas. Han visto miles de ejemplos donde un formato específico condujo a resultados específicos. Cuando especificas ese formato, estás activando patrones aprendidos.
Ejemplo real de producción: Una tubería de extracción financiera necesitaba extraer datos de operaciones de transcripciones de llamadas de resultados. Sin estructura, Claude devolvió 4–7 campos extra que no pedí, formatos de fecha faltantes y precisión decimal inconsistente. Con un esquema incrustado en el prompt, devolvió exactamente lo que especifiqué, cada vez.
El Framework Central: Cuatro Capas de Estructura
Este es el patrón que realmente escala:
- Definición de esquema – Define qué campos existen y sus tipos
- Especificación de restricciones – Define valores, rangos y formatos válidos
- Plantilla de salida – Muestra la estructura exacta esperada
- Reglas de validación – Haz que el modelo sea consciente de lo que hace que la salida sea inválida
Cada capa se refuerza mutuamente. Si falta una, el modelo se desvía.
Capa 1: Definición de Esquema
Comienza definiendo qué datos necesitas. Sé específico con los tipos:
# Mala definición de esquema
Devuelve información sobre la empresa.
# Mejor definición de esquema
Extrae los siguientes campos:
- company_name (cadena, requerido)
- founded_year (entero, 4 dígitos)
- headquarters_location (cadena, ciudad y país)
- revenue_usd (número, en millones)La segunda versión le da al modelo algo concreto. Sabe los tipos que debe producir.
Capa 2: Especificación de Restricciones
Los tipos por sí solos no son suficientes. Añade reglas sobre qué valores son aceptables:
# Esquema con restricciones
- company_name (cadena, requerido, máximo 100 caracteres)
- founded_year (entero, debe estar entre 1800 y 2025)
- headquarters_location (cadena, formato: «Ciudad, País» solamente)
- revenue_usd (número, debe ser positivo, nulo si se desconoce)Estas restricciones reducen la alucinación. El modelo ahora sabe qué hace que una salida válida sea inválida. En pruebas, la adherencia de Claude Sonnet 3.5 a las violaciones de restricciones cayó de ~12% a ~2% con reglas explícitas.
Capa 3: Plantilla de Salida
Muestra, no cuentes. Proporciona un ejemplo de cómo se ve una salida válida:
FORMATO DE SALIDA (esta es la estructura exacta que debes seguir):
{
