Construcción de un arnés de evaluación para tareas de agentes

Objetivo

Decidir si un cambio en un prompt, un conjunto de herramientas o un modelo mejora o empeora a un agente en las tareas para las que realmente se usa, con una cifra que pueda compararse entre ejecuciones en lugar de una impresión basada en unas pocas transcripciones.

Requisitos previos

Una lista de tareas con un estado final verificable por tarea (una fila de base de datos, un archivo, un valor devuelto); un entorno que pueda reiniciarse entre ejecuciones (contenedor, base de datos de prueba, respuestas HTTP grabadas); un presupuesto para ejecuciones repetidas. τ-bench es un ejemplo documentado de esta forma: el agente trabaja con herramientas de dominio y reglas de política frente a un usuario simulado, y el artículo evalúa comparando el estado de la base de datos al final de la conversación con un estado objetivo anotado. Marcos como Inspect (UK AI Security Institute) describen una evaluación como bloques de construcción componibles (conjuntos de datos, agentes, herramientas y calificadores) y ofrecen aislamiento (sandboxing) para código de modelo no confiable y aprobación de herramientas.

Pasos

1. Recopilar tareas a partir del uso real: sesiones fallidas, tickets de soporte, casos límite, no solo éxitos fáciles. Escribir cada una como una entrada más un oráculo (estado final esperado o una comprobación determinista), nunca como una transcripción esperada.
2. Congelar el entorno: fijar versiones de herramientas, datos semilla y respuestas externas grabadas, de modo que una ejecución fallida pueda repetirse con entradas idénticas.
3. Calificar el estado final mediante código. Usar una rúbrica calificada por modelo solo donde no exista una comprobación determinista, y calibrarla frente a una muestra de etiquetas humanas.
4. Ejecutar cada tarea k veces. El artículo de τ-bench propone pass^k, la probabilidad de que las k pruebas tengan éxito, junto con el habitual pass@k; informar ambos, ya que la diferencia entre ellos es la inconsistencia del agente.
5. Registrar el costo, los pasos y los tokens por ejecución junto con la calificación, de modo que una mejora que duplica el costo quede visible.
6. Mantener un conjunto reservado que nunca se use mientras se ajustan los prompts; informar por separado los resultados de ajuste y los del conjunto reservado.
7. Guardar la configuración (modelo, versión del prompt, conjunto de herramientas, semilla) con cada resultado, y ejecutar el arnés en cada cambio de prompt o de modelo.

Resultado esperado

Una calificación por tarea y por ejecución con una banda de confianza, una lista de tareas que alternan entre éxito y fallo entre pruebas, y un costo por tarea completada, todo reproducible a partir de la configuración guardada.

Límites y base de verificación

El artículo citado informa que los agentes de llamada a funciones más avanzados de la época tuvieron éxito en menos del 50 % de sus tareas y fueron inconsistentes (pass^8 por debajo del 25 % en su dominio minorista); aquí no se afirma ninguna cifra para otros agentes o tareas. La calificación por modelo hereda los sesgos del calificador, los conjuntos de tareas pequeños dan bandas de confianza amplias, y el arnés mide solo lo que cubren sus tareas.