Wenn Sie ein klassisches RAG-System entwickelt haben, kennen Sie seine Stärken: Es ruft relevante Chunks ab, das große Sprachmodell generiert fundierte Antworten, die Leistung ist angemessen und die Kosten sind vorhersehbar. Für die meisten Abfragen an einen Wissensspeicher reicht das aus.
Einige Abfragen bringen klassisches RAG jedoch an seine Grenzen. Mehrschrittige Fragen („Welche unserer Kunden nutzen Funktion X und haben in den vergangenen sechs Monaten gekündigt?“). Beziehungsintensive Fragen („Wie schneiden unsere Preise im Vergleich zu den Wettbewerbern A, B und C ab?“). Synthesefragen („Fassen Sie alles zusammen, was wir über den Kundenverlauf wissen.“). Klassisches Chunk-basiertes Retrieval führt Chunks nicht gut zusammen; das große Sprachmodell verliert den Kontext, der über viele Stellen verteilt ist.
Die Ansätze „jenseits von Chunks“ — Graph RAG, agentisches RAG und Long-Context RAG — begegnen diesen Grenzen auf unterschiedliche Weise. Dieser Artikel erläutert jeden Ansatz, seinen passenden Einsatzbereich, seine tatsächliche Funktionsweise im Produktivbetrieb und die relevanten Kompromisse.
Die Grenzen des chunk-basierten RAG
Um zu verstehen, was wir verbessern wollen, betrachten wir zunächst die Grenzen:
Grenze 1: Keine Beziehungsstruktur. Chunks sind unabhängige Einheiten. Die Tatsache, dass Chunk A über das Konto von Kunde X und Chunk B über eine Beschwerde desselben Kunden spricht, geht verloren — es sind lediglich zwei Chunks im Vektorraum, die unabhängig voneinander abgerufen werden oder nicht.
Grenze 2: Keine mehrschrittige Schlussfolgerung. “Kunden, die Funktion X nutzen und sich über Y beschwert haben” erfordert die Kombination von Informationen aus zwei verschiedenen Quellen mit Mengenlogik. Chunk-basiertes Retrieval tut dies nicht.
Grenze 3: Begrenzte Synthese. „Fassen Sie die Entwicklung der Beziehung zu diesem Kunden zusammen“ erfordert, viele Chunks zu einem kohärenten Gesamtbild zusammenzuführen. Chunks werden als Fragmente präsentiert; das große Sprachmodell muss die Synthese jedes Mal von Grund auf neu leisten.
Grenze 4: Starre Pipeline. Klassisches RAG folgt immer demselben Ablauf: Embedding der Abfrage → Abruf der Top-K-Ergebnisse → Generierung. Komplexe Abfragen, die iteratives Retrieval oder mehrschrittige Schlussfolgerungen erfordern, passen nicht in diese Pipeline.
Grenze 5: Verwässerung des Kontexts. Unter den fünf am höchsten bewerteten Chunks können sich Treffer befinden, die zwar zur Abfrage passen, aber thematisch irrelevant sind. Das große Sprachmodell muss sie aussortieren; die Qualität leidet.
Die Varianten, die wir besprechen, beheben jeweils Teile dieser Grenzen.
Graph RAG
Die Idee: Stellen Sie Ihre Daten als Wissensgraphen dar. Entitäten (Menschen, Produkte, Dokumente, Ereignisse) sind Knoten, Beziehungen sind Kanten. Abfragen durchlaufen den Graphen anstelle der Vektorsuche oder ergänzend dazu.
Wann Graph RAG hilft
Beziehungsintensive Domänen. Strukturen aus Kunden, Konten, Geschäftsabschlüssen und Interaktionen. Organisationshierarchien. Produkttaxonomien. Zitierungsnetzwerke. Alles, wobei die Beziehungen zwischen Entitäten genauso wichtig sind wie die Entitäten selbst.
Mehrschrittige Schlussfolgerungen. „Wer leitet das Team, das Produkt X im dritten Quartal gekauft hat?“ erfordert mehrere Sprünge: Produkt → Geschäftsabschluss → Team → Leitung. Graph RAG bildet das auf natürliche Weise ab.
Aggregation. „Wie viele Kunden im Segment Y haben System Z integriert?“ erfordert Mengenoperationen über Entitäten. SQL-Abfragen auf einem Wissensgraphen eignen sich dafür besser als Text-Retrieval.
Quellenangaben und Erklärungen. Graphbeziehungen sind explizit und überprüfbar. Das große Sprachmodell kann angeben: „John leitet das Team Acme [Kante: leitet]“, statt lediglich zu folgern: „Aufgrund des Kontexts gehe ich davon aus, dass John das Team Acme leitet.“
Wie Graph RAG tatsächlich funktioniert
Die typische Pipeline:
1. Extraktion. Erstellen Sie den Graph aus Ihren Daten. Zwei gängige Ansätze:
- Strukturierte Quellen (Datenbanken, strukturierte APIs): importieren Sie direkt. Kunden, Produkte, Transaktionen sind bereits in Tabellen.
- Unstrukturierte Quellen (Dokumente, Transkripte, E-Mails): Verwenden Sie ein großes Sprachmodell, um Entitäten und Beziehungen zu extrahieren. „Extrahieren Sie aus diesem Transkript Personen, Organisationen und die Beziehungen zwischen ihnen.“
Das Ergebnis: Knoten (mit Typen und Eigenschaften) und Kanten (mit Typen und Eigenschaften).
2. Speicherung. Eine Graphdatenbank — etwa Neo4j oder Memgraph — oder eine eigene PostgreSQL-Lösung mit Kantentabellen. Die Wahl hängt von den Abfragemustern und Skalierungsanforderungen ab.
3. Erweiterung durch Embeddings. Jeder Knoten erhält zusätzlich eine Textrepräsentation und ein Embedding. Das ermöglicht einen hybriden Ansatz: den Graphen durchlaufen UND semantisch suchen.
4. Abfragen zur Retrievalzeit. Drei gängige Muster:
- Reine Graphabfrage. Das große Sprachmodell (oder eine Routing-Logik) generiert eine Graphabfrage (Cypher, SQL). Sie wird ausgeführt und die Ergebnisse werden an das Modell zurückgegeben.
- Embedding-first, Graph-Expand. Finden Sie relevante Entitäten durch Embedding. Erweitern Sie dann zu ihren Nachbarn und verwandten Entitäten.
- Hybrid. Kombinieren Sie Vektor-Suche + Graph-Traversal in einer Pipeline.
5. Formatierung für das große Sprachmodell. Graphergebnisse werden als strukturierter Text formatiert, den das Modell verwenden kann: Entitäten mit ihren Eigenschaften und expliziten Beziehungen.
Ein konkretes Beispiel
Ein SaaS-Unternehmen mit Kundendaten. Entitäten: Kunden, Verträge, Produkte, Support-Tickets, Interaktionen, Mitarbeiter.
Klassischer RAG-Ansatz: Kundendokumente in Chunks zerlegen, einbetten und abrufen. Dabei geht die Beziehungsstruktur verloren.
Graph RAG-Ansatz:
- Knoten: Kunde, Vertrag, Produkt, Ticket, Interaktion, Mitarbeiter.
- Kanten: Kunde→hat→Vertrag, Kunde→subscribed_to→Produkt, Kunde→submitted→Ticket, Ticket→assigned_to→Mitarbeiter, Vertrag→sold_by→Mitarbeiter.
Abfrage: “Welche Kunden im SaaS-Tarif haben mehr als 3 Support-Tickets im Q1 und sind im Q2 zur Erneuerung bereit?”
Dies ist natürlich eine Graph-Abfrage:
MATCH (c:Customer)-[:HAS]->(contract:Contract)
WHERE contract.tier = "SaaS"
AND contract.renewal_date BETWEEN "2026-04-01" AND "2026-06-30"
MATCH (c)-[:SUBMITTED]->(t:Ticket)
WHERE t.created BETWEEN "2026-01-01" AND "2026-03-31"
WITH c, count(t) as ticket_count
WHERE ticket_count > 3
RETURN c, ticket_count
Das große Sprachmodell generiert diese Abfrage oder wählt sie aus vorgefertigten Abfragen aus. Die Abfrage wird ausgeführt, die Ergebnisse werden formatiert und daraus wird die Antwort generiert.
Klassisches RAG kann dies nicht leicht beantworten. Graph RAG tut dies sauber.
Kompromisse
Vorteile:
- Behandelt relationale Abfragen natürlich.
- Explizite, überprüfungsfähige Struktur.
- Komponierbar mit Embeddings.
Nachteile:
- Das Erstellen des Graphen ist echte Ingenieursarbeit. Besonders bei unstrukturierten Quellen ist die Extraktion unvollkommen.
- Schema-Design ist wichtig; schlechte Schemata beschränken Sie.
- Wartung: Wenn sich die Daten entwickeln, entwickelt sich auch der Graph.
- Weniger ausgereifte Werkzeuge als bei der Vektorsuche.
Wann auszuwählen:
Wählen Sie Graph RAG, wenn Beziehungen in Ihrer Domäne eine zentrale Rolle spielen. Entscheiden Sie sich nicht nur dafür, weil der Ansatz anspruchsvoll klingt; für viele dokumentenintensive Domänen ist klassisches RAG einfacher und ebenso gut geeignet.
Microsofts Graph RAG und verwandte Arbeiten
Das Open-Source-Projekt GraphRAG von Microsoft (2024) hat einen spezifischen Ansatz bekannt gemacht:
- Extrahieren Sie Entitäten und Beziehungen aus Dokumenten (LLM-basiert).
- Clustern Sie Entitäten in Gemeinschaften.
- Generieren Sie Zusammenfassungen pro Gemeinschaft auf mehreren hierarchischen Ebenen.
- Bei Abfragen: Rufen Sie relevante Gemeinschaftszusammenfassungen ab; verwenden Sie sie als Kontext.
Das funktioniert gut für „globale“ Fragen, die einen gesamten Korpus umfassen (z. B. „Was sind die Hauptthemen in der Beschwerdehistorie dieses Kunden?“), statt für gezielte Suchanfragen.
Varianten umfassen LightRAG, Graphiti und andere — jeder mit spezifischen architektonischen Entscheidungen.
Agentergestütztes RAG
Die Idee: Statt einer festen Retrieve-then-generate-Pipeline verwenden Sie einen LLM-Agenten, der entscheidet, was wann abgerufen und wie die Suche verfeinert werden soll. Der Agent kann aufeinanderfolgende Retrieval-Abfragen stellen, die Ergebnisse prüfen und bei unzureichenden Informationen andere Ansätze ausprobieren.
Wann agentisches RAG hilft
Komplexe Abfragen, die Iteration erfordern. “Helfen Sie mir zu verstehen, warum unsere Abwanderung im Q1 gestiegen ist” erfordert das Betrachten vieler Aspekte (welcher Segment, welcher Zeit, welche Funktionen, welche Wettbewerber). Ein Agent kann iterativ erkunden.
Abfragen, bei denen ein einzelner Abruf nicht ausreicht. Wenn die Antwort Informationen aus mehreren unterschiedlichen Retrieval-Vorgängen kombinieren muss, bewältigt ein Agent dies auf natürliche Weise.
Abfragen mit bedingter Logik. “Wenn X basierend auf Retrieval 1 wahr ist, dann suchen Sie nach Y; andernfalls suchen Sie nach Z.” Agenten behandeln Verzweigungen; feste Pipelines nicht.
Unklare Abfragen. Der Agent kann den Benutzer um Klärung bitten oder weitere Daten zur Klärung abrufen.
Wie agentisches RAG funktioniert
Die Pipeline:
User query
↓
Agent reasons about what it needs
↓
Agent calls retrieval tools (one or many)
↓
Agent reads results
↓
Agent decides: enough info? Or another retrieval?
↓
Loop until done
↓
Generate final answer
Die Umsetzung beinhaltet:
Retrieval als Werkzeuge. Stellen Sie dem Agenten Retrieval-Funktionen bereit: search_documents(query), lookup_by_id(id), aggregate(field, filter). Der Agent ruft sie bei Bedarf auf.
Speicher. Der Agent erinnert sich, was er abgerufen hat, über mehrere Aufrufe hinweg. Vermeidet erneutes Abrufen desselben Inhalts.
Entscheidungsfindung. Der Agent überlegt explizit, ob er genug Informationen hat. “Kenne ich die Antwort auf die Frage des Benutzers? Wenn nicht, was muss ich noch abrufen?”
Beendigung. Der Agent muss wissen, wann er aufhören soll: bei Erreichen einer maximalen Schrittzahl, eines Vertrauensschwellenwerts oder einer Bedingung wie „Die Frage ist beantwortet“.
Ein konkretes Beispiel
Abfrage: “Was waren die drei wichtigsten Kundenbedenken im Q1, mit Beispielen?”
Klassischer RAG-Ansatz: Einige Kundendetails abrufen und hoffen, dass sie das Thema abdecken.
Agentischer RAG-Ansatz:
Agent: I need to find Q1 customer concerns. Let me start by searching for customer complaints in that period.
> Tool: search_documents(query="customer complaints Q1 2026", filter={date_range: "Q1 2026"})
Agent: I got 25 results. Let me see what topics they cover.
> [reads results]
Agent: I see three main themes: pricing, slow support, and missing integrations. Let me get specific examples for each.
> Tool: search_documents(query="customer pricing complaints", filter={...})
> Tool: search_documents(query="customer support speed complaints", filter={...})
> Tool: search_documents(query="customer integration missing complaints", filter={...})
Agent: Now I have 3-5 specific examples per theme. Let me compile the answer.
Mehrere Retrieval-Vorgänge werden iterativ verfeinert. Der Agent bestimmt die Struktur anhand der gefundenen Informationen.
Kompromisse
Vorteile:
- Behandelt komplexe, mehrschrittige Abfragen.
- Passt sich an die Komplexität der Abfrage an (einfache Abfragen lösen keine langen Agentenläufe aus).
- Kann Unklarheiten durch Nachfragen klären.
Nachteile:
- Höhere Latenz (mehrere Retrieval-Vorgänge).
- Höhere Kosten (mehrere LLM-Aufrufe).
- Die Zuverlässigkeit des Agenten ist entscheidend; schlecht konzipierte Agenten drehen sich im Kreis oder geben auf.
- Schwieriger zu bewerten (mehrere Ausführungswege).
- Schwieriger zu kontrollieren (der Agent könnte unerwartete Dinge tun).
Wann auszuwählen:
Wählen Sie agentisches RAG, wenn die Abfragekomplexität stark variiert. Einfache Abfragen können schnelle Pfade nutzen; komplexe Abfragen werden an den agentischen Ansatz weitergeleitet. Bei durchgehend einfachen Abfragen lohnt sich der zusätzliche Aufwand nicht.
Muster innerhalb des agentischen RAG
Einige gängige Muster:
Muster 1: ReAct (Reason + Act). Der Agent überlegt explizit, dann handelt (ruft ab), beobachtet, dann überlegt erneut. Wiederholt, bis er fertig ist.
Muster 2: Plan-and-execute. Der Agent erstellt zunächst einen mehrschrittigen Plan — was in welcher Reihenfolge abgerufen werden soll — und führt ihn aus, wobei er ihn bei Bedarf anpasst.
Muster 3: Selbstkritik. Nach dem Retrieval bewertet der Agent, ob die abgerufenen Informationen ausreichend sind. Wenn nicht, verfeinert er die Abfrage und ruft erneut ab.
Muster 4: Tool-reicher Agent. Der Agent hat viele Retrieval-Tools (Volltextsuche, SQL-Abfrage, Graph-Abfrage, API-Aufrufe) und wählt zwischen ihnen aus.
Verschiedene Muster eignen sich für unterschiedliche Anwendungsfälle. Ein werkzeugreicher Agent eignet sich für heterogene Datenquellen, ReAct für explorative Abfragen und Plan-and-execute, wenn sich die Struktur einer komplexen Abfrage im Voraus planen lässt.
Long-Context RAG
Die Idee: Warum bei Kontextfenstern mit mehr als einer Million Tokens (Gemini, GPT-5) überhaupt Chunks abrufen? Legen Sie einfach den gesamten Korpus in den Kontext.
Wann Long-Context RAG hilft
Kleine Korpora. Ein Korpus mit 100.000 Tokens passt problemlos in ein Kontextfenster mit einer Million Tokens. Dafür ist keine Retrieval-Infrastruktur erforderlich.
Vollständiges Dokumentverständnis. „Fassen Sie dieses gesamte 500-seitige Dokument zusammen.“ Ein Long-Context-Modell verarbeitet es direkt.
Dokumentübergreifende Abfragen für kleine Mengen. „Vergleichen Sie diese zehn Verträge.“ Es ist einfacher, alle in den Kontext zu legen, als sie sorgfältig abzurufen.
Prototyping. Long Context ist der einfachste Weg zu einem funktionierenden System. Entwickeln Sie den Prototyp mit Long Context und optimieren Sie ihn später bei Bedarf durch Retrieval.
Wie Long-Context RAG funktioniert
Die Pipeline ist trivial:
[corpus, possibly 100K-1M tokens]
↓
+ [user query]
↓
LLM call
↓
[answer]
Keine Vektor-Speicher. Kein Chunking. Kein Re-Ranking.
In der Praxis können Sie weiterhin ein grobes Retrieval durchführen, damit der Korpus in den Kontext passt (z. B. für einen Korpus mit fünf Millionen Tokens eine Teilmenge von 500.000 Tokens abrufen). Das Retrieval bleibt jedoch grob — das große Sprachmodell übernimmt die Feinarbeit, die relevanten Teile zu finden.
Das Problem der Kontextdegradation
Eine Realität von 2025–2026: Long-Context-Modelle nutzen langen Kontext nicht wirklich gut.
Empirisch gilt:
- Die Qualität ist bei etwa 5.000–50.000 Tokens Kontext am höchsten — das zugrunde liegende Muster der positionsabhängigen Aufmerksamkeit ist in „Lost in the Middle“ von Liu et al. und nachfolgenden Long-Context-Evaluierungen dokumentiert.
- Ab mehr als 100.000 Tokens sinkt die Qualität deutlich.
- Ab mehr als 500.000 Tokens werden wichtige Informationen häufig übersehen oder falsch angewendet.
Modelle können theoretisch langen Kontext verarbeiten, doch „Nadel-im-Heuhaufen“-Benchmarks überzeichnen ihre Leistungsfähigkeit. Die tatsächliche Nutzung langer Kontexte leidet darunter.
Das bedeutet, dass Long-Context RAG für Korpora bis etwa 50.000 Tokens zuverlässig funktioniert. Darüber hinaus lässt die Leistung gegenüber einem guten Retrieval-System nach.
Kompromisse
Vorteile:
- Einfachste mögliche Architektur.
- Keine Retrieval-Pipeline zu warten.
- Besonders geeignet für Aufgaben, die ein Verständnis des gesamten Korpus erfordern.
Nachteile:
- Nachlassende Qualität bei großen Kontextmengen.
- Hohe Kosten pro Abfrage (Sie zahlen für den gesamten Kontext jedes Mal).
- Hohe Latenz (großer Kontext bedeutet langsamere Antworten).
- Die Skalierbarkeit endet bei Korpora, die zuverlässig in das Kontextfenster passen.
Wann auszuwählen:
Kleine Korpora (unter 50.000 Tokens). Einmalige Analysen. Prototypen. NICHT als allgemeines Retrieval für große Wissensbasen.
Hybrid: Retrieval + Long-Context
Ein gängiges Muster: Rufen Sie einen größeren Kontext ab als beim klassischen RAG — 50.000–200.000 Tokens relevanter Inhalte —, aber weniger als den gesamten Korpus. Das große Sprachmodell erhält genug Kontext, um die Abfrage gut zu bearbeiten, ohne übermäßige Kontextdegradation.
Umsetzung: Rufen Sie die 50 am höchsten bewerteten Chunks statt nur der besten fünf ab, nehmen Sie alle in den Kontext auf und lassen Sie das große Sprachmodell sie durchsuchen.
Dies funktioniert gut, wenn:
- Abfragen breiten Kontext benötigen.
- Modelle gut mit mittellangem Kontext (50.000–200.000 Tokens) umgehen.
- Kosten akzeptabel sind.
Ein guter Kompromiss im Jahr 2026: Rufen Sie großzügig 50–100 Chunks ab, nehmen Sie alle in den Kontext auf und lassen Sie das große Sprachmodell die relevanten Teile verwenden. Höhere Kosten werden gegen Einfachheit und Qualität eingetauscht.
Die richtige Variante wählen
Ein Entscheidungsrahmen:
Verwenden Sie klassisches Chunk-basiertes RAG, wenn:
- Dokumente die primären Daten sind.
- Abfragen überwiegend Abrufcharakter haben.
- Volumen und Kosten wichtig sind (billigste pro Abfrage).
- Sie vorhersehbare Latenz benötigen.
Verwenden Sie Graph RAG, wenn:
- Die Daten eine reiche Entitäts-Beziehungsstruktur haben.
- Abfragen mehrschrittige Schlussfolgerungen, Mengenoperationen oder Aggregation erfordern.
- Sie in die Konstruktion und Wartung des Graphen investieren können.
Verwenden Sie agentisches RAG, wenn:
- Die Abfragekomplexität stark variiert.
- einige Abfragen eine iterative Untersuchung erfordern.
- Sie bereit sind, höhere Latenz/Kosten für schwierige Abfragen zu zahlen.
- Sie über ausreichende Beobachtbarkeit verfügen, um Agentenläufe zu debuggen.
Verwenden Sie Long-Context RAG, wenn:
- der Korpus klein ist (unter 50.000 Tokens).
- Sie die einfachste Architektur wollen.
- Einmalige Analysen oder Prototypen.
Kombinieren Sie, wenn:
- Die meisten realen Systeme dies tun.
- Klassisch + Graph für relationale Abfragen.
- Klassisch + agentisch für komplexe Abfragen.
- Klassisch mit breiterem Retrieval (mittlerer Kontext) für Grenzfälle.
Die ausgereifte Antwort im Jahr 2026 lautet: „Alle oben genannten — abhängig von der jeweiligen Abfrage.“ Ein Router entscheidet anhand der Abfragemerkmale, welche Variante verwendet wird.
Produktionsrealitäten
Einige Beobachtungen aus echten Implementierungen:
Die Komplexität vervielfacht sich. Jede Variante erhöht die Komplexität. Ein System, das alle vier verwendet, erfordert erheblichen Entwicklungsaufwand. Beginnen Sie mit dem klassischen Ansatz und ergänzen Sie Varianten erst, wenn Sie auf klare Grenzen stoßen.
Die Evaluierung ist schwieriger. Bei mehreren Retrieval-Pfaden muss die Evaluierung alle abdecken. Der Testdatensatz sollte Abfragen enthalten, die jeden Pfad ausführen.
Kosten variieren stark. Graph RAG kann billig sein (eine Datenbankabfrage). Long-Context RAG ist teuer. Agentergestütztes RAG variiert (einfach = billig, komplex = teuer). Verfolgen Sie Kosten pro Abfrage.
Die Latenz variiert ähnlich stark. Eine Antwortzeit von 30 Sekunden beim agentischen RAG ist für einige Anwendungsfälle akzeptabel, für andere nicht. Wählen Sie die Variante passend zum UX-Kontext.
Wartungsaufwand. Graphschemata werden migriert, Agenten-Prompts benötigen Feinabstimmung und Embedding-Modelle werden aktualisiert. Jede Variante verursacht eigene Wartungskosten. Planen Sie entsprechend.
Die 80/20-Regel. Klassisches RAG verarbeitet 80 % der Abfragen angemessen. Die Varianten „jenseits von Chunks“ übernehmen die schwierigen 20 %, die klassisches RAG schlecht bewältigt. Ersetzen Sie es nicht, sondern ergänzen Sie es.
Eine kombinierte Architektur
Eine praktische Architektur, die mehrere Varianten verwendet:
Query
↓
Router (classify the query)
├→ "Lookup" → Classic RAG (cheap, fast)
├→ "Relational" → Graph RAG
├→ "Complex / open-ended" → Agentic RAG
└→ "Whole-corpus / small corpus" → Long-context
Each variant produces an answer.
Observability tracks which path was used.
Eval suites cover all paths.
Dies ist komplexer als jede einzelne Variante, deckt jedoch das gesamte Abfragespektrum gut ab. Für ausgereifte Systeme mit unterschiedlichen Abfragetypen ist dies die Zielarchitektur.
Eine praktische Umsetzung
Wenn Sie von einem funktionierenden klassischen RAG-System starten und ausbauen möchten:
Fügen Sie Long-Context zuerst hinzu. Niedrigster Ingenieursaufwand. Nützlich für bestimmte Abfragetypen. Erzeugt oft sofortige Gewinne.
Fügen Sie agentisches RAG für komplexe Abfragen hinzu. Identifizieren Sie die Abfragen, mit denen klassisches RAG Schwierigkeiten hat. Entwickeln Sie einen Agenten, der sie verarbeitet. Leiten Sie Anfragen nur bei Bedarf an ihn weiter.
Fügen Sie Graph RAG zuletzt hinzu. Höchster Ingenieursaufwand. Nur dann wertvoll, wenn Sie klare relationale Abfragemuster haben.
Diese Reihenfolge entspricht üblicherweise dem erwarteten ROI. Long Context: geringer Aufwand, konkreter Nutzen. Agentisch: mittlerer Aufwand, schließt tatsächliche Lücken. Graph: hoher Aufwand, spezifische Anwendungsfälle.
Ergänzen, nicht ersetzen
Klassisches Chunk-basiertes RAG ist das Arbeitstier, hat aber Grenzen. Die Varianten „jenseits von Chunks“ — Graph RAG, agentisches RAG und Long-Context RAG — ermöglichen jeweils unterschiedliche Fähigkeiten.
Der Weg nach vorne besteht nicht darin, klassisches RAG zu ersetzen, sondern es zu ergänzen. Reife Systeme verwenden mehrere Varianten, die entsprechend geroutet werden, wobei jede die Abfragen behandelt, für die sie gut ist.
Die Investition ist beträchtlich — jede Variante erfordert echte Entwicklungsarbeit. Bei Systemen, in denen klassisches RAG an Grenzen stößt, ist der Fähigkeitsgewinn jedoch real. Ein System, das nur „Suchabfragen“ gut verarbeitet, ist deutlich weniger nützlich als eines, das auch relationale, komplexe und den gesamten Korpus betreffende Abfragen bewältigt.
Erfassen und kategorisieren Sie Ihre Abfragen. Identifizieren Sie diejenigen, die klassisches RAG schlecht verarbeitet. Wählen Sie die passende Variante, entwickeln Sie die Ergänzung und iterieren Sie.
So entwickeln sich RAG-Systeme von einer Lösung für einzelne Abfragen zu einem leistungsfähigen System für die Vielfalt realer Fragestellungen.
