Les agents IA et le paradoxe du choix

En 2000, le psychologue Barry Schwartz a écrit un livre intitulé "The paradox of Choice", livre dans lequel il explique que contre intuitivement, plus de choix ne mène pas à la liberté, mais au contraire à l'aliénation.

Son ouvrage est en lien avec une expérience sociale assez connue. Dans un supermarché, des chercheurs installent un stand de pots de confiture. Un jour, le stand propose 24 parfums. Un autre jour, il n'en propose que 6. Les résultats ont conclu que c'est le jour où il y avait moins de parfums disponibles que les ventes ont été les plus élevées (significativement).

Ce que ces études montrent, c'est que face à un trop grand choix, le cerveau se bloque et se retrouve incapable de choisir. Peur de se tromper, envie d'un choix encore meilleur (puisqu'il y a 24 parfums disponibles, peut-être que c'est le 25e qui sera le meilleur). Au final, soit aucun choix n'est fait, soit il est regretté immédiatement, et ces situations sont vécues comme très stressantes par le cerveau, pouvant même conduire à des crises d'angoisse.

Le paradoxe du choix appliqué à l'IA

25 ans plus tard, nous utilisons l'IA avec des modèles LLM de plus en plus puissants, des capacités de plus en plus grandes, et des cas d'usage toujours plus exigeants. On voudrait que nos agents puissent tout faire, et en même temps, on a à notre disposition pléthore de Tools et d'API. Comme si ce n'était pas suffisant, on a désormais le fameux protocole MCP qui doit rendre la connexion entre un agent et un Tool encore plus facile.

Il est donc normal et tentant de se dire que puisqu'un agent est capable de tout faire, alors autant lui donner toutes les capacités possibles. Pourquoi ne pas lui brancher 100 Tools, ou même mieux 1000 Tools ? C'est évidemment ce qui a été fait, et les résultats sont... intéressants.

Avec une quantité importante de Tools (plus de 10) branchés sur un agent, au niveau macroscopique, ce qui est observé, c'est une dégradation de la précision de l'agent, des contraintes à gérer sur l'utilisation de certains LLM, et surtout une explosion des coûts d'infrastructure.

Au niveau microscopique, l'agent a à sa disposition 10 Tools. Chaque Tool a sa description et son scope fonctionnel. L'orchestrateur présente donc au LLM les 10 Tools en utilisant le contexte. Le LLM est bien "embêté", ne sachant lequel choisir. Il va donc utiliser celui qui a priori répond le mieux au besoin. Le Tool est appelé, et la réponse est renvoyée avec toute le contexte. Cette dernière n'étant pas satisfaisante, un autre Tool va être utilisé, et ainsi de suite jusqu'à affiner la réponse qui permettra à l'agent d'accomplir sa mission (et au fur et à mesure, augmenter le contexte avec tous les échanges des précédents tours de LLM).

Le résultat obtenu est le suivant :

un workflow de l'agent qui devient très compliqué (trop compliqué) ;
une dégradation significative de la précision des actions qui sont prises et des réponses qui sont renvoyées ;
une latence accrue, avec des temps de traitement de la demande qui empêchent un passage à l'échelle ;
un contexte de plus en plus gros, qui contraint à utiliser d'autres modèles, plus récents, plus gros et accessoirement plus chers ;
un coût d'utilisation qui explose car un grand contexte revient à avoir beaucoup de tokens consommés en input du LLM. Comme les tarifications des LLM (en SaaS du moins) sont exprimées en dollars par million de tokens, plus on sollicite un LLM, plus la facture sera élevée. De plus, on se trouve contraint d'utiliser des modèles permettant de prendre en entrée de gros contextes, et souvent ils sont plus chers. Pour information, OpenAI-o3 par exemple coûte 10$/million de tokens. Ne sous-estimez pas la facilité avec laquelle on peut remplir un contexte avec 1M tokens.

Combien de Tools par agent IA ? Les règles à appliquer

