L'évaluation des agents de recherche repose généralement sur des scénarios soigneusement définis : des répliques connues à l'avance, des requêtes prévisibles, un utilisateur « moyen » unique. Cette approche est pratique à mesurer, mais elle reflète mal la réalité, où derrière une même interface se trouvent des personnes au rythme, au style et à la patience radicalement différents. Le travail AgentWorld: Personality-Aware Reliability Evaluation for Agentic Information Retrieval (arXiv:2608.24076, accepté au workshop Agent4IR @ KDD 2026) propose d'envisager la fiabilité de l'agent autrement — à travers le caractère de l'interlocuteur et à travers les tentatives de briser ce caractère.
Des scripts aux personnalités : où se situe la lacune
Le benchmark classique pour la recherche agentique répond à la question « l'agent a-t-il résolu la tâche ». Mais il reste muet sur ce qui se passe entre les étapes, et ne dit presque rien sur la dispersion des résultats. Si tous les utilisateurs du test se comportent de la même manière et que les attaques contre le système ne sont pas du tout modélisées, alors les conclusions obtenues sont stériles : un tel mesure ne permet pas de comprendre où exactement l'agent commence à trébucher.
C'est précisément cette brèche que les auteurs — Gunja Agarwal, Arup Kumar Das, Arun Menon, Jitesh Chandra Mishra et Vignesh Divakaran — tentent de combler. Leur idée clé est simple : la dispersion des comportements des utilisateurs ne doit pas être lissée, mais transformée en un instrument de mesure à part entière.
Ce qu'est AgentWorld
AgentWorld est un simulateur, et non un moteur de recherche distinct. Il ne résout pas les tâches à la place de l'agent, mais crée un environnement dans lequel l'agent peut être testé sur différents scénarios et différents types d'interlocuteurs, en enregistrant non seulement la réponse finale, mais aussi la trajectoire pour l'obtenir.
Quatre blocs fondamentaux
- Modèles d'utilisateurs selon les Big Five. Les personas sont définis selon le modèle en cinq facteurs (aussi appelé OCEAN), et ils ne fonctionnent pas dans le vide : chaque utilisateur possède son propre état et son propre ensemble d'outils disponibles, et ces états évoluent au fil du dialogue.
- Métrique de cohérence pass^k. Ce n'est pas simplement « combien de fois cela a fonctionné ». Elle s'accompagne d'une classification structurelle des défaillances, d'une attribution partielle de points pour un progrès incomplet mais significatif, et d'une double vérification du transfert de contrôle — c'est-à-dire que l'on vérifie séparément si l'agent a correctement transmis la main à l'humain ou à un autre système.
- Export de données pour l'affinage. Le simulateur peut exporter les exécutions accumulées, en écartant celles dont l'évaluation est faible, directement dans six formats adaptés au fine-tuning.
- Risk Analyser adversarial. Ce module prélève des empreintes des « crêtes » des états intermédiaires que l'agent doit traverser, puis ramifie les exécutions par la méthode de Monte-Carlo selon quatre types de perturbations liées à une tâche spécifique. Le risque final est calculé via le rapport ΔP / ΔT, la fusion des preuves selon Dempster—Shafer et l'attribution des catégories d'attaques selon Shapley.
Notez la logique : les trois premiers blocs concernent la mesure et l'apprentissage, le quatrième concerne la prédiction des défaillances. Le framework est conçu dès le départ comme un outil non seulement de diagnostic, mais aussi de test de résistance.
Trois exécutions : de l'analytique à l'attaque adversariale
La partie expérimentale se compose de trois parties avec différents degrés de « charge ».
- L'agent analytique conversationnel a été testé contre dix personas OCEAN. Pour l'annotation de la qualité, 240 évaluations de juges ont été recueillies.
- L'agent de support client a été vérifié sur cinq tâches, chacune en quatre variantes de persona.
- Le stress-test adversarial des mêmes cinq tâches : des perturbations y ont été ajoutées pour observer la vitesse à laquelle les trajectoires s'effondrent.
La troisième exécution s'est révélée la plus révélatrice. Déjà en l'absence de perturbations, la stabilité minimale de la trajectoire s'élevait à V_min = 0.375 — c'est-à-dire que même des conditions « pures » n'offrent aucune marge de sécurité. Et lorsque les attaques ont été activées, il s'est avéré que les coups les plus dangereux ne portent pas sur le contenu de la requête, mais sur les outils et l'infrastructure : l'attribution selon Shapley accorde environ 46% au niveau système, et environ 38% au niveau des actions.
C'est un déplacement important de l'accent. La discussion sur la sécurité des agents se réduit souvent aux injections de prompts dans le texte, alors que les chiffres indiquent que le risque principal réside dans la couche qui gère les appels aux outils et leur état.
Le caractère comme source de divergences
Le plus intéressant dans l'article n'est pas les évaluations absolues, mais la dispersion entre les personas. Sur une même tâche, le taux de réussite variait radicalement : 50% contre 100%. Ce n'est pas du bruit de mesure, mais un signal indiquant que l'agent gère différemment les différents styles de communication.
Les modes de défaillance que les tests unifiés ne montrent tout simplement pas sont énumérés séparément :
- les fuites inter-domaines — lorsqu'un contexte d'une tâche fuit dans une autre ;
- la dérive contextuelle — le décalage progressif du sujet et des objectifs au fil d'un long dialogue ;
- l'écart de qualité entre les personas de 0.27 point.
Les auteurs soulignent que le Risk Analyser sait mesurer la fragilité au niveau de la trajectoire — là où la métrique unique pass^k est impuissante, car elle ne fixe que le fait du succès ou de l'échec et ne distingue pas « a échoué dès la première étape » de « est allé presque jusqu'au bout, mais n'a pas maintenu l'état ».
En quoi cela est utile en pratique
Si l'on perçoit les conclusions comme une recette, elle se présente ainsi : testez l'agent non pas sur un utilisateur « moyen » unique, mais sur un ensemble de caractères, et regardez la dispersion entre eux, et non la moyenne. Le score moyen peut être tout à fait correct alors que la moitié des personas échoue systématiquement au scénario.
La deuxième couche pratique concerne les données. Puisque le simulateur sait marquer les exécutions réussies et échouées et les exporter dans des formats prêts à l'emploi, les personnalités deviennent non seulement une épreuve, mais aussi une source de matériel d'apprentissage. Le point faible ici est évident : la qualité d'un tel jeu de données dépend entièrement de la qualité de l'annotation, et les évaluations des juges sont la partie la plus coûteuse et la plus subjective du processus.
Enfin, la troisième couche concerne les priorités en matière de protection. Puisque la part principale du risque incombe au niveau système et aux actions, et non aux formulations, il faut renforcer en premier lieu les droits d'accès, la vérification des appels et la correction du transfert de contrôle, et non seulement les filtres sur le texte d'entrée.
Ce qu'il convient de garder à l'esprit
Il convient de garder à l'esprit l'échelle : il s'agit de trois ensembles d'expériences, dix personas dans l'un d'eux et cinq tâches dans les deux autres. Des chiffres comme 50% contre 100% paraissent dramatiques, mais reposent sur un petit échantillon — c'est plutôt une indication de direction qu'un verdict définitif. De plus, la simulation d'utilisateur selon les Big Five simplifie inévitablement le caractère réel : une personne vivante est incohérente, tandis qu'un persona dans le simulateur suit tout de même le profil défini.
Néanmoins, l'idée méthodologique semble solide et transposable. La fiabilité de l'agent n'est pas un seul nombre, mais une distribution par types d'interlocuteurs et par types de défaillances. Le simulateur AgentWorld fait le premier pas sérieux vers le fait que cette distribution puisse être mesurée, et non devinée.
La version v1 de l'article est apparue le 25 août 2026, la version actuelle v2 du 26 août 2026 (volume 1,710 KB) ; DOI — 10.48550/arXiv.2608.24076, thématique — cs.AI.
