Structured Outputs para Agentes
Nivel intermedio — garantizar respuestas del LLM en formatos estructurados y validados que se integren directamente con tu código.
El problema
Los LLMs generan texto libre por defecto. Cuando necesitas datos estructurados, dependes de que el modelo siga instrucciones de formato — y esto falla con frecuencia: JSON malformado, campos faltantes, tipos incorrectos.
Situación típica: tu sistema de tickets pide "extrae prioridad, categoría y hora del incidente en JSON". A veces el LLM responde con el JSON limpio; otras veces responde en prosa ("la prioridad es alta porque dice 'urgente'..."). Tu código hace json.loads() y falla el 20% de las veces. // texto que "parece" JSON no es lo mismo que JSON garantizado
3 métodos, 3 niveles de confiabilidad
1. Prompt engineering (baseline)
Pedir el JSON directamente en el prompt ("Responde ÚNICAMENTE con JSON válido..."). El enfoque más simple pero menos confiable: el modelo puede ignorar la instrucción, añadir texto antes/después del JSON, y no hay validación de tipos ni manejo consistente de campos opcionales.
2. Tool use como schema enforcer
Usar function calling no para ejecutar código, sino para forzar un schema: defines una "herramienta" que en realidad es solo la forma de los datos que quieres extraer, con tool_choice forzado a esa herramienta específica. Cuando fuerzas tool_choice, el modelo debe retornar datos que cumplan el schema — con tipos, enum para valores limitados, y campos required.
3. Pydantic + validación
Combina tool use con validación estricta en Python: defines un modelo Pydantic (BaseModel) con las mismas restricciones que el schema — tipos, longitudes mínimas/máximas, patrones regex — y validas el output del LLM contra ese modelo antes de usarlo en tu aplicación. Si un campo no cumple, obtienes un ValidationError explícito en vez de un bug silencioso más adelante.
Comparación de métodos
| Método | Confiabilidad | Complejidad | Cuándo usar |
|---|---|---|---|
| Prompt only | 70-80% | Baja | Prototipos rápidos, datos no críticos |
| Tool use | 95%+ | Media | Producción, datos importantes |
| Pydantic + Tool | 99%+ | Alta | Datos críticos, pipelines automatizados |
Esta lección resuelve directamente una confusión detectada en el material de Prompt Engineering: "JSON mode" (pedir JSON en el prompt, Método 1 aquí) y "Structured Outputs" (forzar un schema vía tool use, Método 2-3) no son lo mismo — la garantía de forma viene de forzar tool_choice con un schema, no de Pydantic ni de pedirlo amablemente en el prompt. Pydantic añade la validación de contenido encima de esa garantía de forma, pero son dos mecanismos distintos actuando en capas distintas. Las cifras de confiabilidad (70-80%, 95%+, 99%+) tampoco citan cómo se midieron — trátalas como orden de magnitud relativo entre métodos, no como benchmark verificado.
Practica: extractor de reseñas
Implementa un sistema de extracción de datos que use tool use como schema enforcer, con validación Pydantic y manejo de errores robusto, para un extractor de información de reseñas de productos: sentimiento, rating inferido, pros/contras, y si la reseña sugiere intención de compra.
Prueba deliberadamente con outputs inválidos (rating fuera de rango, valor de enum inexistente, summary demasiado corto) y verifica que Pydantic los rechaza con un ValidationError claro en vez de dejarlos pasar silenciosamente.