RAG technisch erklärt – ohne Buzzwords

Worum es geht

Diese Serie hat RAG von verschiedenen Seiten beleuchtet: als Konzept, als Praxis, als Strategie. Dieser Artikel geht unter die Haube. Was passiert technisch, wenn ein RAG-System eine Frage beantwortet? Keine Marketing-Sprache, keine Vereinfachungen, die wichtige Details verschlucken.

Schritt 1 – Dokumente vorbereiten (Ingestion)

Bevor ein RAG-System Fragen beantworten kann, müssen die Quellen aufbereitet werden. Das passiert in drei Teilschritten.

Loading

Dokumente werden aus verschiedenen Quellen geladen und in ein einheitliches Textformat gebracht. PDFs, HTML-Seiten, Markdown-Dateien, Word-Dokumente – alles wird zu reinem Text.

Das klingt trivial, ist es aber nicht. PDF-Parsing ist fehleranfällig. Tabellen gehen verloren. Kopf- und Fußzeilen werden zu Rauschen. Die Qualität des Loadings beeinflusst alles, was danach kommt.

Normalisierung

Ein oft unterschätzter Schritt ist die Normalisierung. Zwei semantisch identische Texte können durch Encoding, Formatierung oder HTML-Struktur völlig unterschiedliche Embeddings erzeugen.

In der Praxis bedeutet das:

• Unicode-Normalisierung bei kaputten PDFs oder gemischten Zeichensätzen
• Boilerplate-Entfernung bei HTML: Navigation, Footer, Cookie-Banner werden zu Rauschen
• Deduplication: Gleiche Inhalte aus mehreren Quellen müssen erkannt und zusammengeführt werden
• Language Detection: Bei mehrsprachigen Quellen sind getrennte Indizes oft die bessere Wahl

Wer hier schlampig arbeitet, verschlechtert das gesamte Retrieval – ohne es später noch sauber korrigieren zu können.

Chunking

Ein einzelnes Dokument ist meistens zu lang, um komplett ins Kontextfenster eines LLMs zu passen. Also wird es in Chunks zerteilt – kleinere Textabschnitte, typischerweise zwischen 200 und 1000 Token.

Die Herausforderung: Wo schneidet man?

Fixed-size Chunking: Schneidet nach einer festen Token-Anzahl. Einfach, aber Sätze und Absätze werden mitten im Gedanken getrennt.

Recursive Character Splitting: Versucht, an natürlichen Grenzen zu schneiden – erst Absätze, dann Sätze, dann Wörter. Der De-facto-Standard in LangChain.

Semantic Chunking: Nutzt ein Embedding-Modell, um thematische Grenzen zu finden. Rechenintensiv, aber die besten Ergebnisse.

Overlap ist fast immer sinnvoll: Chunks überlappen sich um 10-20%, damit Kontext nicht an den Schnittstellen verloren geht.

Chunk-Größe ist kein fixer Wert, sondern hängt vom Zielmodell und Anwendungsfall ab. Kleine Chunks verbessern die Trefferqualität bei der Suche – sie sind präziser und rauscharmer. Große Chunks liefern mehr Kontext für die Generierung. In der Praxis ist das ein Trade-off, der oft empirisch optimiert wird: erst messen, dann anpassen.

Embedding

Jeder Chunk wird in einen numerischen Vektor umgewandelt. Das ist der Kern von RAG – und der Schritt, der am meisten missverstanden wird.

Was ein Embedding ist:

Ein Embedding-Modell (z.B. text-embedding-3-small von OpenAI oder all-MiniLM-L6-v2 von sentence-transformers) wandelt Text in einen Vektor fester Länge um. Typisch sind 384, 768 oder 1536 Dimensionen.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")

text_a = "Wie verbessere ich die Ladezeit meiner Website?"
text_b = "Performance-Optimierung für Web-Applikationen"
text_c = "Rezept für Apfelkuchen"

vec_a = model.encode(text_a)  # [0.023, -0.145, 0.089, ...]
vec_b = model.encode(text_b)  # [0.019, -0.138, 0.092, ...]
vec_c = model.encode(text_c)  # [-0.234, 0.067, -0.198, ...]

# vec_a und vec_b liegen nahe beieinander
# vec_c liegt weit entfernt

Warum das funktioniert:

