Die Kernidee
RAG (Retrieval-Augmented Generation) existiert, weil deine Wissensdatenbank größer ist als jedes Kontextfenster. Statt dem Modell alles zu füttern, findest du zuerst die relevanten Chunks und lässt es nur daraus antworten. Die meisten RAG-Fehler sind Retrieval-Fehler, keine Modellfehler – die Lösung liegt fast immer darin, was abgerufen wurde, nicht im Prompt.
Deep Dive
Das Problem, das RAG löst
Selbst großzügige Kontextfenster können nicht deine gesamte Wissensdatenbank aufnehmen – jahrelange Angebote, ein komplettes Richtlinienhandbuch, Hunderte Kundenakten. Würdest du versuchen, alles in einen einzigen Prompt einzufügen, würde das meiste nicht hineinpassen. Und selbst wenn doch: Das Modell müsste die Nadel in einem riesigen Heuhaufen aus größtenteils irrelevantem Text suchen.
RAG löst dieses Problem, indem es vom Modell gar nicht erst verlangt, alles auf einmal zu lesen. Stattdessen durchsucht es deine Wissensdatenbank nach den spezifischen Abschnitten, die für die aktuelle Frage relevant sind, und übergibt dem Modell nur diese Teile zusammen mit der Frage. Das ist der eigentliche Grund, warum RAG existiert – es ist ein Workaround für eine handfeste physische Grenze, kein schickes Feature zum Selbstzweck.
RAG in einem Satz
Finde zuerst die relevanten Chunks, und lass das Modell dann daraus antworten. Das ist schon die ganze Pipeline: Ein Retrieval-Schritt durchsucht deine Dokumente nach Inhalten, die zur Frage passen, und ein Generierungsschritt füttert diese Treffer zusammen mit der ursprünglichen Frage an das Modell – mit der Bitte, eine Antwort zu formulieren, die sich auf die abgerufenen Inhalte stützt.
Alles andere – Chunking-Strategie, Embeddings, Vektordatenbanken – sind bloß Implementierungsdetails, die diesem einen Satz dienen. Wenn du dir nur das merkst, wirst du RAG-Systeme zielsicher debuggen: Frage immer zuerst „Was wurde abgerufen?“, bevor du fragst „Was hat das Modell geantwortet?“
Die ehrliche Alternative: Wann Long-Context ausreicht
Bevor du irgendeine RAG-Pipeline baust, prüfe, ob du wirklich eine brauchst. Wenn dein Dokumentensatz klein genug ist, um in einen einzigen Upload zu passen – sagen wir, unter ein paar hundert Seiten –, kann ein gehosteter Assistent mit Projects oder ein einfacher Datei-Upload mit Long-Context-Verarbeitung deine Fragen oft schon perfekt beantworten. Ganz ohne die Komplexität von Chunking und Retrieval, die RAG mit sich bringt.
RAG lohnt sich erst dann, wenn deine Wissensdatenbank wirklich zu groß ist, um sie am Stück hochzuladen, oder wenn du einen stetig wachsenden Ordner durchsuchen musst, ohne jedes Mal alles neu hochzuladen. Wenn du einfach startest und erst dann zu RAG greifst, wenn du an echte Grenzen stößt, ersparst du dir die Lösung von Problemen, die du noch gar nicht hast.
Chunking: Dokumente in ganze Gedanken zerlegen
Bevor überhaupt etwas abgerufen werden kann, werden Dokumente in Chunks zerlegt – kleinere Abschnitte, die einzeln mit einer Frage abgeglichen werden können. Das Ziel ist es, an natürlichen Grenzen zu trennen, damit jeder Chunk einen vollständigen Gedanken enthält (einen ganzen Absatz, eine vollständige Tabelle, einen Richtlinienabschnitt), anstatt mitten im Satz oder mitten in einer Tabelle abzuschneiden.
Schlechtes Chunking ist die häufigste Ursache für RAG-Fehler: Wird eine Tabelle über zwei Chunks getrennt, hat keiner der Chunks das vollständige Bild. Eine Frage zu dieser Tabelle liefert dann eine unvollständige oder falsche Antwort, obwohl die Information im Dokumentensatz eigentlich vorhanden war. Wenn der Abruf bei einer bestimmten Art von Inhalt immer wieder scheitert, ist ein erneutes, besseres Chunking oft die wahre Lösung – nicht ein besserer Prompt.
Embeddings, intuitiv erklärt
Embeddings verwandeln Text in Koordinaten in einem hochdimensionalen Raum, in dem die Bedeutung die Position bestimmt: Chunks zu ähnlichen Themen landen nah beieinander, Chunks zu unzusammenhängenden Themen weit voneinander entfernt. Wenn du eine Frage stellst, wird auch sie in Koordinaten umgewandelt, und das Retrieval findet einfach die Chunks, die diesem Punkt am nächsten liegen.
Du brauchst keine Mathematik, um das gut zu nutzen – das intuitive Bild reicht völlig: Ähnliche Bedeutung bedeutet Nähe, und Retrieval ist eine Umkreissuche. In der Praxis zählt vor allem, dass Embeddings Bedeutung erfassen und nicht nur reine Keyword-Übereinstimmungen. Eine Frage, die anders formuliert ist als das Dokument, kann also trotzdem den richtigen Chunk finden – wenn auch nicht immer perfekt.
Gehostete Lösungen nutzen
Du musst keine Vektordatenbank selbst aufbauen oder verwalten, um RAG zu nutzen. Gehostete Optionen – ein Assistent mit integrierter Dateisuche oder eine vorgefertigte RAG-Vorlage in einer No-/Low-Code-Automatisierungsplattform – übernehmen Chunking, Embeddings und Retrieval im Hintergrund. Du lädst einen Ordner hoch, und das System stellt dir eine Such- oder Chat-Oberfläche darauf bereit.
Ein Beispiel aus der Beratung: Lade 60 frühere Angebote in einen Assistenten mit Dateisuche und frage dann: „Was haben wir für Onboarding-Automatisierungsprojekte angeboten und welche Argumente haben überzeugt?“ Das System ruft die relevanten Angebots-Chunks ab, und das Modell formuliert eine Antwort mit Quellenangaben zu bestimmten Dateien – lebendiges Organisationswissen, das Fragen beantwortet, ohne dass jemand Infrastruktur aufbauen musste.
Retrieval testen: Das 10-Fragen-Audit
Sobald dein RAG-System live ist, vertraue ihm nicht einfach blind – überprüfe es mit einem Audit. Notiere dir 10 Fragen, deren richtige Antwort du bereits kennst, jage jede durch das System und prüfe für jede einzelne, welche Chunks tatsächlich abgerufen wurden, bevor du dir die finale Antwort ansiehst. So erkennst du, ob Fehler am Retrieval liegen (falsche Chunks geholt) oder echte Modellfehler sind (richtige Chunks, falsche Schlussfolgerung) – Ersteres kommt viel häufiger vor.
In der Praxis: Zwei Fehler gehen auf eine unglücklich gechunkte Tabelle zurück. Diese Dateien werden neu aufgeteilt, und ein erneuter Durchlauf erzielt 9 von 10 Punkten. Genau dafür ist das Audit da: Du hast das Retrieval debuggt, nicht das Modell, und hast nun eine konkrete Genauigkeitsquote statt nur des vagen Gefühls, dass es „schon irgendwie funktioniert“.
Die Grenzen kennen
RAG hat klare Grenzen, die du kennen solltest, bevor du dich darauf verlässt. Aktualität: Wenn sich deine Dokumente ändern, muss auch der Retrieval-Index aktualisiert werden, sonst erhältst du souverän vorgetragene falsche Antworten aus veralteten Chunks. Tabellen und strukturierte Daten: Der Abruf tut sich oft schwer mit tabellarischen Informationen, da beim Chunking Zeilen und Spalten von ihren Kopfzeilen getrennt werden können.
Die Synthese über mehrere Dokumente hinweg ist die härteste Grenze: Wenn sich die wahre Antwort auf eine Frage über fünf verschiedene Dokumente erstreckt, übersieht ein System, das nur die wenigen relevantesten Chunks abruft, möglicherweise verstreute Puzzleteile. Das Ergebnis ist eine Antwort, die mit voller Überzeugung unvollständig ist. Wenn du diese Grenzen von vornherein kennst, kannst du solche Fragetypen an einen Menschen oder ein anderes Tool weiterleiten, anstatt RAG blind zu vertrauen.
Ausführung & Setup
- Golden Set vorhanden. Ein festes Set aus 10–15 echten Fragen mit bekannten richtigen Antworten ist gespeichert und wird bei jeder Änderung am RAG-Setup wiederverwendet.
- Abgerufene Chunks sind sichtbar. Du kannst für jede Antwort genau sehen, welche Chunks an das Modell übergeben wurden – nicht nur das Endergebnis.
- „Weiß ich nicht“ ist getestet. Mindestens einige Fragen im Golden Set lassen sich anhand der Dokumente nicht beantworten, und das System weist nachweislich darauf hin, statt zu halluzinieren.
- Chunking respektiert die Struktur. Tabellen, Code-Blöcke und nummerierte Listen werden durch die Chunking-Strategie nicht mitten im Block zerteilt.
- Fehler sind nach Schichten klassifiziert. Jede falsche Antwort wird als Retrieval-Fehler oder Generierungs-Fehler eingestuft, bevor ein Lösungsversuch unternommen wird.
Aus der Praxis
Eine kleine Kanzlei baut ein RAG-System für ihr 40-seitiges Mitarbeiterhandbuch auf. Das Retrieval-Audit zeigt, dass 4 von 15 Testfragen fehlschlugen, weil der Chunker die Tabelle zum Urlaubsanspruch über zwei Chunks getrennt hatte. Das Modell sah also immer nur die halbe Tabelle – ein klarer, behebbarer Retrieval-Fehler und kein Prompting-Problem, der nur auffiel, weil das Audit Retrieval-Fehler von Generierungsfehlern trennte.
Wann du es nicht nutzen solltest
Greife nicht zu RAG, wenn der gesamte Dokumentsatz problemlos und mit reichlich Spielraum in das Kontextfenster des Modells passt. Bei einer einzelnen 10-seitigen Richtlinie lädst du sie einfach direkt hoch oder fügst sie in einen Long-Context-Prompt ein; der Overhead aus Chunking, Embeddings und Retrieval-Infrastruktur bringt dir gegenüber dem einfachen Einfügen des Ganzen keinen Vorteil. RAG rechtfertigt seine Komplexität erst, wenn der Datenbestand zu groß wird, um hineinzupassen, sich so oft ändert, dass erneutes Einfügen lästig ist, oder von vielen Nutzenden abgefragt werden muss, ohne dass jede Person alles neu hochladen muss.
Stolperfallen und Learnings
- Direkt zu RAG zu greifen, bevor geprüft wurde, ob Projects oder ein Long-Context-Upload das Problem bereits lösen würden
- Dem Modell die Schuld für falsche Antworten zu geben, obwohl das eigentliche Problem ein mangelhaftes Retrieval ist
- Dokumente so aggressiv zu zerteilen, dass zusammenhängende Gedanken (vor allem Tabellen) auseinandergerissen werden
- Auf ein Retrieval-Audit zu verzichten und somit nie die tatsächliche Treffsicherheit deines Systems zu kennen
- Blind anzunehmen, RAG könne problemlos Fragen beantworten, deren Antwort sich über fünf verschiedene Dokumente gleichzeitig erstreckt
- RAG existiert, weil Wissensdatenbanken nicht in Context Windows passen – erst abrufen, dann auf Basis der Fundstücke antworten.
- Die meisten falschen RAG-Antworten sind Retrieval-Fehler, keine Modellfehler – prüfe immer zuerst, was überhaupt geladen wurde.
- Prüfe vor dem Bau einer RAG-Pipeline, ob Projects oder Long-Context-Modelle dein Problem nicht bereits einfacher lösen.
Mach dich an die Arbeit
Ziel: Führe ein Retrieval-Audit für dein RAG-Setup durch, um dessen tatsächliche Genauigkeit zu ermitteln – anstatt einfach anzunehmen, dass es funktioniert, nur weil ein paar Testfragen gut aussahen. (40 Min.)
- Formuliere 15 realistische Fragen – keine Alibi-Fragen. Erstelle eine Liste mit 15 Fragen, die ein echter Nutzer an diese Dokumentensammlung stellen würde. Davon sollten mindestens 3 Fragen Informationen aus zwei verschiedenen Chunks kombinieren und 2 Fragen Antworten erfordern, die tatsächlich gar nicht in den Dokumenten stehen.
- Stelle jede Frage und protokolliere die abgerufenen Chunks. Notiere für jede Frage nicht nur die finale Antwort, sondern auch, welche Chunks tatsächlich abgerufen und an das Modell übergeben wurden – die meisten RAG-Tools zeigen dies in einem Panel für „Quellen“ oder „Zitate“ an.
- Bewerte jede Antwort nach einem einfachen Schema. Bewerte jede Antwort als Richtig, Teilweise richtig, Falsch oder Halluziniert (überzeugend falsch, ohne jede Grundlage in den abgerufenen Chunks). Zähle die Gesamtergebnisse zusammen.
- Diagnostiziere Fehler nach Schichten. Entscheide bei jeder nicht korrekten Antwort: Wurde der richtige Chunk gar nicht erst abgerufen (Retrieval-Fehler) oder lag der richtige Chunk vor, aber das Modell hat ihn schlecht verarbeitet (Generierungs-Fehler)? Zähle beide Kategorien separat.
- Behebe den größten einzelnen Retrieval-Fehler. Wähle das häufigste Fehlermuster – z. B. unpassendes Chunking, das eine Tabelle zerschneidet, zu wenige abgerufene Chunks (k zu niedrig) oder ein einzelnes Dokument, das die Ergebnisse dominiert – und nimm eine gezielte Optimierung vor.
- Lass alle 15 Fragen erneut laufen und vergleiche die Scores. Führe dieselben 15 Fragen nach deiner Optimierung noch einmal aus und vergleiche das Vorher-Nachher-Ergebnis. Fasse in einem Satz zusammen, was sich verbessert hat und was weiterhin hakt.
Ergebnis: Ein bewertetes Retrieval-Audit mit 15 echten Fragen (vor und nach einer Optimierung), bei dem Fehler in Retrieval vs. Generierung unterteilt sind – gespeichert als wiederverwendbares Golden Set.
Quellen
- Anthropic docs & cookbooks (docs.claude.com, github.com/anthropics — RAG guides)
- OpenAI Cookbook (cookbook.openai.com — file search/RAG)
- Latent Space (latent.space) for practitioner context