Un agente de IA puede resolver una tarea correctamente y aun así no ser confiable. ¿La razón? Puede responder bien hoy y fallar mañana ante exactamente la misma solicitud, incluso cuando usa temperatura cero y una semilla fija.
En flujos críticos, como conciliar una transacción financiera o revisar un contrato, esa variabilidad no es un detalle estadístico. Es un problema de producción. IBM Research propone medirlo con mayor precisión mediante nuevas métricas y un sistema capaz de detectar las decisiones inestables de un agente.
La precisión promedio puede ocultar fallos
La mayoría de los benchmarks reporta una cifra promedio. Por ejemplo, un agente ReAct basado en GPT-4.1 alcanzó un Mean@5 de 77,4 % en AppWorld, después de ejecutar cada tarea cinco veces.
El resultado parece sólido. Pero hay otra pregunta más cercana a la experiencia real del usuario: ¿en cuántas tareas acertó en las cinco ejecuciones?
La respuesta fue un Pass⁵ de solo 53,0 %. Esto significa que casi una cuarta parte de las tareas fueron resueltas algunas veces, pero no de manera consistente.
Un agente puede ser capaz y, al mismo tiempo, impredecible.
La diferencia entre ambas métricas se conoce como brecha de consistencia. En este caso, fue de 24,4 puntos porcentuales:
- Mean@5: 77,4 % de éxito promedio.
- Pass⁵: 53,0 % de tareas aprobadas en las cinco ejecuciones.
- Brecha de consistencia: 24,4 puntos porcentuales.
Mean@k, Pass^k y Pass@k no significan lo mismo
Estas métricas responden preguntas distintas:
- Mean@k: porcentaje promedio de éxito después de ejecutar una tarea
kveces. - Pass^k: porcentaje de tareas que el agente resuelve correctamente en las
kejecuciones. - Pass@k: porcentaje de tareas en las que al menos una de las
kejecuciones tiene éxito.
Pass@k es útil cuando puedes intentar varias veces y verificar el resultado. Pass^k es más exigente: cada intento debe funcionar. Por eso, la relación esperada es Pass^k ≤ Mean@k ≤ Pass@k.
Por qué un agente puede cambiar de decisión
Cada acción de un agente depende de una distribución de probabilidades sobre los siguientes tokens. Si una opción tiene una probabilidad claramente mayor que las demás, la decisión es estable.
Pero algunas decisiones están mucho más parejas. Dos tokens pueden quedar casi empatados y cualquier pequeña variación del entorno puede cambiar cuál aparece primero. Entre esas variaciones están el procesamiento paralelo, la aritmética de punto flotante en la GPU o cambios mínimos en la infraestructura del proveedor.
Esto puede ocurrir aunque el agente use temperature=0.0. La temperatura cero evita el muestreo aleatorio convencional, pero no elimina las diferencias en las probabilidades internas ni resuelve necesariamente los empates cercanos.
El problema se amplifica a lo largo de una trayectoria. Un agente suele tomar decenas de decisiones: qué API utilizar, qué argumento enviar, si debe buscar más información o si conviene reintentar. Una pequeña posibilidad de cambio en cada paso puede terminar produciendo una trayectoria completamente diferente.
Por eso, aumentar el tamaño del modelo no siempre soluciona la inconsistencia. Un modelo más potente puede elevar el promedio de aciertos, pero la consistencia es un eje distinto de la capacidad.
Consistency Analyzer: detectar los pasos inestables
IBM Research incorporó un nuevo componente a ALTK-Evolve, un sistema que convierte las trayectorias anteriores de un agente en guías reutilizables para futuras ejecuciones.
La nueva herramienta se llama Consistency Analyzer. Su función es localizar los puntos de decisión donde el agente estuvo cerca de elegir otra acción, aunque en la trayectoria original haya tomado la decisión correcta.
El proceso funciona así:
- Se toma una trayectoria registrada del agente.
- Se revisa cada paso de decisión con el contexto que ya existía.
- Para cada paso se solicitan varias completaciones controladas, cinco por defecto.
- Se mide cuánto varían las respuestas.
- Se genera una puntuación que identifica los pasos con mayor riesgo de cambiar.
El análisis no requiere acceder a los logits ni modificar el modelo. Tampoco necesita volver a ejecutar toda la tarea ni interactuar otra vez con las herramientas y el entorno. Se realiza de forma offline con una llamada adicional por paso de decisión.
Esto es importante para sistemas reales. En producción, repetir una tarea completa puede ser costoso, lento o directamente imposible. En cambio, analizar una traza ya registrada ofrece una forma más práctica de estudiar la confiabilidad.
De la detección a las guías reutilizables
Una vez que el analizador encuentra una decisión inestable, ALTK-Evolve la convierte en una consistency guideline, o guía de consistencia.
Estas guías se incorporan al flujo normal de almacenamiento y recuperación del sistema. La idea no es memorizar una respuesta específica, sino capturar un patrón de error que pueda aparecer en otras tareas.
En una tarea de AppWorld, por ejemplo, el agente debía contar actividades marcadas en una nota de SimpleNote. A partir de una trayectoria, el sistema generó recomendaciones como:
- Al contar marcadores similares a casillas, usar una expresión regular anclada al inicio de cada línea en lugar de un conteo simple de subcadenas.
- Verificar los resultados de búsqueda comprobando que existan varias coincidencias y confirmando cuál nota es la correcta.
¿Por qué importa este nivel de detalle? Porque una nota puede repetir el símbolo de la casilla en una leyenda o en el título. Un conteo superficial puede parecer correcto en una ejecución y fallar en la siguiente.
La herramienta busca precisamente esos puntos de inestabilidad. No se limita a estudiar lo que el agente hizo mal, sino también lo que hizo bien por poco y podría equivocarse después.
La brecha se reduce casi a la mitad
El equipo evaluó el método en 168 tareas de AppWorld test_normal. Usó un agente ReAct con GPT-4.1, generó guías a partir de una sola trayectoria inicial por tarea y luego probó cada caso en cinco ejecuciones nuevas.
Los resultados fueron los siguientes:
- Pass⁵: subió de 53,0 % a 69,0 %.
- Mean@5: subió de 77,4 % a 81,0 %.
- Brecha de consistencia: bajó de 24,4 a 12,0 puntos porcentuales.
En otras palabras, casi un tercio de las tareas que antes eran inconsistentes pasaron a resolverse correctamente en las cinco ejecuciones.
La mejora fue más fuerte en los niveles de dificultad medio y alto:
- Tareas medias: aumento de 22,9 puntos porcentuales en Pass⁵.
- Tareas difíciles: aumento de 14,3 puntos porcentuales.
- Tareas fáciles: aumento de 12,2 puntos porcentuales.
Además, el promedio de precisión no cayó. Ese era un requisito central del experimento: mejorar la confiabilidad sin trasladar los fallos a otros escenarios.
Las guías también transfieren conocimiento
El sistema no solo mejoró las mismas tareas de las que obtuvo las guías. Cuando se probó en tareas similares dentro del mismo escenario, Pass⁵ aumentó 13 puntos porcentuales.
Eso sugiere que las guías no estaban memorizando una trayectoria específica. Estaban capturando patrones más generales, como la necesidad de validar una búsqueda o elegir un método de conteo más preciso.
El resultado también se observó con un modelo más débil, gpt-oss-120b. En las mismas tareas, Pass⁵ pasó de 10,1 % a 16,1 %, una mejora de 6 puntos. En tareas similares, el incremento llegó a 8,7 puntos porcentuales.
Este comportamiento es relevante para empresas que no siempre pueden utilizar el modelo más costoso. Una guía bien construida puede estabilizar comportamientos sin tener que cambiar toda la arquitectura ni reemplazar el modelo.
Qué cambia para evaluar agentes de IA
La recomendación más directa es reportar Pass^k junto a Mean@k. Una media de aciertos puede hacer que un agente afortunado parezca tan confiable como uno que responde bien de manera repetida.
También conviene prestar atención a la dificultad. La brecha suele crecer en las tareas complejas, justo donde una métrica promedio resulta más engañosa.
Antes de buscar un modelo más grande, vale la pena diagnosticar la fuente de la variabilidad. Tal vez el agente no necesite más conocimiento, sino instrucciones específicas para estabilizar decisiones que están demasiado cerca entre sí.
La pregunta ya no es únicamente si el agente puede resolver una tarea. También importa si puedes confiar en que volverá a resolverla.
El código abierto de ALTK-Evolve incorpora el Consistency Analyzer y la generación de guías de consistencia utilizadas en estos experimentos. Para sistemas que ejecutan acciones sobre datos, APIs o procesos empresariales, este enfoque ofrece una forma concreta de pasar de medir capacidad promedio a medir confiabilidad operativa.
Fuente original
https://huggingface.co/blog/ibm-research/altk-evolve-consistency