Controlar salidas probabilísticas y estructuradas

Los modelos de lenguaje generan salidas flexibles. Esa capacidad es útil para redactar, resumir, clasificar o interpretar texto, pero una aplicación empresarial necesita distinguir entre una respuesta plausible y un dato válido para continuar un proceso.

El objetivo no es «hacer determinista al LLM». Es rodear una salida probabilística de contratos, validaciones y rutas de error que impidan convertir una generación incorrecta en un efecto empresarial.

Empieza por el contrato de salida

Antes de escribir el prompt, define qué necesita consumir la siguiente etapa.

Para una clasificación de solicitudes podrías necesitar:

• categoría;
• subcategoría;
• campos extraídos;
• evidencia textual;
• información ausente;
• señal de revisión;
• explicación breve.

El contrato debe expresar tipos, campos obligatorios, catálogos y relaciones. Si la salida va a software, evita pedir «devuelve algo parecido a JSON». Define un esquema real.

Estructura válida no significa verdad

Las salidas estructuradas pueden restringir la forma. OpenAI documenta Structured Outputs como un mecanismo para hacer que la salida se ajuste a un esquema compatible. JSON Schema 2020-12, por su parte, define mecanismos generales para describir y validar estructura de datos JSON.

Pero una salida que cumple esquema puede contener un importe inventado, una fecha equivocada o una categoría semánticamente incoherente.

Por eso necesitas varias capas.

Valida por capas

1. Validación estructural

Comprueba que existen los campos, tipos y formatos esperados.

2. Validación semántica

Comprueba relaciones que el esquema no garantiza por sí solo. Una fecha de fin puede ser anterior a la de inicio. Una categoría puede ser incompatible con el tipo de solicitud.

3. Validación de negocio

Aplica reglas externas al modelo: límites, permisos, catálogos, estados y umbrales.

4. Validación de evidencia

Si una afirmación depende de un documento o entrada, conserva el fragmento que la sostiene y verifica la relación.

5. Validación de riesgo

Decide si el resultado puede ejecutarse automáticamente o requiere revisión.

Estas capas tienen responsabilidades distintas. No intentes resolverlas todas con «un prompt mejor».

Diseña salidas para poder rechazar

Un buen contrato no solo describe el caso feliz. Define:

• campo desconocido;
• dato ausente;
• conflicto;
• evidencia insuficiente;
• categoría no aplicable;
• necesidad de revisión.

Si el modelo se ve obligado a elegir siempre una opción de un catálogo aunque ninguna encaje, la estructura puede empeorar la calidad al ocultar incertidumbre.

Incluye estados explícitos como unknown, needs_review o un mecanismo equivalente cuando el negocio lo permita.

Reintentos: corrige el fallo correcto

Si la salida incumple el esquema, un reintento limitado puede tener sentido. Si la salida cumple forma pero inventa un dato porque falta evidencia, repetir la misma solicitud esperando «que ahora acierte» no resuelve la causa.

Distingue:

• fallo de formato;
• fallo de contenido;
• contexto insuficiente;
• política ambigua;
• error de herramienta;
• falta de permiso.

Cada uno necesita una ruta distinta.

No confundas configuración con determinismo

Una temperatura baja, un seed cuando exista, un formato rígido o un prompt estable pueden reducir variación en determinados sistemas. No convierten el LLM en una función matemática determinista ni sustituyen validación.

Para cálculos exactos, normalización o reglas binarias, extrae los datos y utiliza código. Por ejemplo, si debes calcular IVA, vencimientos o límites de crédito, el modelo puede localizar campos, pero el cálculo debe quedar en una función comprobable.

Diseña evidencia junto con el resultado

Cuando el sistema extrae o clasifica, conserva la base de la decisión.

Un contrato útil puede incluir:

category
confidence_signal
supporting_text
missing_fields
review_required

No conviertas confidence_signal en una probabilidad universal de corrección salvo que el proveedor y tu evaluación hayan demostrado una interpretación concreta. Muchas puntuaciones son internas o específicas del sistema.

Versiona contratos y evaluaciones

Registra:

• versión de esquema;
• versión de prompt o instrucciones;
• versión de modelo;
• configuración relevante;
• dataset de evaluación;
• fecha de prueba.

Si una nueva versión del modelo empieza a utilizar una categoría de forma diferente, necesitas saber qué cambió.

Ejemplo: extracción de requisitos de una solicitud

Entrada: un email de cliente.

Salida estructurada:

• customer_id si está presente;
• request_type;
• requested_date;
• constraints;
• evidence;
• missing_fields;
• review_required.

El modelo no consulta automáticamente el CRM. Si falta el customer_id, una herramienta o una regla posterior puede resolverlo. Si la fecha no cumple política, una validación de negocio lo detecta. Si la evidencia no contiene la restricción que el modelo afirmó, la salida se bloquea.

Refusals, bloqueos y estados de salida

Una aplicación también debe representar cuando el proveedor o el modelo no produce la salida de negocio esperada. Puede haber rechazo de seguridad, corte por límite, timeout, error de API o contenido imposible de clasificar.

No conviertas todos esos estados en null. Mantén códigos internos diferenciados para que la aplicación sepa si debe reintentar, pedir información, escalar o detenerse.

Un esquema de dominio podría separar:

• success;
• needs_input;
• needs_review;
• provider_refusal;
• technical_error.

Los nombres son un ejemplo, no un estándar. Lo importante es que una ausencia de resultado tenga semántica operativa.

Prueba consistencia entre campos

Los errores más peligrosos no siempre rompen JSON. Un modelo puede devolver requires_review: false y al mismo tiempo missing_fields: ["customer_id"].

Añade invariantes de dominio: si faltan campos obligatorios, revisión debe ser verdadera; si una categoría es unknown, no puede activar una herramienta destructiva; si la evidencia está vacía, no se acepta una afirmación de alta confianza.

Estas comprobaciones son código y pruebas, no prompting.

Ejercicio: contrato ejecutable

Diseña una salida para un caso real y entrega:

1. esquema;
2. ejemplo válido;
3. ejemplo estructuralmente inválido;
4. ejemplo válido pero semánticamente incorrecto;
5. reglas de negocio;
6. evidencia requerida;
7. ruta de reintento;
8. ruta de revisión;
9. métricas de calidad;
10. versión del contrato.

Después intenta construir un caso adversarial que pase el esquema pero deba ser rechazado por negocio o evidencia.

Resultado de la lección

Debes terminar con un contrato que permita a la aplicación consumir, rechazar o escalar una salida. El modelo sigue siendo flexible; el sistema ya no depende de que esa flexibilidad sea siempre correcta. En la siguiente lección decidirás cómo proporcionar conocimiento, datos vivos, capacidades y estado sin mezclar recuperación, herramientas y memoria.