En el benchmark HALO, el 61,20% de las respuestas rechazadas de los agentes de IA llegó demasiado pronto o con exceso de insistencia

Un agente proactivo debe decidir por sí mismo si conviene ayudar, cuándo hacerlo y hasta dónde llegar, y todo ello sin una petición explícita. Investigadores de la Universidad de California en Davis y de la Universidad del Sur de California han propuesto el benchmark HALO para evaluar esta capacidad. Su principal conclusión es que los agentes fallan con más frecuencia por exceso de iniciativa que por inacción. Entre las respuestas rechazadas por los evaluadores humanos, el 61,20% (2188 de 3575) adolecía de una intervención demasiado temprana o de una fuerza de acción excesiva.

Cómo está diseñado HALO y quién etiquetó las respuestas

Los escenarios abarcan cuatro tipos de necesidad: dependencia (falta una condición para una tarea futura), bloqueo (no se puede continuar con la actividad actual), riesgo (un posible problema que aún no ha ocurrido) y oportunidad (un paso útil pero no imprescindible). Se reparten en 10 ámbitos cotidianos, desde los estudios y el trabajo hasta la familia, la salud, los viajes, las finanzas y las aficiones. Cada ámbito tiene cinco personajes, lo que suma 50 entornos personales. Cada entorno incluye ocho escenarios, hasta un total de 400.

El entorno consta de correo, calendario, chat, contactos y cartera, y las pruebas se almacenan en bases de datos SQLite y archivos de texto. El agente dispone de 29 comandos para buscar datos y 19 para actuar. En cada punto de control ve una parte de la cadena de eventos, puede reunir datos en varias rondas y después emite una única respuesta ejecutable o renuncia a actuar. Las acciones se dividen en niveles: L0, observación; L1, llamada de atención; L2, preparación sin compromisos externos; L3, ejecución con consecuencias reales. Un nivel más alto no implica una mejor ayuda. Los escenarios los creó GPT5.6-Sol y luego los revisaron un validador y revisores humanos.

Sobre este entorno se construyó el conjunto HALO-8K: 8000 respuestas de 10 modelos, 800 por cada uno. Veinte expertos dictaminaron si cada respuesta era aceptable y, en las rechazadas, indicaron el motivo: prematuridad, tardanza, insuficiencia, exceso y otros. La inacción razonable contaba como respuesta correcta.

Qué muestran los resultados

La dispersión es grande: va del 30,38% de GPT-OSS-20B al 72,88% de Gemini3.8-Flash. Incluso el mejor modelo da una respuesta inaceptable en más de una cuarta parte de los casos. Entre los modelos abiertos lidera DeepSeekV4-Pro con un 56,63%, por delante de los cerrados Gemini3.1-Pro y GPT5.6-Luna. De media, los modelos cerrados lograron un 63,08% y los abiertos un 47,55%, pero los tres mejores modelos abiertos están a menos de 2,50 puntos entre sí, y es la cola débil la que arrastra el promedio a la baja.

Los agentes eligieron con más frecuencia el nivel L1 (69,20% de las respuestas); L3 representó el 16,09% y L2 solo el 4,18%. La proporción de ejecución es casi idéntica en ambos grupos, en torno al 16,1%. Los modelos cerrados eligen L0 el doble de veces. La intervención prematura aparece casi tres veces más que la tardía, y la fuerza excesiva, aproximadamente el doble que la insuficiente. Los dos mejores modelos cometen menos errores de este tipo.

La inacción no garantiza por sí sola la calidad. Qwen3.8-27B casi nunca falla por inacción (0% Inaction), pero elige L0 solo en el 0,38% de los casos y alcanza únicamente un 55,13% de aceptabilidad.

La búsqueda de datos pesa más que el volumen de razonamiento

Los modelos abiertos gastan de media 4,77 mil tokens de razonamiento y hacen 1,21 rondas de búsqueda por respuesta. Los cerrados usan 5,53 mil tokens y 2,55 rondas. Los abiertos emplean solo un 14% menos de tokens, pero hacen aproximadamente un 53% menos de búsqueda. Entre los recordatorios, consultar el contenido local se asocia con una mayor aceptabilidad y conduce con menos frecuencia a la valoración «insuficiente». Claude-Opus5.5, el siguiente en la clasificación, gasta alrededor del 23% de los tokens de razonamiento del líder, de modo que es posible lograr un buen resultado con consumos de recursos muy distintos.

Incluso cuando el momento del recordatorio es correcto, los recordatorios suelen resultar insuficientes y la ejecución, excesiva.

Limitaciones

La aceptabilidad varía poco según el tipo de necesidad (54,35–56,00%) y algo más según el ámbito, del 50,88% al 58,88%. La evaluación se basa en una muestra de 800 respuestas por modelo, y los tokens se contabilizan según las reglas de cada proveedor, por lo que conviene comparar el consumo con cautela. Los escenarios los genera un modelo, aunque los revisan personas. La conclusión para los desarrolladores es que un asistente proactivo debe medirse no por el número de necesidades detectadas, sino por la oportunidad del momento y la proporción de las acciones, y que en el producto conviene mantener L0 y L1 como modos seguros por defecto.