Conviene ejecutar el agente cinco veces sobre la misma tarea antes de ponerlo en producción, porque la cifra de precisión que se está citando describe casi con seguridad un sistema distinto del que encontrarán los usuarios. Esa es la conclusión práctica de un nuevo trabajo de IBM Research, que midió un agente ReAct con un 77,4% de éxito promedio en el benchmark AppWorld y después comprobó que solo el 53,0% de esas tareas salía bien en los cinco intentos.
Puntos clave
- La diferencia de 24,4 puntos entre ambas cifras —lo que IBM llama brecha de consistencia— apareció con la decodificación fijada en temperatura cero y sin cambiar nada de las tareas entre ejecuciones.
- Un diagnóstico llamado Consistency Analyzer localiza los pasos inestables a partir de una sola traza ya registrada: necesita una llamada adicional al modelo por decisión y ninguna etiqueta, evaluador ni reejecución del entorno.
- Las guías generadas a partir de ese diagnóstico elevaron al 69,0% la tasa de aciertos en las cinco ejecuciones y, al mismo tiempo, subieron la precisión media al 81,0%. El conjunto de herramientas está en GitHub.
Una puntuación promediada es el contrato equivocado
Los rankings citan Mean@k: se ejecuta la suite k veces, se promedia la tasa de aprobación y se publica el número. Es una descripción justa del comportamiento típico y una descripción pobre de lo que promete un flujo de trabajo en producción, porque conciliar una transacción o revisar una cláusula contractual no es una tarea que se pueda intentar una y otra vez para quedarse con el mejor resultado.
La métrica que corresponde a esa promesa es Pass^k, la proporción de tareas que el agente resuelve bien en cada una de las k ejecuciones. IBM insiste en que no debe confundirse con el optimista Pass@k, conocido por los artículos de generación de código, al que le basta con acertar una vez de k. En la partición test_normal de AppWorld, con 168 tareas, cambiar de la primera métrica a la segunda recorta la cifra de titular en casi una cuarta parte, y el déficit llega a unos 30 puntos en el nivel más difícil.
No es un fallo de muestreo, es un problema de distribución
Lo incómodo del hallazgo es que las palancas habituales no lo tocan. La decodificación voraz y las semillas fijas gobiernan cómo se colapsa una distribución de probabilidad en un token, así que no sirven de nada cuando la propia distribución reparte una masa casi idéntica entre dos acciones siguientes igual de plausibles; en infraestructura alojada, fuentes ordinarias de ruido numérico como la no asociatividad del punto flotante o el agrupamiento de peticiones bastan para invertir ese empate técnico entre ejecuciones. Encadene decenas de decisiones así y una probabilidad pequeña de cambio por paso se convierte en una grande por ejecución.
El planteamiento de IBM es que la fiabilidad se sitúa en un eje distinto del de la capacidad, lo que significa que el reflejo de actualizar el modelo apunta al lugar equivocado: un agente de IA más potente obtiene un mejor promedio sin volverse necesariamente más repetible.
Encontrar los puntos de quiebre sin gastar de más
El Consistency Analyzer trabaja hacia atrás desde una trayectoria que el agente ya produjo. Por cada decisión de esa traza lanza una única llamada que pide cinco terminaciones sobre el contexto registrado, puntúa cuánto se mueve la salida y anota el resultado en una tabla paso a paso. No se reejecuta nada contra el entorno, no hace falta verdad de referencia y el método no toca los internos del modelo, que es justo lo que lo hace viable sobre tráfico real, donde reproducir una tarea de principio a fin suele ser imposible.
Los pasos señalados se convierten después en guías con el formato que ya usa ALTK-Evolve y se recuperan en el momento de la inferencia. Los ejemplos publicados se leen como hábitos de ingeniería más que como respuestas: anclar una expresión regular al inicio de línea al contar casillas marcadas, confirmar que una búsqueda devolvió el registro correcto antes de actuar sobre él. Lo decisivo es que el analizador busca inestabilidad y no fallos, de modo que marca pasos que el agente resolvió bien por casualidad en la ejecución examinada.
Qué se movió y cuánto
Generar guías a partir de una trayectoria base por tarea y evaluar después con cinco ejecuciones nuevas llevó el Pass^5 del 53,0% al 69,0% y el Mean@5 del 77,4% al 81,0%, reduciendo la brecha a la mitad, hasta 12,0 puntos, y convirtiendo casi un tercio de las tareas antes inestables en tareas que aprobaban siempre. Las de dificultad media fueron las que más ganaron en términos absolutos, con 22,9 puntos, por delante de los 14,3 de las difíciles y los 12,2 de las fáciles, y la precisión media no retrocedió en ningún nivel: una restricción que IBM se impuso a propósito, ya que comprar consistencia a costa de precisión no haría más que mudar de sitio la falta de fiabilidad.
La transferencia también parece real. Las mismas guías aplicadas a otra tarea del mismo escenario siguieron aportando una mejora de 13,0 puntos en Pass^5, y en el más limitado gpt-oss-120b la ganancia de 8,7 puntos en tareas similares superó a los 6,0 puntos obtenidos en la misma tarea, un patrón más compatible con capturar modos de fallo reutilizables que con memorizar una ejecución.
Por qué importa más allá de un benchmark
Los compradores corporativos llevan el año entero recibiendo ofertas de agentes basadas en puntuaciones de un solo intento, y aquí hay un instrumento concreto y barato para interrogar esas promesas: pedirle a un proveedor su Pass^3 y ver qué contesta. IBM liberó el analizador y la generación de guías en el repositorio ALTK-Evolve, con la metodología detallada en un informe técnico en arXiv y resumida en la publicación del equipo en Hugging Face.
Encaja además en un patrón más amplio de la evaluación de agentes este año, en el que la cifra de capacidad resiste el escrutinio que el comportamiento detrás de ella no aguanta, igual que una prueba de presión de 25 turnos encontró modelos cuyo razonamiento se sostenía mientras su conducta cedía.
Preguntas frecuentes
¿Cuál es la diferencia entre Pass^k y Pass@k?
Pass@k da una tarea por resuelta si funciona cualquiera de los k intentos, algo razonable cuando la salida se puede verificar y reintentar. Pass^k solo la cuenta cuando funcionan los k intentos, que se parece más a lo que vive un usuario al hacer dos veces la misma pregunta. Pass^k siempre es el menor de los dos.
¿Bajar la temperatura corrige la inconsistencia de los agentes?
No. La brecha de 24,4 puntos se midió a temperatura 0,0. Los parámetros de decodificación deciden cómo se convierte una distribución en un token, pero dejan intacta la distribución, y los endpoints alojados desplazan esas probabilidades ligeramente de una ejecución a otra de todos modos.
¿Se puede usar ya el Consistency Analyzer?
Sí, como código abierto en el repositorio ALTK-Evolve. Funciona sobre trazas que ya se tienen, necesita una llamada adicional al modelo por paso de decisión y ninguna etiqueta de referencia, así que el costo de una primera medición es bajo.
