RAG von Grund auf – Teil 7: Advanced RAG, GraphRAG und Agentic RAG
In den bisherigen Teilen haben wir eine klassische RAG-Pipeline Schritt für Schritt aufgebaut.
Aus Dokumenten wurden Chunks.
Aus Chunks wurden durch Embeddings Vektoren.
Dense Retrieval und Sparse Retrieval ermöglichten unterschiedliche Arten der Suche.
Hybrid Search kombinierte beide Welten.
Reranking verbesserte die Reihenfolge der Kandidaten.
Context Selection entschied, welche Evidenz tatsächlich an das Sprachmodell gelangt.
Grounding und Answerability sollten schliesslich verhindern, dass das Modell Antworten erzeugt, die von den Quellen nicht getragen werden.
Unsere Pipeline sieht inzwischen ungefähr so aus:
Documents
↓
Parsing
↓
Chunking
↓
Indexing
↓
Query
↓
Retrieval
↓
Fusion
↓
Reranking
↓
Context Selection
↓
Answerability
↓
Generation
↓
Grounding
↓
Answer
Das ist bereits ein leistungsfähiges RAG-System.
Aber es besitzt eine fundamentale Eigenschaft:
Der Ablauf ist weitgehend vorgegeben.
Eine Frage kommt hinein.
Das System sucht.
Es erzeugt Kontext.
Das LLM antwortet.
Was aber, wenn eine Frage nicht mit einem einzigen Retrieval-Schritt beantwortet werden kann?
Was, wenn das System nach dem Retrieval feststellt, dass die gefundenen Dokumente schlecht sind?
Was, wenn eine Frage zuerst zerlegt werden muss?
Was, wenn nach der ersten Antwort erneut gesucht werden sollte?
Was, wenn die gesuchte Information nicht in einem einzelnen Chunk steht, sondern über mehrere Dokumente verteilt ist?
Was, wenn Beziehungen zwischen Personen, Systemen, Ereignissen oder Konzepten wichtiger sind als semantische Ähnlichkeit?
Was, wenn das Modell selbst entscheiden soll, ob, wann und wie oft Retrieval notwendig ist?
Hier beginnt das Feld, das häufig unter Begriffen wie:
- Advanced RAG,
- Modular RAG,
- Adaptive RAG,
- Self-RAG,
- Corrective RAG,
- Multi-Hop RAG,
- RAPTOR,
- GraphRAG,
- Agentic RAG
zusammengefasst wird.
Allerdings beschreiben diese Begriffe nicht alle dieselbe Art von Verbesserung.
Genau deshalb lohnt es sich, sie sauber auseinanderzuhalten.
1. Naive RAG als Ausgangspunkt
Um Advanced RAG zu verstehen, brauchen wir zuerst einen Ausgangspunkt.
Dieser wird häufig als Naive RAG bezeichnet.
Eine stark vereinfachte Pipeline:
Question
↓
Retrieve Top-k
↓
Put chunks into prompt
↓
LLM
↓
Answer
Oder noch kompakter:
Retrieve
→
Augment
→
Generate
Das ist die ursprüngliche Grundidee von RAG.
Und sie ist keineswegs nutzlos.
Für viele Anwendungen kann genau diese Architektur bereits ausreichend sein.
2. Warum „naive“ nicht „schlecht“ bedeutet
Der Begriff klingt abwertend.
Das sollte er nicht.
Eine einfache Pipeline besitzt erhebliche Vorteile:
- geringe Komplexität,
- geringe Latenz,
- niedrige Kosten,
- einfache Fehlersuche,
- einfache Evaluation,
- vorhersehbarer Ablauf.
Wenn ein einzelner Retrieval-Schritt zuverlässig die richtige Evidenz findet, benötigt man möglicherweise überhaupt kein Agentic RAG.
Komplexität sollte nicht Selbstzweck sein.
3. Die Grenzen von Naive RAG
Probleme entstehen beispielsweise bei Fragen wie:
Welche Änderungen gab es zwischen Version A und Version B
und welche Auswirkungen haben sie auf Prozess C?
Die Antwort könnte Informationen aus mehreren Dokumenten benötigen.
Oder:
Wer war Projektleiter des Projekts, das die Bibliothek
entwickelt hat, die in System X verwendet wird?
Hier muss möglicherweise eine Kette von Beziehungen verfolgt werden.
Oder:
Warum ist die aktuelle Regel anders als die frühere?
Hier müssen möglicherweise:
- aktuelle Dokumente,
- historische Dokumente,
- Änderungsinformationen
kombiniert werden.
Ein einzelnes:
Query → Top-k
reicht dann möglicherweise nicht.
4. Advanced RAG
Advanced RAG ist kein einzelner Algorithmus.
Der Begriff beschreibt allgemein RAG-Systeme, die die einfache Retrieve-then-Generate-Pipeline um zusätzliche Verfahren erweitern.
Beispielsweise:
Query Transformation
Hybrid Retrieval
Reranking
Context Compression
Iterative Retrieval
Answerability Checks
Verification
Viele Techniken aus den Teilen 4 bis 6 können deshalb bereits als Advanced-RAG-Techniken betrachtet werden.
5. Naive RAG versus Advanced RAG
Vereinfacht:
Naive RAG
Query
↓
Retrieve
↓
Generate
Advanced:
Query
↓
Rewrite / Decompose
↓
Multiple Retrieval Methods
↓
Fusion
↓
Reranking
↓
Context Processing
↓
Generate
↓
Verify
Advanced RAG bedeutet also zunächst:
Die Pipeline wird intelligenter und mehrstufig.
6. Advanced RAG ist kein standardisiertes Protokoll
Es gibt keine offizielle Definition:
Wenn Pipeline X mindestens fünf Schritte besitzt,
ist sie Advanced RAG.
Der Begriff dient eher zur Abgrenzung von sehr einfachen RAG-Pipelines.
Deshalb sollte man ihn nicht wie einen konkreten Algorithmus behandeln.
7. Modular RAG
Noch allgemeiner ist die Idee von Modular RAG.
Statt RAG als feste Pipeline zu betrachten, wird das System aus austauschbaren Modulen zusammengesetzt.
Beispielsweise:
┌── Dense Retriever
│
Query ───────────┼── Sparse Retriever
│
└── Graph Retriever
│
▼
Fusion
│
▼
Reranker
│
▼
Context Builder
│
▼
Generator
│
▼
Verifier
Die einzelnen Komponenten können unabhängig voneinander ausgetauscht oder kombiniert werden.
8. Module statt Pipeline
Ein Modular-RAG-System könnte Module besitzen für:
Query Understanding
Query Routing
Query Rewriting
Retrieval
Graph Traversal
Reranking
Context Compression
Generation
Verification
Je nach Anfrage werden unterschiedliche Module verwendet.
Damit wird RAG zunehmend zu einem Orchestrierungsproblem.
9. Routing
Ein wichtiger Baustein ist Routing.
Das System entscheidet:
Welche Wissensquelle oder Retrieval-Methode ist für diese Frage geeignet?
Beispiel:
Query
│
▼
Router
│
├──► Vector Search
│
├──► Keyword Search
│
├──► SQL
│
└──► Knowledge Graph
Nicht jede Frage muss über denselben Retriever laufen.
10. Query Routing
Angenommen, ein System besitzt:
Dokumentensuche
Datenbank
API
Knowledge Graph
Frage:
Wie lautet unsere Richtlinie für X?
→ Dokumentensuche.
Frage:
Wie viele Bestellungen wurden gestern verarbeitet?
→ Datenbank.
Frage:
Welche Systeme hängen von Komponente Y ab?
→ möglicherweise Knowledge Graph.
Das ist Query Routing.
11. Routing versus Retrieval
Routing entscheidet:
Wo oder wie soll gesucht werden?
Retrieval entscheidet:
Welche Informationen innerhalb dieser Quelle
sind relevant?
Diese beiden Aufgaben sollten nicht verwechselt werden.
12. Adaptive RAG
Bei Adaptive RAG wird die Strategie abhängig von der Anfrage gewählt.
Eine einfache Frage:
Was bedeutet Begriff X?
benötigt vielleicht:
ein Retrieval
Eine komplexe Frage:
Vergleiche X und Y unter Berücksichtigung von Z.
benötigt vielleicht:
Query Decomposition
+
mehrere Retrieval-Schritte
+
Synthese
Das System passt seine Vorgehensweise an.
13. Warum adaptive Strategien interessant sind
Ohne Anpassung gibt es zwei Extreme.
Immer einfache Pipeline
billig
schnell
aber manchmal unzureichend
Immer komplexe Pipeline
leistungsfähig
aber langsam
teuer
unnötig komplex
Adaptive RAG versucht:
Komplexität nur dann,
wenn sie benötigt wird.
14. Query Complexity
Dafür muss das System möglicherweise die Komplexität einer Frage einschätzen.
Beispielsweise:
simple
multi-hop
comparison
aggregation
temporal
requires external tool
Die Klassifikation beeinflusst anschliessend den Ablauf.
15. Single-Hop Retrieval
Eine einfache Frage:
Wie lange dauert die Probezeit?
kann möglicherweise mit einem einzigen Chunk beantwortet werden.
Question
↓
Retrieve
↓
Chunk
↓
Answer
Das ist ein Single-Hop-Problem.
16. Multi-Hop Question
Eine Multi-Hop-Frage benötigt mehrere Informationsschritte.
Beispiel:
Wer leitet die Abteilung,
die für Produkt X verantwortlich ist?
Vielleicht findet man zuerst:
Produkt X gehört zur Abteilung Y.
Dann benötigt man:
Wer leitet Abteilung Y?
Die zweite Suche hängt vom Ergebnis der ersten ab.
17. Multi-Hop Retrieval
Die Pipeline könnte aussehen:
Question
↓
Retrieve
↓
Fact A
↓
New Query
↓
Retrieve
↓
Fact B
↓
Answer
Das ist Multi-Hop Retrieval.
18. Hop
Ein Hop ist vereinfacht ein Informations- beziehungsweise Retrieval-Schritt.
Single-Hop:
Question
→ Evidence
→ Answer
Two-Hop:
Question
→ Evidence A
→ Intermediate Question
→ Evidence B
→ Answer
19. Beispiel für Two-Hop Retrieval
Frage:
Welche Kündigungsfrist gilt nach der Probezeit,
wenn diese drei Monate dauert?
Quelle A:
Die Probezeit dauert drei Monate.
Quelle B:
Nach Ablauf der Probezeit beträgt die
ordentliche Kündigungsfrist einen Monat.
Das System muss mehrere Informationen kombinieren.
Je nach Formulierung und Dokumentstruktur kann dafür mehrstufiges Retrieval notwendig sein.
20. Multi-Hop ist nicht einfach Multi-Query
Diese Begriffe sind ähnlich, aber unterschiedlich.
Multi-Query:
eine Frage
→ mehrere alternative Suchanfragen
→ Ergebnisse zusammenführen
Multi-Hop:
eine Frage
→ erste Information
→ daraus neue Suche
→ nächste Information
Bei Multi-Hop hängt ein späterer Schritt von einem früheren Ergebnis ab.
21. Iterative Retrieval
Allgemeiner spricht man von Iterative Retrieval, wenn das System mehrfach sucht.
Retrieve
↓
Evaluate
↓
Need more information?
├── No → Generate
└── Yes
↓
New Retrieval
Die Anzahl der Suchschritte ist nicht zwingend im Voraus bekannt.
22. Retrieval Loop
Damit entsteht eine Schleife:
┌─────────────────┐
│ │
▼ │
Query → Retrieve → Evaluate ───┘
│
▼
Enough?
│
▼
Generate
Das unterscheidet sich fundamental von einer linearen Pipeline.
23. Query Decomposition
Eine andere Strategie besteht darin, eine komplexe Frage zuerst zu zerlegen.
Frage:
Welche Unterschiede bestehen zwischen Regel A und Regel B
und welche Auswirkungen haben diese auf Prozess C?
Zerlegung:
1. Was sagt Regel A?
2. Was sagt Regel B?
3. Welche Unterschiede bestehen?
4. Welche Teile betreffen Prozess C?
Dann kann jede Teilfrage separat retrieved werden.
24. Decomposition RAG
Eine mögliche Pipeline:
Complex Question
↓
Decomposition
↓
┌────┼────┐
▼ ▼ ▼
Q1 Q2 Q3
│ │ │
▼ ▼ ▼
R1 R2 R3
└────┼────┘
▼
Synthesis
↓
Answer
Das verbessert häufig komplexe Vergleichs- und Analysefragen.
25. Parallel versus Sequential Retrieval
Teilfragen können parallel verarbeitet werden:
Q1 ──► Retrieval
Q2 ──► Retrieval
Q3 ──► Retrieval
Oder sequenziell:
Q1
↓
Result
↓
Q2 based on Result
↓
Result
Parallel eignet sich für unabhängige Teilfragen.
Sequenziell für abhängige Informationsketten.
26. Planning
Wenn das System vor der Ausführung festlegt, welche Schritte notwendig sind, sprechen wir allgemein von Planning.
Beispiel:
Goal:
Vergleiche Version A mit B.
Plan:
1. Retrieve Version A.
2. Retrieve Version B.
3. Extract relevant sections.
4. Compare.
5. Verify differences.
6. Generate answer.
Damit bewegen wir uns bereits in Richtung agentischer Systeme.
27. Retrieval Planning
Planning kann speziell das Retrieval betreffen.
Das System entscheidet beispielsweise:
zuerst Dokument A suchen
dann:
Version bestimmen
dann:
entsprechenden Abschnitt suchen
statt sofort eine einzige semantische Suche auszuführen.
28. Self-RAG
Ein bekannter Ansatz in diesem Bereich ist Self-RAG.
Die Grundidee lautet:
Das Sprachmodell soll nicht einfach immer Retrieval durchführen und danach blind antworten, sondern Retrieval und Generierung stärker selbst reflektieren.
Das Modell soll unter anderem beurteilen können:
- ob Retrieval notwendig ist,
- ob gefundene Passagen relevant sind,
- ob die Antwort durch die Evidenz gestützt wird,
- ob die erzeugte Antwort nützlich ist.
29. Das Problem hinter Self-RAG
Eine klassische Pipeline macht:
jede Frage
↓
Retrieval
↓
Generation
Aber nicht jede Frage benötigt zwingend externe Evidenz.
Und nicht jeder retrieved Text ist nützlich.
Self-RAG versucht deshalb, Entscheidungen rund um Retrieval und Generation stärker in den Modellprozess einzubauen.
30. Reflection
Ein Schlüsselbegriff bei Self-RAG ist Reflection.
Das Modell soll nicht nur Text generieren.
Es soll seinen Prozess beziehungsweise Zwischenergebnisse bewerten.
Konzeptionell:
Need Retrieval?
↓
Retrieve
↓
Relevant?
↓
Generate
↓
Supported?
↓
Useful?
31. Reflection Tokens
Im ursprünglichen Self-RAG-Konzept werden spezielle Reflection Tokens verwendet.
Sie repräsentieren Entscheidungen beziehungsweise Bewertungen im Generierungsprozess.
Konzeptionell beispielsweise:
Retrieve?
Relevant?
Supported?
Useful?
Damit werden Retrieval und Selbstkritik stärker mit der Generierung verzahnt.
32. Self-RAG ist mehr als „LLM prüft seine Antwort“
Der Begriff wird gelegentlich sehr locker verwendet.
Aber Self-RAG bezeichnet ursprünglich einen konkreteren Ansatz, bei dem ein Modell darauf trainiert wird, Retrieval und Reflection in seinen Generierungsprozess einzubeziehen.
Ein beliebiger Prompt wie:
Prüfe deine Antwort nochmals.
ist deshalb nicht automatisch Self-RAG.
33. Self-RAG mental modelliert
Vereinfacht:
Question
↓
Need Retrieval?
│
├── No ─────────────► Generate
│
└── Yes
↓
Retrieve
↓
Relevant?
│
├── No → Retrieve again / reject
│
└── Yes
↓
Generate
↓
Supported?
↓
Answer
Das ist deutlich dynamischer als Naive RAG.
34. CRAG
Ein weiterer bekannter Ansatz ist Corrective Retrieval-Augmented Generation, kurz:
CRAG.
Die Kernidee:
Retrieval-Ergebnisse werden bewertet und bei schlechter Qualität korrigierende Massnahmen eingeleitet.
35. Das Problem hinter CRAG
Naive RAG geht implizit davon aus:
Retriever liefert Chunks
→ Chunks sind brauchbar
Das stimmt nicht immer.
Retriever können:
- irrelevante Dokumente,
- schwache Treffer,
- mehrdeutige Treffer,
- unvollständige Evidenz
liefern.
CRAG fügt deshalb eine Bewertung der Retrieval-Qualität hinzu.
36. Retrieval Evaluator
Konzeptionell:
Query
↓
Retrieve
↓
Retrieval Evaluator
↓
Quality?
Je nach Ergebnis kann das System unterschiedlich reagieren.
37. Corrective Action
Vereinfacht:
Retrieved Documents
↓
Evaluation
│
┌─────┼─────┐
▼ ▼ ▼
Good Bad Ambiguous
│ │ │
▼ ▼ ▼
Use Correct Expand / refine
Der entscheidende Punkt ist:
Retrieval wird nicht einfach als gegeben akzeptiert.
38. Retrieval Confidence
CRAG führt damit die Idee einer Art Retrieval-Vertrauensbewertung ein.
Nicht im Sinn einer universellen Wahrscheinlichkeit.
Sondern:
Wie brauchbar sind die gefundenen Dokumente für diese Anfrage?
39. Corrective Retrieval
Wenn die ursprünglichen Treffer schlecht sind, kann das System beispielsweise:
- eine neue Suche durchführen,
- die Anfrage umformulieren,
- alternative Wissensquellen verwenden,
- zusätzliche Informationen beschaffen.
Damit entsteht:
Retrieve
↓
Evaluate
↓
Correct
↓
Retrieve again
40. CRAG versus Self-RAG
Die beiden Konzepte überschneiden sich thematisch, setzen aber unterschiedliche Schwerpunkte.
Self-RAG
Fokus:
adaptive Retrieval- und Generierungsentscheidungen
+
Reflection
CRAG
Fokus:
Qualität des Retrievals bewerten
+
bei schlechten Ergebnissen korrigieren
Sie sind verwandt.
Aber nicht identisch.
41. Corrective RAG als allgemeines Muster
Unabhängig vom konkreten Forschungsansatz ist die allgemeine Idee sehr nützlich:
Search
↓
Evaluate Search Result
↓
If insufficient:
change strategy
Damit wird Retrieval fehlertoleranter.
42. RAPTOR
Ein ganz anderes Problem adressiert RAPTOR.
Der Name steht für:
Recursive Abstractive Processing for Tree-Organized Retrieval.
Hier geht es nicht primär darum, Retrieval während einer Anfrage zu reflektieren.
Sondern darum, Dokumentinformationen hierarchisch zu organisieren.
43. Das Problem hinter RAPTOR
Chunk-basierte Suche funktioniert hervorragend für lokale Fakten.
Aber manche Fragen benötigen ein Verständnis grösserer Zusammenhänge.
Beispielsweise:
Was sind die wichtigsten Argumente dieses 200-seitigen Berichts?
Ein einzelner kleiner Chunk enthält die Antwort nicht.
Auch Top-k kleine Chunks bilden möglicherweise nicht die Gesamtstruktur ab.
44. Lokale versus globale Information
Kleine Chunks sind gut für:
präzise lokale Fakten
Grosse Einheiten sind besser für:
übergeordnete Themen
Zusammenhänge
Gesamtargumentation
Das ist ein grundlegender Zielkonflikt.
RAPTOR versucht, beide Ebenen verfügbar zu machen.
45. Hierarchische Repräsentation
Vereinfacht:
Summary
│
┌─────────┴─────────┐
▼ ▼
Summary A Summary B
│ │ │ │
▼ ▼ ▼ ▼
Chunk Chunk Chunk Chunk
Kleine Textteile werden gruppiert.
Aus Gruppen entstehen Zusammenfassungen.
Diese können wiederum gruppiert und zusammengefasst werden.
So entsteht eine Baumstruktur.
46. Recursive Summarization
Der Prozess ist rekursiv.
Chunks
↓
Cluster
↓
Summaries
↓
Cluster summaries
↓
Higher-level summaries
↓
...
Dadurch entstehen mehrere Abstraktionsebenen.
47. Tree-Organized Retrieval
Retrieval kann anschliessend nicht nur auf Leaf Chunks stattfinden.
Sondern auch auf höherliegenden Zusammenfassungen.
Damit kann das System je nach Frage unterschiedliche Granularität abrufen.
48. Beispiel
Frage:
Wann trat Regel X in Kraft?
→ kleiner Chunk wahrscheinlich ideal.
Frage:
Wie entwickelte sich die Regelung über die letzten Jahre?
→ höherliegende Zusammenfassungen können hilfreicher sein.
RAPTOR versucht, beide Informationsarten in einer gemeinsamen Hierarchie abzubilden.
49. RAPTOR versus Parent-Child Retrieval
Parent-Child Retrieval aus Teil 2 ist verwandt, aber nicht dasselbe.
Parent-Child:
kleinen Chunk suchen
→ grösseren Originalkontext zurückgeben
RAPTOR:
Information rekursiv clustern
+
abstraktive Zusammenfassungen erzeugen
+
mehrere Abstraktionsebenen retrievbar machen
50. RAPTOR erzeugt neue Repräsentationen
Das ist wichtig.
Bei klassischem Chunking stammen die Retrieval-Einheiten direkt aus Dokumenten.
Bei RAPTOR können zusätzliche abstraktive Repräsentationen entstehen:
Original Chunks
+
Generated Summaries
Damit wird der Retrieval-Korpus semantisch erweitert.
51. Risiko abstraktiver Zusammenfassungen
Generierte Zusammenfassungen können allerdings Fehler enthalten.
Wenn ein Summary einen Sachverhalt falsch zusammenfasst, kann dieser Fehler später selbst retrieved werden.
Damit entsteht:
Generation during ingestion
→ possible error
→ retrieval of generated error
→ grounded answer based on wrong summary
Grounding auf eine Zusammenfassung ist nicht dasselbe wie Grounding auf den Originaltext.
52. Provenance bleibt entscheidend
Eine hierarchische Zusammenfassung sollte deshalb idealerweise auf ihre Ursprungsknoten zurückverweisen können.
Summary
↓
Child Summaries
↓
Original Chunks
↓
Original Documents
Damit kann die Evidenz bis zur Quelle zurückverfolgt werden.
53. GraphRAG
Noch einmal anders funktioniert GraphRAG.
Die Grundidee:
Wissen wird nicht nur als Sammlung unabhängiger Textchunks betrachtet, sondern Beziehungen zwischen Entitäten und Konzepten werden explizit modelliert.
54. Warum Vektorsuche Beziehungen nur indirekt kennt
Eine Vektorsuche kann semantisch ähnliche Texte finden.
Aber sie besitzt nicht automatisch eine explizite Struktur:
Person A
│
└── manages ──► Department B
│
└── owns ──► Product C
Solche Beziehungen können für bestimmte Fragen entscheidend sein.
55. Knowledge Graph
Ein Knowledge Graph repräsentiert Wissen typischerweise als:
Nodes
+
Edges
Beispiel:
[Person A]
│
leads
│
▼
[Team B]
│
develops
│
▼
[System C]
Nodes repräsentieren Entitäten.
Edges repräsentieren Beziehungen.
56. Entity
Eine Entity ist ein identifizierbares Objekt.
Beispiele:
Person
Organisation
Projekt
Produkt
Ort
Technologie
Dokument
Ereignis
57. Relation
Eine Relation beschreibt eine Beziehung zwischen Entitäten.
Beispiele:
Person A → works_for → Company B
System A → depends_on → Library B
Project A → produced → Product B
58. Triple
Eine solche Beziehung kann als Triple dargestellt werden:
Subject
Predicate
Object
Beispiel:
System A
depends_on
Library B
also:
(System A, depends_on, Library B)
59. Graph Traversal
Wenn Wissen als Graph vorliegt, kann man Beziehungen traversieren.
Frage:
Welche Systeme hängen indirekt von Bibliothek X ab?
Dann kann der Graph beispielsweise verfolgt werden:
Library X
↑
depends_on
│
System A
↑
used_by
│
Product B
Diese Art von Anfrage ist mit reiner semantischer Ähnlichkeit schwieriger.
60. Graph Retrieval
Graph Retrieval sucht deshalb nicht nur nach ähnlichem Text.
Es kann:
- Entitäten identifizieren,
- Nachbarn traversieren,
- Pfade verfolgen,
- Beziehungen aggregieren.
Das ist eine andere Retrieval-Form.
61. GraphRAG ist nicht einfach „Vector Search plus Graph Database“
Der Begriff wird heute sehr breit verwendet.
Im Kern geht es aber darum, Graphstrukturen für Retrieval und Antwortbildung zu nutzen.
Ein System kann dabei durchaus zusätzlich:
- Embeddings,
- Vektorsuche,
- Textchunks,
- Community Summaries
verwenden.
Graph und Vector Retrieval schliessen sich nicht aus.
62. Text und Graph ergänzen sich
Text ist hervorragend für:
Erklärungen
Details
Nuancen
Formulierungen
Graphen sind hervorragend für:
Entitäten
Beziehungen
Strukturen
Pfade
Netzwerke
Ein leistungsfähiges System kann beides kombinieren.
63. Entity Extraction
Um aus Dokumenten einen Graph aufzubauen, müssen zunächst Entitäten erkannt werden.
Text:
System A verwendet Bibliothek B.
Bibliothek B wird von Team C gepflegt.
Extraktion:
Entities:
System A
Bibliothek B
Team C
64. Relation Extraction
Danach werden Beziehungen extrahiert:
System A
→ uses
→ Bibliothek B
Bibliothek B
→ maintained_by
→ Team C
Damit entsteht ein Graph.
65. Graph Construction
Die Ingestion-Pipeline wird damit umfangreicher:
Documents
↓
Parsing
↓
Entity Extraction
↓
Relation Extraction
↓
Graph Construction
Zusätzlich können weiterhin Chunks und Embeddings erzeugt werden.
66. Entity Resolution
Ein schwieriges Problem ist Entity Resolution.
Beispiel:
Microsoft
Microsoft Corp.
Microsoft Corporation
MS
Sind das dieselben Entitäten?
Das System muss möglicherweise unterschiedliche Schreibweisen zusammenführen.
67. Entity Disambiguation
Umgekehrt können identische Namen verschiedene Dinge meinen.
Beispiel:
Mercury
kann je nach Kontext bedeuten:
- Planet,
- Element,
- Unternehmen,
- Produkt.
Diese Mehrdeutigkeit muss aufgelöst werden.
68. Graphqualität
Ein Knowledge Graph ist nur so gut wie:
Entity Extraction
+
Relation Extraction
+
Entity Resolution
Fehler in diesen Schritten erzeugen falsche Graphstrukturen.
GraphRAG beseitigt Datenqualitätsprobleme also nicht.
Es verschiebt und erweitert sie.
69. Local Search im Graph
Eine Frage über eine konkrete Entität kann lokal beantwortet werden.
Beispiel:
Welche Projekte gehören zu Team A?
Dann startet Retrieval bei:
Team A
und untersucht relevante Nachbarn.
Das kann man konzeptionell als Local Graph Search betrachten.
70. Global Questions
Andere Fragen betreffen den gesamten Korpus.
Beispiel:
Welche übergeordneten Themen treten in diesen Dokumenten auf?
Hier reicht ein lokaler Graphpfad möglicherweise nicht.
Man benötigt aggregierte Informationen über grössere Graphbereiche.
71. Communities
Graphen können in Communities zerlegt werden.
Eine Community ist vereinfacht eine Gruppe stark miteinander verbundener Knoten.
Community A
├─ Node
├─ Node
└─ Node
Community B
├─ Node
├─ Node
└─ Node
Diese Gruppen können semantisch zusammenhängende Themenbereiche repräsentieren.
72. Community Detection
Algorithmen können versuchen, solche Gruppen automatisch zu identifizieren.
Das nennt man Community Detection.
Dadurch entsteht eine höhere Organisationsebene des Graphen.
73. Community Summaries
Aus Communities können Zusammenfassungen erzeugt werden.
Graph Community
↓
LLM Summary
↓
Community Report
Damit können globale Fragen effizienter beantwortet werden.
Diese Idee spielt insbesondere bei bestimmten GraphRAG-Ansätzen eine wichtige Rolle.
74. Local versus Global GraphRAG
Konzeptionell:
Local
bestimmte Entität
→ Nachbarschaft
→ Beziehungen
Global
gesamter Graph
→ Communities
→ Summaries
→ globale Synthese
Die beiden Fragetypen benötigen unterschiedliche Retrieval-Strategien.
75. Wann GraphRAG sinnvoll sein kann
Graphbasierte Ansätze sind besonders interessant, wenn Fragen stark von Beziehungen abhängen.
Beispiele:
Wer arbeitet mit wem?
Welche Komponenten hängen voneinander ab?
Welche Ereignisse stehen miteinander in Verbindung?
Welche Entitäten tauchen in mehreren Themenbereichen auf?
Welche indirekten Abhängigkeiten existieren?
76. Wann GraphRAG möglicherweise unnötig ist
Für:
Wie lautet die Kündigungsfrist während der Probezeit?
kann ein sauberer BM25-/Dense-/Hybrid-Retriever völlig ausreichend sein.
Einen Knowledge Graph aufzubauen wäre dafür möglicherweise unnötige Komplexität.
Wieder gilt:
Die Retrieval-Struktur sollte zum Informationsproblem passen.
77. GraphRAG ersetzt klassische Suche nicht zwingend
Eine häufig sinnvolle Kombination ist:
Query
│
├──► Text Retrieval
│
└──► Graph Retrieval
│
▼
Evidence
│
▼
Synthesis
Graph Retrieval wird damit zu einer zusätzlichen Retrieval-Modalität.
78. ColBERT
Nun zu einem Begriff, der häufig zusammen mit Advanced RAG genannt wird, aber in eine ganz andere Kategorie gehört:
ColBERT.
ColBERT ist kein Agentic-RAG-Framework.
Es ist keine GraphRAG-Methode.
Es ist keine RAG-Orchestrierung.
ColBERT ist primär ein Retrieval-Modell.
79. Das Problem klassischer Dense Retrieval Models
Bei einem klassischen Bi-Encoder wird ein gesamter Text typischerweise in einen einzelnen Vektor komprimiert.
Query
↓
Query Vector
Document
↓
Document Vector
Dann:
similarity(query_vector, document_vector)
Das ist sehr effizient.
Aber viele Tokeninformationen werden in einem einzigen Vektor verdichtet.
80. Single-Vector Representation
Beispiel:
Document:
"The quick brown fox jumps over the lazy dog."
wird zu:
[0.12, -0.44, 0.91, ...]
Ein Vektor repräsentiert den gesamten Text.
Das ist eine Single-Vector Representation.
81. Late Interaction
ColBERT verfolgt eine andere Idee:
Query- und Dokumenttokens erhalten separate Repräsentationen und interagieren erst spät miteinander.
Das nennt man Late Interaction.
82. Token-Level Embeddings
Statt:
Document
→
one vector
entsteht vereinfacht:
Token 1 → Vector
Token 2 → Vector
Token 3 → Vector
...
Ebenso für die Query.
83. Late Interaction mental modelliert
Query:
q1 q2 q3
Dokument:
d1 d2 d3 d4 d5
Jeder Query-Token kann mit Dokumenttoken-Repräsentationen verglichen werden.
Konzeptionell:
q1 → best matching document token
q2 → best matching document token
q3 → best matching document token
Diese Interaktionen werden zu einem Gesamtscore kombiniert.
84. MaxSim
Ein charakteristisches Konzept ist MaxSim.
Für jeden Query-Token wird ein besonders ähnlicher Dokumenttoken gesucht.
Vereinfacht:
score(Q,D)
=
Σ max similarity(q_i, d_j)
Also:
für jeden Query-Token
→ bester Dokumenttoken-Match
→ Scores aufsummieren
Die tatsächliche Modellierung besitzt natürlich weitere Details, aber dieses mentale Modell ist zentral.
85. Warum Late Interaction interessant ist
Single-vector Dense Retrieval komprimiert:
ganzer Text
→ ein Vektor
Late Interaction behält wesentlich feinere Tokeninformationen.
Dadurch können präzisere Interaktionen zwischen Query und Dokument möglich werden.
86. Bi-Encoder versus Cross-Encoder versus ColBERT
Wir können nun drei wichtige Ansätze vergleichen.
Bi-Encoder
Query → Vector
Document → Vector
Similarity
Sehr effizient.
Cross-Encoder
[Query + Document]
↓
Transformer
↓
Score
Sehr genaue gemeinsame Bewertung, aber teuer.
ColBERT / Late Interaction
Query Tokens → Vectors
Document Tokens → Vectors
↓
Late Interaction
↓
Score
Versucht, einen Mittelweg zwischen Effizienz und feiner Interaktion zu finden.
87. Wo ColBERT in unsere Serie gehört
ColBERT verändert vor allem:
Retrieval / Ranking
nicht:
RAG Orchestration
Man kann also durchaus ein:
Naive RAG
+
ColBERT Retriever
bauen.
Oder:
Agentic RAG
+
ColBERT Retriever
Diese Begriffe beschreiben unterschiedliche Ebenen.
88. Multi-Vector Retrieval
ColBERT gehört zur Familie von Ansätzen, bei denen ein Dokument durch mehrere Vektoren repräsentiert wird.
Deshalb begegnet man dem Begriff:
Multi-Vector Retrieval.
Das unterscheidet sich vom klassischen:
one chunk
→ one vector
89. Speicherbedarf
Mehrere Vektoren pro Dokument beziehungsweise Chunk bedeuten allerdings:
mehr Repräsentationen
→ mehr Speicher
Deshalb spielen Kompression und effiziente Indizes eine wichtige Rolle.
Auch hier existiert ein Trade-off:
Retrieval Quality
↔
Storage
↔
Latency
90. ColBERT ersetzt Reranking nicht zwingend
Ein Late-Interaction-Retriever kann bereits sehr gute Rankings erzeugen.
Trotzdem kann ein System zusätzlich einen Cross-Encoder-Reranker verwenden.
Beispielsweise:
ColBERT Retrieval
↓
Top 100
↓
Cross-Encoder
↓
Top 10
Ob das sinnvoll ist, hängt von Qualitäts-, Kosten- und Latenzanforderungen ab.
91. Agentic RAG
Nun kommen wir zum wahrscheinlich am stärksten diskutierten Begriff:
Agentic RAG.
Die zentrale Idee lautet:
Retrieval ist nicht mehr nur ein fest definierter Pipeline-Schritt, sondern eine Aktion, die ein Agent abhängig vom aktuellen Zustand auswählen und wiederholen kann.
92. Klassisches RAG
Klassisch:
Query
↓
Retrieve
↓
Generate
Der Ablauf steht vorher fest.
93. Agentic RAG
Agentisch:
Goal
↓
Reason / Plan
↓
Choose Action
↓
Retrieve / Search / Tool
↓
Observe Result
↓
Reason Again
↓
Need More Information?
├── Yes → another action
└── No → Answer
Der Ablauf entsteht dynamisch.
94. Agent
Ein Agent ist in diesem Zusammenhang vereinfacht ein System, bei dem ein Modell nicht nur Text generiert, sondern:
- einen Zustand berücksichtigt,
- Entscheidungen trifft,
- Aktionen auswählt,
- Ergebnisse beobachtet,
- weitere Schritte plant.
Das LLM wird damit Teil einer Kontrollschleife.
95. Agent Loop
Ein typisches mentales Modell:
┌──────────────────────┐
│ │
▼ │
Observe │
↓ │
Reason │
↓ │
Choose Action │
↓ │
Execute Tool │
↓ │
Result ────────────────────┘
Bis das Ziel erreicht ist.
96. Retrieval als Tool
Bei Agentic RAG kann Retrieval als Werkzeug betrachtet werden.
Beispielsweise:
search_documents(query)
Der Agent entscheidet selbst:
wann
mit welcher Query
wie oft
dieses Werkzeug verwendet wird.
97. Mehrere Retrieval Tools
Ein Agent könnte besitzen:
vector_search()
keyword_search()
graph_search()
database_query()
web_search()
und abhängig von der Frage eine Methode auswählen.
Damit verbindet sich Agentic RAG mit Modular RAG.
98. Beispiel
Frage:
Welche Änderungen wurden an Richtlinie X vorgenommen
und warum?
Agent:
1. Suche aktuelle Version.
2. Suche vorherige Version.
3. Vergleiche beide.
4. Suche Änderungsbegründung.
5. Prüfe, ob Begründung gefunden wurde.
6. Erzeuge Antwort.
Der Ablauf wurde nicht vollständig als starre Pipeline vorgegeben.
99. Tool Calling
Technisch basiert Agentic RAG häufig auf Tool Calling.
Das Modell kann strukturierte Aktionen auslösen.
Beispiel:
{
"tool": "search_documents",
"query": "Richtlinie X Version 2025"
}
Das System führt die Suche aus und gibt das Ergebnis zurück.
100. Observation
Das Tool-Ergebnis wird zur Observation.
Action:
search_documents(...)
Observation:
3 matching documents found
Danach entscheidet der Agent über den nächsten Schritt.
101. State
Ein Agent benötigt einen State.
Dieser kann enthalten:
Original Question
Current Plan
Retrieved Evidence
Previous Tool Calls
Intermediate Results
Remaining Questions
Der State repräsentiert den aktuellen Stand der Bearbeitung.
102. Memory
Agenten können zusätzlich verschiedene Formen von Memory besitzen.
Beispielsweise:
Short-term working memory
für den aktuellen Task.
Oder:
Long-term memory
für Informationen über mehrere Interaktionen hinweg.
Memory ist jedoch ein eigenes grosses Thema und nicht automatisch RAG.
103. Agentic RAG versus RAG mit mehreren Schritten
Nicht jede mehrstufige Pipeline ist agentisch.
Beispiel:
Rewrite
→ Retrieve
→ Rerank
→ Generate
→ Verify
Wenn diese Reihenfolge immer feststeht, ist das primär eine Pipeline.
Agentisch wird es, wenn das System abhängig vom Zustand entscheidet:
Was mache ich als Nächstes?
104. Entscheidungsfreiheit als Kern
Der entscheidende Unterschied ist also nicht:
Wie viele Schritte gibt es?
Sondern:
Wer entscheidet zur Laufzeit über den nächsten Schritt?
Starre Pipeline:
Programm entscheidet vorher.
Agent:
Modell / Policy entscheidet während der Ausführung.
105. Deterministische Orchestrierung
Nicht jede Entscheidung sollte dem LLM überlassen werden.
Beispielsweise:
Wenn user.hasPermission == false
→ deny
sollte deterministisch bleiben.
Agentic RAG bedeutet nicht:
Das LLM kontrolliert alles.
106. Agentische und deterministische Logik kombinieren
Ein robustes System kann kombinieren:
Deterministic Security Rules
+
Agentic Planning
+
Deterministic Tool Execution
+
Grounding Verification
Das ist oft sinnvoller als vollständige Modellautonomie.
107. Agentic Retrieval
Man kann auch enger von Agentic Retrieval sprechen.
Dabei entscheidet ein Agent speziell über die Informationsbeschaffung.
Beispielsweise:
Question
↓
Agent
├─ Search A
├─ Search B
├─ Refine Query
├─ Search Again
└─ Stop
Die Antwortgenerierung kann danach weiterhin relativ klassisch erfolgen.
108. Planning Agent
Ein Agent kann zunächst einen Plan erstellen:
Question
↓
Planner
↓
Step 1
Step 2
Step 3
Danach werden die Schritte ausgeführt.
Das nennt man häufig Plan-and-Execute.
109. Plan-and-Execute
Vereinfacht:
Goal
↓
Planner
↓
Plan
↓
Executor
↓
Observations
↓
Final Answer
Bei Bedarf kann der Plan angepasst werden.
110. ReAct
Ein bekanntes allgemeines Agentenmuster ist ReAct:
Reason + Act.
Konzeptionell wechselt das Modell zwischen:
Reason
→
Action
→
Observation
→
Reason
→
Action
Damit können Informationssuche und Schlussfolgerung miteinander verzahnt werden.
111. ReAct und RAG
Wenn eine der verfügbaren Actions:
retrieve_documents
ist, kann ReAct als Grundlage für agentisches Retrieval dienen.
Aber ReAct selbst ist nicht gleich RAG.
Es ist ein allgemeineres Agentenmuster.
112. Tool Selection
Ein Agent kann zwischen mehreren Tools wählen:
Question
↓
Agent
│
├── Document Search
├── Database
├── Calculator
├── Knowledge Graph
└── API
Damit verschwimmt die Grenze zwischen:
RAG
und:
Tool-augmented Generation
113. Wann ist es noch RAG?
Wenn externe Informationen retrieved und als Kontext für die Antwort verwendet werden, bleibt Retrieval ein zentraler Bestandteil.
Aber bei einem Agenten, der:
- Datenbanken abfragt,
- APIs aufruft,
- Berechnungen durchführt,
- Dateien verändert,
- Aktionen ausführt,
ist „RAG“ allein möglicherweise keine ausreichende Beschreibung mehr.
Das Gesamtsystem ist dann eher ein agentisches Tool-Using-System, in dem RAG eine Fähigkeit darstellt.
114. Agentic RAG ist also kein Ersatz für RAG
Besser:
Agent
│
├── RAG
├── Database
├── API
└── Other Tools
RAG kann ein Werkzeug innerhalb eines Agentensystems sein.
115. Agentic RAG und Multi-Hop
Multi-Hop Retrieval kann agentisch implementiert werden.
Muss aber nicht.
Deterministisch:
immer maximal 3 Retrieval-Hops
Agentisch:
Agent entscheidet nach jedem Hop,
ob weitere Evidenz benötigt wird.
116. Stop Condition
Agentische Systeme benötigen eine Stop Condition.
Sonst könnte ein Agent endlos:
search
→ search
→ search
→ search
ausführen.
Mögliche Stop-Kriterien:
Evidence sufficient
Maximum iterations reached
Maximum token budget reached
Maximum cost reached
No new evidence found
117. Budget
Agenten benötigen deshalb oft ein explizites Budget.
Beispielsweise:
max 5 retrieval calls
max 20'000 retrieved tokens
max 3 reasoning loops
max execution time
Ohne Grenzen kann adaptive Suche teuer und langsam werden.
118. Agentic RAG und Latenz
Naive RAG:
1 Retrieval
+
1 Generation
Agentic:
Planning
+
Retrieval
+
Evaluation
+
Retrieval
+
Tool Call
+
Verification
+
Generation
Die Qualität kann steigen.
Aber die Latenz ebenfalls erheblich.
119. Agentic RAG und Kosten
Dasselbe gilt für Kosten.
Jeder zusätzliche:
LLM Call
Retriever Call
Reranker Call
Tool Call
verbraucht Ressourcen.
Agentische Systeme benötigen deshalb besonders gute Observability.
120. Agent Loops können fehlschlagen
Ein Agent kann:
- die falsche Suchstrategie wählen,
- unnötig oft suchen,
- falsche Zwischenschlüsse ziehen,
- wichtige Evidenz ignorieren,
- zu früh stoppen,
- nie stoppen.
Mehr Autonomie bedeutet auch mehr mögliche Fehlerpfade.
121. Error Compounding
Besonders problematisch ist Error Compounding.
Beispiel:
Hop 1:
falsche Entität gewählt
↓
Hop 2:
Suche basiert auf falscher Entität
↓
Hop 3:
weitere falsche Evidenz
↓
Answer:
plausibel, aber falsch
Fehler können sich über mehrere Schritte verstärken.
122. Intermediate Verification
Deshalb können Zwischenschritte geprüft werden.
Retrieve
↓
Verify
↓
Next Hop
↓
Verify
↓
Generate
Das reduziert Error Compounding, erhöht aber wiederum Kosten und Latenz.
123. Trajectory
Die Folge von Agentenaktionen wird häufig als Trajectory bezeichnet.
Beispiel:
Query
→ Search A
→ Read Result
→ Search B
→ Read Result
→ Compare
→ Answer
Die Qualität des Agenten hängt nicht nur von der finalen Antwort ab.
Auch die Trajectory kann bewertet werden.
124. Agent Trace
Ähnlich wie der RAG Trace aus Teil 6 sollte ein Agentensystem protokollieren:
Goal
Plan
Actions
Tool Inputs
Tool Outputs
Retrieved Sources
Intermediate Decisions
Final Evidence
Answer
Ohne diesen Trace wird Debugging sehr schwierig.
125. Observability wird wichtiger
Bei Naive RAG kann man prüfen:
Query
Top-k
Prompt
Answer
Bei Agentic RAG muss man möglicherweise zwanzig Zwischenschritte verstehen.
Mit wachsender Systemintelligenz wächst deshalb auch der Bedarf an Observability.
126. Agentic RAG und Grounding
Agentisches Retrieval löst Grounding nicht automatisch.
Der Agent kann zehn perfekte Suchschritte durchführen und am Ende trotzdem eine unbelegte Aussage generieren.
Deshalb bleiben die Prinzipien aus Teil 6 gültig:
Evidence
↓
Answerability
↓
Grounded Generation
↓
Citation
↓
Verification
127. Advanced RAG ersetzt die Grundlagen nicht
Das ist vielleicht die wichtigste Erkenntnis dieses Teils.
Keiner dieser Ansätze repariert automatisch:
schlechtes Parsing
schlechtes Chunking
schlechte Embeddings
schlechte Metadaten
schlechte Quellen
fehlende Grounding-Regeln
Advanced RAG baut auf den Grundlagen auf.
Es ersetzt sie nicht.
128. Schlechte Chunks plus Agent
Wenn ein Agent fünfmal auf einem schlecht aufgebauten Index sucht, erhält man nicht automatisch gute Ergebnisse.
Man erhält möglicherweise:
fünfmal schlechtes Retrieval
Agentische Komplexität kann grundlegende Datenprobleme sogar verschleiern.
129. Wann sollte man Advanced RAG einsetzen?
Nicht:
Weil Agentic RAG moderner klingt.
Sondern wenn eine konkrete Fehlerklasse existiert.
Beispielsweise:
Problem:
ein Retrieval-Schritt reicht nicht
→ Multi-Hop
Problem:
komplexe Fragen enthalten mehrere Teilfragen
→ Query Decomposition
Problem:
Retriever liefert manchmal schlechte Evidenz
→ Corrective Retrieval
Problem:
Fragen betreffen globale Dokumentzusammenhänge
→ hierarchisches Retrieval / RAPTOR
Problem:
Beziehungen zwischen Entitäten sind zentral
→ GraphRAG
Problem:
Single-vector Retrieval verliert zu viel Tokeninformation
→ Late Interaction / ColBERT
Problem:
Suchstrategie muss dynamisch gewählt werden
→ Agentic Retrieval
130. Problem zuerst, Technik danach
Das ist eine gute allgemeine Regel:
Observed Failure
↓
Understand Failure
↓
Choose Technique
Nicht:
Interesting Technique
↓
Force it into architecture
RAG-Systeme können sonst sehr schnell unnötig komplex werden.
131. Die Advanced-RAG-Landschaft als Ebenenmodell
Die vielen Begriffe werden verständlicher, wenn wir sie verschiedenen Ebenen zuordnen.
Ebene 1 – Repräsentation
Wie wird Wissen repräsentiert?
Chunks
Hierarchies
Graphs
Multi-vector representations
Ebene 2 – Retrieval
Wie wird gesucht?
Dense
Sparse
Hybrid
Late Interaction
Graph Traversal
Ebene 3 – Query Processing
Wie wird die Frage vorbereitet?
Rewrite
Multi-Query
Decomposition
HyDE
Ebene 4 – Retrieval Control
Wie wird entschieden, ob weitergesucht werden muss?
Adaptive Retrieval
Corrective Retrieval
Self-RAG
Ebene 5 – Orchestration
Wer entscheidet über den Ablauf?
Fixed Pipeline
Router
Planner
Agent
Ebene 6 – Generation Control
Wie wird die Antwort abgesichert?
Grounding
Answerability
Verification
Citations
Viele vermeintlich konkurrierende Verfahren liegen also auf völlig unterschiedlichen Ebenen.
132. Die Begriffe im direkten Vergleich
| Ansatz | Primäres Problem | Kernidee |
|---|---|---|
| Naive RAG | externe Evidenz bereitstellen | Retrieve → Generate |
| Advanced RAG | Qualität der einfachen Pipeline verbessern | zusätzliche Retrieval-/Processing-Schritte |
| Modular RAG | starre Pipeline | austauschbare und kombinierbare Module |
| Adaptive RAG | jede Query gleich behandeln | Strategie an Query anpassen |
| Multi-Hop RAG | Antwort benötigt mehrere Informationsschritte | sequenzielles Retrieval |
| Self-RAG | starres Retrieval und fehlende Selbstbewertung | Retrieval + Reflection |
| CRAG | schlechte Retrieval-Ergebnisse | Retrieval bewerten und korrigieren |
| RAPTOR | lokale Chunks erfassen globale Zusammenhänge schlecht | hierarchische abstraktive Repräsentationen |
| GraphRAG | Beziehungen sind in Textretrieval nur implizit | Wissen als Graph nutzen |
| ColBERT | Informationsverlust durch Single-Vector Retrieval | Token-Level Late Interaction |
| Agentic RAG | Ablauf muss dynamisch entstehen | Agent plant und steuert Retrieval |
133. Diese Verfahren sind kombinierbar
Ein System könnte theoretisch verwenden:
Query
↓
Agent
↓
Query Decomposition
↓
Router
├── ColBERT
├── BM25
└── Graph Retrieval
↓
Fusion
↓
Reranking
↓
Corrective Evaluation
↓
Need More Evidence?
├── Yes → Agent Loop
└── No
↓
Grounded Generation
↓
Verification
Das wäre extrem leistungsfähig.
Aber auch extrem komplex.
134. Mehr Komponenten bedeuten mehr Fehlerquellen
Jede zusätzliche Komponente bringt:
Configuration
Evaluation
Latency
Cost
Failure Modes
Observability Requirements
Maintenance
mit sich.
Ein komplexeres System ist nicht automatisch ein besseres System.
135. Complexity Budget
Neben Token- und Kostenbudgets kann man deshalb auch gedanklich von einem Complexity Budget sprechen.
Jede zusätzliche Technik sollte eine Frage beantworten:
Welches gemessene Problem löst diese Komponente?
Wenn die Antwort unklar ist, ist die Komponente möglicherweise nicht notwendig.
136. RAG Reifegrad
Man kann RAG-Systeme grob als Entwicklung betrachten:
Level 1
Naive Retrieval
↓
Level 2
Hybrid + Reranking
↓
Level 3
Context Engineering + Grounding
↓
Level 4
Adaptive / Corrective Retrieval
↓
Level 5
Hierarchical / Graph Retrieval
↓
Level 6
Agentic Orchestration
Das ist keine offizielle Klassifikation.
Es ist lediglich ein nützliches mentales Modell.
Und wichtig:
Ein höheres Level ist nicht automatisch besser.
137. Einfache Systeme sind leichter zu evaluieren
Bei:
Query
→ Top-k
→ Answer
kann man relativ klar messen:
War der richtige Chunk in Top-k?
Bei:
Agent
→ Query Rewrite
→ Graph Search
→ Vector Search
→ New Query
→ Search
→ Verification
→ Answer
wird schwieriger zu bestimmen:
Welcher Schritt war für Erfolg oder Misserfolg verantwortlich?
138. Evaluation wird deshalb zentral
Je komplexer die Pipeline, desto wichtiger werden:
- Retrieval-Metriken,
- Ranking-Metriken,
- Grounding-Metriken,
- End-to-End-Evaluation,
- Agent-Trajectory-Evaluation,
- Sicherheitsprüfungen.
Damit führt Advanced RAG direkt zu unserem letzten Teil.
139. Ein vollständiges mentales Modell
Nach sieben Teilen können wir RAG nun deutlich umfassender darstellen:
KNOWLEDGE
│
▼
Documents
│
Parsing / OCR
│
Chunking
│
┌────────────┼────────────┐
▼ ▼ ▼
Sparse Dense Graph
Index Index Model
│ │ │
└────────────┼────────────┘
│
▼
QUERY
│
Query Understanding
│
Rewrite / Decompose
│
▼
Retrieval Router
┌────────────┼────────────┐
▼ ▼ ▼
BM25 Dense Graph Search
│ │ │
└────────────┼────────────┘
▼
Fusion
│
Reranking
│
Evidence Evaluation
│
┌─────────┴─────────┐
│ │
insufficient sufficient
│ │
▼ ▼
Correct / Retrieve Context Build
Again │
│ ▼
└──────────► Grounded Generation
│
▼
Verification
│
▼
Answer
Bei einem agentischen System wird diese Pipeline nicht mehr zwingend einmal von oben nach unten durchlaufen.
Stattdessen kann ein Controller beziehungsweise Agent einzelne Teile wiederholt aufrufen.
140. Die agentische Variante
┌───────────────────────┐
│ │
▼ │
Observe │
│ │
▼ │
Plan │
│ │
▼ │
Choose Action │
│ │
┌─────────┼─────────┐ │
▼ ▼ ▼ │
Search Graph Tool │
│ │ │ │
└─────────┼─────────┘ │
▼ │
Evidence │
│ │
▼ │
Enough Evidence? │
│ │ │
Yes No ───────────────┘
│
▼
Grounded Generation
│
▼
Verification
│
▼
Answer
Das ist die wesentliche Entwicklung:
RAG als Pipeline
wird zu:
RAG als kontrollierbarer Informationsprozess
141. Die wichtigste Erkenntnis aus Teil 7
Advanced RAG ist nicht eine einzelne Technologie.
Es ist eine Sammlung unterschiedlicher Antworten auf unterschiedliche Grenzen klassischer RAG-Systeme.
Man sollte deshalb nicht fragen:
Was ist die beste Advanced-RAG-Technik?
Sondern:
Welche Art von Informationsproblem versuche ich zu lösen?
Wenn die Information lokal und leicht auffindbar ist:
klassisches RAG
kann perfekt sein.
Wenn mehrere Informationsschritte notwendig sind:
Multi-Hop
kann helfen.
Wenn Retrieval-Ergebnisse bewertet und korrigiert werden müssen:
CRAG
wird interessant.
Wenn Retrieval selbst Teil der Modellreflexion werden soll:
Self-RAG
wird relevant.
Wenn globale und lokale Dokumentinformationen auf verschiedenen Abstraktionsebenen benötigt werden:
RAPTOR
bietet eine andere Repräsentation.
Wenn Beziehungen zwischen Entitäten zentral sind:
GraphRAG
kann eine geeignete Struktur liefern.
Wenn Single-Vector Retrieval zu grob ist:
ColBERT / Late Interaction
adressiert das Retrieval selbst.
Wenn der Ablauf nicht im Voraus bekannt ist:
Agentic RAG
ermöglicht dynamische Orchestrierung.
Diese Ansätze konkurrieren also nicht zwingend miteinander.
Sie liegen häufig auf unterschiedlichen Ebenen eines RAG-Systems.
142. Aber wie wissen wir, ob das alles tatsächlich besser ist?
Damit bleibt eine entscheidende Frage offen.
Angenommen, wir bauen:
Hybrid Search
+
Reranking
+
Query Decomposition
+
GraphRAG
+
Agent
+
Grounding Verification
Wie wissen wir, ob das System besser geworden ist?
Ist Retrieval tatsächlich besser?
Sind die richtigen Dokumente in Top-k?
Steht der relevante Treffer auf Position 1 oder Position 20?
Sind die Antworten quellengetreu?
Sind die Citations korrekt?
Wann sollte das System nicht antworten?
Wie testen wir RAG reproduzierbar?
Wie schützen wir das System gegen:
Prompt Injection
RAG Poisoning
unauthorized retrieval
Und wann sollte man überhaupt RAG verwenden – statt:
Fine-Tuning
Tool Calling
Long Context
Search
Damit kommen wir zum letzten Teil dieser Serie:
Teil 8 – RAG messen, absichern und richtig einordnen
Dort schliessen wir den Kreis mit:
- Hit@k,
- Recall@k,
- Precision@k,
- MRR,
- nDCG,
- Retrieval Evaluation,
- Grounding Evaluation,
- Faithfulness,
- Answer Relevance,
- Citation Evaluation,
- Answerability,
- Golden Datasets,
- LLM-as-a-Judge,
- RAGAS,
- Prompt Injection,
- Indirect Prompt Injection,
- RAG Poisoning,
- Zugriffskontrolle,
- RAG versus Fine-Tuning,
- RAG versus Tool Calling,
- RAG versus Long Context
und der entscheidenden Frage:
Wie weiss ich, ob mein RAG-System tatsächlich funktioniert?
RAG von Grund auf
Teil 1 – RAG verstehen
LLM, parametrisches Wissen, Kontext, Retrieval, Augmentation, Generation und Grounding.
Teil 2 – Dokumente, Parsing und Chunking
Ingestion, Parser, OCR, Dokumentstruktur, Chunks, Overlap, Structured Chunking, Parent-Child und Small-to-Big.
Teil 3 – Embeddings und Vektorsuche
Embeddings, Dense Vectors, Bi-Encoder, Cosine Similarity, ANN, HNSW und Vector Stores.
Teil 4 – Information Retrieval und Hybrid Search
TF, IDF, TF-IDF, BM25, Sparse Retrieval, Hybrid Search und Reciprocal Rank Fusion.
Teil 5 – Reranking und Retrieval-Strategien
Cross-Encoder, Retrieve-then-Rerank, MMR, Query Rewrite, Multi-Query, Query Decomposition, HyDE, Context Selection und Compression.
Teil 6 – Kontext, Grounding und quellengebundene Antworten
Context Window, Token Budget, Context Packing, Lost in the Middle, Grounding, Faithfulness, Citations, Answerability, Abstention und Grounding Verification.
Teil 7 – Advanced RAG, GraphRAG und Agentic RAG
Advanced RAG, Modular RAG, Adaptive RAG, Multi-Hop, Self-RAG, CRAG, RAPTOR, GraphRAG, ColBERT, Late Interaction und Agentic RAG.
Teil 8 – Evaluation, Sicherheit und Abgrenzung
Hit@k, Recall@k, Precision@k, MRR, nDCG, RAG-Evaluation, Grounding-Evaluation, Prompt Injection, RAG Poisoning, Fine-Tuning, Tool Calling und Long Context.