¿Qué demuestra realmente la puntuación de un agente de IA en un benchmark?

Redacte la afirmación prevista antes de elegir un benchmark¶

Agent Evaluation Reliability: More Tasks Won’t (Always) Fix An Agent Leaderboard, un preprint enviado el 30 de septiembre de 2026 por Michael Hardy, Ruhana Azam, Anka Reuel, Mykel Kochenderfer y Sanmi Koyejo, separa dos preguntas que puede responder una tabla de clasificación (leaderboard). Una pregunta qué sistema completo ocupa un puesto más alto. La otra, qué modelo subyacente ocupa un puesto más alto. Los autores aplican una descomposición bayesiana de la varianza a 22 benchmarks: nueve del Holistic Agent Leaderboard (HAL) y trece del Harbor Index.

Los autores indican que las clasificaciones de sistemas fijos de modelo y scaffold eran más fiables que las clasificaciones de los modelos subyacentes. Sus medidas de fiabilidad describen con qué consistencia se mantiene una clasificación para los modelos, scaffolds y tareas muestreados. No indican con qué frecuencia un agente completa una tarea ni establecen si una clasificación mide la capacidad adecuada. No se ha verificado la aceptación del artículo. Leer el artículo.

Un scaffold es el software que rodea al modelo: gestiona el estado, expone las herramientas y convierte las salidas del modelo en acciones. Un comprador que selecciona una aplicación de agente completa debe incluir ese software en el sistema evaluado. Un equipo que elige un modelo de sustitución debe tratar ese mismo software como una condición que se mantiene fija o se hace variar de forma deliberada.

Redacte la conclusión prevista en una frase antes de construir o leer una evaluación. Por ejemplo: «Esta configuración puede preparar una instrucción de pago autorizada a partir de estos tipos de documento con esta política de aprobación». La frase fija el flujo de trabajo, la acción y las condiciones que debe cubrir la evidencia. Una afirmación general sobre la capacidad del agente necesitaría un diseño mucho más amplio.

Declare los límites de lo evaluado¶

Evaluation Profiles for AI Agent Security Assessment, de Han, Chen, Fan y Wu, se publicó el 23 de octubre de 2026. Organiza la evaluación en torno a perfiles de infraestructura y de escenario, pide que los informes declaren los perfiles elegidos y su configuración, y pide que las métricas no aplicables se marquen de forma explícita. El documento es la revisión 00 de un Internet-Draft individual. No cuenta con el respaldo del IETF ni tiene rango de estándar; aquí se usa como una propuesta concreta de informe todavía en desarrollo. Leer la propuesta y su estado.

En un flujo de trabajo empresarial, una declaración de límites identifica las partes del sistema que produjeron el resultado y a quien lo evaluó:

La persistencia necesita su propia línea. Una sesión limpia no puede mostrar cómo trata un agente la información que pasa de una sesión a otra, una cuestión que aborda la nota sobre políticas en la memoria del agente. Una herramienta simulada respalda afirmaciones sobre la simulación. Una afirmación sobre un servicio real necesita evidencia que cubra la interacción con el servicio y el estado en que lo dejó.

• Modelo: identificador de la instantánea (snapshot) y parámetros de inferencia.
• Scaffold: el software operativo y su versión.
• Herramientas y permisos: a qué herramientas podía llamar el agente y qué podía modificar cada una.
• Estado inicial: el caso de prueba de partida y cómo se restableció entre un caso y otro.
• Destinos de los efectos: los sistemas que reciben efectos y si cada uno es simulado o real.
• Observador: lo que podía leer el calificador. Un calificador que lee la conversación del agente dispone de una evidencia distinta de la de un observador que lee una base de datos oficial después de la ejecución.

Compruebe qué establecen las herramientas y el calificador¶

Do Agent Benchmarks Do What They Say?, un preprint enviado el 29 de septiembre de 2026 por Rohith Reddy Bellibatlu, Zichong Wang y Wenbin Zhang, trata el comportamiento anunciado de cada herramienta como un contrato y contrasta la implementación con él. En cuatro benchmarks, los autores identifican siete defectos de herramientas y una propiedad del evaluador en commits fijados. Los defectos ya conocidos influyeron en parte en su elección de benchmarks, de modo que los hallazgos son ejemplos y no ofrecen ninguna tasa general de defectos. La instantánea de código anterior de los autores usa otros términos; seguimos la clasificación del artículo. Leer la auditoría.

El artículo anterior sobre MedAgentBench (versión 2, 12 de febrero de 2025) muestra un límite declarado en sus propios métodos. Su configuración de evaluación envía solicitudes GET al entorno, comprueba las cargas útiles POST y comunica al agente que la ejecución se ha realizado correctamente; la calificación de las acciones comprueba la carga útil solicitada. Los autores documentan este diseño, de modo que los lectores pueden interpretar los resultados de las acciones dentro de él. Leer los métodos originales, secciones 2.4–2.4.3.

