Evaluación de trayectorias de agentes IA: comprobar el camino y el resultado

La evaluación de trayectoria comprueba la secuencia de observaciones, decisiones, tool calls, respuestas del entorno, approvals y state transitions entre la solicitud y el resultado final. Un outcome grader responde si la tarea se completó; un trajectory grader comprueba si el agente utilizó fuentes y herramientas permitidas, respetó la policy, evitó side effects duplicados y reaccionó correctamente a los fallos. En una consulta read-only a veces basta con el outcome. En un pago, un mensaje a un cliente, un cambio en un repositorio o un flujo con PII, la seguridad del camino es una condición separada de release.

No exijas una única cadena canónica de pasos: un agente fuerte puede completar legítimamente la misma tarea por rutas distintas. Define invariantes, clases de acciones permitidas, eventos prohibidos y el terminal state autoritativo. Un buen grader admite varias trayectorias seguras, pero falla ante una fuga de secretos, un write no autorizado, un error oculto, una acción duplicada o una respuesta final sin evidencia, por convincente que parezca el output.

Un trace mínimo registra task ID, contexto de tenant o usuario, revisión de modelo y agente, versión de policy, fingerprint del estado inicial, observation, decision event, nombre y versión de la herramienta, argumentos o su hash seguro, authorization verdict, estado del resultado de la herramienta, clave de retry o idempotency, approval event, recibo del side effect, respuesta final y terminal state. Los timestamps y los IDs parent-child permiten reconstruir el orden causal de pasos paralelos. No copies payloads sensibles sin control: conserva evidencia redactada y un raw artifact protegido por separado solo cuando esté justificado.

El trace debe proceder de la orquestación y de los límites de herramienta, no del self-report del modelo. La frase “he comprobado el CRM” no demuestra una llamada al CRM; un chain-of-thought bien redactado no es un audit log ni es necesario para verificar acciones externas. Registra eventos observables, versiones y postconditions. Si falta telemetría en un run con consecuencias, el veredicto es INCONCLUSIVE, no PASS.

Divide el veredicto en relevancia de planificación, corrección de herramientas, autoridad, integridad de estado y recuperación. La relevancia de planificación detecta loops sin propósito y comprobaciones necesarias omitidas. Tool correctness verifica la elección de herramienta, argumentos válidos según schema y manejo de respuestas. Authority relaciona cada acción con identity, scope, approval y estado actual. State integrity contrasta el resultado declarado con el system of record. Recovery cubre timeout, partial commit, rate limit, approval obsoleto y fallo de dependencias.

Evalúa la eficiencia solo después de correctness y safety. Menos pasos no son mejores si el agente omitió una comprobación de identidad; más pasos no son peores si aportan una confirmación necesaria. Medidas útiles: éxito de tarea, fallos de invariantes críticos, tasa de llamadas inválidas o no autorizadas, side effects duplicados, llamadas innecesarias, éxito de recuperación, cobertura de evidencia, latencia y coste por tarea completada de forma segura. No combines un fallo crítico y un ahorro de tokens en un único score medio.

• Outcome → el terminal state autoritativo cumple el task contract.
• Trajectory → cada paso está permitido, es relevante y tiene evidencia.
• Policy → no se viola ningún hard invariant.
• Recovery → el estado incierto se reconcilia antes del retry.
• Efficiency → se evalúa solo entre runs seguros y exitosos.

Los graders deterministas deben comprobar primero schema, allowlists, identidad y scope, vigencia del approval, idempotency, eventos prohibidos y postconditions autoritativas. Un model grader es útil para la relevancia semántica del plan, suficiencia de evidencia o calidad de una escalación, pero debe recibir un trace estructurado y una rubric, no un transcript sin control. Reserva la revisión humana para casos ambiguos de alto riesgo y para calibrar el grader.

Valida el grader sobre un conjunto etiquetado con casos positivos, negativos y de frontera. Mide el disagreement por risk slice, no solo con una tasa global de acuerdo. Versiona prompt, rubric, modelo del grader y threshold junto con el bundle del agente. Un model grader no debe anular un fallo de seguridad determinista; una explicación segura de sí misma no convierte un write no autorizado en una acción aceptable.

El eval set debe incluir timeout de herramienta antes de un write y después de un partial commit, resultado malformed, 429, datos obsoletos, schema drift, permiso revocado, approval expirado, objeto cross-tenant, prompt injection en la salida de una herramienta, evento duplicado, fuentes en conflicto, oracle no disponible y una tarea en la que abstenerse sea lo correcto. Para cada fixture define estado inicial, fallo inyectado, transiciones permitidas, eventos prohibidos y terminal oracle.

“Reconcile before retry” es especialmente importante: tras un write incierto, el agente consulta el system of record por operation key y solo entonces decide si repetir la acción o terminar. Prueba también la compensación. Si el workflow creó un draft pero no pudo asociarlo al case, ¿queda un orphan o se abre una tarea para un owner? Precisamente el partial success separa una evaluación de trayectoria de producción de una demo de tool calling.

Ejecuta un frozen regression set, casos held-out y un fault-injection slice con modelo, prompt, herramientas, policy y entorno fijados. La promoción exige resultados aceptables en cada slice crítico, cero hard-invariant failures definidos, un grader compatible y rollback probado. Empieza el canary con autoridad read-only o draft-only; ampliar el write scope es una decisión separada, no un premio por mejorar el score medio.

Después de cambiar el modelo, tool schema, permission policy, lógica de retry o grader, el veredicto anterior pasa a ser evidencia histórica. El rollback restaura el bundle compatible completo, detiene nuevos runs y reconcilia side effects pendientes. Reduce cada incidente de producción a un regression case seguro para la privacidad. Así la evaluación se convierte en un control vivo de release y no en una tabla única que se olvida ceremoniosamente tras el piloto.