Open Deep Wide Research: Eine Architektur für die Zusammenarbeit von Allzweck-Agenten zur umfangreichen Informationsbeschaffung

Abstract

Ein neuartiges KI-Forschungsparadigma automatisiert Aufgaben zur Informationsbeschaffung mit hoher Breite (wie z. B. horizontale Recherchen über Hunderte von Entitäten), indem jeder Benutzersitzung eine dedizierte virtuelle Cloud-Maschine zugewiesen wird, in der mehrere Allzweck-Agenten Teilaufgaben parallel ausführen. Diese Architektur stützt sich auf eine Turing-vollständige Ausführungsumgebung und einen rollenunabhängigen Mechanismus zur Zusammenarbeit mehrerer Agenten, was eine hohe Flexibilität bietet. Sie steht jedoch noch vor technischen Herausforderungen bei der Latenzkontrolle, der Ressourcenplanung und der Kostenvorhersehbarkeit.

Problemhintergrund

Herkömmliche Retrieval-Augmented Generation (RAG)-Systeme folgen typischerweise einem linearen Ablauf: Benutzereingabe → Abruf → Generierung. Obwohl dieses Design für punktuelle Frage-Antwort-Szenarien effektiv ist, stößt es bei Aufgaben, die eine mehrstufige Validierung, strukturierte Vergleiche oder die Erkundung zahlreicher heterogener Quellen erfordern (z. B. „Analysieren Sie die Karrierewege von Doktoranden der Informatikfakultäten der 50 besten Universitäten der Welt nach ihrem Abschluss“), an erhebliche Grenzen. Die Hauptengpässe sind:

• Mangelnde proaktive Erkundungs- und Aufgabenzerlegungsfähigkeiten in der Abrufphase.
• Unfähigkeit, während der Generierungsphase dynamisch zu planen oder zurückzuverfolgen.
• Der Gesamtprozess ist nicht unterbrechbar und nicht erweiterbar, was die Unterstützung langlaufender Aufgaben erschwert.

Um diese Einschränkungen zu überwinden, modelliert die neue Generation von Systemen umfangreiche Rechercheaufgaben als ein verteiltes Problem der Agenten-Kollaboration.

Methodenübersicht

Das Kerndesign besteht darin, jeder Benutzersitzung eine dedizierte virtuelle Cloud-Maschine (VM) zuzuweisen. Diese VM bietet ein vollständiges Betriebssystem, Netzwerkzugang und eine Ausführungsumgebung und bildet so eine Turing-vollständige Sandbox. Innerhalb dieser Sandbox startet das System dynamisch mehrere Sub-Agenten. Jeder ist eine voll funktionsfähige Allzweck-Instanz (anstatt eine vordefinierte Rolle wie „Rechercheur“ oder „Prüfer“ zu haben) mit den folgenden Fähigkeiten:

• Eigenständig HTTP-Anfragen initiieren oder externe APIs aufrufen.
• Skripte ausführen, um unstrukturierte Daten von Webseiten, PDFs, Tabellen usw. zu parsen.
• Integrierte Toolchains aufrufen (z. B. Headless-Browser, Dokumentenextraktoren).
• Zwischenergebnisse mit anderen Sub-Agenten austauschen.

Die Aufgabenzerlegung wird dynamisch von einem Haupt-Controller generiert. Um beispielsweise „das Ökosystem der generativen KI-Tools zu recherchieren“, könnte das System die Aufgabe automatisch wie folgt aufteilen:

1. Eine Liste von Tools von mehreren Plattformen (GitHub, Product Hunt, offizielle Aggregator-Seiten) abrufen.
2. Für jedes Tool gleichzeitig Dokumentation, Versionshistorie und Nutzerbewertungen scrapen.
3. Schlüsselmetriken extrahieren (z. B. Open-Source-Status, API-Unterstützung, Preismodell).
4. Entitäten abgleichen und eine strukturierte Vergleichstabelle ausgeben.

