Multi-Agent RAG: Warum Datenstruktur wichtiger ist als jede Retrieval-Architektur

Die meisten RAG-Projekte scheitern nicht an der falschen Architektur. Sie scheitern daran, dass die Daten dahinter ein unkontrolliertes Chaos sind. Wer Multi-Agent RAG einführen will, sollte weniger Zeit damit verbringen, GraphRAG gegen Hybrid Search abzuwägen, und mehr damit, die eigene Datenlage ehrlich zu bewerten.

Das unterschätzte Problem: Nicht die Architektur entscheidet

In fast jedem Scoping-Gespräch beginnt die erste halbe Stunde nicht mit Architektur, sondern mit Daten-Archäologie. Wo liegen die relevanten Dokumente? Auf einem zentralen SharePoint, auf lokalen Laufwerken, in E-Mail-Anhängen? Sind sie versioniert? Gibt es Metadaten?

Die Antwort ist meistens: jein.

Das ist kein Vorwurf. Gewachsene IT-Landschaften im deutschen Mittelstand sehen so aus. Aber es bedeutet, dass die eigentliche Arbeit vor der ersten Zeile Code beginnt.

Was klassisches RAG leistet - und wo es scheitert

Klassisches RAG funktioniert im Kern einfach: Eine Anfrage wird vektorisiert, ähnliche Chunks aus einer Dokumentendatenbank werden abgerufen, ein LLM generiert eine Antwort. Im Pilotprojekt sieht das überzeugend aus.

In der Produktion wird es schwieriger. Die Dokumentenmenge wächst, Chunk-Qualität nimmt ab, weil niemand die Metadaten pflegt. Fehlende Klassifizierungen bedeuten, dass das System nicht mehr unterscheiden kann, ob ein Dokument aus 2019 oder 2024 stammt. Forschung zu Agentic RAG bestätigt, dass klassische RAG-Systeme durch statische Workflows und fehlende Anpassungsfähigkeit an komplexen Aufgaben scheitern. Das Ergebnis: schlechte Antworten, Vertrauensverlust, Projektabbruch.

Hybrid Search vs. GraphRAG: Ein ehrliches Urteil

GraphRAG hat in der Forschung solide Ergebnisse gezeigt. Eine Benchmark-Studie der University of Leeds belegt, dass Hybrid GraphRAG die faktische Korrektheit gegenüber klassischem Vector RAG um 8 % verbessert. Forscher der Michigan State University zeigen, dass kombinierte RAG-und-GraphRAG-Strategien konsistente Leistungsverbesserungen bringen.

Trotzdem ist GraphRAG in realen KMU-Projekten fast nie die richtige Wahl. Wissensgraphen müssen gepflegt werden, und das erfordert Expertise und Prozesse, die die meisten Mittelständler schlicht nicht haben.

Hybrid Search - die Kombination aus semantischer Suche und keyword-basiertem Retrieval wie BM25 - gewinnt die meisten Produktionsprojekte. Eine Benchmark-Studie mit über 23.000 Anfragen zeigt, dass BM25 modernes Dense Retrieval bei Finanzdokumenten übertrifft, mit einem Recall@5 von 0,816 bei Hybrid-Pipelines mit neuronalem Reranking. Robuster, leichter wartbar, praxistauglicher.

GraphRAG empfehlen wir nur in Nischenfällen: stark vernetzte regulatorische Dokumente, explizite Graphstruktur-Anforderungen, dediziertes Engineering-Budget.

Multi-Agent RAG: Wie Agenten mehrere RAG-Instanzen orchestrieren

In modernen Multi-Agent System-Setups existiert nicht ein einzelner RAG-Endpoint. Stattdessen gibt es mehrere spezialisierte RAG-Instanzen, jede für eine klar abgegrenzte Wissensdomäne. Ein übergeordneter Agent entscheidet zur Laufzeit, welche Instanz relevant ist.

Ein konkretes Beispiel aus der Fertigung: Eine RAG-Instanz enthält technische Datenblätter, eine zweite Compliance-Dokumente, eine dritte greift auf strukturierte ERP-Lieferkettendaten zu. Der Orchestrierungs-Agent bewertet die eingehende Anfrage und wählt die passende Kombination.

Das MA-RAG-Framework vom Dartmouth College zeigt, wie Planner-, Extractor- und QA-Agent über Chain-of-Thought-Prompting zusammenarbeiten, sodass selbst LLaMA3-8B größere standalone LLMs übertrifft. Das HM-RAG-System vom Shanghai AI Laboratory und HKUST ergänzt das um parallelen Abruf aus Vektor-, Graph- und Webdatenbanken, mit +12,95 % Verbesserung der Antwortgenauigkeit gegenüber Baseline-RAG.

Diese Architektur funktioniert jedoch nur, wenn die Daten in den einzelnen Stores bereits sauber abgegrenzt und klassifiziert sind. Hintergrund zu Agentic AI liefert der Überblick zu Agentic AI.

Die Datenfrage: Vier Fragen vor dem ersten Code

Bevor eine Architekturentscheidung sinnvoll ist, müssen diese vier Fragen beantwortet sein:

