¿Cómo debería medirse la fiabilidad de un agente que actúa cuando una ejecución puede tener éxito en su tarea y aun así causar un efecto secundario no deseado?

Pregunta abierta

El artículo citado sobre τ-bench puntúa a un agente comparando el estado de la base de datos al final de una conversación con un estado objetivo anotado, y propone pass^k para la fiabilidad a lo largo de intentos repetidos. Ambas medidas evalúan si se alcanzó el objetivo. Un agente que actúa sobre sistemas reales puede alcanzar el objetivo y aun así hacer algo que no debía: tocar un archivo fuera de la tarea, ejecutar un comando con un efecto más amplio del necesario, enviar un mensaje que no se pidió, reintentar una llamada no idempotente o consumir un presupuesto de coste varias veces. Una métrica de éxito de la tarea cuenta esa ejecución como un acierto; un recuento de incidentes en producción solo cuenta los casos que alguien notó. Lo que falta es una práctica documentada para medir la segunda dimensión:

• ¿Qué se cuenta como efecto secundario no deseado, y quién lo decide: una lista fija de efectos prohibidos por tarea, una comparación del entorno frente a una comparación esperada, el registro de denegaciones de una puerta de aprobación, o una revisión humana del registro de acciones?
• ¿Cómo se informan juntas las dos dimensiones: como un par (éxito de la tarea, tasa de ejecuciones limpias), como una puntuación única con una penalización, o como pass^k sobre ejecuciones que son a la vez exitosas y limpias?
• ¿Qué tan estable es la tasa de efectos secundarios entre versiones de prompt, versiones de modelo y ejecuciones repetidas, y si se mueve en la misma dirección que el éxito de la tarea o de forma independiente?
• ¿Qué proporción de los efectos secundarios se detecta mediante mecanismos de ejecución en seco y de aprobación antes de que ocurran, y qué proporción solo mediante inspección posterior?
• ¿Los entornos con una comparación completa del estado antes y después (contenedores, instantáneas) han producido recuentos que difieren de los registros de acciones autoinformados?

Qué contiene una respuesta útil

El tipo de tarea y el conjunto de herramientas del agente; la definición de efecto secundario no deseado utilizada, con ejemplos de lo que se contó y lo que no; el método de observación (comparación del entorno, revisión de registros, denegaciones de la puerta de aprobación); el número de ejecuciones; el éxito de la tarea y el recuento de efectos secundarios uno al lado del otro, por versión si se compararon varias; y qué cambió el equipo como resultado. Las propuestas sin datos deben etiquetarse como propuestas, y los informes de un solo equipo deben indicarlo.