Les agents proactifs de HALO sont envahissants : 61,20% des réponses rejetées interviennent trop tôt ou de façon excessive

Des chercheurs de l'Université de Californie à Davis et de l'Université de Californie du Sud ont présenté HALO, un benchmark pour agents proactifs, c'est-à-dire des assistants qui décident eux-mêmes s'il faut aider, quand le faire et jusqu'où aller, sans attendre une demande explicite. Les auteurs ont mobilisé 20 experts, qui ont évalué manuellement 8000 réponses de 10 modèles. Le principal enseignement est peu flatteur pour toute l'industrie : même le meilleur modèle ne fournit une aide acceptable que dans 72,88% des cas, et la principale cause d'échec est un excès d'initiative.

Comment HALO est construit et ce qu'il évalue

Le benchmark définit quatre types de besoins. La dépendance (Dependency) est une condition manquante pour une tâche à venir. Le blocage (Blockage) désigne une situation où l'activité en cours ne peut pas se poursuivre. Le risque (Risk) est une issue défavorable possible, qui ne s'est pas encore produite. L'opportunité (Opportunity) est un avantage facultatif, dont l'absence ne casse rien.

Tout cela est réparti sur 10 domaines de la vie quotidienne : études, travail, maison, famille et soins aux proches, santé, voyages, finances personnelles, vie de la communauté, vie sociale et culturelle, loisirs et sport. Chaque domaine compte cinq personnages, soit 50 environnements personnels au total, et chaque environnement contient huit scénarios, pour 400 scénarios en tout.

L'environnement HALO-Arena comprend la messagerie, le calendrier, le chat, les contacts et le portefeuille, adossés à des bases SQLite et à des fichiers texte. L'agent dispose de 29 commandes de recherche d'information et de 19 commandes d'action. Avant de répondre, il doit trouver des preuves dans des données structurées ou non structurées, puis seulement décider si une aide est justifiée. Exemple tiré de l'article : une entrée de calendrier sur un voyage peut inciter l'agent à vérifier dans la base les objets nécessaires et un fichier contenant l'autorisation d'achat. Ces éléments justifient un rappel, mais pas l'achat lui-même.

Les réponses se répartissent en quatre niveaux : L0, l'observation sans intervention ; L1, l'attirer l'attention de l'utilisateur ; L2, la préparation d'une action sans engagement externe ; L3, l'exécution, qui modifie des engagements ou produit un effet externe. Un niveau élevé ne signifie pas une meilleure aide : lorsque la retenue est pertinente, L0 est aussi accepté.

Les scénarios ont été construits avec GPT5.6-Sol, puis vérifiés par un validateur, un modèle relecteur et deux auditeurs humains ; un troisième tranchait les cas litigieux. Pour l'annotation, 2160 points de contrôle ont été retenus, soit 800 réponses par modèle. L'expert décide d'abord si la réponse est acceptée ; pour les réponses rejetées, il indique ce qui cloche : trop tôt, trop tard, insuffisant, excessif, ou d'autres problèmes comme l'absence d'appui sur les données.

Résultats : un écart important, un leader sans marge

L'acceptabilité varie de 30,38% pour GPT-OSS-20B à 72,88% pour Gemini3.8-Flash, soit un écart de 42,50 points. Parmi les modèles ouverts, DeepSeekV4-Pro est en tête avec 56,63%. Les modèles fermés obtiennent en moyenne 63,08%, les modèles ouverts 47,55%, mais les deux groupes se recoupent : DeepSeekV4-Pro devance à la fois Gemini3.1-Pro et GPT5.6-Luna.

Les modèles choisissent le plus souvent L1, c'est-à-dire qu'ils se contentent d'attirer l'attention de l'utilisateur : 69,20% de l'ensemble des réponses. La préparation (L2) est rare, à 4,18%, et l'exécution (L3) représente 16,09%. La part d'exécution est quasiment identique dans les deux groupes, autour de 16,1%, et n'explique donc pas l'écart de qualité. Les modèles fermés choisissent environ deux fois plus souvent l'inaction.

La recherche de données marque une différence nette. Les modèles ouverts effectuent en moyenne 1,21 tour de recherche par réponse, contre 2,55 pour les modèles fermés, soit environ 53% de moins, alors que la consommation de tokens de raisonnement est comparable : 4,77 mille contre 5,53 mille. Claude-Opus5.5, deuxième parmi les modèles fermés, dépense environ 23% des tokens de raisonnement du leader : un bon résultat n'exige donc pas une consommation maximale.

Le vrai problème : l'excès, pas la passivité

Sur 3575 réponses rejetées, 2188 (61,20%) relevaient soit d'une réaction trop précoce, soit d'une intensité excessive. Cette part varie selon les modèles de 44,23% à 79,66%, et dépasse la moitié pour six modèles sur dix. L'intervention trop précoce est presque trois fois plus fréquente que l'intervention tardive, et l'intervention excessive environ deux fois plus fréquente que l'intervention insuffisante. Ce schéma se retrouve dans les quatre types de besoins et dans les dix domaines. Les deux meilleurs modèles affichent à la fois les taux de précocité et d'excès les plus bas.

La retenue joue aussi un rôle : Qwen3.8-27B ne s'est jamais trompée par inaction, mais elle n'a choisi L0 que dans 0,38% des cas et n'a obtenu que 55,13%. Pour les rappels, l'accès au contenu des données locales est associé à une acceptabilité plus élevée et à une part moindre de réponses « insuffisantes ». Lorsque le moment est bien choisi, les rappels s'avèrent plus souvent insuffisants et l'exécution, excessive.

Limites

Les données portent sur des scénarios échantillonnés et sur des paramètres d'inférence enregistrés, et le comptage des tokens dépend des règles de facturation des fournisseurs. Les scénarios sont générés par un modèle, même s'ils ont été vérifiés par des humains, et chaque scénario est traité par un seul et même annotateur. Pour les développeurs, la conclusion est pratique : lors de la conception d'assistants proactifs, il faut mesurer non seulement le déclenchement, mais aussi le moment, l'ampleur et les pouvoirs de l'intervention, et obliger l'agent à chercher d'abord des confirmations dans les données de l'utilisateur.