Ce qu'on constate au niveau de l'agent, c'est qu'il est victime de ce que l'on appelle le paradoxe du choix. Si ses capacités sont trop élevées, comme un humain, il se trouve paralysé et ne "sait" plus quelle option choisir. Un humain va hésiter, et sans doute ne rien choisir de peur de se tromper, alors que le LLM va se résoudre à demander à l'orchestrateur de tester les Tools (car quel que soit le scénario, un LLM doit toujours répondre...).

Le paradoxe du choix est un problème réel et difficile à éviter car contre-intuitif. Voyant que les LLM peuvent faire toujours plus, beaucoup y voient à tort une opportunité de se simplifier la vie en jetant tous leurs œufs dans le même panier, pensant (aussi à tort) que le LLM saura démêler le vrai du faux.

Pour rester concis, voici les règles que je m'applique lorsque je mets en place un agent :

Entre 1 et 3 Tools : c'est OK ;
Entre 4 et 6 Tools : ça se tend, et il faut s'attendre à une baisse de la précision de l'agent. Il est donc important de monitorer le workflow des agents qui tournent avec des outils comme LangFuse pour mesurer l'impact sur la performance ;
Au delà de 6 Tools : red flag, c'est la conception même du système agentique qu'il faut revoir.

Un changement de paradigme : des agents aux systèmes multi-agents

Dire qu'il ne faut pas utiliser plus de 3 Tools en même temps, c'est bien, mais il existe tout de même des cas d'usage exigeant de plus grandes capacités. C'est ici qu'il faut changer de paradigme.

Plutôt que de considérer un agent qui peut tout faire, pourquoi ne pas considérer une équipe d'agents, chacun ayant sa spécialité. C'est bien comme cela que nous nous organisons au quotidien, non ? Dans un projet IA on a un ingénieur, un PO, un scrum master, un data scientist, un devops, etc. Chaque membre de l'équipe joue un rôle et a une spécialité. Pourquoi n'en serait-il pas de même pour les agents ?

Une façon intuitive de gérer le paradoxe du choix est de considérer un système multi-agents, et donner à chacun d'entre eux un rôle précis, avec des capacités qui le représentent.

Par exemple, on peut imaginer un agent "knowledge", qui sera capable de récupérer de l'information dans JIRA et dans Confluence. Un autre agent "developer" quant à lui pourra générer du code, se connecter à Git. Enfin, un troisième agent "devops" aura accès à Git et à l'infrastructure Cloud. En utilisant ces 3 agents ensemble, on a alors un système multi-agent qui sait gérer de bout en bout (ou presque) la chaîne de production d'un programme : assistant de code, écriture des tests, rédaction de la documentation, revue de code, CICD, déploiement, mise à jour des tickets.

Les systèmes multi-agents permettent de s'affranchir de cette barrière que représente le paradoxe du choix. Evidemment, les systèmes multi-agents sont plus complexes à mettre en place qu'un agent seul sur lequel on aurait branché plein de Tools. Des frameworks comme CrewAI, Google ADK permettent néanmoins de construire relativement simplement et rapidement des architectures multi-agents.

Les LLM, un peu trop à l'image de l'Homme ?

Il reste tout de même fascinant de constater autant de similarités entre le fonctionnement d'un LLM et celui d'un cerveau humain (toutes proportions gardées). Comprenez bien que le paradoxe du choix n'a pas été encodé dans le LLM, c'est un effet qui a émergé de l'utilisation de ce dernier avec des Tools. Je ne vois pas non plus de relation de cause à effet avec l'entraînement du modèle, ni même les données qui ont servi à son entrainement.

Le paradoxe du choix serait alors un phénomène émergent de la construction d'un LLM, avec les mêmes effets que ceux observés sur un cerveau humain. En outre, les LLM sont construits sur des architectures de réseaux de neurones, et la notion même de "réseau de neurones" a été inspirée aux scientifiques par le fonctionnement du cerveau humain.

Il se dit que l'Homme aurait créé la machine à son image. Du coup, peut-on imaginer que le paradoxe du choix soit un signe que la réalité est en train de rattraper la fiction ?