1. Sind die Daten zentral zugänglich oder verteilt? SharePoint, lokale Laufwerke und E-Mail-Anhänge bedeuten: Integrationsarbeit zuerst.
2. Gibt es eine Klassifizierung? Dokumenttyp, Abteilung und Aktualität sind Mindestanforderungen.
3. Wo liegen die Daten physisch? Cloud, On-Premise oder Hybrid beeinflusst Datenschutz, Latenz und Zugriff direkt.
4. Gibt es eine API? Viele ERP-Systeme im Mittelstand bieten keine offenen APIs. Manuelle Exports sind kein tragfähiges Produktionskonzept.

Ein gut strukturierter Datenbestand braucht deutlich weniger Engineering als ein chaotischer Store mit perfekter Retrieval-Architektur. Unsere RAG-Entwicklungsleistungen bauen immer auf dieser Grundlage auf.

Welche Architekturen wir 2026 einsetzen - und welche nicht

• Hybrid Search: Empfohlen für die meisten KMU-Setups mit gemischten Dokumenttypen. Robust, wartbar, erprobt.
• Multi-Agent RAG mit Orchestrierung: Empfohlen, wenn klar abgegrenzte Wissensdomänen bereits existieren.
• GraphRAG: Nur bei expliziten Graphstruktur-Anforderungen und dediziertem Pflegeaufwand.
• Naive RAG: Ausschließlich für Proofs of Concept.

Vor dem Scoping: Fünf Fragen für interne Klarheit

Wer ein Multi-Agent RAG Projekt plant, sollte diese Fragen intern klären, bevor er mit einem Dienstleister spricht:

1. Wo liegen unsere relevanten Daten heute, konkret und vollständig?
2. Gibt es eine zentrale API oder müssen wir Exports bauen?
3. Sind Dokumenttypen klassifiziert oder alles in einem Topf?
4. Wer pflegt die Datenbasis nach dem Go-Live?
5. Welche Wissensdomänen sind klar genug abgegrenzt für separate RAG-Stores?

Wer merkt, dass die Datenlage noch nicht stimmt, sollte dort anfangen. Unser Consulting-Angebot ist genau für diesen Einstieg gedacht.

Frequently Asked Questions

Q: Was ist der Unterschied zwischen klassischem RAG und Multi-Agent RAG?

Klassisches RAG ruft statisch die ähnlichsten Dokument-Chunks ab und gibt sie an ein LLM weiter. Multi-Agent RAG erweitert das um autonome Agenten, die Abfragestrategien dynamisch anpassen, Aufgaben in Teilschritte zerlegen und mehrere spezialisierte RAG-Instanzen koordiniert anfragen.

Q: Wann lohnt sich GraphRAG und wann reicht Hybrid Search?

Hybrid Search reicht für die meisten KMU-Projekte mit gemischten Dokumenttypen. GraphRAG lohnt sich nur bei expliziten Graphstruktur-Anforderungen und ausreichendem Engineering-Budget für Pflege. Ohne dedizierte Ressourcen wird GraphRAG schnell zur Wartungslast.

Q: Wie orchestriert Multi-Agent RAG mehrere RAG-Instanzen?

Ein übergeordneter Orchestrierungs-Agent analysiert die eingehende Anfrage und entscheidet zur Laufzeit, welche spezialisierte RAG-Instanz zuständig ist. Er kombiniert bei Bedarf Ergebnisse mehrerer Instanzen und gibt eine konsolidierte Antwort zurück. Voraussetzung ist eine saubere Datenabgrenzung in den einzelnen Stores.

Q: Welche Voraussetzungen brauche ich für ein produktionsreifes RAG-System?

Zentral zugängliche Daten, eine Klassifizierung nach Dokumenttyp und Aktualität, eine API für automatisierten Zugriff und eine klare Zuständigkeit für laufende Datenpflege. Ohne diese Grundlagen liefert kein Retrieval-Ansatz zuverlässige Ergebnisse.

Q: Warum scheitern RAG-Projekte in der Produktion so häufig?

Meistens nicht wegen der Retrieval-Architektur, sondern wegen der Datenlage. Fehlende Metadaten und fehlende Klassifizierung führen dazu, dass das System im Piloten gut funktioniert und in der Produktion schlechte Antworten liefert - das kostet Vertrauen und führt häufig zum Projektabbruch.

Sources

1. [2501.09136] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
2. HM-RAG: Hierarchical Multi-Agent Multimodal Retrieval Augmented Generation
3. MA-RAG: Multi-Agent Retrieval-Augmented Generation via Collaborative Chain-of-Thought Reasoning
4. [2505.20096] MA-RAG: Multi-Agent Retrieval-Augmented Generation via Collaborative Chain-of-Thought Reasoning
5. Benchmarking Vector, Graph and Hybrid Retrieval Augmented Generation (RAG) Pipelines for Open Radio Access Networks (ORAN)
6. RAG vs. GraphRAG: A Systematic Evaluation and Key Insights
7. Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
8. When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation
9. From BM25 to Corrective RAG: Benchmarking Retrieval Strategies for Text-and-Table Documents