La evaluación de agentes

La evaluación de agentes es la medición de sistemas que no producen un texto sino una secuencia de acciones: consultan una base de datos, leen ficheros, llaman a una interfaz de programación, escriben código, lo ejecutan y deciden por sí mismos cuándo han terminado. Cambia todo respecto a evaluar una respuesta. Un texto se juzga como objeto; un agente se juzga como proceso, y el resultado de ese proceso puede ser correcto por casualidad o incorrecto por un detalle irrelevante después de veinte pasos impecables.

La ventaja compensa la dificultad: en muchas tareas de agente el éxito es verificable por programa, y eso es lo mejor que le puede pasar a una evaluación. En vez de discutir si una respuesta es buena, se comprueba si el estado final del mundo es el pedido. Los dos bancos de pruebas que definieron el género lo hacen así. SWE-bench, publicado por Carlos Jimenez y sus coautores en 2024, toma incidencias reales de repositorios de código abierto, pone al agente a resolverlas sobre el repositorio tal como estaba antes del arreglo y decide con las pruebas unitarias que acompañaban al parche humano: pasan o no pasan, sin juicio. τ-bench, de Shunyu Yao y sus coautores el mismo año, sienta al agente a conversar con un usuario simulado mientras usa las interfaces de un dominio de atención al cliente y comprueba al final el estado de la base de datos contra un estado objetivo anotado. GAIA, con sus cuatrocientas sesenta y seis tareas de asistente general, va por el mismo camino con respuestas de formato cerrado. Cuando se puede construir un verificador así, se construye: es determinista, no cuesta dinero por ejecución y no tiene sesgos.

Lo que no es, es completo, y conviene saberlo antes de fiarlo todo a la cifra verde. El propio SWE-bench tuvo que ser depurado: al revisarlo caso por caso aparecieron enunciados que no contenían información suficiente para resolver la tarea y pruebas que fallaban por motivos ajenos al cambio, lo que dio lugar a un subconjunto de quinientas tareas validadas por personas que es el que hoy se usa como referencia. Y el trabajo de UTBoost, en 2025, mostró el defecto complementario y más incómodo: las pruebas que acompañan a un parche humano a menudo no cubren lo que el parche arregla, de modo que un agente puede pasarlas con una solución que no resuelve el problema. Al generar pruebas adicionales para esas tareas, sus autores encontraron trescientos cuarenta y cinco parches que constaban como correctos y no lo eran, y la corrección movió de sitio a casi una cuarta parte de las posiciones de la tabla. Un verificador es una medida de lo que verifica, nunca de lo que uno quería.

La segunda cosa que cambia con los agentes es que el resultado final es un resumen muy pobre de lo ocurrido. El marco que mejor organiza esto es el de las tres capas que describe el equipo de Airbnb: se puntúa la trayectoria, el uso de herramientas y la salida final, y se puntúan por separado. La razón es práctica antes que conceptual: un agente que llega al resultado correcto tras catorce llamadas, tres callejones sin salida y una lectura de todo el repositorio cuesta diez veces más que uno que llega en cuatro pasos, falla en cuanto la tarea crece un poco y no se puede poner delante de un usuario que espera. Con solo la puntuación final, esas dos ejecuciones son idénticas.

Puntuar la trayectoria no exige un juez sofisticado; casi todo se cuenta. Qué ficheros tocó frente a los que tocó la solución humana, en forma de precisión y cobertura combinadas —nunca solo cobertura, porque premiar la cobertura sola premia tocarlo todo—; cuántos pasos, cuántas llamadas repetidas idénticas, que son el síntoma de un bucle; si usó la herramienta adecuada con los parámetros adecuados; cuánto tiempo y cuánto dinero; y si en algún momento ejecutó una acción que la tarea no autorizaba. Esa última es la comprobación de seguridad que ninguna cifra de éxito contiene: un agente que resuelve la tarea borrando la tabla que estorbaba ha tenido éxito según el verificador y es un incidente. Las acciones prohibidas se puntúan como fallo de la ejecución completa, igual que una inyección en el corpus de un sistema de texto.

Cuando sí hace falta un juez en una tarea de agente, su pregunta correcta es la equivalencia y no la identidad. La solución humana es una solución válida, no la solución; comparar el parche del agente con el parche del repositorio letra a letra mide parecido estilístico. Hay además una señal de calidad que suele estar disponible y casi nadie usa: los comentarios de revisión que recibió el cambio humano. Son modos de fallo conocidos, anotados por alguien que conocía el código, y comprobar que el agente no repite exactamente aquello que un revisor ya objetó es un puntuador barato con una validez muy alta, porque no lo inventó nadie para la evaluación.

Queda la propiedad que más distingue a un agente de un generador de texto, que es la fiabilidad.

