Evaluar agentes de principio a fin: estado final, trayectoria y fiabilidad en varios intentos

Un agente que resuelve una tarea el 90% de las veces la resolverá cinco veces seguidas solo alrededor del 59% de las veces (0,9 elevado a 5). Para un usuario que repite la misma tarea cada día, eso es un fallo casi cada semana. La tasa de éxito media, la métrica que suele reportarse, no refleja esa falta de consistencia. Evaluar agentes exige ejecutar cada tarea varias veces, comprobar el resultado en el entorno y no solo en la respuesta, y revisar cómo llegó el agente hasta ahí.

Tareas con resultado verificable

La respuesta de texto del agente es la parte menos fiable de evaluar. Lo verificable es el estado del entorno al terminar: qué registros cambió en la base de datos, qué archivos creó, qué correo quedó en la bandeja de salida. Diseña las tareas para que su éxito se compruebe con código:

TAREA = {
    "id": "reembolso_parcial_01",
    "instruccion": "El cliente 4821 recibió 2 de las 3 unidades del pedido P-9930. "
             "Reembolsa la unidad que falta y avisa al cliente.",
    "estado_inicial": "fixtures/pedido_9930.sql",
    "comprobar": [
  "SELECT importe FROM reembolsos WHERE pedido = 'P-9930'",  # debe ser 1/3 del total
  "SELECT count(*) FROM correos_enviados WHERE cliente = 4821",  # debe ser 1
    ],
    "prohibido": [
  "SELECT count(*) FROM reembolsos WHERE pedido <> 'P-9930'",  # ningún otro reembolso
    ],
}

Cada tarea parte de un estado inicial conocido y se ejecuta en un entorno aislado que se reinicia entre ejecuciones: una base de datos de pruebas, servicios externos simulados, un sistema de archivos temporal. Sin reinicio, una ejecución contamina la siguiente y los resultados dejan de ser comparables.

Las comprobaciones de lo prohibido importan tanto como las de éxito. Un agente que reembolsa el pedido correcto y además otro pedido «por si acaso» ha completado la tarea y ha causado un incidente.

Fiabilidad: pass@k y pass^k

Dos métricas que suenan parecido y miden cosas opuestas. pass@k es la probabilidad de que al menos uno de k intentos tenga éxito: útil cuando puedes generar varias soluciones y elegir la buena (por ejemplo, código que se valida con tests). pass^k, popularizada por el benchmark τ-bench, es la probabilidad de que los k intentos tengan éxito: la que importa cuando el agente actúa directamente en nombre de un usuario.

from math import comb

def pass_hat_k(n, c, k):
    """n ejecuciones de una tarea, c exitosas: estimación de que k intentos
    elegidos al azar entre las n sean todos exitosos."""
    if c < k:
  return 0.0
    return comb(c, k) / comb(n, k)

# Tarea ejecutada 8 veces, 7 éxitos
print(pass_hat_k(8, 7, 1))  # 0,875
print(pass_hat_k(8, 7, 4))  # 0,5

Ejecuta cada tarea entre 4 y 8 veces y reporta la media de pass^k sobre todas las tareas para varios valores de k. Una caída fuerte de k=1 a k=4 indica un agente inconsistente: acierta por suerte en una parte de las ejecuciones.

Qué revisar en la trayectoria

Dos agentes con el mismo resultado final pueden ser muy distintos: uno lo resuelve en 4 pasos, otro en 25 con tres intentos fallidos de borrar algo. Registra la trayectoria completa y extrae métricas:

• Número de pasos y tokens consumidos por tarea, comparados con una solución de referencia.
• Llamadas a herramientas con error y llamadas repetidas con los mismos argumentos.
• Acciones que violan la política aunque no cambien el resultado final: consultar datos de otro cliente, intentar una acción sin confirmación.
• Si el agente pidió aclaración cuando la instrucción era ambigua, o adivinó.

Algunas de estas comprobaciones se hacen con código sobre el registro de llamadas; otras, como la calidad de las aclaraciones, necesitan un juez LLM o revisión humana de una muestra.

Usuarios simulados

Los agentes conversacionales no reciben una instrucción completa: el usuario da información poco a poco, se contradice o responde a preguntas. Para evaluarlos se usa un LLM que interpreta al usuario, con un perfil y un objetivo ocultos al agente («quieres cambiar la dirección de envío, pero solo das el código postal si te lo piden»).

Es útil y tiene límites: el usuario simulado es más cooperativo y coherente que uno real, y a veces revela información que no debería o se desvía del guion. Revisa una muestra de conversaciones simuladas para comprobar que el simulador sigue su perfil, y complementa con conversaciones reales anonimizadas.

Errores frecuentes y limitaciones

Evaluar contra servicios reales. Si el agente usa APIs externas en la evaluación, los resultados cambian con el estado de esas APIs y las pruebas pueden causar efectos reales. Simula los servicios externos con respuestas fijas y deja las pruebas contra servicios reales para un conjunto pequeño y controlado.

Una ejecución por tarea. Con temperatura mayor que cero y entornos con cierta variabilidad, una sola ejecución no distingue un agente fiable de uno afortunado. El costo de ejecutar varias veces es el precio de una métrica útil.

Tareas demasiado fáciles o solo del camino feliz. Incluye tareas con información insuficiente, con herramientas que devuelven errores, con instrucciones que el agente debe rechazar por política y con estados iniciales inesperados. Ahí es donde los agentes fallan en producción.

Banco de pruebas mínimo

Escribe 30 tareas con estado inicial reproducible, comprobaciones de éxito y de acciones prohibidas sobre el estado final, servicios externos simulados y ejecución aislada. Ejecuta cada tarea 5 veces y reporta pass^1, pass^3 y pass^5 junto con pasos y tokens medios, en cada cambio de modelo, prompt o herramientas.