En un flujo de trabajo de facturas, mantenga separadas cuatro etapas y conserve cada una de las que existan. Si la evaluación se detiene en una de ellas, haga visible ese punto de detención en el resultado.

• Instrucción propuesta: lo que el agente pretendía hacer.
• Solicitud a la herramienta: lo que el agente envió realmente.
• Respuesta de la herramienta: lo que la herramienta comunicó. Un mensaje de éxito es una afirmación de la propia herramienta.
• Efecto registrado: lo que un observador independiente encontró después en el sistema de registro.

Un registro de límites práctico para el pago a un proveedor¶

Consideremos un flujo de trabajo ficticio de pago a proveedores con tres diseños de evaluación. La entrada es fija: el proveedor SUP-042, la factura INV-042 por 1200 EUR y la instrucción de preparar un pago que un operador financiero debe aprobar antes de que se registre ningún pago. La ejecución del pago solo existe dentro de una simulación local. No se ejecutó ningún modelo, simulador ni flujo de pago, y aún no se han seleccionado la instantánea del modelo ni las versiones del harness y del evaluador. La tabla es un extracto del registro de límites de la evaluación (en inglés) completo.

El proveedor, el importe y la aprobación requerida son idénticos en los tres diseños, y aun así las columnas de resultados se mantienen separadas. Añadir memoria persistente introduce un comportamiento nuevo que observar. Trasladar el host de las herramientas traslada el punto donde se comprueban los permisos y los efectos. El diseño C también ejecuta dos sesiones, por lo que su presupuesto de recursos es distinto y el registro indica esa diferencia. Unas instantáneas de modelo idénticas no bastarían por sí solas para que las tres puntuaciones fueran intercambiables.

Asigne un estado a cada caso, también a los que no se ejecutaron¶

El registro define tres casos: un pago autorizado ordinario, una instrucción sin aprobación y una segunda sesión que reutiliza un registro de proveedor almacenado en la primera. Muestran la cobertura prevista. No estiman con qué frecuencia falla algo en la práctica, y su selección no indica nada sobre si una implementación los supera. El caso de la segunda sesión no prueba la corrupción, la revocación ni la eliminación del registro almacenado, y el caso de la aprobación ausente no ofrece ninguna estimación de la robustez frente a ataques.

Cada resultado lleva una de cinco etiquetas. El borrador de perfiles de evaluación pide que se marquen las métricas no aplicables; el resto de este vocabulario es una propuesta nuestra que ningún grupo ha adoptado. En este ejemplo, todos los resultados que dependen de la ejecución tienen la etiqueta No ejecutado, y el registro no define ninguna puntuación agregada.

• Publique la disponibilidad de evidencia de cada caso y el denominador de cualquier tasa.
• Excluya del recuento de éxitos las observaciones ausentes y los controles no aplicables.

Lo que comprobamos en los datos publicados¶

Los autores del artículo sobre fiabilidad publican sus datos de resultados. Descargamos el archivo de resultados de HAL de su repositorio en el commit e7ec464 (29 de septiembre de 2026) y lo contamos con la biblioteca estándar de Python: 29.923 filas, 9 benchmarks, 54 valores de nombre de modelo, 13 nombres de scaffold y 1117 pares distintos de benchmark y tarea, con todas las puntuaciones iguales a 0 o a 1. Estas dimensiones coinciden con la descripción de datos del propio repositorio. Los nombres de modelo incluyen variantes de esfuerzo de razonamiento, de modo que 54 es un recuento de identificadores y sobrestima el número de modelos base. Repositorio fijado, archivo fijado.

Fue un recuento de datos. No volvimos a ejecutar ningún agente, no inspeccionamos trayectorias ni reajustamos el modelo estadístico, y el recuento no puede demostrar que las etiquetas y calificaciones del archivo sean correctas. Confirma la forma y la identidad de los datos de entrada en los que se basan las cifras de fiabilidad publicadas. Esas cifras siguen siendo resultados de los autores.

Publique el registro de límites con el resultado¶

Adjunte el registro de límites a un resultado con el mismo identificador de versión y complete los campos de ejecución cuando se ejecute la evaluación:

Cuando cambie un componente, indique el cambio junto al nuevo resultado para que los lectores puedan valorar qué significa una comparación. Así, un lector puede remontar una conclusión hasta una configuración, una acción y una observación concretas, y un equipo de aseguramiento puede decidir qué evidencia adicional necesita su propio flujo de trabajo.

• ID de ejecución y versiones exactas: instantánea del modelo, harness, host de herramientas, evaluador y hash del conjunto de datos.
• Parámetros de muestreo o semilla, el presupuesto de recursos y lo que consumió realmente la ejecución.
• Evidencia del restablecimiento, permisos de los actores e identidad de cualquier persona que haya tomado una decisión.
• Acceso del observador, fallos de inicialización y exclusiones, con la forma en que cada uno entra en el denominador.
• Traza de acciones y diferencias de estado, con los mensajes de éxito de las herramientas separados de los efectos observados de forma independiente.
• La regla de veredicto aplicada a cada caso.