Das Embedding-Modell wurde auf Millionen von Textpaaren trainiert: ähnliche Texte sollen ähnliche Vektoren ergeben. Das Modell lernt dabei keine Keywords, sondern semantische Beziehungen. „Ladezeit verbessern” und „Performance-Optimierung” landen nahe beieinander, obwohl sie kein Wort teilen.

Was ein Embedding nicht ist:

Es ist keine Zusammenfassung. Es ist keine Kompression. Es ist eine Projektion des Textes in einen geometrischen Raum, in dem Ähnlichkeit als Distanz messbar wird.

Query vs. Document Embeddings

In vielen Systemen werden Dokumente und Queries mit demselben Modell erzeugt – aber nicht immer mit derselben Konfiguration. Manche Modelle unterscheiden explizit zwischen „query embedding” und „document embedding”, etwa durch unterschiedliche Instruktions-Präfixe oder separate Modellvarianten.

Wer das ignoriert, verliert messbar an Retrieval-Qualität: Die Embeddings optimieren dann nicht mehr auf dasselbe Ziel.

Schritt 2 – Speicherung in einer Vektordatenbank

Die Vektoren werden in einer spezialisierten Datenbank gespeichert. Keine SQL-Datenbank – die Anforderungen sind fundamental anders.

Wie Vektorsuche funktioniert

Eine Vektorsuche berechnet die Distanz zwischen dem Fragevektor und allen gespeicherten Vektoren. Die nächsten Nachbarn sind die relevantesten Chunks.

Gängige Distanzmaße:

Maß	Beschreibung	Typisch für
Cosine Similarity	Winkel zwischen Vektoren	Text-Embeddings (Standard)
Euclidean Distance	Geometrischer Abstand	Numerische Daten
Dot Product	Skalarprodukt	Normalisierte Vektoren

In der Praxis nutzen fast alle Text-RAG-Systeme Cosine Similarity.

Das Skalierungsproblem

Bei 10.000 Dokumenten mit je 50 Chunks sind das 500.000 Vektoren. Bei 1536 Dimensionen pro Vektor eine erhebliche Datenmenge. Brute-Force-Suche (jeden Vektor vergleichen) wird ab einer gewissen Größe zu langsam.

Die Lösung: Approximate Nearest Neighbor (ANN) Algorithmen. Sie finden nicht garantiert den nächsten Nachbarn, aber mit hoher Wahrscheinlichkeit einen sehr nahen – in einem Bruchteil der Zeit.

Gängige Algorithmen:

• HNSW (Hierarchical Navigable Small World): Der aktuelle Standard. Schnell, gute Recall-Raten. Genutzt in Qdrant, pgvector, Chroma.
• IVF (Inverted File Index): Teilt den Vektorraum in Cluster. Schnell bei großen Datenmengen.
• ScaNN: Googles Ansatz. Besonders effizient bei sehr großen Datenbanken.

Index-Building vs. Abfragezeit

ANN-Algorithmen verlagern Komplexität in die Indexstruktur. Ein Teil der Arbeit passiert beim Aufbau des Index – beim Einfügen neuer Dokumente werden Graphstrukturen oder Cluster aktualisiert. Das erklärt, warum Inserts teuer sein können, während Abfragen sehr schnell sind: Die eigentliche Sucharbeit ist bereits vorberechnet.

Hybrid Retrieval

Reine Vektorsuche reicht selten aus. In der Praxis wird sie fast immer mit klassischen Filtern kombiniert – etwa nach Dokumenttyp, Datum oder Sprache. Dieses „Hybrid Retrieval” verhindert, dass semantisch ähnliche, aber kontextuell falsche Ergebnisse zurückgegeben werden.

Viele Systeme kombinieren zusätzlich Vektorsuche mit klassischer Volltextsuche (z.B. BM25). Die Scores beider Methoden werden dann zusammengeführt – Reciprocal Rank Fusion ist ein gängiger Ansatz dafür.

Schritt 3 – Retrieval

Wenn eine Frage gestellt wird, passiert Folgendes:

1. Die Frage wird mit dem gleichen Embedding-Modell vektorisiert
2. Die Vektordatenbank liefert die Top-K nächsten Chunks (typisch: K = 3 bis 10)
3. Optional: Ein Reranker sortiert die Ergebnisse nach Relevanz um

