Salidas estructuradas de LLM: JSON Schema y validación segura en producción
Una respuesta JSON válida no es automáticamente correcta ni segura. Aprende a diseñar schemas para la respuesta final del modelo, validarla en tu aplicación y decidir cuándo rechazar, reintentar o pedir revisión humana.
Las salidas estructuradas convierten la respuesta final de un LLM en un objeto que tu aplicación puede parsear. Es mejor que extraer JSON de markdown, pero no convierte al modelo en una fuente de verdad: JSON válido no significa correcto ni seguro.
Un schema pequeño y explícito reduce ambigüedad; `additionalProperties: false` puede ayudar, aunque debes adaptarlo al subconjunto soportado por la API.
Pydantic o Zod: parsear no es validar negocio
Pydantic en Python y Zod en TypeScript deben estar en el borde de confianza: hasta que el parser termine, trata la respuesta como `unknown`. Después aplica reglas de dominio separadas.
¿Te está sirviendo? Hay una dosis cada semana
Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratisfrom typing import Literal\nfrom pydantic import BaseModel, Field, ValidationError\n\nclass LlmDecision(BaseModel):\n schema_version: Literal["1"]\n decision: Literal["allow", "deny", "review"]\n reason: str = Field(min_length=1, max_length=500)\n confidence: float = Field(ge=0, le=1)\n requires_human_review: bool\n\ndef parse_model_output(payload: object) -> LlmDecision:\n return LlmDecision.model_validate(payload)\n\ntry:\n result = parse_model_output(response_json)\nexcept ValidationError as error:\n record_validation_failure(error.errors())\n raise RuntimeError("Respuesta rechazada") from error\n\nif result.decision == "allow" and result.confidence < 0.85:\n raise RuntimeError("La política exige revisión")Pydantic comprueba tipos y límites, pero no sabe si un tenant puede ejecutar una acción o si una cita es autoridad. Esa comprobación pertenece a la aplicación.
Checklist
Rechazo, reintento y repair
- Clasifica el fallo. JSON truncado o campo ausente puede justificar una petición de corrección; una violación de autorización o una respuesta peligrosa debe rechazarse o escalarse.
- Limita intentos, conserva el error original, mide tokens y latencia, y vuelve a ejecutar todas las validaciones tras un repair. No aceptes solo porque el segundo texto parsea.
- Tras agotar intentos devuelve `needs_review` o `unavailable`. Un fallback a texto libre para una interfaz humana no debe entrar silenciosamente en automatización.
Versionado, observabilidad y evals
Versiona schema, prompt, modelo y política. Si cambias enums o campos obligatorios, trátalo como cambio de contrato y migra consumidores de forma planificada.
Puntos a revisar
Lo que conviene comprobar
Registra hash de schema, proveedor, modelo, latencia, reintentos y tipo de fallo; redacta contenido sensible. Mide validez sintáctica, exactitud semántica, rechazos y acciones peligrosas bloqueadas con [evals de agentes](/evals-agentes-ia-tools-trayectorias/).
Preguntas frecuentes
¿JSON válido significa que la respuesta es correcta?
No. Comprueba evidencia, reglas, permisos, actualidad y coherencia.
¿Puedo usar cualquier JSON Schema con cualquier proveedor?
No necesariamente: soportan subconjuntos, keywords y versiones distintas.
¿Pydantic sustituye al schema del proveedor?
No; es una segunda barrera local antes del dominio.
¿Cuándo reintento?
Solo ante fallos recuperables y con límite; los fallos de autorización deben escalarse.
¿Cómo difiere de MCP outputSchema?
MCP describe resultados de una tool; aquí validas la respuesta final del modelo.
<script type="application/ld+json">{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿JSON válido significa que la respuesta es correcta?
","acceptedAnswer":{"@type":"Answer","text":"No; hay que comprobar evidencia, reglas, permisos y actualidad."}}]}</script>
Cómo implantar un contrato de salida para un workflow LLM
- Definir consumidor. lista campos y estados de error.
- Versionar schema. fija tipos, límites y enums compatibles con el proveedor.
- Configurar salida estructurada. usa la capacidad documentada.
- Parsear en la frontera. valida con Pydantic, Zod o JSON Schema.
- Paso 5. Validar semántica y autoridad fuera del modelo.
- Paso 6. Decidir el fallo con límites de reintento y revisión.
- Paso 7. Medir y evolucionar con evals.
- <script type="application/ld+json">{"@context". "https://schema.org","@type":"HowTo","name":"Cómo implantar un contrato de salida para un workflow LLM","step":[{"@type":"HowToStep","name":"Definir y validar","text":"Define schema, parsea, valida semántica y decide aceptar o reintentar."}]}</script>
Conclusión
JSON Schema, Pydantic y Zod reducen ambigüedad y hacen visibles fallos; la aplicación sigue siendo responsable de autoridad, negocio y seguridad.
El patrón sostenible es schema versionado, parseo local, validación semántica, política de rechazo/reintento y evals.
Fuentes y referencias
También te puede interesar
MCP outputSchema y structuredContentEvals de agentes de IAPrompt injection en agentesEvaluación RAG en producciónPydantic AI: agentes Python tipadosRecibe una lectura semanal de herramientas IA para devs
Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratis
