Lösungen für
Bitte auswählen
Web-App testen
ki-konzepte

RAG verstehen — von der Idee bis zum produktiven System

Redaktion ·

Warum RAG — und warum nicht einfach mehr Kontextfenster

Ein LLM, das alles wissen soll, was in deinem Unternehmen je geschrieben wurde, scheitert an drei Punkten gleichzeitig: Das Modell wurde nicht auf deinen Daten trainiert, das Kontextfenster ist endlich, und ein Fine-Tune ist teuer und altert mit jedem neuen Dokument. Retrieval-Augmented Generation löst das, indem es den Kontextfenster-Trick umdreht: Statt alles ins Modell zu trainieren oder alles in den Prompt zu kippen, wird vor jeder Anfrage zur Laufzeit das relevante Material aus einer Sammlung herausgeholt und nur diese Auszüge ins Prompt gelegt.

Das Verfahren ist seit 2023/2024 der De-facto-Standard für „LLM auf eigenen Daten” — egal ob interner Support-Bot, Doku-Suche oder Recherche-Assistent. Dieser Artikel geht den Weg von der nackten Pipeline bis zu den Optimierungen, die in produktiven Systemen den Unterschied machen, plus ein Rechenbeispiel, das zeigt, wo die Kosten wirklich liegen.

Die Grundmechanik — fünf Schritte, ein Loop

Eine minimale RAG-Pipeline besteht aus fünf Stationen. Sobald du die einmal sauber durchschaust, fallen alle weiteren Verfeinerungen darunter.

1. Indexierung — Dokumente in den Vektorraum

Vor dem ersten Query muss dein Korpus einmal verarbeitet werden. Die Texte werden in Häppchen geteilt — siehe Chunking — und jeder Chunk durch ein Embedding-Modell geschickt. Heraus kommt pro Chunk ein Vektor mit typisch 768 bis 3.072 Dimensionen, ein Zahlenkamm, der die Bedeutung des Texts kodiert. Details dazu im Glossar-Eintrag Embedding.

Diese Vektoren landen in einer Vektor-Datenbank, zusammen mit dem Original-Text und beliebigen Metadaten (Quelle, Datum, Autor, Tags). Indexierung läuft einmal beim Bestücken und bei jedem Update — also kein Laufzeit-Schritt, sondern Batch.

2. Query-Embedding

Wenn ein Nutzer eine Frage stellt, durchläuft die Frage dasselbe Embedding-Modell wie die Dokumente. Wichtig: dasselbe — Vektoren aus zwei verschiedenen Modellen sind nicht vergleichbar. Heraus kommt ein einzelner Query-Vektor.

3. Retrieval — die Top-K finden

Die Vektor-DB beantwortet jetzt eine simple Frage: „Welche K Vektoren liegen am dichtesten an meinem Query-Vektor?” Die übliche Distanzmetrik ist Kosinus-Ähnlichkeit (zwei Vektoren sind sich ähnlicher, je kleiner der Winkel zwischen ihnen ist). Typische K-Werte: 5 bis 50.

Das ist semantische Suche: Die Treffer enthalten oft nicht das exakte Suchwort, sondern Texte, die bedeutungsähnlich sind. „Wie kündige ich mein Abo?” findet auch einen Absatz, in dem das Wort „kündigen” gar nicht vorkommt, sondern nur „Vertrag beenden”.

4. Reranking — vom Grobsieb zum Feinsieb (optional, aber stark)

Die Top-K aus dem Vektor-Retrieval sind eine schnelle, aber grobe Vorauswahl. Ein Reranking-Modell — meist ein Cross-Encoder wie Cohere Rerank oder ein lokaler bge-reranker — bekommt Query und jeden der K Treffer als Paar gezeigt und scort die echte Relevanz. Aus den Top-50 werden dann die Top-5, die wirklich ins Prompt wandern.

Reranker sind langsamer (sie laufen pro Treffer einmal durchs Modell, nicht bloß als Vektor-Vergleich), aber liefern deutlich bessere Reihenfolgen. In der Praxis ist Reranking der Hebel, der naive RAG von „okay” zu „brauchbar” hebt.

5. Generation — Prompt zusammenbauen, LLM antwortet

Die finalen Top-N Chunks werden zusammen mit der Originalfrage in ein Prompt eingebaut, typisch mit einer Systeminstruktion in der Art „Antworte ausschließlich auf Basis der folgenden Kontextpassagen. Wenn die Information dort nicht steht, sag das.” Das LLM generiert die Antwort.

Wenn du das einmal als Loop denkst — Query → Embedding → Retrieval → Rerank → Prompt → Antwort — hast du das Skelett von 90 % aller produktiven RAG-Systeme.

Stolperfallen, die fast jeden treffen

Die Pipeline klingt geradlinig, aber genau die Stellen, an denen man am wenigsten erwartet zu stolpern, sind die teuersten.

Chunking-Größe ist nicht egal. Zu kleine Chunks (50 Tokens) zerreißen Sätze und Argumente, zu große (2.000 Tokens) verwässern die Embeddings, weil ein Vektor zu viele Themen kodieren muss. Faustregel: 200–500 Tokens mit 10–20 % Overlap zwischen Chunks. Wer Tabellen, Listen oder Code indexiert, braucht oft Custom-Splitter — Markdown-Heading-basiert oder Recursive-Character-Splitter.

Embedding-Modell-Wechsel ohne Reindex. Wenn du vom alten Embedding-Modell auf ein neues umsteigst, musst du den kompletten Index neu bauen. Vektoren aus zwei Modellen sind inkompatibel — Mischbetrieb produziert lautlosen Schrott.

Query und Dokument sehen zu unterschiedlich aus. Nutzer fragen kurz („Urlaubstage Teilzeit?”), Dokumente sind lang und beamtensprachlich. Das Embedding der Frage liegt im Vektorraum dann oft fern von der Antwort, obwohl die semantisch matcht. Lösung: Query-Expansion oder HyDE (siehe nächster Abschnitt).

Top-K zu klein. Wer nur Top-3 holt und kein Reranking hat, verpasst regelmäßig den richtigen Treffer. Besser: Top-30 holen, dann auf Top-5 reranken.

Halluzinationen trotz Kontext. Auch wenn du dem Modell explizit sagst „nur aus dem Kontext”, kommt es vor, dass es füllt. Mitigationen: Zitate-Pflicht im Prompt, Eval auf Faithfulness (siehe weiter unten), strengere Modelle (Claude Sonnet/Opus sind in der Beobachtung disziplinierter als kleinere Open-Source-Modelle).

Fortgeschrittene Verfahren — was du brauchst, wenn naiv nicht reicht

Wenn das Basis-Setup nicht abliefert, gibt es eine Handvoll Hebel, die in produktiven Systemen oft den Unterschied machen.

Reine semantische Suche tut sich schwer mit exakten Begriffen — Produktnamen, Versionsnummern, IDs. Hybrid Search kombiniert Vektor-Retrieval mit klassischem Keyword-Retrieval (BM25) und merged die Ergebnisse, oft per Reciprocal Rank Fusion. Wenn dein Korpus viele Eigennamen oder technische Begriffe enthält, ist Hybrid fast immer eine Verbesserung.

Query Expansion

Statt der Original-Frage werden zusätzlich generierte Varianten („Urlaubsanspruch bei Teilzeit”, „Anteilige Urlaubstage”, „Wie wird Urlaub bei reduzierter Stundenzahl berechnet”) gegen den Index gefahren und die Treffer zusammengeführt. Kostet einen Extra-LLM-Call, hilft aber bei knapp formulierten Nutzerfragen messbar.

HyDE (Hypothetical Document Embeddings)

Trick: Statt die Frage selbst zu embedden, lässt man das LLM erst eine hypothetische Antwort generieren und embedded die. Die hypothetische Antwort liegt im Vektorraum näher an den echten Antworten als die Frage. Funktioniert besonders, wenn Frage und Korpus stilistisch weit auseinanderliegen.

Contextual Retrieval

Anthropic-Variante (2024): Vor dem Embedding bekommt jeder Chunk eine kurze, vom LLM generierte Kontextzusammenfassung vorangestellt („Dieser Abschnitt stammt aus dem HR-Handbuch, Kapitel Urlaubsregelung, und beschreibt …”). Damit sinkt die Retrieval-Fehlerrate laut Anthropic-Studie um zweistellige Prozentwerte. Kosten: Indexierungs-Aufwand wird größer (jeder Chunk durchläuft einmal das LLM), Laufzeit bleibt gleich.

GraphRAG

Wenn dein Wissen vernetzt ist (Personen, Organisationen, Beziehungen) und Fragen mehrere Hops brauchen („Welche Tochterfirmen von X arbeiten an Projekt Y?”), reicht reine Ähnlichkeitssuche oft nicht. GraphRAG baut zusätzlich einen Knowledge Graph aus dem Korpus auf und kombiniert Graph-Traversal mit Vektor-Retrieval. Aufwand: deutlich höher (Entity-Extraktion, Graph-Aufbau, Hybrid-Query). Lohnt sich für vernetzte Wissensdomänen, ist Overkill für FAQ-Bots.

Agentic RAG

Statt einer festen Pipeline (Retrieve → Generate) bekommt ein Agent das Retrieval als Tool an die Hand und entscheidet selbst, ob, wie oft und mit welcher Reformulierung er sucht. Kann in komplexen Recherchen Mehrschritt-Reasoning auflösen, das ein One-Shot-RAG verfehlt. Trade-off: höhere Latenz, höhere Kosten, schwerer zu debuggen — und Agenten haben ihre eigenen Stolperfallen (endlose Loops, Tool-Halluzinationen).

Vektor-Datenbanken im Vergleich

Drei Optionen decken 95 % der Fälle ab.

| Tool | Typ | Stärken | Schwächen | Wann nehmen | |---|---|---|---|---| | Pinecone | Managed SaaS | Null Ops, schnell, gut skaliert | Kosten, Vendor-Lock | Schnellstart, kleines Team, kein DBA | | Qdrant | Self-hosted (Rust) | Open Source, performant, Hybrid-Search nativ, Cloud-Variante verfügbar | Eigene Infrastruktur, Backups selbst | Mittlere Skalierung, on-prem-Pflicht | | pgvector | PostgreSQL-Extension | Relationale Daten + Vektoren in einer DB, simple Ops | Langsamer bei sehr großen Indexen (> 10 Mio Vektoren) | Bestehende Postgres-Landschaft, < 5 Mio Chunks |

Daneben gibt es Weaviate (ähnlich Qdrant, mit eingebautem Hybrid- und Schema-System), Milvus (sehr großer Maßstab, mehr Komplexität) und für Schnellstarts auch Chroma und LanceDB.

Faustregel: Fang mit pgvector an, wenn du schon Postgres hast und unter ein paar Millionen Chunks bleibst. Greif zu Qdrant oder Weaviate, sobald Hybrid-Search nativ wichtig wird oder die Datenmenge wächst. Pinecone, wenn Ops-Aufwand das Entscheidungs­kriterium ist und Budget egal.

Rechenbeispiel — naive vs. optimierte Pipeline

Damit die Kostenseite nicht abstrakt bleibt, ein konkreter Vergleich für 10.000 Anfragen pro Monat. Annahmen: Embedding-Modell text-embedding-3-small (0,02 $/1M Tokens), Generation mit gpt-5-mini (0,15 $/1M Input, 0,60 $/1M Output), durchschnittliche Frage 50 Tokens, Chunk-Größe 400 Tokens, Antwort 300 Tokens.

Naive Pipeline — Top-3 ohne Reranking:

| Posten | Tokens | Kosten | |---|---|---| | Query-Embeddings | 10.000 × 50 = 500k | 0,01 $ | | Generation Input (Frage + 3×400 Token Kontext) | 10.000 × 1.250 = 12,5M | 1,88 $ | | Generation Output | 10.000 × 300 = 3M | 1,80 $ | | Summe | | 3,69 $ |

Reranking-optimiert — Top-30 holen, auf Top-5 reranken (Cohere Rerank: 1 $/1k Anfragen), dann Generation:

| Posten | Tokens / Calls | Kosten | |---|---|---| | Query-Embeddings | 500k Tokens | 0,01 $ | | Reranking | 10.000 Calls × 30 docs | 10,00 $ | | Generation Input (Frage + 5×400 Token Kontext) | 10.000 × 2.050 = 20,5M | 3,08 $ | | Generation Output | 3M | 1,80 $ | | Summe | | 14,89 $ |

Reranking vervierfacht die Kosten — und liefert in fast allen produktiven Tests messbar bessere Antworten (typisch +15 bis +30 Prozentpunkte bei Faithfulness und Context Precision). Bei 10k Anfragen sind die ~11 $ Mehrkosten meist günstiger als ein zweiter Support-Mitarbeiter, der falsche Antworten korrigiert. Bei 10M Anfragen sieht die Rechnung anders aus — dann lohnt sich ein lokaler Reranker.

Qualität messen — kurzer Anriss

RAG ohne Eval ist Hoffnung mit Extra-Schritten. Drei Metriken aus dem RAGAS-Framework reichen für den Anfang:

  • Faithfulness — Stützt die Antwort wirklich auf den abgerufenen Kontext, oder halluziniert das Modell? Gemessen, indem ein Judge-LLM jede Aussage in der Antwort gegen den Kontext prüft.
  • Context Precision — Sind die abgerufenen Chunks tatsächlich relevant für die Frage, oder ist viel Rauschen dabei? Misst, wie weit oben in den Top-K die echten Treffer stehen.
  • Context Recall — Fehlen relevante Chunks im Retrieval? Setzt einen Goldstandard voraus (welche Chunks wären die richtigen), wird daher meist auf einem kuratierten Eval-Set gemessen.

Eval-Setups verdienen einen eigenen Artikel — Datensatz-Pflege, Judge-Bias, Goodhart-Effekt. Hier reicht der Merksatz: Bevor du Reranking, HyDE oder GraphRAG einbaust, brauchst du eine Eval-Metrik, sonst weißt du nicht, ob die Optimierung tatsächlich besser ist oder nur anders.

Fazit — was als Erstes, was kann warten

Der schnellste Weg zu einem brauchbaren RAG: pgvector + Top-30 + Cohere Rerank + Top-5 ins Prompt + Faithfulness-Eval auf 50 manuell kuratierten Fragen. Das ist kein Tag-1-Setup, aber zwei Wochen für ein kleines Team. Ab da kannst du datengetrieben entscheiden, welcher Hebel als nächstes lohnt.

HyDE und Query Expansion sind günstige Verbesserungen, wenn deine Nutzer kurz und stichwortartig fragen. Contextual Retrieval lohnt sich, sobald du den Indexierungs-Aufwand verkraften kannst und Halluzinationen das Hauptproblem sind. GraphRAG und Agentic RAG sind Spezialwerkzeuge — bau sie ein, wenn du nachweislich an Limits der naiven Pipeline stößt, nicht aus Vorsicht.

Was du nicht brauchst, bevor das Basis-Setup steht: ein eigenes Embedding-Modell, einen exotischen Vektor-DB-Wechsel, eine selbst gebaute Reranking-Architektur. Die größten Sprünge in RAG-Qualität kommen von Chunking, Reranking und Eval — nicht vom Modellzoo.

Themenuebersicht

KI-KonzepteRAG