Top-K allein ist oft zu simpel. In vielen Fällen ist es sinnvoll, zusätzlich einen Mindest-Ähnlichkeitswert (Score Threshold) zu definieren. Andernfalls zwingt man das System, auch schwache Treffer in den Kontext zu nehmen – was die Antwortqualität verschlechtert, ohne dass es offensichtlich wird.

Warum Reranking hilft

Die Vektorsuche ist schnell, aber nicht perfekt. Ein Reranker (z.B. ein Cross-Encoder) nimmt die Top-K Ergebnisse und bewertet sie nochmal – diesmal mit dem vollen Kontext von Frage und Chunk gleichzeitig.

Der Zweischritt-Ansatz kombiniert Geschwindigkeit (Vektorsuche) mit Präzision (Reranking).

Retrieval-Strategien

• Naive RAG: Top-K Chunks direkt ins Prompt. Einfach, funktioniert oft.
• Multi-Query: Die Frage wird in mehrere Varianten umformuliert, um verschiedene Perspektiven abzudecken.
• Hypothetical Document Embedding (HyDE): Das LLM generiert erst eine hypothetische Antwort, die dann als Suchquery verwendet wird.
• Parent-Child Retrieval: Kleine Chunks für präzise Suche, aber der größere Eltern-Chunk wird als Kontext geliefert.

Das Intent-Problem

Ein strukturelles Problem bleibt: Embeddings kennen keine echte „Suchintention”. Eine Frage wie „Warum ist X schlecht?” und „Warum ist X gut?” kann ähnliche Vektoren erzeugen, weil beide Formulierungen thematisch nah sind. Ohne zusätzliche Logik – Reranking oder Query-Rewriting – kann das zu widersprüchlichen Kontexten führen.

Schritt 4 – Generation

Jetzt wird aus Frage und Kontext eine Antwort generiert.

Das Prompt-Template

Beantworte die folgende Frage ausschließlich auf Basis
der bereitgestellten Kontextdokumente. Wenn die Antwort
nicht in den Dokumenten zu finden ist, sage das explizit.

Kontext:
{chunk_1}
{chunk_2}
{chunk_3}

Frage: {user_question}

Antwort:

Das Template steuert das Modellverhalten: Nur auf Basis der Quellen antworten, Unsicherheit kommunizieren.

Kontext ≠ Wahrheit

Das LLM bewertet den Kontext nicht auf Wahrheit, sondern auf Plausibilität. Wenn falsche oder widersprüchliche Chunks im Prompt landen, wird das Modell trotzdem eine kohärente Antwort erzeugen – aber nicht zwingend eine korrekte. Das Modell kann nicht wissen, ob ein Chunk aktuell, vollständig oder korrekt ist.

Sehr strikte Prompt-Templates können darüber hinaus zu einer Art „Overfitting” führen: Das Modell wiederholt Formulierungen oder wirkt unnatürlich eingeschränkt. In der Praxis werden Prompts iterativ gelockert, um ein Gleichgewicht zwischen Kontrolle und natürlicher Antwort zu finden.

Das Kontextfenster

Jedes LLM hat ein begrenztes Kontextfenster:

Modell	Kontextfenster
GPT-4o	128K Token
Claude 3.5 Sonnet	200K Token
Llama 3 70B	8K Token
Mistral Large	128K Token

Mehr Kontext bedeutet nicht automatisch bessere Antworten. LLMs haben eine „Lost in the Middle”-Tendenz: Informationen am Anfang und Ende des Kontexts werden besser verarbeitet als solche in der Mitte.

Wo es schiefgehen kann

Retrieval Failure vs. Generation Failure

Fehler lassen sich grundsätzlich in zwei Kategorien einteilen:

• Retrieval Failure: Die falschen Chunks wurden gefunden – das Modell hatte nie eine Chance, die richtige Antwort zu geben
• Generation Failure: Die richtigen Chunks wurden gefunden, aber das Modell hat sie falsch interpretiert oder falsch zusammengefasst

Diese Unterscheidung ist entscheidend für Debugging. Wer beide Fehlertypen zusammenwirft, optimiert am falschen Teil der Pipeline.

Embedding-Mismatch

