« More agents is all you need. »

En octobre 2024, le labo IA de Tencent avait publié un article ainsi intitulé. Il y présentait une méthode permettant d’accroître la performance d’un LLM en augmentant le nombre d’agents instanciés.

La technique, dite « forêt d’agents », est simple dans son principe : envoyer une requête à plusieurs agents (instances d’un LLM) et les faire voter à la majorité sur les outputs.

Google Research y fait référence dans un autre article… qui en prend partiellement le contrepied. Il y propose des principes de mise à l’échelle des systèmes agentiques.

3 familles de LLM, 4 benchmarks, 5 architectures

Ces principes découlent de l’analyse de 180 configurations. En l’occurrence, 5 architectures agentiques appliquées à 3 familles de modèles et testées sur 4 benchmarks.

Les architectures en question :

• Mono-agent
• Agents indépendants (aucune communication entre eux)
• Centralisé (plusieurs agents, chacun communiquant avec un orchestrateur)
• Décentralisé (communication entre pairs)
• Hybride (orchestrateur + P2P limité)

L’orchestrateur détermine la manière dont sont agrégés les outputs des agents et s’il a le droit de passer outre. Il gère aussi la mémoire.

Ces architectures ont été appliquées à des modèles d’Anthropic (Claude Sonnet 3.7, 4.0 et 4.5), de Google (Gemini 2.0 Flash, 2.5 Flash et 2.5 Pro) et d’OpenAI (GPT-5, 5 mini et 5 nano).

Les benchmarks étaient les suivants :

• Finance Agent (2025 ; analyse financière sur dépôts SEC)
• BrowseComp-Plus (2025 ; « recherche approfondie » sur le web)
• Plancraft (2024 ; planification en environnement Minecraft)
• WorkBench (2024 ; exécution de tâches en environnement de bureau)

Les tests se sont faits à paramètres fixes (outils, prompts, budgets de calcul). En sont ressorties 8 métriques, le taux de réussite étant la principale.

À partir de ces métriques, ainsi que de trois autres indicateurs (propriétés des tâches, nombre d’agents, capacités de modèles de base), Google Research a élaboré un modèle prédictif. Son rôle : identifier l’architecture optimale pour une tâche donnée.

Ce n’est pas (vraiment) le nombre qui compte

Là semble effectivement résider le véritable enjeu. Si on en croit les résultats communiqués, ce n’est pas tant le nombre d’agents qui importe que l’adéquation entre la tâche et l’architecture agentique.

La complexité des tâches joue moins que la capacité à les décomposer. Les résultats sur Finance Agent et Plancraft en témoignent.

Fait d’informations statiques et structurées, Finance Agent se prête à une division du travail. Toutes les architectures multi-agents apportent effectivement un gain important par rapport au mono-agent.

Plancraft est, au contraire, intrinsèquement séquentiel (chaque action modifie potentiellement l’environnement). Le multi-agent y est systématiquement moins efficace que le mono-agent. Diviser le travail implique que chaque agent synchronise l’état du système. Dans un tel environnement dynamique, cela impacte significativement le budget de calcul disponible. Les agents compressent alors d’autant plus les informations qu’ils (se) transmettent, au risque de perdre de l’information.

Sur WorkBench, la différence est plus marginale. Idem sur BrowserComp-Plus, où l’approche décentralisée, adaptée à l’exploration parallèle de pages web (espaces de recherche à forte entropie), affiche le meilleur score de précision.

Google perçoit un modèle généralisable

La surcharge liée à la coordination des agents pèse démesurément sur les tâches qui impliquent beaucoup d’outils. L’étude ne révèle pas, en revanche, de corrélation entre l’augmentation de cette surcharge et celle de la complexité des tâches. À performance équivalente, le multi-agent consomme bien plus de tokens que le mono-agent (+ 58 % en mode « indépendant », + 263 % en décentralisé, + 285 % en centralisé, + 515 % en hybride.

Dès qu’un agent seul dépasse les 45 % de taux de réussite, en ajouter a des effets négatifs. Quant à la redondance des tâches (en confier une à plusieurs agents), elle n’a, à l’échelle, qu’un bénéfice marginal.

La présence ou l’absence de points de validation engendre une grande différence dans l’amplification des erreurs. En centralisé, elles sont multipliées par 4,4 par rapport au mono-agent ; en décentralisé, par 7,8 ; en hybride, par 5,1 ; en indépendant, par 17,2.

Les architectures centralisée et décentralisée tendent à réduire le taux moyen d’erreurs par rapport au mono-agent. Notamment pour ce qui est de l’omission de contexte. Et, dans une moindre mesure, les contradictions de logique. C’est n’est pas toujours le cas pour les architectures hybrides, avec lesquels ce taux s’accroît même parfois. En particulier sur les dérives numériques (découlant d’arrondis ou de mauvaises conversions en cascade).

La hiérarchie des architectures est relativement stable entre domaines. Google Research y voit la preuve que son modèle est généralisable. Sur labase de ses expérimentations, il affirme qu’à budget constant, au-delà de 3 ou 4 agents, la qualité de raisonnement de chacun se dégrade.

Illustration principale générée par IA

The post « More agents is all you need »… ou pas : une esquisse de lois d’échelle pour l’IA agentique appeared first on Silicon.fr.

Tous les clients ARTESCA bénéficient désormais d’une « garantie cyber » de 100 000 $.

Jérôme Lecat, président-fondateur de Scality, présente les choses ainsi, en anglais dans le texte.

En pratique, cette garantie ne s’applique pas à tous les clients. Elle concerne les titulaires de licences commerciales – matérielles, perpétuelles ou à durée indéterminée – d’une capacité de stockage d’au moins 50 To.

Scality s’engage à verser les 100 000 $ en question (ou l’équivalent dans d’autres devises) si survient un « incident cybernétique admissible ». En l’occurrence, « le cryptage ou la suppression démontrable de données résidant sur un volume de stockage géré par le logiciel, conséquence directe et unique d’une cyberattaque externe non autorisée ».

Les exfiltrations de données sont exclues. L’incident ne doit par ailleurs pas découler, en tout ou partie :

• De la compromission des identifiants d’accès stockés, transmis ou gérés en dehors du logiciel
• D’identifiants d’accès obtenus par des tiers via l’ingénierie sociale, le phishing, des logiciels malveillants ou le vol
• Des actes malveillants et répréhensibles commis par des utilisateurs autorisés
• D’une des responsabilités d’indemnisation du client

Coopération, maintenance, conformité…

Pour prétendre à une indemnisation, il faut utiliser la dernière version majeure d’ARTESCA (actuellement, la 4.1), « en stricte conformité avec la documentation […] et les directives de sécurité ». Et avoir installé l’ensemble des mises à jour / mises à niveau (dernière release en date : 4.1.3) et des correctifs dans les 30 jours suivant leur mise à disposition.

Quant aux données, elles doivent avoir été stockées dans des compartiments avec Object Lock (immuabilité) activé en mode conformité (aucun utilisateur, y compris root, ne peut les modifier ou les supprimer). Et être, au moment de l’incident, dans une période de conservation active.

La garantie constitue une pénalité forfaitaire unique. Son paiement est le seul recours en cas d’incident admissible (le client ne peut réclamer aucun autre dommage). Il n’interviendra qu’à condition que le client ait notifié l’incident par écrit dans les 48 heures suivant sa découverte. Et qu’il ait par la suite « coopéré pleinement » en fournissant les informations et les accès demandés.

Illustration générée par IA

The post Comment fonctionne la nouvelle « garantie ransomware » de Scality appeared first on Silicon.fr.