Las dos medidas de la figura responden a preguntas distintas y confundirlas es el error de lectura más común en los informes de agentes. La primera, pass@k, la introdujeron Mark Chen y sus coautores en 2021 para evaluar generación de código: se generan k candidatos y se cuenta un acierto si al menos uno pasa las pruebas. Es la medida adecuada cuando existe un verificador automático que puede elegir, porque entonces los k intentos son un recurso y no un riesgo. La segunda, pass^k, la propuso τ-bench para lo contrario: exige acertar en los k intentos, y mide consistencia. Los números de aquel artículo siguen siendo el mejor argumento a favor de mirarla: los agentes de llamada a funciones de la época resolvían menos de la mitad de las tareas y su pass^8 en el dominio de comercio caía por debajo del veinticinco por ciento. Un sistema que acierta una de cada dos veces no es medio sistema: para un usuario que necesita el mismo resultado dos veces seguidas, es uno que falla casi siempre.

La heterogeneidad que la figura permite mover explica por qué las dos curvas teóricas rara vez se cumplen tal cual. Los intentos no son independientes: hay tareas que el agente resuelve siempre y tareas que no resuelve nunca, y bajo esa mezcla pass^k no se desploma exponencialmente sino que se estabiliza alrededor de la proporción de tareas fáciles. La consecuencia práctica es que la media esconde la forma: dos sistemas con la misma tasa de éxito, uno mediocre en todo y otro excelente en la mitad e inútil en la otra, se comportan de forma completamente distinta en producción y solo se distinguen ejecutando varias veces cada tarea y mirando la distribución por tarea.

Montar el entorno es la mitad del trabajo y la parte que nadie cuenta en los artículos. Un agente necesita un mundo con el que interactuar, y ese mundo tiene que ser reproducible, aislado y honesto. Reproducible significa que la tarea se ejecuta sobre un estado congelado —una copia del repositorio en el commit anterior al arreglo, una base de datos restaurada desde un volcado— y que dos ejecuciones parten de lo mismo. Aislado significa que el agente no puede tocar nada real: ni publicar, ni escribir en producción, ni enviar correo. Y honesto significa que no hay fuga del futuro, que es el fallo específico de estas evaluaciones y el más fácil de cometer: si el repositorio clonado conserva la historia posterior, el agente puede leer el arreglo en el registro de cambios y «resolver» la tarea copiándolo. Hay que recortar las referencias y la historia posteriores al punto de partida, y comprobar además que el enunciado no contiene identificadores que solo aparecen en la solución, porque un enunciado reconstruido a partir del texto del cambio filtra por descuido.

El resto de los obstáculos son mundanos y dominan el calendario. Un estado antiguo a menudo ya no compila, porque las dependencias se movieron; la suite de pruebas del repositorio tiene fallos intermitentes que se confunden con fallos del agente; cada tarea tarda minutos y cuesta dinero de verdad. Las cifras de un caso medido dan la escala: media hora de reloj y medio dólar por tarea significan que una suite de cien tareas cuesta entre cincuenta y doscientos dólares y una noche entera. De ahí tres decisiones que se repiten en todos los montajes que funcionan: restringir el corpus a tareas suficientemente recientes para que el entorno se construya, muestrear diez o veinte tareas por tipo en lugar de todas, y separar dos caminos de ejecución —uno corto que se lanza a mano sobre un puñado de tareas mientras se itera, y otro completo que corre de noche y alimenta la serie histórica.

Esa clasificación por tipo de tarea, que empieza siendo una comodidad para muestrear, acaba siendo lo más valioso del montaje. Cuando las tareas están etiquetadas —migración de esquema, punto de entrada nuevo, corrección de error, arreglo de integración continua, componente de interfaz—, la evaluación deja de dar un número y empieza a dar un perfil, y el perfil es accionable: dice en qué tipo de trabajo conviene dejar al agente solo y en cuál no. Además abre la puerta a componer el prompt según el tipo de tarea, con la instrucción específica y unos cuantos ejemplos parecidos recuperados del historial, y entonces la suite de evaluación tiene una función nueva: es lo que gatea cada versión de esas instrucciones. El orden correcto es ese y no el inverso. Primero se mide si las instrucciones que ya hay ayudan —comparar el agente con y sin ellas es una de las mediciones más baratas y más incómodas que se pueden hacer, y a veces la respuesta es que no ayudan— y solo después se invierte en hacerlas dinámicas.

La medición final, la que cierra el círculo, no vive en la suite sino en el trabajo real. Un agente de programación produce cambios que alguien revisa: cuántos se integran sin tocar nada, cuántos comentarios de revisión reciben, cuánto texto modifica el humano antes de aprobarlos. Son tres señales gratuitas, disponibles desde el primer día y con una validez que ningún juez alcanza, porque las produce la persona que responde del código. La disciplina que las hace utilizables es llamarlas igual que a las dimensiones de la evaluación fuera de línea, para que la comparación entre lo que la suite predijo y lo que el equipo experimentó sea una resta y no una discusión.