Wenn das Embedding-Modell die Domäne nicht gut versteht, findet es die falschen Chunks. Medizinische Fachsprache, juristisches Vokabular oder sehr spezialisierte Technik kann problematisch sein.

Lösung: Fine-Tuning des Embedding-Modells oder Nutzung domänenspezifischer Modelle.

Chunk-Kontextverlust

Ein Chunk, der den Satz „Dies führte zu einem Umsatzrückgang von 15%” enthält, ist ohne den vorherigen Absatz (der erklärt, was „dies” ist) nutzlos.

Lösung: Overlap, Parent-Child Retrieval, oder Metadata-Anreicherung (z.B. Dokumenttitel und Kapitel als Kontext zum Chunk).

Skalierungsprobleme

Bei sehr großen Wissensbasen sinkt die Retrieval-Qualität. Mehr Dokumente bedeuten mehr irrelevante Chunks, die als „ähnlich” bewertet werden.

Lösung: Hierarchisches Retrieval, Namespace-Trennung, oder vorgeschaltete Klassifikation der Frage.

Der aktuelle Stand der Technik

RAG entwickelt sich schnell weiter. Einige aktuelle Trends:

Graph RAG: Statt nur Chunks zu speichern, werden Wissens-Graphen aufgebaut. Entitäten und ihre Beziehungen werden explizit modelliert. Das verbessert Fragen, die Zusammenhänge über mehrere Dokumente erfordern.

Agentic RAG: Ein KI-Agent entscheidet dynamisch, welche Retrieval-Strategie und welche Quellen für eine bestimmte Frage am besten geeignet sind. Statt einer fixen Pipeline wird der Retrieval-Prozess selbst intelligent.

Multimodale RAG: Nicht nur Text, sondern auch Bilder, Tabellen und Diagramme werden vektorisiert und durchsuchbar. Besonders relevant für technische Dokumentation.

Caching & Cost Control: Wiederkehrende Fragen oder ähnliche Queries können auf bereits berechnete Retrieval- und Generationsschritte zurückgreifen. Semantisches Caching – nicht nur exakte Treffer, sondern ähnliche Queries – reduziert Latenz und Kosten erheblich, besonders bei großen Modellen.

Wie misst man, ob RAG funktioniert?

Die häufigste Schwachstelle in RAG-Projekten ist nicht die Pipeline – es ist das fehlende Evaluation-Framework. Ohne Metriken bleibt unklar, ob eine Änderung tatsächlich eine Verbesserung war.

Gängige Metriken:

• Recall@K: Sind die relevanten Chunks überhaupt unter den Top-K Ergebnissen?
• Precision: Wie viele der zurückgegebenen Chunks sind tatsächlich relevant?
• Answer Faithfulness: Stimmt die Antwort mit den Quellen überein – oder halluziniert das Modell trotz Kontext?
• Context Relevance: Ist der gelieferte Kontext überhaupt relevant für die Frage?

Automatisierte Frameworks wie RAGAS ermöglichen es, diese Metriken ohne manuelle Bewertung zu berechnen. Periodische Human Evaluation bleibt trotzdem nötig – besonders für Faithfulness, wo automatische Metriken noch unzuverlässig sind.

Zusammenfassung der Pipeline

Jeder dieser Schritte bietet Stellschrauben. Die Kunst liegt nicht darin, die Pipeline einmal aufzusetzen, sondern sie iterativ zu verbessern – basierend auf tatsächlicher Nutzung und messbarer Qualität.

Abschluss der Serie

Diese Serie hat RAG von allen Seiten beleuchtet: als Paradigmenwechsel, als Evolution, als praktisches Werkzeug, als strategische Investition, als System mit Grenzen, und schließlich als technische Architektur.

Die Kernbotschaft zieht sich durch alle Artikel: Nicht das Modell entscheidet über die Qualität der Ausgabe. Es entscheidet, wie Wissen strukturiert wird – wie es gefunden wird – und wie es dem Modell präsentiert wird. RAG ist der Mechanismus, der alle drei Fragen beantwortet. Wer ihn versteht, baut Systeme, die nicht nur beeindrucken, sondern zuverlässig sind.

Wer RAG technisch von Grund auf durcharbeiten möchte – Vektorindizierung, Embedding-Modelle, Retrieval-Strategien – findet auf learn.casoon.dev einen strukturierten Kurs dazu.