Resumen Técnico: ¿Cuándo termina la evaluación de un agente?

Planteamiento del problema

Los marcos actuales de evaluación de agentes suelen calificar a los modelos basándose en el estado visible en el momento en que se detiene una ejecución (el "punto final" o endpoint). Este enfoque asume que el punto final establece simultáneamente dos condiciones críticas: la finalidad del resultado (el resultado está asentado y no puede cambiar) y la separación entre unidades (la ejecución actual es independiente de ejecuciones anteriores o futuras).

El artículo sostiene que estas dos condiciones son independientes y, a menudo, no se cumplen en el punto final.

1. Finalidad del resultado: Una ejecución puede detenerse mientras aún hay operaciones asíncronas pendientes (por ejemplo, escrituras retrasadas, procesos en segundo plano). Calificar el estado antes de que estas operaciones se completen puede conducir a etiquetas incorrectas (por ejemplo, marcar una tarea como fallida cuando una escritura retrasada habría tenido éxito, o viceversa).
2. Separación entre unidades: Si el entorno retiene estado entre ejecuciones (por ejemplo, bases de datos compartidas, cuentas persistentes o artefactos no limpiados), una ejecución previa puede alterar las condiciones iniciales o el resultado de una ejecución posterior. Esto viola la suposición de que los ensayos son independientes e idénticamente distribuidos (i.i.d.), invalidando las métricas agregadas (como $pass@k$).

Las auditorías existentes suelen buscar fallos en los benchmarks o mecanismos de reinicio, pero no logran distinguir entre un resultado calificado que está simplemente "incompleto" frente a uno donde la conexión entre ejecuciones no ha sido contabilizada.

Metodología

El autor emplea un enfoque de tres vertientes para investigar estos problemas:

1. Marco Teórico (El argumento de la completitud):
   El artículo desarrolla un marco lógico que distingue entre el punto final (cuando cesa la interacción) y la completitud (cuando el resultado está asentado y los límites son seguros). Define la evidencia requerida para justificar una etiqueta final frente al tratamiento de las ejecuciones como ensayos separados.

2. Experimento de Replay Controlado:
   Utilizando AgentDojo 0.1.35, el autor construyó un sistema para aislar las elecciones de frontera.

   • Configuración: Un ejecutor independiente (standalone runner) replicó llamadas a herramientas y cronogramas de operación fijos. Un servicio HTTP local simuló retrasos asíncronos (0, 25, 100, 250 ms) y persistencia de estado.
   • Variables: El estudio varió el tiempo de calificación (instantánea en el punto final frente a la espera del estado terminal) y la gestión del estado (estado compartido frente a estado con namespace o reinicio verificado).
   • Métricas: El experimento midió el desacuerdo entre las etiquetas del punto final y las etiquetas terminales (finalidad) y la frecuencia de exposición entre ejecuciones (separación).

3. Revisión de Documentación:
   El autor revisó la documentación pública y los artículos de diez benchmarks prominentes de agentes: WebArena, WorkArena, OSWorld, SWE-bench, tau-bench, ToolSandbox, TheAgentCompany, RE-Bench, Cybench y AgentCanary.

   • Criterios: Codificó declaraciones explícitas sobre definiciones de ejecución, reglas de parada, persistencia de estado, mecanismos de reinicio y evidencia para tratar las ejecuciones como ensayos separados.
   • Limitaciones: La revisión se centró en lo que se reportó explícitamente, no en inferir propiedades no declaradas.

Contribuciones Clave

1. Distinción Conceptual: Finalidad del Resultado vs. Separación entre Unidades

El artículo establece que estos son requisitos distintos que requieren evidencias diferentes:

• Finalidad del Resultado: Requiere que toda operación o evento relevante que pueda cambiar el resultado esté resuelto, acotado o confirmado como cancelado.
• Separación entre Unidades: Requiere que ninguna ruta relevante (estado compartido, credenciales, artefactos) permita que una ejecución influya en las condiciones o el resultado de otra.
• Implicación: Se puede lograr la finalidad sin separación (por ejemplo, esperar a que termine una escritura, pero dejar el archivo accesible para la siguiente ejecución) y la separación sin finalidad (por ejemplo, aislar las ejecuciones, pero calificar antes de que se complete una operación retrasada).

