Systèmes multi-agents : un potentiel qui s'effrite à mesure qu'ils passent à l'échelle
La promesse des systèmes multi-agents basés sur de grands modèles de langage semble séduisante : plusieurs agents LLM peuvent se partager une vaste tâche, se consulter mutuellement et trouver ensemble une solution. Cependant, la pratique révèle un effet inverse : plus le nombre d'agents collaborant augmente, moins le système devient stable. Intuitivement, on pourrait penser que le problème vient de la coordination, mais un groupe de chercheurs, dans un article de position sur arXiv, propose d'examiner la situation plus en profondeur.
La racine de nombreuses défaillances réside dans la manière dont les agents accèdent à l'état partagé. Chacun d'eux lit et écrit des données dans un stockage commun — notes, résultats, versions des faits. Lorsque le nombre d'accès augmente, des courses de données classiques apparaissent. S'il s'agissait d'un programme multithread ordinaire, les ingénieurs suspecteraient immédiatement des problèmes de synchronisation. Mais comme les participants du système semblent « intelligents », leurs erreurs sont souvent attribuées à des malentendus, alors qu'en réalité, ce comportement est typique d'un accès parallèle à des ressources partagées.
De longues « réflexions » — deux fois plus dangereuses
La particularité des agents LLM ajoute une complexité supplémentaire. Le processus d'inférence du modèle prend un temps considérable, et pendant tout ce temps, l'agent travaille avec l'instantané de l'état qu'il a vu au moment de sa requête. Pendant que le modèle « réfléchit », les autres agents ne restent pas inactifs : ils mettent à jour les données communes. En revenant avec une solution prête, l'agent peut s'appuyer sur une vision obsolète du monde.
Avec l'augmentation du nombre d'agents, ces longues fenêtres de réflexion se multiplient, et avec elles, la probabilité de diverses anomalies augmente. Un agent ne remarque pas qu'une sous-tâche a déjà été accomplie par un collègue et commence à dupliquer le travail. Deux agents tentent d'écrire le résultat final, et la dernière écriture écrase la précédente sans aucun avertissement. Quelqu'un lit des données au moment où un autre n'a pas encore fini de les mettre à jour et obtient une version intermédiaire incohérente. Tout cela semble chaotique, mais obéit en réalité à des schémas bien connus de la théorie des bases de données — lectures obsolètes, mises à jour perdues et violation de l'intégrité de l'état.
Les pannes de communication ne sont aussi qu'une conséquence
Pourquoi est-il si facile de se tromper de diagnostic ? Prenons la violation de la coordination. Les agents ont clairement réparti les rôles et, semble-t-il, coordonné leurs actions. Mais si la base de faits commune change constamment, un agent peut agir en se basant sur un état qu'un collègue a déjà réécrit. De l'extérieur, cela ressemble à une incohérence des plans ou à une mauvaise compréhension des instructions. Cependant, la cause première n'est pas une coordination faible, mais l'absence de contrôle sur l'accès simultané aux données.
Il en va de même pour la communication. Le message lui-même peut être parfaitement formulé et livré à temps. Mais si, au moment où le destinataire commence à le traiter, les données communes ont déjà été modifiées, le sens du message est faussé. De telles pannes sont extrêmement difficiles à reproduire : elles dépendent d'un minutage précis. Tant que les agents sont peu nombreux, le problème se manifeste à peine, mais lors du passage à l'échelle, le nombre d'opérations qui se chevauchent augmente, et les erreurs commencent à apparaître avec une régularité inquiétante.
Le contrôle de la concurrence — comme fondement, et non comme rustine
La solution proposée par les chercheurs consiste à transposer des approches éprouvées du monde des bases de données dans l'architecture des systèmes multi-agents. Au lieu de compter sur le fait que les LLM « s'arrangent » d'une manière ou d'une autre, la plateforme doit gérer explicitement l'accès concurrent. Concrètement, cela signifie trois axes de travail :
- Détection des conflits. Le système surveille les tentatives simultanées des agents de modifier les mêmes données et prévient la collision avant qu'elle n'entraîne une corruption du résultat.
- Garanties d'isolation. Chaque agent doit travailler avec un instantané cohérent de l'état ou disposer de mécanismes empêchant la lecture d'écritures non terminées.
- Accès structuré aux ressources. Au lieu d'accès directs au contexte commun, des interfaces explicites sont utilisées : verrous, versions d'opérations, files d'attente d'écriture ou mises à jour atomiques.
Les auteurs soulignent que le contrôle de la concurrence ne peut pas être ajouté après coup, lorsque le système a déjà commencé à montrer des signes de défaillance. Cela doit être une décision architecturale de niveau « deuxième étage », sur laquelle repose toute la conception ultérieure. Si l'on réfléchit d'abord aux règles de gestion de l'état partagé, puis que l'on construit la coordination des agents par-dessus, de nombreux problèmes de fiabilité n'auront tout simplement pas le temps de survenir.
Conclusions
Les systèmes multi-agents basés sur les LLM possèdent un potentiel énorme, mais leur vulnérabilité n'est pas liée à la faiblesse des modèles individuels, mais au fait que nous essayons de faire travailler plusieurs exécutants parallèles sur un même état changeant sans mécanismes de protection élémentaires. En reconnaissant dans les courses de données la principale source de défaillances, les développeurs ont la possibilité d'appliquer des solutions connues depuis longtemps — l'isolation, la détection des conflits et l'ordonnancement des accès. C'est peut-être moins spectaculaire que d'améliorer les prompts, mais c'est précisément cette approche qui permet à un système multi-agents de rester fiable à mesure que le nombre de participants augmente.
