Wie funktioniert RAG? Schritt für Schritt an einem echten Beispiel erklärt
Wie funktioniert RAG? Vorab werden Ihre Dokumente in Abschnitte zerlegt und indexiert; kommt eine Frage, sucht das System passende Abschnitte, sortiert sie neu, baut daraus einen Prompt und lässt ein Sprachmodell ausschließlich auf dieser Grundlage antworten, mit Quellenangaben. Am besten versteht man das, wenn man zusieht. In diesem Leitfaden verfolgen wir eine einzige Frage aus dem Alltag eines fiktiven Maschinenbauers aus dem Mittelstand durch alle sieben Stufen der Retrieval Augmented Generation, vom hochgeladenen PDF bis zur belegten Antwort.
Die Ausgangslage: eine Frage, drei Dokumente
Unser Beispielunternehmen, ein Hersteller hydraulischer Pressen mit 120 Beschäftigten in Baden-Württemberg, hat drei Dokumente in eine Wissensdatenbank geladen: das Wartungshandbuch Revision C von 2026 (ein PDF mit 90 Seiten), die alte Revision B, die noch im Laufwerk liegt, und eine Service-FAQ als Word-Datei. Ein Servicetechniker tippt beim Kunden vor Ort in das Assistenzsystem:
Wann muss ich bei der Presse HP 400 den Ölfilter tauschen?
Die Antwort steht in Kapitel 7.4 der Revision C, überschrieben mit „Hydraulikfilter: Austausch des Filterelements“. Das Wort „Ölfilter“ kommt dort nicht vor. Die Revision B nannte ein anderes Intervall. Merken Sie sich diese beiden Details: Genau diese Fallen muss eine RAG Pipeline umgehen.
Vor der ersten Frage: Ingestion, Chunking und Indexierung
Die ersten drei Schritte laufen einmal beim Hochladen und erneut bei jeder Aktualisierung. Der Techniker sieht davon nichts, doch hier entscheidet sich der größte Teil der Antwortqualität.
Schritt 1. Ingestion: aus Dateien wird sauberer Text
Die Pipeline öffnet jede Datei und extrahiert den Text. Beim Handbuch heißt das: die Textebene des PDF Seite für Seite lesen, wiederkehrende Kopf- und Fußzeilen („Rev. C, Seite 54 von 90“) entfernen und Überschriften erhalten, damit die Struktur bleibt. Jedes Dokument bekommt Metadaten: Titel, Dateiname und möglichst Revisionsstand mit Datum. Diese Angabe wird später wichtig, wenn Revision B und C konkurrieren.
Typische Probleme: Ein eingescanntes PDF ohne Textebene liefert gar nichts, und eine Wartungstabelle zerfällt beim Extrahieren gern in eine Zahlenreihe ohne Zuordnung. Wichtige Intervalle sollten deshalb auch im Fließtext stehen.
Schritt 2. Chunking: Text in auffindbare Abschnitte schneiden
Der Text wird in Chunks zerlegt, Abschnitte von einigen hundert Wörtern. Kapitel 7.4 wird zu Chunk 212. Ein guter Chunker erledigt zwei Kleinigkeiten, die unserer Frage helfen: Er stellt dem Abschnitt seinen Überschriftenpfad voran („Wartungshandbuch HP 400 Rev. C > 7 Hydraulik > 7.4 Hydraulikfilter“) und lässt ihn leicht mit dem nächsten Abschnitt überlappen, damit kein Satz zerschnitten wird. Inhaltlich sagt Chunk 212: Filterelement alle 2.000 Betriebsstunden oder spätestens jährlich tauschen, bei Anzeige der Verschmutzungsanzeige sofort.
Schritt 3. Indexierung: Abschnitte auffindbar machen
Jeder Chunk landet in einem Suchindex. Ein Volltextindex speichert die Wörter in normalisierter Form, sodass „Filter“, „Filters“ und „Filterelement“ zusammenfinden; gerade bei deutschen Komposita ist eine gute Sprachkonfiguration entscheidend. Ein Vektorindex speichert ein Embedding, eine Zahlenfolge, die die Bedeutung abbildet. Viele Systeme nutzen beides. Wann sich die Vektorvariante lohnt, erklärt unser Beitrag Was ist eine Vektordatenbank?.
Die Frage kommt: Retrieval und Reranking
Schritt 4. Retrieval: zuerst breit suchen
Der Techniker schreibt „Ölfilter“ und „tauschen“, das Handbuch sagt „Hydraulikfilter“, „Filterelement“ und „Austausch“. Eine wörtliche Suche würde danebenliegen. Zwei Techniken schließen die Lücke: Bei der Query Expansion formuliert ein Sprachmodell die Frage in zusätzliche Suchbegriffe um (Hydraulikfilter, Filterelement, Austausch, Wartungsintervall, Betriebsstunden). Die semantische Suche findet Abschnitte mit ähnlicher Bedeutung trotz anderer Wörter. Heraus kommt eine Kandidatenliste, oft 20 bis 50 Abschnitte. Die Spitze sieht etwa so aus:
- Chunk 212 (Rev. C, 7.4 Hydraulikfilter): alle 2.000 Betriebsstunden oder jährlich.
- Chunk 488 (Rev. B, 7.4 Hydraulikfilter): das alte Intervall von 1.500 Betriebsstunden.
- Chunk 213 (Rev. C, 7.5 Ölwechsel): Hydrauliköl nach Ölanalyse oder alle 8.000 Stunden wechseln.
- Chunk 17 (Service-FAQ): Bestellnummern der Ersatzfilter.
- Chunk 95 (Rev. C, 3.2 Sicherheit): Anlage vor Arbeiten am Hydrauliksystem drucklos machen.
Schritt 5. Reranking: die besten Belege nach vorn
Retrieval ist auf Tempo und Vollständigkeit ausgelegt und darf großzügig sein. Reranking ist die sorgfältige zweite Lesung: Ein Reranker liest Frage und Kandidat gemeinsam und bewertet, wie gut der Abschnitt die Frage wirklich beantwortet. Dazu kommen Geschäftsregeln wie Dubletten entfernen und die neueste Revision bevorzugen. In unserem Beispiel rückt Chunk 212 an die Spitze, der Sicherheitshinweis bleibt, weil er vor jeder Arbeit am System gilt, die Bestellnummern bleiben als praktischer Nachsatz, und Revision B fliegt raus oder wird klar als veraltet markiert. Übrig bleiben drei bis acht Abschnitte.
Reranking ist optional, seine Aufgabe nicht
Manche Systeme nutzen ein eigenes Reranking-Modell, andere eine gut abgestimmte hybride Suche mit Metadatenfiltern. Entscheidend ist, dass ein veralteter Abschnitt nie ungekennzeichnet an erster Stelle beim Modell ankommt. Hier hieße das: ein falsches Wartungsintervall, souverän formuliert.
Prompt zusammensetzen und Antwort mit Quellen erzeugen
Schritt 6. Prompt Assembly
Das Sprachmodell sucht selbst nichts. Es erhält einen von der Pipeline gebauten Prompt, meist aus vier Teilen:
- Anweisungen: nur aus den folgenden Quellen antworten, sie als [1], [2] zitieren und klar sagen, wenn die Antwort fehlt.
- Nummerierte Quellen: [1] Chunk 212 mit Titel und Revisionsstand, [2] Chunk 95, [3] Chunk 17.
- Die Frage im Wortlaut des Technikers.
- Kontext: Sprache, Datum, gewünschtes Format (kurze Antwort, dann Details).
Abschnitte aus Dokumenten gelten als Daten, nicht als Befehle, und stehen zwischen klaren Begrenzern. So kann ein eingeschmuggelter Satz in einem Dokument das Modell nicht umsteuern.
Schritt 7. Generierung mit Quellenangaben
Das Modell schreibt sinngemäß: „Das Filterelement des Hydraulikfilters wird alle 2.000 Betriebsstunden, spätestens aber jährlich getauscht, sofort, wenn die Verschmutzungsanzeige anspricht [1]. Vorher die Anlage drucklos machen [2]. Die Bestellnummer des Ersatzelements finden Sie in der Service-FAQ [3].“ Jede Ziffer führt zum Originalabschnitt, der Techniker kann den genauen Wortlaut prüfen.
Das Modell hat kein Intervall erfunden und nicht die alte Revision zitiert. Ebenso wichtig ist, was es nicht tut: Fragt der Techniker nach einer Maschine, die gar nicht im Handbuch steht, sollte die Antwort lauten, dass die Quellen dazu nichts enthalten, statt einen Wert zu raten.
Alle sieben Schritte auf einen Blick
Eine Frage durch die RAG Pipeline
| Schritt | Was mit unserer Frage passiert | Typischer Fehler |
|---|---|---|
| 1. Ingestion | Text extrahiert, Kopfzeilen entfernt, Revision erfasst | Gescanntes PDF, zerstörte Tabellen |
| 2. Chunking | Kapitel 7.4 wird Chunk 212 mit Überschriftenpfad | Regel auf zwei Chunks verteilt |
| 3. Indexierung | Chunk im Volltext- und Vektorindex | Falsche Sprache, veralteter Index |
| 4. Retrieval | Ölfilter mit Hydraulikfilter verknüpft; 5 Kandidaten | Richtiger Abschnitt fehlt |
| 5. Reranking | Rev. C vorn, Rev. B entfernt | Veraltete Revision auf Platz 1 |
| 6. Prompt | Anweisungen, drei nummerierte Quellen, Frage | Zu viele Abschnitte, keine Zitierpflicht |
| 7. Generierung | Antwort mit [1][2][3] | Aussagen ohne Beleg |
Die Tabelle ist zugleich eine Checkliste zur Fehlersuche. Bei einer falschen Antwort gehen Sie rückwärts vor: Stand der richtige Abschnitt im Prompt? Wenn ja, liegt es an Anweisungen oder Generierung. Wenn nein, war er unter den Kandidaten? Wenn nein, prüfen Sie Chunking und Extraktion. Die meisten Fehler entstehen in den Schritten 1, 2 und 4.
Die Pipeline nutzen, ohne sie zu bauen
Wer alle sieben Stufen selbst aufbaut, braucht Parser, Chunker, Datenbank, Suchschicht, Modell-API und den Code dazwischen. Ob sich das lohnt, beleuchtet unser Beitrag RAG as a Service. Kopik übernimmt diese Pipeline: Eine Wissensdatenbank anzulegen ist kostenlos, Sie laden PDF, Word, Text oder Markdown hoch, und Kopik extrahiert, zerlegt und indexiert die Inhalte für eine hybride Suche (Volltext plus semantische Erweiterung der Suchbegriffe). Antworten stützen sich auf Ihre Dokumente und zeigen die zitierten Abschnitte, im Modus „Passagen“ erhalten Sie nur die Rohabschnitte.
Eine Datenbank bleibt privat (nur Sie und Ihre API-Schlüssel) oder wird im Katalog veröffentlicht, wo pro Frage bezahlt wird; der Ersteller legt den Preis fest und behält 70 %. Abfragen laufen über die Website, die REST-API oder über MCP aus Claude, Cursor, ChatGPT und anderen Clients, beschrieben in der Entwicklerdokumentation. Prüfen Sie wie bei jedem Dienstleister vor dem Hochladen, ob die Dokumente personenbezogene Daten enthalten, die unter die DSGVO fallen.
Schicken Sie Ihre eigene Frage durch die Pipeline
Laden Sie ein Handbuch oder eine Richtlinie hoch und stellen Sie eine echte Frage: Die Antwort kommt mit den Abschnitten, auf denen sie beruht.
So testen Sie Ihre Pipeline
Notieren Sie fünf Fragen, die Ihr Team wirklich stellt, und wo die Antwort in den Dokumenten steht. Vergleichen Sie dann die Quellenangaben jeder Antwort mit dieser Stelle. So sehen Sie schnell, welcher Schritt Nacharbeit braucht.
Häufige Fragen
Welche Schritte hat Retrieval Augmented Generation?
Zwei Phasen. Vorab: Ingestion (Text extrahieren), Chunking (in Abschnitte zerlegen) und Indexierung. Zur Fragezeit: Retrieval (Kandidaten finden), Reranking (nach echter Relevanz sortieren), Prompt Assembly (Anweisungen, Quellen, Frage) und Generierung einer Antwort mit Quellenangaben.
Ist Reranking in einer RAG Architektur Pflicht?
Nicht unbedingt. Kleine, aufgeräumte Wissensdatenbanken funktionieren oft schon mit einer guten hybriden Suche. Reranking lohnt sich, wenn die Kandidatenliste lang ist, mehrere Versionen eines Dokuments existieren oder Abschnitte sich ähneln, aber verschiedene Fragen beantworten.
Wie viele Abschnitte sollte man an das Modell geben?
Meist eine Handvoll, oft drei bis zehn. Zu wenige, und die Antwort fehlt womöglich; zu viele, und das Modell wird abgelenkt, während Kosten und Antwortzeit steigen. Der richtige Wert hängt von Chunkgröße und Dokumenten ab und sollte mit echten Fragen getestet werden.
Warum zitiert ein RAG System manchmal veraltete Dokumente?
Weil beide Versionen indexiert sind und die alte gut zur Frage passte. Abhilfe: veraltete Dateien entfernen, Revisionsstand als Metadatum speichern und die neueste Version im Ranking bevorzugen. Ein Datum im Dokument selbst hilft zusätzlich.
Durchsucht das Sprachmodell die Dokumente selbst?
Nein. Die Suche erledigt die Retrieval-Schicht, bevor das Modell aufgerufen wird. Das Modell sieht nur die ausgewählten Abschnitte im Prompt. Deshalb hat die Qualität der Suche so großen Einfluss auf die Antwort.
Den Kopik-Newsletter abonnieren
Neue Wissensdatenbanken, RAG-Leitfäden und Produktneuheiten. Eine E-Mail alle ein bis zwei Wochen, Abmeldung mit einem Klick.
Mit dem Abonnement stimmen Sie dem Erhalt unseres Newsletters zu. Ihre Adresse wird nie weitergegeben.