2. El Argumento de la Completitud

El autor propone un marco de decisión para los evaluadores:

• Para Etiquetas Finales: Una etiqueta de éxito/fallo solo se justifica si todas las rutas que podrían cambiar el resultado están bloqueadas, seguidas hasta su completitud o estrictamente acotadas. De lo contrario, el resultado debe reportarse como no resuelto.
• Para Ensayos Separados: Las ejecuciones solo pueden contarse como unidades de análisis separadas si todas las rutas entre ellas están bloqueadas o se demuestra que no pueden afectar el resultado. Si existe una conexión, las ejecuciones deben modelarse como una unidad conectada o agruparse.

3. El Registro de Efectos Abiertos

El artículo propone un nuevo estándar de reporte: un registro de efectos abiertos (open-effects record). Este registro debe listar las operaciones o recursos que siguen siendo relevantes después del punto final, su estado actual y si podrían cambiar el resultado calificado o afectar a otra ejecución.

Resultados Experimentales

Hallazgos del Replay Controlado

• Finalidad: En retrasos distintos de cero, las etiquetas del punto final discreparon con las etiquetas terminales en el 100% de los casos (150/150 ensayos). La calificación por instantánea registró 50 éxitos, mientras que la reconciliación (esperar a la completitud) registró 200 éxitos. La cancelación verificada identificó correctamente las escritas pendientes como fallos.
• Separación: Bajo estado compartido, el 75% de los pares (150/200) mostró exposición donde la Ejecución A cambió el resultado de la Ejecución B. Esta exposición se eliminó (0/200) bajo estado con namespace, reinicio verificado o cuando la Ejecución B se ejecutó antes que la A.
• Conclusión: El punto final por sí solo no puede justificar la etiqueta final ni la unidad de análisis. El tiempo de calificación y la política de gestión de estado determinan directamente la validez del resultado.

Hallazgos de la Revisión de Documentación

• Reinicio/Retención: Documentado explícitamente en 8/10 protocolos; parcialmente en 2/10.
• Operaciones Incompletas: Reportado de forma mucho menos consistente. 6/10 protocolos expusieron terminales (shells), navegadores o servicios sin declarar si los procesos descendientes o los efectos retrasados han finalizado, se han cancelado o se han comprobado antes de la calificación.
• Evidencia de Separación: Solo 3/10 protocolos proporcionaron evidencia explícita para tratar las ejecuciones como observaciones separadas. Siete describieron procedimientos de reinicio pero no detallaron completamente el alcance de los recursos cubiertos o cómo se verificó el éxito de la restauración.
• Brecha: Ningún protocolo documentó consistentemente los periodos de tiempo durante los cuales los efectos relevantes podrían cambiar el resultado.

Significado y Reivindicaciones

El artículo afirma que las prácticas de evaluación actuales suelen confundir el fin de la interacción con el fin de la cadena causal de la tarea. Su importancia radica en:

1. Corrección de la Validez de las Métricas: Demuestra que, sin verificar la finalidad y la separación, las métricas agregadas (como las tasas de éxito) pueden medir una mezcla de rendimiento de la tarea y artefactos del entorno.
2. Refinamiento de los Límites de Evaluación: Argumenta que el "límite de evaluación" no es un momento único, sino un conjunto de decisiones sobre cuándo detenerse, cuándo calificar y cómo separar las ejecuciones.
3. Propuesta de un Estándar de Reporte: Al introducir el "registro de efectos abiertos", el artículo proporciona un mecanismo concreto para que los evaluadores reporten de forma transparente los estados no resueltos y los recursos persistentes, permitiendo a los lectores evaluar la validez de los resultados declarados.

El autor mantiene una postura modesta, señalando que su revisión de documentación se limita a diez protocolos y que sus recuentos experimentales reflejan condiciones construidas más que la frecuencia de estos problemas en el panorama general de los benchmarks publicados. El argumento central es que una etiqueta final se justifica solo cuando todo aquello que aún podría cambiar el resultado reclamado ha sido resuelto, acotado o se mantiene como una incertidumbre.