Cómo definir la salida válida de un agente antes de elegir un modelo
Define una salida válida describiendo qué podrá hacer quien la reciba, qué evidencia necesita y qué condiciones impedirán usarla.
Define una salida válida describiendo qué podrá hacer quien la reciba, qué evidencia necesita y qué condiciones impedirán usarla. Así podrás comparar modelos con un contrato de trabajo concreto, en lugar de elegir por una demostración convincente.
Empieza por el destinatario
Pregunta al equipo que consumirá la salida qué decisión toma después. Un resumen para leer y un registro para importar necesitan criterios distintos. En un ejemplo hipotético de incidencias, el resultado podría ser una propuesta de clasificación con identificador del caso, motivo y datos que faltan. La aplicación puede mostrarla sin conceder al agente permiso para cerrar la incidencia. Escribe también qué tarea queda expresamente fuera del resultado.
Un contrato con tres capas
Separa forma, contenido y uso permitido. La forma describe campos, tipos y estados. El contenido exige que cada afirmación crítica corresponda a una fuente disponible. El uso establece si se trata de un borrador, una recomendación o una orden pendiente de autorización. Un objeto bien formado puede contener un importe falso; una explicación correcta puede carecer del identificador necesario para tramitarla. Ninguna capa sustituye a las otras.
Incluye salidas sin solución
Acuerda cómo expresar falta de evidencia, petición ambigua, tarea fuera de alcance y fallo técnico. No fuerces un resultado resuelto cuando faltan datos. Para cada estado, determina qué verá la persona y qué operaciones bloqueará el consumidor. Diferencia no encontrar una respuesta de no haber podido consultar la fuente: requieren actuaciones distintas y deben poder contarse por separado.
Prueba el contrato antes del modelo
Redacta manualmente una salida aceptable y otra rechazable para varios casos. Pide al destinatario que intente utilizarlas y al responsable del proceso que valide los bloqueos. Después prueba los modelos contra esas mismas condiciones, conservando ejemplos y motivos de rechazo. Si nadie puede decidir si la salida manual es válida, afina el contrato antes de comparar capacidades. Revisa el contrato cuando cambie el uso previsto, no para acomodar cada error del candidato.
Comprobaciones para cerrar la tarea
- ✓ Identifica quién consume cada campo y para qué.
- ✓ Distingue estructura, evidencia y autorización.
- ✓ Comprueba que una salida sin solución llega al circuito previsto.
- ✓ Aprueba el contrato antes de comparar modelos.
Fuentes y documentación
- JSON Schema · Objetos — Presencia, tipos y propiedades adicionales; no valida la verdad de un dato.
- OpenAI · Structured Outputs — El formato estructurado no evita errores de contenido; comprueba las condiciones del proveedor.
Aplicarlo en tu empresa
Podemos revisar el entorno y acordar qué actuaciones, validaciones y mantenimiento necesitas.
Conocer el servicio relacionado →