Las pruebas de consistencia de agentes de IBM revelan por qué un solo éxito no es suficiente
Las pruebas de consistencia de agentes de IBM han expuesto un marcado conflicto entre el éxito en benchmarks y un comportamiento fiable. Un agente GPT-4.1 completó el 77,4 % de sus ejecuciones de AppWorld, pero solo superó los cinco intentos en el 53,0 % de las tareas.
Esa brecha de 24,4 puntos cambia el significado de una demostración exitosa de un agente. Una ejecución correcta puede demostrar que un agente posee la capacidad necesaria. No puede demostrar que los usuarios recibirán el mismo resultado mañana, ni siquiera cinco minutos después.
IBM Research aborda esta distinción con nuevas directrices de consistencia en ALTK-Evolve. El sistema detecta decisiones inestables en una trayectoria registrada del agente y convierte esas debilidades en instrucciones reutilizables. Sus primeros resultados sugieren que las mejoras de fiabilidad no siempre requieren un modelo más grande.
El trabajo también cuestiona la forma habitual en que los proveedores presentan el rendimiento de los agentes. Un promedio de clasificación puede premiar a un agente que funciona con frecuencia, al tiempo que oculta cuántas veces falla después de haber tenido éxito.
Los resultados de consistencia de agentes de IBM exponen la métrica ausente
La conclusión central de IBM es que la precisión media y el éxito repetible describen dos productos sustancialmente diferentes.
Los investigadores probaron un agente ReAct impulsado por GPT-4.1 en 168 tareas de la división test_normal de AppWorld. ReAct es un diseño de agente que alterna pasos de razonamiento con acciones, como llamar a una aplicación o buscar información almacenada.
Cada tarea recibió cinco ejecuciones nuevas. Según el estudio de consistencia de IBM, el agente base logró una puntuación Mean@5 del 77,4 %. Mean@5 promedia la tasa de éxito entre cinco intentos.
Esa cifra parece adecuada para una demostración sólida de producto. Sin embargo, el agente obtuvo una puntuación Pass^5 de solo el 53,0 %. Pass^5 considera una tarea exitosa únicamente cuando los cinco intentos tienen éxito.
La diferencia entre esos resultados es la brecha de consistencia. En este caso, alcanzó 24,4 puntos porcentuales. En el grupo de tareas más difícil, IBM afirma que la brecha llegó a 30 puntos.
Esta distinción importa porque Pass^5 no es la métrica habitual Pass@5 utilizada en algunas evaluaciones de programación. Pass@5 pregunta si al menos uno de cinco intentos tiene éxito. Pass^5 pregunta si todos los intentos tienen éxito.
Estas métricas respaldan productos diferentes. Pass@5 funciona cuando un sistema puede generar varios candidatos, probarlos y conservar el ganador. Pass^5 se ajusta a flujos de trabajo en los que cada ejecución debe ser fiable.
Un desarrollador que pide a un agente cinco posibles parches de código puede beneficiarse de una respuesta válida. Un equipo de contabilidad que pide a un agente conciliar una transacción no puede aceptar con seguridad cuatro ejecuciones correctas y un error perjudicial.
El mismo problema se aplica al análisis de contratos. Un agente que identifica una obligación durante una revisión pero la omite en otra no es simplemente variable. Genera decisiones empresariales inconsistentes a partir de pruebas idénticas.
Los resultados de IBM no muestran que GPT-4.1 carezca de la capacidad de realizar estas tareas. Un promedio del 77,4 % establece que con frecuencia puede hacerlo. Los resultados muestran que la capacidad no sobrevivió de forma fiable a la repetición dentro de esta configuración concreta del agente.
Esta es la inversión central del artículo. El primer éxito es evidencia de posibilidad, no evidencia de fiabilidad operativa.
La comunidad más amplia de evaluación ha llegado a una conclusión similar. La guía de evaluación de agentes de Anthropic distingue Pass@k de Pass^k y recomienda ajustar la métrica a los requisitos del producto.
Anthropic ofrece una ilustración sencilla. Una tarea con una tasa de éxito por prueba del 75 % tiene aproximadamente un 42 % de posibilidades de tener éxito en tres pruebas independientes. La calidad aparente disminuye porque el requisito pasa del éxito ocasional al éxito ininterrumpido.
Los promedios siguen teniendo valor. Ayudan a comparar la capacidad general y revelan si un cambio mejora los resultados en un conjunto de tareas. Se vuelven engañosos cuando los compradores los interpretan como una garantía de fiabilidad.
Para los despliegues empresariales, ambos números deben formar parte de la evaluación. Mean@k indica a los equipos con qué frecuencia funciona un agente. Pass^k les indica cuántas tareas siguen siendo fiables tras un uso repetido.
Por qué un agente puede cambiar de rumbo con temperatura cero
Un agente puede volverse inconsistente incluso cuando el prompt, el modelo, las herramientas y la temperatura de decodificación parecen no haber cambiado.
Un LLM elige cada token siguiente a partir de una distribución de probabilidades. Algunas decisiones tienen una opción claramente preferida, mientras que otras contienen varias opciones casi empatadas.
IBM las describe como decisiones pronunciadas y planas. Una distribución pronunciada concentra la mayor parte de la probabilidad en una opción. Es poco probable que pequeños cambios computacionales alteren la ganadora.
Una distribución plana reparte la probabilidad entre varias opciones plausibles. Un pequeño cambio numérico puede modificar qué token aparece primero y enviar al agente por una ruta distinta.
Esa diferencia cobra importancia en sistemas que utilizan herramientas. Un solo token alterado puede cambiar la selección de una API, una consulta de búsqueda, un argumento de herramienta, una decisión de reintento o la interpretación de un resultado intermedio.
Un chatbot convencional puede absorber cierta variación en la redacción sin cambiar su significado final. Un agente actúa según sus elecciones intermedias. Cada elección alterada cambia la información disponible en el siguiente paso.
El riesgo se acumula a lo largo de una trayectoria extensa. Si un agente toma decenas de decisiones, varias pueden situarse cerca de límites inestables. Basta con que una cambie para que falle una llamada posterior a una herramienta o la respuesta final.
IBM ejecutó su agente ReAct a temperatura 0,0. Por ello, los investigadores sostienen que el muestreo ordinario no provocó la variabilidad observada.
La temperatura cero no hace que cada ejecución de un modelo alojado sea matemáticamente idéntica. La agrupación de solicitudes, el comportamiento del hardware, las operaciones de coma flotante y los detalles de implementación del proveedor pueden alterar ligeramente las probabilidades.
Esos cambios suelen permanecer invisibles en la generación de texto convencional. Importan cuando dos opciones están casi empatadas. Una leve variación puede reordenarlas, pese a que la solicitud del usuario no haya cambiado.
Una semilla fija también tiene límites. Controla parte del proceso de generación, pero no congela todas las capas de un sistema de inferencia remoto. Tampoco hace más decisiva una decisión incierta.
Este mecanismo explica por qué un ensayo exitoso puede fallar durante una demostración en vivo. El agente no necesariamente ha olvidado la tarea. Ha entrado en una rama diferente del mismo árbol de decisiones.
Consideremos un agente al que se le pide contar actividades completadas en una nota. En una ejecución podría contar cada marcador de casilla. En otra, también podría contar una leyenda que explica el formato de las casillas.
Ambas rutas pueden parecer razonables inicialmente. Solo una produce el total previsto. El error surge de una decisión no resuelta sobre cómo interpretar el documento, no de la falta de acceso a la nota.
Los flujos de trabajo más largos amplifican este comportamiento. Un agente de investigación podría elegir una fuente diferente, malinterpretar una fecha ambigua o detenerse después del primer documento coincidente. Cada elección moldea todo lo que ocurre después.
Eso convierte la fiabilidad de los agentes de IA, en parte, en un problema de orquestación. Un mejor modelo base puede aumentar la probabilidad de tomar buenas decisiones, pero no garantiza que desaparezcan sus decisiones límite.
Las condiciones externas añaden otra capa. ReliabilityBench evalúa la ejecución repetida junto con solicitudes parafraseadas y fallos de herramientas. Su marco de pruebas de estrés para producción considera la consistencia, la robustez y la tolerancia a fallos como dimensiones independientes.
El experimento actual de IBM aísla de forma más acotada las ejecuciones repetidas. Ese enfoque facilita examinar la brecha de consistencia, pero no representa todos los fallos de producción que encontrará un agente.
Los despliegues reales afrontan datos modificados, credenciales vencidas, límites de tasa de API, respuestas parciales y esquemas en evolución. Por tanto, un comportamiento estable con una entrada idéntica es un requisito inicial, no todo el estándar de fiabilidad.
ALTK-Evolve convierte la incertidumbre en orientación específica
ALTK-Evolve intenta reparar decisiones inestables sin repetir cada tarea en un entorno en vivo.
El nuevo proceso comienza con una trayectoria registrada. Una trayectoria es el registro ordenado de prompts, decisiones, llamadas a herramientas, observaciones y respuestas producidas durante una ejecución del agente.
El Analizador de Consistencia de IBM revisita cada punto de decisión utilizando el contexto ya almacenado en ese rastro. Solicita varias finalizaciones alternativas y mide cuánto varía la elección del modelo.
La configuración predeterminada genera cinco finalizaciones mediante una llamada adicional al modelo por paso de decisión. No repite las llamadas a herramientas externas ni vuelve a ejecutar la tarea completa.
Ese diseño importa en producción. Una repetición completa podría enviar otro correo electrónico, modificar un registro dos veces, duplicar una compra o encontrarse con datos que ya han cambiado.
El remuestreo sin conexión evita esos efectos secundarios. También elimina la necesidad de una etiqueta de verdad fundamental durante la fase de diagnóstico.
El analizador es de caja negra, lo que significa que no requiere logits del modelo ni acceso interno. Los equipos pueden aplicarlo a un modelo alojado si poseen el rastro original y pueden volver a enviar sus contextos de decisión.
Cada decisión recibe una puntuación de consistencia. Los pasos con finalizaciones divergentes se convierten en candidatos para orientación adicional.
ALTK-Evolve transforma entonces esos candidatos en instrucciones de comportamiento concisas. Su propósito más amplio es extraer lecciones útiles de trayectorias anteriores y recuperarlas durante tareas posteriores.
Para el ejemplo de conteo de notas, la orientación generada recomendaba una expresión regular anclada a líneas en lugar de un conteo básico de subcadenas. También instruía al agente a inspeccionar múltiples coincidencias de búsqueda antes de seleccionar una nota.
Estas instrucciones abordan patrones generales de fallo. No se limitan a guardar la respuesta numérica correcta de la tarea original.
Esa diferencia es esencial. Memorizar una respuesta mejoraría un elemento del benchmark sin fortalecer al agente. Una regla reutilizable puede ayudar con notas nuevas, distintos formatos de casillas o decisiones de búsqueda relacionadas.
El repositorio de ALTK-Evolve incluye ahora el Analizador de Consistencia y los componentes de generación de directrices. El proyecto utiliza una licencia Apache 2.0 y admite integración mediante el Model Context Protocol.
Su capa de recuperación incorpora directrices relevantes al contexto del agente en tiempo de inferencia. Esto proporciona al modelo recordatorios específicos sin exigir que cada rastro histórico permanezca en el prompt activo.
El enfoque se asemeja a una forma enfocada de memoria operativa. En lugar de pedir al agente que relea todo lo que ha hecho, el sistema destila lecciones recurrentes y recupera las asociadas con la tarea actual.
Esta distinción también importa para el trabajo del conocimiento. Un archivo más grande no produce automáticamente mejores decisiones. La memoria útil requiere selección, manejo de conflictos y un contexto apropiado para la solicitud activa.
El mismo principio sustenta una base de conocimiento de IA bien estructurada. El material almacenado adquiere valor cuando un sistema puede recuperar la evidencia adecuada sin saturar el contexto de trabajo.
El método de ALTK-Evolve es más limitado que una plataforma de conocimiento general. Se centra en el comportamiento de los agentes y utiliza directrices derivadas de trayectorias. Aun así, ambos casos revelan la misma limitación: retener información es más fácil que aplicar la información adecuada en el momento oportuno.
El mecanismo también crea un ciclo de retroalimentación. Los equipos pueden recopilar trazas, detectar pasos inestables, generar guías candidatas y evaluar si esas guías mejoran ejecuciones posteriores.
Sin embargo, el sistema no elimina la necesidad de realizar pruebas. Una regla generada puede ser errónea, demasiado amplia o perjudicial fuera de la situación que la produjo.
Los equipos aún necesitan control de versiones y reversión. También deben rastrear qué directriz influyó en una decisión, especialmente cuando un agente realiza trabajo regulado o con consecuencias financieras.
La ganancia de fiabilidad es grande, pero la evidencia es limitada
IBM informa de una mejora sustancial, aunque el estudio sigue siendo una evaluación inicial sobre una configuración principal de benchmark.
Tras añadir directrices de consistencia, Pass^5 aumentó del 53.0% al 69.0% en las 168 tareas de AppWorld. Esto representa una mejora de 16 puntos en las tareas superadas en las cinco ejecuciones.
Mean@5 también aumentó, pasando del 77.4% al 81.0%. Por tanto, la brecha de consistencia se redujo de 24.4 puntos a 12.0 puntos.
Este resultado importa porque la media no disminuyó. Un método que mejorara la repetibilidad obligando al agente a seguir una estrategia sistemáticamente mediocre no resolvería el problema subyacente.
IBM afirma que las directrices mantuvieron o mejoraron Mean@5 en todos los niveles de dificultad. El grupo medio ganó 22.9 puntos en Pass^5, mientras que el grupo difícil ganó 14.3 puntos.
Las mejoras relativas fueron del 44% para las tareas medias y del 45% para las difíciles. Las tareas fáciles ganaron 12.2 puntos, con menos margen de mejora disponible.
IBM también probó las directrices en una tarea distinta pero relacionada dentro del mismo escenario de AppWorld. Pass^5 aumentó 13 puntos, frente a la ganancia de 16 puntos en la misma tarea.
Ese resultado respalda la afirmación de que algunas directrices se transfieren más allá de una trayectoria registrada. No demuestra una generalización amplia entre aplicaciones, sectores o arquitecturas de agentes no relacionadas.
Un segundo experimento utilizó gpt-oss-120b. Su Pass^5 en la misma tarea aumentó del 10.1% al 16.1%, mientras que el rendimiento en tareas similares ganó 8.7 puntos.
La línea de base más débil muestra que las directrices no pueden sustituir por completo a la capacidad. Una mejora de seis puntos es significativa, pero una tasa de éxito en todas las ejecuciones del 16.1% sigue siendo inadecuada para automatizaciones con consecuencias relevantes.
El informe técnico completo presenta la metodología que sustenta estas afirmaciones. Aun así, los lectores deberían considerar los resultados como evidencia de la evaluación de los autores, no como una confirmación independiente en sistemas de producción.
La prueba principal utiliza una configuración ReAct, una división principal del benchmark y cinco repeticiones por tarea. AppWorld ofrece escenarios realistas con múltiples aplicaciones, pero un benchmark sigue siendo un entorno controlado.
Cinco ejecuciones revelan una inestabilidad que una sola ejecución oculta. No estiman con precisión los fallos poco frecuentes que podrían aparecer en miles de interacciones con clientes.
La evaluación también plantea una cuestión estadística. Pass^k disminuye de forma natural a medida que k aumenta, porque cada ensayo adicional crea otra oportunidad de fallar.
Por tanto, un equipo de producto debe elegir k según la exposición real. Cinco ejecuciones exitosas pueden ser un filtro razonable durante el desarrollo. No demuestran fiabilidad a escala empresarial.
Las directrices también pueden quedar obsoletas. Las API cambian, las políticas evolucionan y soluciones previas pueden entrar en conflicto con el nuevo comportamiento del sistema.
Una regla derivada de una rama inestable podría suprimir una alternativa válida en otro contexto. Cuantas más directrices acumule un sistema, más importantes se vuelven la resolución de conflictos y la calidad de la recuperación.
También existe una diferencia entre un comportamiento consistente y un comportamiento correcto. Un agente que repite la misma acción equivocada tiene una estabilidad conductual perfecta y ningún valor para la tarea.
El experimento de IBM aborda este problema al informar Mean@5 junto con Pass^5. Los equipos de producción deberían conservar la misma combinación y añadir medidas de seguridad específicas para los resultados.
En flujos de trabajo sensibles, la corrección consistente debe ser el objetivo. La estabilidad por sí sola nunca debe sustituir la precisión factual, el cumplimiento de políticas, las comprobaciones de autorización ni la revisión humana.
Los modelos más grandes ahora se enfrentan a un competidor a nivel de sistemas
La nueva evidencia cuestiona la suposición de que los problemas de fiabilidad deben resolverse primero reemplazando el modelo subyacente.
Las actualizaciones de modelos siguen siendo atractivas porque pueden mejorar muchas tareas a la vez. También requieren menos diagnóstico personalizado que reconstruir la memoria o el sistema de evaluación de un agente.
Sin embargo, un modelo más grande no revela dónde se vuelve inestable un agente existente. Puede elevar el rendimiento medio y, al mismo tiempo, dejar una brecha significativa entre el éxito ocasional y el repetido.
El enfoque de IBM representa una vía alternativa. En vez de cambiar el modelo, cambia la información proporcionada en los puntos de decisión de alto riesgo.
La comparación no es estrictamente entre modelo y memoria. Los sistemas sólidos combinarán modelos capaces, herramientas bien diseñadas, contexto específico, comprobaciones deterministas y evaluaciones repetidas.
La presión recae sobre los proveedores de agentes y los compradores empresariales que aún informan una única tasa de éxito. Cuando Pass^k entre en las conversaciones de compra, una media elevada será solo una parte de la evidencia.
Los compradores pueden preguntar si se repitió la misma tarea, si se restableció el entorno y si cada ejecución alcanzó un resultado aceptable. También pueden solicitar resultados por dificultad en lugar de una única cifra agregada.
Los desarrolladores afrontan un cambio relacionado. Un informe de error que indique que un agente falló una vez podría dejar de poder reproducirse bajo demanda. Los equipos necesitan trazas completas para localizar la decisión anterior que divergió.
La observabilidad pasa a formar parte de la calidad del producto. Sin prompts almacenados, argumentos de herramientas, resultados y decisiones intermedias, una ejecución inestable puede desaparecer sin explicarse.
Eso hace que la arquitectura de evaluación sea importante antes del despliegue. Los equipos necesitan tareas representativas, estados iniciales controlados, criterios de éxito explícitos y suficientes repeticiones para revelar la variabilidad.
También deben separar el trabajo reintentable de las acciones de una sola oportunidad. Generar un borrador puede tolerar varios intentos. Enviar un pago, eliminar un archivo o aprobar un contrato requiere controles más estrictos.
Pass@k encaja con el primer grupo cuando los resultados pueden verificarse automáticamente. Pass^k es más informativo para el segundo, especialmente cuando los usuarios esperan que el primer resultado sea seguro.
Algunos flujos de trabajo no deberían depender de ninguna de las dos métricas por sí sola. Un agente transaccional también necesita límites de permisos, controles de idempotencia, registros de auditoría y validación determinista antes de ejecutar una acción irreversible.
Las directrices pueden reducir el razonamiento incierto, pero no reemplazan esas salvaguardas. Un agente fiable es una propiedad del sistema, no una puntuación del modelo.
Los resultados también refuerzan el argumento a favor de un contexto de trabajo seleccionado. Los equipos ya utilizan knowledge blending para conectar evidencia almacenada con el trabajo activo. Las directrices de agentes aplican una idea similar a las lecciones de comportamiento.
La clave es la moderación. Más contexto recuperado puede generar distracción, contradicciones y mayor latencia. Una instrucción específica solo aporta valor cuando llega a la tarea correcta y no desplaza evidencia esencial.
Aquí reside el desafío a largo plazo de ALTK-Evolve. Su diagnóstico puede identificar decisiones variables, pero el sistema circundante debe gestionar una colección creciente de lecciones.
Un despliegue exitoso necesitará políticas de expiración, detección de conflictos, procedencia y evaluaciones de los cambios en las directrices. De lo contrario, la solución de ayer puede convertirse en la fuente oculta de fallos de mañana.
Qué mostrará si el enfoque de IBM se sostiene
Tres señales determinarán si las directrices de consistencia se convierten en una capa estándar para agentes o siguen siendo una técnica prometedora de benchmark.
La primera señal es la reproducción independiente en otros benchmarks y arquitecturas de agentes. Los investigadores deberían probar el método con agentes de navegador, agentes de programación, sistemas de atención al cliente y flujos de trabajo con fallos reales de API.
Repetir la mejora de 16 puntos en Pass^5 reforzaría la afirmación central de IBM. Mejoras menores o inconsistentes sugerirían que AppWorld contiene patrones de fallo especialmente adecuados para la reparación mediante directrices.
Las comparaciones deberían incluir varios modelos base. También deberían informar del uso de tokens, la latencia, el coste del analizador, la sobrecarga de recuperación y el número de directrices inyectadas por tarea.
La segunda señal es el rendimiento durante periodos más largos. Un sistema de aprendizaje útil debe gestionar nuevas directrices sin acumular reglas conflictivas u obsoletas.
Los equipos deberían medir si el beneficio se mantiene después de cientos o miles de trayectorias. También deberían probar si la recuperación de directrices sigue siendo precisa a medida que crece el repositorio.
Habrá que observar evaluaciones que congelen un conjunto de directrices y lo prueben frente a versiones posteriores de las aplicaciones. Un rendimiento sólido demostraría que las reglas capturan comportamientos duraderos. Un deterioro rápido pondría de manifiesto una carga de mantenimiento.
La tercera señal es la adopción de informes de ejecuciones repetidas. Los cuadros de resultados de los proveedores deberían publicar Mean@k y Pass^k juntos, indicando k con claridad.
Ese cambio permitiría a los compradores distinguir entre modelos que tienen éxito con frecuencia y sistemas que tienen éxito de forma fiable. También desincentivaría las demostraciones construidas alrededor de una sola ejecución favorable.
El sector debería ir más allá combinando la repetición con paráfrasis y fallos controlados de herramientas. Los prompts idénticos representan solo un tipo de presión de producción.
El trabajo de IBM presenta un argumento convincente: una sola ejecución exitosa es un estándar demasiado débil. También ofrece un método práctico para localizar la incertidumbre sin repetir cada acción del mundo real.
La pregunta pendiente es si esas mejoras persisten fuera de la configuración de investigación. Los desarrolladores pueden responderla repitiendo sus propios flujos de trabajo importantes, conservando trazas completas y midiendo el éxito en todas las ejecuciones.
Si su agente realiza trabajo con consecuencias relevantes, no pregunte solo si completó la tarea. Pregunte con qué frecuencia completa correctamente la misma tarea, qué decisiones varían y qué ocurre cuando las directrices de ayer se enfrentan a las condiciones de mañana.