Da alle Sub-Agenten dieselbe Ausführungsumgebung teilen und über Allzweck-Fähigkeiten verfügen, ist die Aufgabenlogik nicht durch vordefinierte Rollen eingeschränkt, was die Generalisierungsfähigkeit erheblich verbessert.

Wichtige technische Details

1. Virtuelle Maschinen als Ausführungseinheiten

• Jede Sitzung nutzt exklusiv eine schlanke Linux-VM (möglicherweise basierend auf Mikro-Virtualisierungstechnologie wie Firecracker).
• Vorinstalliert mit gängigen Laufzeitumgebungen (Python, Node.js), Parsing-Bibliotheken (BeautifulSoup, PyPDF2) und Browser-Automatisierungstools.
• Der ausgehende Netzwerkverkehr wird über einen Proxy-Pool rotiert, um das Risiko zu verringern, von Anti-Scraping-Maßnahmen blockiert zu werden.
• Alle Operationen werden in einer isolierten Umgebung durchgeführt, was Sicherheit und Datengrenzen gewährleistet.

2. Multi-Agenten-Kommunikation und -Scheduling

• Sub-Agenten tauschen Daten über einen gemeinsamen Speicher oder einen leichtgewichtigen Message-Broker (wie Redis Pub/Sub) aus.
• Zwischenergebnisse werden in einem strukturierten Format (z. B. JSON oder JSON-LD) persistiert, um die spätere Aggregation und Validierung zu erleichtern.
• Der Haupt-Controller verwaltet einen Aufgabenabhängigkeitsgraphen (DAG), der dynamisches Scheduling, Wiederholungsversuche bei Fehlern und Ergebnis-Caching unterstützt.

3. Datenverarbeitungspipeline

Nehmen wir als Beispiel die „Analyse von Fortune-500-Unternehmen“:

• Entdeckungsphase: Suchmaschinen oder öffentliche Datenbanken aufrufen, um eine Liste von Unternehmen zu erhalten.
• Sammelphase: Jeder Sub-Agent ist für mehrere Unternehmen verantwortlich und scrapt offizielle Websites, PDF-Jahresberichte und Pressemitteilungen.
• Parsing-Phase: Regelbasiertes Matching, OCR oder multimodale Modelle verwenden, um Schlüsselfelder (z. B. Umsatz, Mitarbeiterzahl, CEO) zu extrahieren.
• Abgleichphase: Eine Entitätsauflösung basierend auf einem eindeutigen Bezeichner (wie einem Börsenkürzel) durchführen, um eine standardisierte Wissenstabelle zu erstellen.

Dieser Prozess ist sehr E/A-intensiv und stellt hohe Anforderungen an die parallelen Verarbeitungskapazitäten und die Netzwerkbandbreite der VM.

Einschränkungen und Skalierbarkeitsherausforderungen

Aktuelle Einschränkungen

• Unkontrollierbare Antwortzeit: Die Fertigstellungszeit einer Aufgabe wird durch die langsamste Teilaufgabe bestimmt, ohne einen Mechanismus für Timeouts, Circuit Breaking oder die Rückgabe von Teilergebnissen.
• Intransparente Ressourcenkosten: Es wird kein Ressourcenverbrauchsmodell basierend auf dem Aufgabenmaßstab bereitgestellt, was es für Benutzer schwierig macht, Ausgaben vorherzusagen.
• Skalierungsengpass auf einem einzelnen Knoten: Alle Sub-Agenten laufen auf derselben VM, und die Konkurrenz um CPU/Speicher kann zu Leistungsschwankungen führen.
• Starke Abhängigkeit vom öffentlichen Internet: Kann nicht direkt auf private Wissensdatenbanken oder interne Datenquellen zugreifen.

Herausforderungen bei der großflächigen Bereitstellung

