Wie funktioniert Retrieval-Augmented Generation (RAG) technisch genau?
Direkte Antwort
RAG verbindet eine Retrieval-Komponente mit einem LLM. Eine Nutzerfrage wird per Embedding-Modell in einen Vektor umgewandelt, gegen einen Index vorab eingebetteter Dokumentenabschnitte per Cosine-Similarity oder ANN-Suche verglichen, und die ähnlichsten Abschnitte werden zusammen mit der Frage als Kontext in den Prompt eingefügt, bevor das Modell antwortet.
"RAG ist kein Modell-Feature, sondern eine Pipeline aus mehreren unabhängig wartbaren und unabhängig fehleranfälligen Komponenten.
Für Entwickler:innen, die RAG produktiv einsetzen wollen, reicht die Erklärung "das Modell bekommt zusätzliches Wissen" nicht aus. Entscheidend ist, was zwischen Frage und Antwort technisch passiert und welche Komponente an welcher Stelle versagen kann.
Die vier Kernkomponenten der Pipeline
Eine produktive RAG-Implementierung besteht aus einem Ingestion-Pfad (Parsing, Chunking, Embedding, Indexierung), einem Retrieval-Pfad (Query-Embedding, ANN-Suche, optionales Reranking), einem Assembly-Schritt (Kontextfenster füllen, Zitate anhängen) und der eigentlichen LLM-Inferenz.
Diese Trennung ist wichtig, weil jede Komponente unabhängig getestet, versioniert und ausgetauscht werden muss. Ein schlechtes Embedding-Modell lässt sich nicht durch ein besseres LLM kompensieren, und umgekehrt repariert ein besseres Embedding-Modell keine schlechte Chunking-Strategie.
Vektorraum und Ähnlichkeitssuche
Embeddings bilden Text als hochdimensionale Vektoren ab, typischerweise 384 bis 3072 Dimensionen je nach Modell. Ähnlichkeit wird meist über Cosine Similarity oder Dot Product berechnet, die Suche selbst läuft über Approximate-Nearest-Neighbor-Verfahren wie HNSW, weil eine exakte lineare Suche bei Millionen Vektoren zu langsam wäre.
HNSW baut einen mehrschichtigen Graphen auf, der bei der Suche exponentiell viele Kandidaten ausschließt. Der Trade-off ist Rückrufgenauigkeit gegen Latenz: Wer `ef_search` niedrig einstellt, bekommt schnellere, aber potenziell unvollständigere Ergebnisse.
Prompt-Assembly und Kontextfenster
Nach der Suche werden die Top-k-Treffer in einen Prompt eingefügt, meist mit System-Anweisung, den gefundenen Passagen inklusive Quellenverweis und der ursprünglichen Frage.
Das Kontextfenster ist begrenzt, und mehr Kontext bedeutet nicht automatisch bessere Antworten — Studien zu "Lost in the Middle" zeigen, dass LLMs Informationen in der Mitte langer Kontexte schlechter nutzen als am Anfang oder Ende. Die Reihenfolge der eingefügten Passagen ist damit ein eigener Stellhebel.
Schritt-für-Schritt
- 1
Dokumente parsen und chunken
PDFs, Markdown oder Confluence-Seiten werden in Abschnitte von meist 200 bis 800 Tokens zerlegt, oft mit Overlap, damit Kontext an Chunk-Grenzen nicht verloren geht.
- 2
Embeddings erzeugen
Jeder Chunk wird durch ein Embedding-Modell (z. B. text-embedding-3-large, bge-large oder ein selbst gehostetes Modell) in einen Vektor umgewandelt.
- 3
Index aufbauen
Die Vektoren werden in einer Vector Database wie pgvector, Pinecone oder Weaviate mit Metadaten (Quelle, Zugriffsrecht, Zeitstempel) gespeichert.
- 4
Anfrage verarbeiten
Bei einer Nutzerfrage wird dieselbe Embedding-Funktion angewendet, die ähnlichsten Chunks werden abgerufen und optional durch ein Reranking-Modell neu sortiert.
- 5
Antwort generieren
Das LLM erhält Frage und Kontext in einem strukturierten Prompt und erzeugt eine Antwort mit nachvollziehbaren Quellenverweisen.
Wann passt es — wann nicht?
Passt gut
- ✓Die Wissensbasis ändert sich häufiger als ein Fine-Tuning-Zyklus vertretbar wäre
- ✓Antworten müssen auf konkrete, zitierbare Quellen zurückführbar sein
- ✓Zugriffsrechte pro Dokument müssen bei der Antwort berücksichtigt werden
Passt nicht
- ✗Es geht um implizites Stilverhalten oder Formatvorgaben statt um Faktenwissen
- ✗Die Wissensbasis ist klein genug, um komplett in den Kontext zu passen
- ✗Latenz ist kritischer als Zugriff auf aktuelle Dokumente
Quellen
Patrick Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", 2020, https://arxiv.org/abs/2005.11401