Open Deep Wide Research : une architecture de collaboration d'agents polyvalente pour la collecte d'informations à grande échelle

Résumé

Un nouveau paradigme de recherche en IA automatise les tâches de collecte d'informations de grande envergure (telles que la recherche horizontale sur des centaines d'entités) en attribuant une machine virtuelle cloud dédiée à chaque session utilisateur, au sein de laquelle plusieurs agents polyvalents exécutent des sous-tâches en parallèle. Cette architecture repose sur un environnement d'exécution Turing-complet et un mécanisme de collaboration multi-agents agnostique des rôles, offrant une grande flexibilité. Cependant, elle fait encore face à des défis d'ingénierie en matière de contrôle de la latence, de planification des ressources et de prévisibilité des coûts.

Contexte du problème

Les systèmes traditionnels de génération augmentée par la récupération (RAG) suivent généralement un flux linéaire : Entrée utilisateur → Récupération → Génération. Bien que cette conception soit efficace pour les questions-réponses ponctuelles, elle est considérablement limitée face à des tâches nécessitant une validation en plusieurs tours, une comparaison structurée ou une exploration de nombreuses sources hétérogènes (par ex., « Analysez les parcours professionnels post-doctorat des diplômés des départements d'informatique des 50 meilleures universités du monde »). Les principaux goulots d'étranglement sont les suivants :

• Manque de capacités d'exploration proactive et de décomposition des tâches dans la phase de récupération.
• Incapacité à planifier ou à revenir en arrière de manière dynamique pendant la phase de génération.
• Le processus global est non interruptible et non extensible, ce qui rend difficile la prise en charge des tâches de longue durée.

Pour surmonter ces limitations, la nouvelle génération de systèmes modélise les tâches de recherche à grande échelle comme un problème de collaboration d'agents distribués.

Aperçu de la méthode

La conception principale consiste à attribuer une machine virtuelle (VM) cloud dédiée à chaque session utilisateur. Cette VM fournit un système d'exploitation complet, un accès réseau et un environnement d'exécution, formant un bac à sable (sandbox) Turing-complet. Au sein de ce bac à sable, le système lance dynamiquement plusieurs sous-agents. Chacun est une instance entièrement fonctionnelle et polyvalente (plutôt que d'avoir un rôle prédéfini comme « Chercheur » ou « Valideur ») avec les capacités suivantes :

• Lancer indépendamment des requêtes HTTP ou appeler des API externes.
• Exécuter des scripts pour analyser (parser) des données non structurées à partir de pages web, de PDF, de tableaux, etc.
• Appeler des chaînes d'outils intégrées (par ex., navigateurs sans tête, extracteurs de documents).
• Échanger des résultats intermédiaires avec d'autres sous-agents.

La décomposition des tâches est générée dynamiquement par un contrôleur principal. Par exemple, pour « étudier l'écosystème des outils d'IA générative », le système pourrait le décomposer automatiquement en :

1. Obtenir une liste d'outils à partir de plusieurs plateformes (GitHub, Product Hunt, pages d'agrégateurs officielles).
2. Pour chaque outil, récupérer (scraper) simultanément la documentation, l'historique des versions et les avis des utilisateurs.
3. Extraire les métriques clés (par ex., statut open-source, prise en charge des API, modèle de tarification).
4. Aligner les entités et produire un tableau de comparaison structuré.

Comme tous les sous-agents partagent le même environnement d'exécution et possèdent des capacités polyvalentes, la logique des tâches n'est pas contrainte par des rôles prédéfinis, ce qui améliore considérablement la généralisation.

Principaux détails techniques

1. Machines virtuelles comme unités d'exécution

• Chaque session utilise exclusivement une VM Linux légère (potentiellement basée sur une technologie de micro-virtualisation comme Firecracker).
• Préinstallée avec des environnements d'exécution (runtimes) courants (Python, Node.js), des bibliothèques d'analyse (BeautifulSoup, PyPDF2) et des outils d'automatisation de navigateur.
• Le trafic réseau sortant est routé à travers un pool de proxys pour réduire le risque d'être bloqué par des mesures anti-scraping.
• Toutes les opérations sont effectuées dans un environnement isolé, garantissant la sécurité et la séparation des données.

2. Communication et ordonnancement multi-agents

• Les sous-agents échangent des données via une mémoire partagée ou un courtier de messages léger (comme Redis Pub/Sub).
• Les résultats intermédiaires sont persistés dans un format structuré (par ex., JSON ou JSON-LD) pour faciliter l'agrégation et la validation ultérieures.
• Le contrôleur principal maintient un graphe de dépendances de tâches (DAG), prenant en charge l'ordonnancement dynamique, les nouvelles tentatives en cas d'échec et la mise en cache des résultats.

3. Pipeline de traitement des données

Prenons l'exemple de l'« analyse des entreprises du Fortune 500 » :

• Phase de découverte : Appeler des moteurs de recherche ou des bases de données publiques pour obtenir une liste d'entreprises.
• Phase de collecte : Chaque sous-agent est responsable de plusieurs entreprises, récupérant les sites web officiels, les rapports annuels en PDF et les communiqués de presse.
• Phase d'analyse (parsing) : Utiliser la correspondance à base de règles, l'OCR ou des modèles multimodaux pour extraire les champs clés (par ex., chiffre d'affaires, nombre d'employés, PDG).
• Phase d'alignement : Effectuer une résolution d'entité basée sur un identifiant unifié (comme un symbole boursier) pour construire un tableau de connaissances standardisé.

Ce processus est très intensif en E/S (I/O), ce qui impose des exigences élevées aux capacités de traitement concurrent de la VM et à la bande passante réseau.

Limitations et défis de la mise à l'échelle

Limitations actuelles

• Temps de réponse non maîtrisable : Le temps d'achèvement de la tâche est déterminé by la sous-tâche la plus lente, sans mécanisme de timeout, de disjoncteur (circuit breaker) ou de retour de résultats partiels.
• Coûts en ressources non transparents : Aucun modèle de consommation de ressources n'est fourni en fonction de l'échelle de la tâche, ce qui rend difficile pour les utilisateurs de prédire les dépenses.
• Goulot d'étranglement de la mise à l'échelle sur un seul nœud : Tous les sous-agents s'exécutent sur la même VM, et la contention pour le CPU/la mémoire peut entraîner une instabilité des performances.
• Forte dépendance à l'Internet public : Ne peut pas accéder directement aux bases de connaissances privées ou aux sources de données internes.

Défis du déploiement à grande échelle

• Latence de démarrage à froid (cold-start) : La création et l'initialisation de la VM prennent généralement de plusieurs à plusieurs dizaines de secondes, ce qui affecte l'expérience utilisateur.
• Surcharge de l'ordonnancement concurrent : Lorsqu'un grand nombre de sous-tâches s'exécutent simultanément, la gestion des processus et la communication peuvent devenir des goulots d'étranglement.
• Coûts de stockage : Si les résultats intermédiaires ne sont pas nettoyés rapidement, une grande quantité de données temporaires s'accumulera.
• Sécurité et conformité : Un bac à sable qui exécute dynamiquement du code arbitraire nécessite un audit strict, en particulier dans les environnements d'entreprise.

Pistes d'amélioration

• Introduire des paramètres de contrôle de la profondeur et de la largeur : Permettre aux utilisateurs de limiter explicitement le parallélisme maximal (largeur) et le nombre d'étapes de raisonnement (profondeur).
• Adopter une stratégie d'exécution par couches : Donner la priorité aux sous-tâches à forte valeur, tandis que les tâches à faible priorité peuvent être déclassées ou ignorées.
• Prendre en charge l'accès aux sources de données hybrides : Combiner le scraping web public avec la récupération depuis une base de données vectorielle privée.
• Fournir une API d'estimation des coûts : Prédire la consommation de ressources pour la configuration actuelle en se basant sur les statistiques des tâches historiques.

Si vous recherchez une solution RAG agentique prête pour la production, auto-hébergeable et avec un contrôle granulaire, puppyone offre une voie d'implémentation prête à l'emploi. Basé sur le protocole MCP, puppyone prend en charge l'ajustement dynamique de la profondeur et de la largeur, la commutation entre plusieurs backends de modèles et l'intégration transparente avec les bases de connaissances privées, ce qui le rend adapté à une variété de scénarios, des questions-réponses du service client à l'analyse intelligente au niveau de l'entreprise. Visitez https://www.puppyone.ai/ pour apprendre à déployer votre propre agent de recherche contrôlable en quelques minutes.

FAQ

Q1 : Quelle est la différence fondamentale entre cette architecture et les systèmes multi-agents traditionnels ?
R : Les systèmes traditionnels reposent sur des rôles prédéfinis (par ex., « Planificateur », « Exécuteur »), tandis que dans cette architecture, tous les sous-agents sont des instances polyvalentes qui peuvent décider de manière autonome de leur plan d'action. Cela rend la structure des tâches plus flexible et améliore les capacités de généralisation.

Q2 : Un système similaire peut-il être déployé sur site (on-premises) ou dans un cloud privé ?
R : Oui, mais vous devriez gérer vous-même l'ordonnancement de la virtualisation, la gestion des proxys réseau, la sécurité du bac à sable et la coordination des tâches. Une alternative plus légère consiste à utiliser des conteneurs (comme Docker) au lieu de VM complètes et à implémenter la communication entre agents via une file d'attente de messages.

Q3 : Quels sont les principaux goulots d'étranglement en matière de performance dans les scénarios à haute concurrence ?
R : Les principaux goulots d'étranglement incluent la latence de démarrage à froid des VM, le débit de l'ordonnanceur de sous-tâches et la surcharge de sérialisation de la communication inter-agents. Les techniques d'optimisation comprennent l'utilisation d'un pool pré-chauffé, des files d'attente de tâches asynchrones et la mise en cache/réutilisation des résultats intermédiaires.