• Kaltstartlatenz: Die Erstellung und Initialisierung der VM dauert typischerweise mehrere Sekunden bis zu einer zweistelligen Sekundenzahl, was die Benutzererfahrung beeinträchtigt.
• Overhead beim parallelen Scheduling: Wenn eine große Anzahl von Teilaufgaben gleichzeitig ausgeführt wird, können Prozessverwaltung und Kommunikation zu Engpässen werden.
• Speicherkosten: Wenn Zwischenergebnisse nicht zeitnah bereinigt werden, sammelt sich eine große Menge an temporären Daten an.
• Sicherheit und Compliance: Eine Sandbox, die dynamisch beliebigen Code ausführt, erfordert eine strenge Überprüfung, insbesondere in Unternehmensumgebungen.

Verbesserungsansätze

• Steuerungsparameter für Tiefe und Breite einführen: Benutzern erlauben, die maximale Parallelität (Breite) und die Anzahl der Schlussfolgerungsschritte (Tiefe) explizit zu begrenzen.
• Eine geschichtete Ausführungsstrategie anwenden: Hochwertige Teilaufgaben priorisieren, während Aufgaben mit niedriger Priorität herabgestuft oder übersprungen werden können.
• Hybriden Zugriff auf Datenquellen unterstützen: Öffentliches Web-Scraping mit dem Abruf aus privaten Vektordatenbanken kombinieren.
• Eine API zur Kostenschätzung bereitstellen: Den Ressourcenverbrauch für die aktuelle Konfiguration basierend auf historischen Aufgabenstatistiken vorhersagen.

Wenn Sie nach einer produktionsreifen, selbst hostbaren Agentic RAG-Lösung mit feingranularer Steuerung suchen, bietet puppyone einen sofort einsatzbereiten Implementierungspfad. Aufbauend auf dem MCP-Protokoll unterstützt puppyone die dynamische Anpassung von Tiefe und Breite, den Wechsel zwischen verschiedenen Modell-Backends und die nahtlose Integration mit privaten Wissensdatenbanken. Dadurch eignet es sich für eine Vielzahl von Szenarien, von Frage-Antwort-Systemen im Kundenservice bis hin zu intelligenten Analysen auf Unternehmensebene. Besuchen Sie https://www.puppyone.ai/, um zu erfahren, wie Sie in wenigen Minuten Ihren eigenen steuerbaren Recherche-Agenten bereitstellen können.

FAQ

F1: Was ist der grundlegende Unterschied zwischen dieser Architektur und traditionellen Multi-Agenten-Systemen?
A: Traditionelle Systeme basieren auf vordefinierten Rollen (z. B. „Planer“, „Ausführer“), während in dieser Architektur alle Sub-Agenten Allzweck-Instanzen sind, die autonom über ihre Vorgehensweise entscheiden können. Dies macht die Aufgabenstruktur flexibler und verbessert die Generalisierungsfähigkeiten.

F2: Kann ein ähnliches System on-premises oder in einer privaten Cloud bereitgestellt werden?
A: Ja, aber Sie müssten sich selbst um das Virtualisierungs-Scheduling, das Netzwerk-Proxying, die Sandbox-Sicherheit und die Aufgabenkoordination kümmern. Eine leichtgewichtige Alternative ist die Verwendung von Containern (wie Docker) anstelle von vollständigen VMs und die Implementierung der Agentenkommunikation über eine Message-Queue.

F3: Was sind die Hauptleistungsengpässe in Szenarien mit hoher Parallelität?
A: Die Hauptengpässe sind die Kaltstartlatenz der VM, der Durchsatz des Teilaufgaben-Schedulers und der Serialisierungs-Overhead der Inter-Agenten-Kommunikation. Zu den Optimierungstechniken gehören die Verwendung eines vorgewärmten Pools, asynchrone Aufgabenwarteschlangen und das Caching/Wiederverwenden von Zwischenergebnissen.