Klassische RAG-Systeme stossen an ihre Grenzen, wenn Abfragen mehrere Datenmodalitaeten gleichzeitig erfordern. Ein Finanzanalyst, der fragt "Warum performen unsere europaeischen Operationen schlechter?", braucht sowohl SQL-Ergebnisse aus strukturierten Datenbanken als auch Kontext aus unstrukturierten Dokumenten wie Quartalsberichten oder internen Analysen. Standard-RAG bedient jeweils nur eine Modalitaet und liefert damit unvollstaendige oder halluzinierte Antworten. InfoQ beschreibt eine hierarchische Agentenarchitektur, die dieses Problem durch Aufgabenteilung und autonome Fehlerkorrektur adressiert.
Kernarchitektur: Supervisor-Worker-Topologie
Das System folgt einem Supervisor-Worker-Muster, das die sogenannte "Modality Gap" schliesst:
- Supervisor-Agent: Nimmt die urspruengliche Abfrage entgegen, zerlegt sie in spezialisierte Teilaufgaben und orchestriert die Ausfuehrung. Er entscheidet, welche Worker-Agenten aktiviert werden und fuegt die Teilergebnisse zu einer kohaerenten Antwort zusammen.
- SQL-Agenten: Spezialisiert auf strukturierte Datenquellen. Sie generieren Abfragen gegen relationale Datenbanken, kennen das Schema und validieren Ergebnisse.
- Vektor-Agenten: Zustaendig fuer semantische Suche ueber unstrukturierte Dokumente via Embedding-basiertem Retrieval.
Der Supervisor verteilt die Arbeit nicht blind, sondern analysiert die Abfrage und routet gezielt an die passende Modalitaet. Bei der Beispielfrage wuerde ein SQL-Agent Umsatzdaten nach Region abfragen, waehrend ein Vektor-Agent relevante Abschnitte aus Strategiedokumenten oder Risikoberichten extrahiert.
Autonome Fehlerkorrektur: Reflective Retry
Das zentrale Differenzierungsmerkmal gegenueber flachen Agentensystemen ist der Umgang mit Fehlern. Statt fehlerhafte Ergebnisse weiterzureichen -- was in klassischen Systemen zu Halluzinationen fuehrt -- implementiert die Architektur einen dedizierten Retry-Knoten:
- Ein Worker-Agent schlaegt fehl (SQL-Syntaxfehler, Schema-Mismatch, leere Ergebnismenge)
- Der Fehlerkontext wird an einen Retry-Knoten uebergeben
- Der Retry-Knoten analysiert die Fehlerursache, schlaegt Korrekturen vor und validiert das Ergebnis vor der Rueckgabe
- Erst nach erfolgreicher Validierung fliesst das Ergebnis zurueck zum Supervisor
Dieser Mechanismus verhindert, dass das System bei Fehlern entweder halluziniert oder stumm unvollstaendige Antworten liefert.
Benchmarks
Die Evaluation erfolgte auf dem EntQA-Benchmark mit 200 Enterprise-Fragen, die strukturierte und unstrukturierte Datenquellen erfordern:
| System | Tier-3-Genauigkeit | Halluzinationsrate | p95-Latenz |
|---|---|---|---|
| Protocol-H (hierarchisch) | 84,5% | 7,1% | 2,1s |
| Flat Agent | 62,8% | 18,2% | 1,4s |
| Standard RAG | 45,2% | 28,5% | 0,8s |
Protocol-H erreicht gegenueber flachen Agenten eine Verbesserung von 21,7 Prozentpunkten bei der Genauigkeit und reduziert Halluzinationen um 60% gegenueber Standard-RAG. Der Preis dafuer ist eine hoehere Latenz -- 2,1 Sekunden gegenueber 0,8 Sekunden -- die aus der mehrstufigen Orchestrierung und den Validierungsschleifen resultiert.
Praxis-Relevanz
Fuer Teams, die agentenbasierte RAG-Systeme in Produktionsumgebungen betreiben, ergeben sich mehrere Implikationen:
- Fehlerbehandlung als Architekturentscheidung: Die Ergebnisse zeigen, dass explizite Fehlerkorrektur-Knoten deutlich effektiver sind als implizites Retry oder einfaches Error-Propagation. Das ist kein optionales Feature, sondern architekturrelevant.
- Latenz-Genauigkeits-Tradeoff: Die 2,6-fach hoehere Latenz gegenueber Standard-RAG ist fuer interaktive Szenarien relevant. In Batch-Szenarien oder bei hohen Qualitaetsanforderungen (Finanzanalyse, Compliance) ist der Tradeoff akzeptabel.
- Sicherheitsaspekte: Die Architektur erfordert parametrisierte Queries, rollenbasierte Zugriffskontrolle (RBAC), Query-Timeouts und Schema-Awareness -- besonders wenn SQL-Agenten gegen Produktionsdatenbanken arbeiten.
- Schema-Drift: In Produktionsumgebungen aendern sich Datenbank-Schemata. Die Architektur muss Schema-Aenderungen erkennen und die Agenten entsprechend aktualisieren, um stille Fehler zu vermeiden.
- Containerisierung: Die Worker-Agenten sollten isoliert laufen, damit fehlerhafte Queries oder Endlosschleifen einzelner Agenten nicht das Gesamtsystem beeintraechtigen.