Kartierung von RAG: Pipelineschritte, Kernkomponenten und das Variantenlandschaft
Verstehen Sie, wie Retrieval-augmented Generation von Anfang bis Ende funktioniert, welche Komponenten ein RAG-System benötigt und wie die vielen verschiedenen RAG-Varianten in einem Gesamtbild zusammenpassen.
Quellen: The Complete Guide to RAG — Part 1: What It Is, Why It Exists & How It Works
Ein Sprachmodell kann beeindruckend reasoning-fähig sein und dennoch nichts über Ihre interne Dokumentation, die Richtlinienänderung von letzter Woche oder das vor einer Stunde eingereichte Ticket wissen. Retrieval-augmented Generation (RAG) schließt diese Lücke, indem das Modell vor der Beantwortung in einer externen Wissensquelle nach Informationen suchen kann. Diese Anleitung erläutert die Probleme, die RAG löst und welche nicht, die drei Phasen eines RAG-Systems, die Komponenten, die man zum Aufbau benötigt, sowie eine Übersicht zur Orientierung in der langen Liste der verschiedenen RAG-Varianten.
RAG in einem Satz
RAG kombiniert zwei Prozesse:
- Auswertung: Das Finden relevanter Informationen in einer externen Wissensquelle.
- Erstellung: Das Erzeugen einer Antwort durch ein Sprachmodell, die auf den gefundenen Informationen beruht.
Einfach ausgedrückt gibt RAG dem Modell eine Referenzbibliothek zur Verfügung, auf die es sich vor der Antwort beziehen kann. Die Forschung, die diesen Ansatz einführte, beschrieb ihn als Kombination aus dem parametrischen Speicher des Modells – den während des Trainings in seinen Gewichten gespeicherten Kenntnissen – und einem nicht-parametrischen Speicher, also einem externen Index, der unabhängig gesucht und aktualisiert werden kann.
Eine Vergleichsmetapher ist ein Prüfungsszenario mit offenen Büchern:
- Das LLM ist der Schüler.
- Die Wissensbasis ist das Lehrbuch.
- Das Auswahlsystem ist der Schüler, der zu den richtigen Seiten blättert.
- Die endgültige Antwort ist die Antwort des Schülers, verfasst mit diesen Seiten geöffnet.
Das Modell liefert das Denken und die fließende Sprache; das Auswahlsystem liefert die Fakten, die für diese spezifische Frage relevant sind.
Die Probleme, die RAG lösen soll
Das Alleinverlassen auf das eingebaute Wissen eines Modells stößt auf mehrere praktische Grenzen. Für jede dieser Grenzen bietet RAG eine teilweise Lösung.
Wissen, das nur bis zum Trainingszeitpunkt reicht
Ein Modell kann nichts über Dinge wissen, die nach der Sammlung seiner Trainingsdaten hinzugefügt oder geändert wurden. Mit RAG befindet sich aktuelle Informationen in einem externen Speicher, den Sie jederzeit aktualisieren können, ohne das Modell anzufassen.
Nicht unterstützte oder erfundene Antworten
Modelle erzeugen manchmal Aussagen, die falsch sind oder keinen Grund haben. Die abgerufenen Belege geben dem Modell etwas Konkretes, woran es sich orientieren kann, wodurch ununterstützte Ausgaben reduziert werden. Dies eliminiert sie jedoch nicht: Die Abfrage kann falsche Abschnitte zurückgeben, die Quellen selbst können ungenau sein, und das Modell kann weiterhin Behauptungen aufstellen, die von den Belegen nicht gestützt werden.
Private Daten, die das Modell noch nie gesehen hat
Ein allgemein einsetzbares Modell hat keinen Zugriff auf interne Dokumente Ihrer Organisation, proprietären Code oder vertrauliche Informationen. RAG ermöglicht es einer Anwendung, zum Zeitpunkt der Abfrage auf autorisierte private Quellen zuzugreifen, ohne dass dafür ein Neutraining des Modells erforderlich ist. Der Zugriffskontrollmechanismus bleibt weiterhin wichtig: Der Informationsabruf sollte nur das zurückgeben, was der aktuelle Benutzer lesen darf.
Informationen, die sich häufig ändern
Richtlinien, Produkt- und Technikdokumentation sowie interne Aufzeichnungen ändern sich ständig. Das Hinzufügen oder Aktualisieren von Einträgen im Informationsabrufindex ist weitaus günstiger und schneller als jedes Mal ein Neutraining eines Sprachmodells bei jeder Änderung.
Dokumente, die zu groß sind, um vollständig übertragen zu werden
Das Einfügen ganzer Dokumente in jede Anfrage verschwendet Ressourcen und Geld. RAG überträgt nur die relevanten Teile der Wissensbasis, wodurch die Anfragen gezielter und kürzer bleiben.
Störgeräusche aus irrelevantem Kontext
Zu viel lose miteinander verbundenes Material erschwert es dem Modell, die wichtigen Beweise zu finden. Filtern, Neuranking und Kontextkompression dienen alle dazu, die Qualität dessen zu verbessern, was schließlich beim Modell ankommt.
RAG verbessert die Grundlage für die Antworten und verringert das Auftreten von Halluzinationen, bietet aber keine Garantie für genaue oder halluzinationsfreie Antworten. Betrachten Sie es als Zuverlässigkeitswerkzeug, nicht als Beweis für Korrektheit.
Die drei Phasen eines RAG-Systems
Phase 1: Indizierung
Die Indizierung findet statt, bevor ein Benutzer eine Frage stellt. Quellmaterialien wie PDFs, Webseiten, Dokumentationen oder Datenbankzeilen werden:
- in das System geladen,
- in kleinere Abschnitte aufgeteilt,
Das Ergebnis ist eine suchbare Darstellung Ihres Wissens. Konzeptionell erstellen Sie damit einen Suchindex für Ihre eigenen Daten.
Phase 2: Abfrage
Wenn eine Frage eintrifft:
- wird die Anfrage mit demselben Modell wie bei der Indexierung in ein Embedding umgewandelt,
- wird in der Wissensdatenbank nach nahegelegenen Vektoren gesucht,
- werden die relevantesten Teile ausgewählt,
- optionales Filtern oder Neuranking präzisiert die Auswahl.
Der Ablauf von der Frage bis zu den potenziellen Antwortteilen sieht so aus:
User Query
│
▼
[Embedding Model]
│
▼
[Query Vector]
│
▼
[Vector Database]
│
▼
[Relevant Chunks]
Die wichtige Eigenschaft ist, dass Abfragen und Dokumente im selben Vektorraum existieren. Deshalb muss das Embedding-Modell, das zur Abfragezeit verwendet wird, mit dem übereinstimmen, das zum Erstellen des Indexes genutzt wurde; die Kombination verschiedener Modelle erzeugt Vektoren, die nicht sinnvoll verglichen werden können.
Schritt 3: Generierung
Die ausgewählten Abschnitte werden zusammen mit der Frage des Benutzers zu einem Prompt kombiniert, und das Modell erzeugt daraufhin die Antwort:
User Query
+
Retrieved Context
│
▼
[Prompt / Context]
│
▼
[LLM]
│
▼
Final Answer
Die resultierende Antwort stützt sich auf die allgemeinen Fähigkeiten des Modells sowie auf die spezifischen Belege aus Ihrer Wissensquelle. Die Art und Weise, wie der Prompt diese Belege präsentiert – beispielsweise durch Quellensymbole, auf die das Modell verweisen kann – beeinflusst stark, inwieweit die Antwort diesen Belegen treu bleibt.
Innere Struktur des Indexierungsprozesses
Durch die Indexierung wird der größte Teil der Qualität eines RAG-Systems bestimmt. Ihre grundlegende Struktur sieht wie folgt aus:
Raw Data
│
▼
Document Loader
│
▼
Text Chunking
│
▼
Embedding Model
│
▼
Vector Database
Rohdaten
Wissen kann fast überallher stammen:
- PDFs
- Websites
- Dokumentation
- Word-Dokumente
- Datenbanken
- APIs
- Interne Unternehmensdateien
Dokumentlader
Ein Dokumentlader liest eine Quelle und wandelt sie in eine einheitliche Struktur um, die der Rest des Pipelines verarbeiten kann. In LangChain teilen beispielsweise die Lader eine gemeinsame Schnittstelle, die Document-Objekte erzeugt, und sie können sowohl load() als auch lazy_load() bereitstellen. Die verzögerte Variante liefert die Dokumente nacheinander aus, anstatt alles im Speicher zu materialisieren – was bei großen Sammlungen wichtig ist. LangChain und LlamaIndex sind die beiden Ökosysteme, mit denen die meisten Menschen beginnen.
Chunking
Große Dokumente werden in kleinere Teile aufgeteilt, die als Chunks bezeichnet werden, denn es ist in der Regel nützlicher, den relevanten Abschnitt eines Dokuments abzurufen, anstatt dem Modell das gesamte Dokument zur Verarbeitung zu geben. Eine gute Analogie ist die Umwandlung eines Buches in einen Stapel Indexkarten, wobei jede Karte eine Idee darstellt.
Für die Größe der Chunks sowie deren Überschneidung gibt es keine universell richtigen Werte. Sie hängen davon ab, wie Ihre Dokumente strukturiert sind, welche Arten von Fragen Sie erwarten, welches Embedding-Modell Sie verwenden und wie viel Kontext Sie später noch verarbeiten können. Zu kleine Chunks führen zum Verlust des umgebenden Kontexts; zu große Chunks schwächen das Signal der wichtigsten Aussage ab. Für eine ausführlichere Betrachtung dieses Kompromisses siehe Chunking, das Beweise bewahrt.
Embedding-Modelle
Jeder Teilabschnitt wird in ein Embedding umgewandelt, eine Liste von Zahlen, die seine Bedeutung darstellt:
"RAG retrieves relevant information"
↓
[0.24, 0.87, 0.11, 0.62, ...]
Embeddings ermöglichen es einem System, zu messen, wie eng miteinander zwei Inhalte verbunden sind – das ist die Grundlage für semantische Suche und Abruf: Texte mit ähnlicher Bedeutung liegen im Vektorraum nah beieinander, selbst wenn sie nur wenige Wörter teilen.
In OpenAI’s text-embedding-3-Familie liefert das kleine Modell standardmäßig 1536-dimensionalen Vektoren, während das große Modell 3072 Dimensionen liefert.
Sowohl Modelle akzeptieren einen dimensions-Parameter, um kürzere Vektoren anzufordern – dabei wird etwas Genauigkeit zugunsten geringerer Speicherkapazitäten und schnellerer Suche geopfert. Die Modellangebote ändern sich, daher sollten Sie die aktuellen Optionen in der Dokumentation des Anbieters überprüfen.
Vektordatenbanken
Die Embeddings werden in einer Vektordatenbank oder einem Vektorindex gespeichert, der für schnelle Ähnlichkeitssuche konzipiert ist. Häufige Optionen sind:
- Qdrant
- Pinecone
- Chroma
- Weaviate
- FAISS
Ein gespeichertes Datensatz enthält in der Regel mehr als nur den Vektor. Er beinhaltet außerdem den ursprünglichen Textabschnitt sowie Metadaten wie Quelle, Seitenzahl, Dokument-ID oder Zeitstempel. Gerade diese Metadaten ermöglichen es später, nach Datum oder Dokumenttyp zu filtern und anzugeben, woher eine Antwort stammt.
Die Bausteine einer RAG-Anwendung
Insgesamt setzt sich eine typische RAG-Anwendung aus sechs Arten von Komponenten zusammen:
- Wissensquelle: liefert die Informationen, beispielsweise PDFs, Webseiten, SQL-Datenbanken oder APIs.
- Textteiler: teilt Dokumente in verarbeitbare Abschnitte auf, wobei entweder LangChain’s Textteiler oder eigene Logiken verwendet werden.
Eine Übersicht der RAG-Familie
Sobald das grundlegende Verarbeitungsverfahren klar ist, kann das Ökosystem der verschiedenen Varianten überwältigend erscheinen. Es gibt keine einzige kanonische Liste der RAG-Typen; wissenschaftliche Arbeiten und Engineering-Blogs verwenden überschneidende Bezeichnungen für Architekturen, Suchstrategien, Kontexttechniken, Wissensquellen und spezialisierte Systeme. Die Gruppierung nach den veränderten Aspekten macht das Gesamtbild übersichtlicher.
Basische Architekturen
- Naiver RAG: der einfache Ablauf aus Einbetten, Suchen und Erzeugen.
- Fortgeschrittener RAG: es werden Schritte vor und nach der Informationsbeschaffung hinzugefügt, wie z. B. die Umformulierung der Anfrage und das Neurankieren.
- Modularer RAG: jede Phase wird als austauschbares Modul behandelt, das neu kombiniert werden kann.
Strategien zur Informationsbeschaffung
- Einzugangsprüf-RAG: eine Informationsbeschaffung pro Frage.
- Mehrfachanfragen-RAG: es werden mehrere Formulierungen der Frage erstellt und für jede eine Informationsbeschaffung vorgenommen.
- Iterativer RAG: Informationsbeschaffung, Abwägung und erneute Informationsbeschaffung.
- Mehrfachschritt-RAG: mehrere Informationsbeschaffungen werden nacheinander durchgeführt, wenn die Antwort die Verknüpfung mehrerer Fakten erfordert.
- Hybrid-RAG: es wird die semantische Vektorsuche mit der Schlüsselwortsuche kombiniert.
- RAG Fusion: fügt die Ergebnisse mehrerer Abfragen zu einer einzigen Rangliste zusammen.
- Self-Query RAG: ermöglicht es dem Modell, die Frage in eine Suche zusammen mit Metadatenfiltern umzuwandeln.
Kontext- und Chunking-Ansätze
- Parent-Child RAG: vergleicht kleine Abschnitte, gibt aber den größeren übergeordneten Abschnitt zurück.
- Sentence Window RAG: holt einen Satz zusammen mit seinen Nachbarsätzen ab.
- Hierarchical RAG: durchsucht die Ebenen, von Dokumenten bis hin zu Abschnitten.
- Contextual RAG: bereichert die Abschnitte vor dem Einbetten mit kontextuellen Informationen auf Dokumentenebene.
- RAPTOR: erstellt einen Baum aus rekursiven Zusammenfassungen und sucht in seinen Ebenen.
Selbstkorrigierende und anpassungsfähige Ansätze
- Self-RAG: Das Modell prüft, ob eine Informationsbeschaffung notwendig ist und ob seine Ausgabe durch die gefundenen Daten gestützt wird.
- Corrective RAG (CRAG): Es bewertet die ermittelten Ergebnisse und löst eine ergänzende Informationsbeschaffung aus, wenn diese unzureichend sind.
- Adaptive RAG: Jede Frage wird einer Strategie zugeordnet, die zu ihrer Komplexität passt.
- Feedback-based RAG: Es nutzt Feedback von Nutzern oder Bewertern, um im Laufe der Zeit die Informationsbeschaffung zu verbessern.
Agentenbasierte Ansätze
- Agentic RAG
- Multi-Hop Agentic RAG
- Multi-Agent RAG
Dabei entscheidet ein Agent, wann und wo Informationen beschafft werden sollen – möglicherweise über mehrere Tools oder kooperierende Agenten – anstatt einem festgelegten Ablauf zu folgen.
Varianten, die durch die Wissensquelle definiert werden
Mehrere Bezeichnungen beschreiben lediglich die Herkunft der Beweismittel. Vector RAG durchsucht einen Embedding-Index, während SQL RAG und Table RAG relationale oder tabellarische Daten abrufen, oft indem das Modell die Abfrage erstellt. GraphRAG holt Informationen aus einem Wissensgraphen von Entitäten und Beziehungen, Web oder Search RAG zieht aktuelle Ergebnisse aus einem Suchmaschinen ab, und Knowledge-Base RAG nutzt ein sorgfältig zusammengestelltes Korpus wie ein Helpcenter oder eine Wiki.
Multimodale Varianten
Weitere Bezeichnungen beziehen sich auf die Art des abgerufenen Inhalts. Text RAG ist der Standardfall; Image, Video und Audio RAG holen Informationen aus diesen Medien ab, typischerweise über Embeddings oder Transkripte, und Multimodal RAG ist der Sammelbegriff für Systeme, die mehrere dieser Ansätze kombinieren.
Spezialisierte Varianten
Ein letzte Gruppe von Systemen für Namensgebung, die auf spezifische Anforderungen abgestimmt sind: ein einzelnes Feld wie Recht oder Medizin (domain-spezifisch), zeitbezogene Fragen, bei denen die Aktualität wichtig ist (temporal), Antworten, die an einen einzelnen Benutzer angepasst sind (personalisiert), Abfragen und Quellen in mehreren Sprachen (multilingual), sensible Daten, die geschützt bleiben müssen (Datenschutz), sowie Indizes, die über mehrere Standorte oder Organisationen verteilt sind (verteilt oder federiert).
Diese Gruppen überschneiden sich frei. Ein echtes Produktionsystem kann gleichzeitig hybrid, agentbasiert und domain-spezifisch sein; die Bezeichnungen beschreiben Designentscheidungen, nicht gegenseitig ausschließende Produkte.
Von naiven zu fortgeschrittenen Pipelines
Der einfachste Pipeline ist eine gerade Linie:
Query
↓
Embedding
↓
Vector Search
↓
Top-K Chunks
↓
LLM
↓
Answer
Das ist gemeint, wenn von naiven oder grundlegenden RAG-Systemen die Rede ist: Die Frage wird eingebettet, die k-k nächsten Passagen ausgewählt und an das Modell übergeben. Es handelt sich um eine sinnvolle Erstversion, die oft bereits für kleine, strukturierte Korpora ausreicht.
Reifere Systeme fügen zusätzliche Schritte vor der Informationsbeschaffung ein:
User Query
↓
Query Rewriting
↓
Query Routing
↓
Hybrid Retrieval
↓
Metadata Filtering
↓
Reranking
↓
Context Compression
↓
LLM
↓
Answer
Jeder dieser Schritte behebt eine bestimmte Schwäche. Die Umformulierung von Abfragen korrigiert vage oder konversationelle Anfragen, die Routierung leitet die Frage an den richtigen Index oder das richtige Tool weiter, die hybride Informationsbeschaffung erfasst präzise Begriffe, die eine reine Vektorsuche übersieht, das Filtern nach Metadaten entfernt Dokumente, die nicht zum Thema gehören, die Neubewertung ordnet die Kandidaten mit einem präziseren Modell neu, und die Komprimierung kürzt das Übrige, um den Ressourcenrahmen einzuhalten. Fügen Sie diese Schritte nur hinzu, wenn Sie die Probleme messen können, die sie lösen – Komplexität ist an sich kein Ziel.
Warum RAG mehr ist als eine Vektordatenbank plus ein LLM
Eine weit verbreitete Annahme bei Anfängern ist, dass RAG gleichbedeutend mit „Embeddings speichern, danach abfragen und das Modell aufrufen“ ist. Ein Produktionspipeline sieht in der Regel eher so aus:
Document Processing
↓
Chunking
↓
Metadata
↓
Embedding
↓
Vector / Keyword Retrieval
↓
Filtering
↓
Reranking
↓
Context Compression
↓
Prompt Construction
↓
LLM
↓
Validation
↓
Final Answer
Jeder Schritt in dieser Kette kann die Endantwort verschlechtern: schlechte Parsing-Verarbeitung, nachlässiges Aufteilen in Blöcke, fehlende Metadaten, ein nicht passendes Embedding-Modell, schwache Filterung oder eine schlecht formulierte Anfrage. Deshalb ist die Verbindung eines Vektorstores mit einem Modell nur der Anfang. So leistungsfähig das Modell auch sein mag, es kann nicht vollständig ausgleichen, dass ihm falsche Informationen zur Verfügung gestellt werden.
Wie man ein RAG-System beurteilt
Die Erstellung einer Antwort ist nicht das Maßstab. Ein gutes RAG-System liefert wirklich nützliche Informationen und erzeugt eine Antwort, die tatsächlich von den abgerufenen Belegen gestützt wird. Die wichtigen Messkriterien sind:
- Qualität der Informationsabrufung: Werden tatsächlich die relevanten Dokumente oder Blöcke zurückgegeben?
Durch die getrennte Messung jeder Phase lassen sich Fehler diagnostizieren; der Ansatz der Bewertung von RAG nach Fehlerstufe zeigt, wie dies strukturiert werden kann.
Was kommt als Nächstes?
Die nächste Ebene der Tiefe ist der Indexierungsprozess selbst: Wie ein PDF in Text umgewandelt wird, der Unterschied zwischen Laden, Parsen und Reinigen, die Abwägungen bei der Aufteilung in Zeichen-, Token-, rekursive, semantische und strukturbezogene Blöcke, was eine Überlappung dieser Blöcke tatsächlich bewirkt, wie Metadaten gestaltet werden sollten, wie aus Text Vektoren entstehen, wie sich Kosinusähnlichkeit, Skalarprodukt und euklidische Distanz unterscheiden sowie wie eine Vektordatenbank Suchvorgänge in großem Umfang durchführt.
Kernpunkte
- RAG verbindet das trainierte Wissen eines Modells mit einem suchbaren externen Speicher, sodass Antworten private und aktuelle Informationen widerspiegeln können, ohne erneutes Trainieren.
- Es verringert unzulässige Antworten, garantiert aber nie die Korrektheit; die Abrufung, die Quellen sowie die Generierung können weiterhin fehlschlagen.