RAG: wann es sich lohnt

Retrieval-Augmented Generation, kurz RAG, ist eines der Muster, das man beim Bau von LLM-Anwendungen früh vorgeschlagen bekommt, oft als Antwort auf jedes Wissensproblem. Aus der Sicht von Entwickler:innen ist es weder Zauber noch Pflicht, sondern ein Architekturmuster mit einem klaren Zweck und ebenso klaren Grenzen. Dieser Beitrag beschreibt, welches Problem RAG löst, wie die Bausteine zusammenspielen und, vor allem, wann sich der Aufwand lohnt und wann nicht.

Das Problem: was ein LLM allein nicht weiß

Ein Large Language Model bringt sehr viel Wissen mit, aber dieses Wissen hat drei harte Grenzen. Erstens ist es statisch: Es endet am Trainingsstichtag, alles Spätere kennt das Modell nicht. Zweitens umfasst es keine privaten oder internen Daten, die nie Teil des Trainings waren, also genau die Dokumente, Tickets und Handbücher, um die es in einer konkreten Anwendung meist geht. Drittens ist das Kontextfenster endlich und jedes Token kostet Geld und Latenz. Wer das Konzept des Kontextfensters auffrischen möchte, findet es in Was ist ein LLM? (aus IT-Sicht) beschrieben.

Man könnte versucht sein, fehlendes Wissen durch die Halluzinationsneigung des Modells zu ersetzen und einfach zu hoffen, dass die Antwort schon stimmt. Genau das ist der Fehler. Das Modell erzeugt plausibel klingenden Text, nicht nachprüfbar korrekten. RAG setzt an allen drei Grenzen an, indem es Wissen zur Laufzeit statt beim Training bereitstellt und nur die relevanten Ausschnitte in den Kontext legt.

Die Grundidee: nachschlagen statt auswendig lernen

RAG lässt sich in einem Satz zusammenfassen: relevante Textausschnitte zur Antwortzeit aus einer externen Wissensbasis abrufen (Retrieval) und in den Prompt einfügen (Augmentation), bevor das Modell generiert. Das Modell bekommt so die Fakten mitgeliefert, auf die es sich stützen soll.

Diese Zwischenlösung steht zwischen zwei teureren Extremen. Das eine ist Fine-Tuning, also das Einbacken des Wissens in die Modellgewichte. Das andere ist das Vollstopfen des gesamten Korpus in das Kontextfenster bei jeder Anfrage. Ersteres ist aufwendig und muss bei jeder Änderung wiederholt werden, Letzteres ist bei nennenswerten Datenmengen schlicht zu teuer und stößt an die Fenstergrenze. Gezielt die passenden Ausschnitte nachzuschlagen ist meist der günstigste Weg, aktuelles und faktisches Wissen bereitzustellen.

Wie es funktioniert: Indexierung und Abruf

Die Pipeline zerfällt in zwei Phasen. Die erste läuft offline, einmalig oder bei Änderungen: Dokumente werden in Chunks geteilt, jeder Chunk wird in einen Embedding-Vektor umgerechnet und in einem Vektor-Index abgelegt. Die zweite läuft online, pro Anfrage: Die Frage wird in einen Vektor umgerechnet, die ähnlichsten Chunks werden per Vektorsuche gefunden, optional neu geordnet, in den Prompt eingebaut, und erst dann generiert das Modell seine Antwort, idealerweise mit Quellenangabe.

Dieses Vokabular durchzieht den Rest des Artikels: Chunk, Embedding, Vektorsuche, Ranking.

Die Bausteine im Detail

Chunking ist ein Zielkonflikt und keine feste Tokenzahl. Zu große Chunks verwässern die Ähnlichkeitssuche und verbrauchen unnötig Kontext-Tokens. Zu kleine Chunks zerreißen Zusammenhänge und liefern kontextlose Fragmente. Sinnvolle Schnitte folgen der Dokumentstruktur, also Absätzen und Abschnitten, oft mit einer Überlappung, damit Aussagen an den Chunk-Grenzen nicht verloren gehen. Die richtige Größe hängt von Dokumentart und Abfrage ab.

Embeddings bilden Text auf Vektoren ab, sodass semantisch ähnliche Texte nahe beieinanderliegen. Die Nähe misst ein Ähnlichkeitsmaß, typisch die Kosinus-Ähnlichkeit zweier Vektoren $u$ und $v$:

$\cos(u, v) = \frac{u \cdot v}{\lVert u \rVert \, \lVert v \rVert}$

Wichtig ist, dass Frage und Chunks mit demselben Embedding-Modell kodiert werden, sonst liegen sie in unvergleichbaren Räumen. Diese Vektoren sind übrigens etwas anderes als die Modellgewichte des LLM aus dem verlinkten Artikel: Erzeugt werden sie von einem eigenen, meist kleineren Modell, das genau diese Abbildung leistet. Der Gewinn: Retrieval findet Bedeutung statt Wortgleichheit. Der Preis: Bei exakten Schlüsselwörtern wie Fehlercodes, IDs oder Eigennamen versagt die semantische Suche gern, weil die genaue Zeichenfolge in der Bedeutung untergeht. Dort hilft es, die semantische Suche mit einer klassischen Stichwortsuche zu kombinieren, die sogenannte hybride Suche, etwa mit BM25, einem bewährten Verfahren, das Treffer nach Häufigkeit und Seltenheit der Suchbegriffe gewichtet.

Die Vektorsuche selbst arbeitet in großen Beständen nicht exakt, sondern approximativ. Approximative Nächste-Nachbarn-Verfahren (ANN, etwa HNSW-Indizes, spezielle Graphstrukturen, die das Auffinden ähnlicher Vektoren stark beschleunigen) tauschen Geschwindigkeit gegen minimale Genauigkeitseinbußen. Ein optionaler Re-Ranking-Schritt sortiert danach die Kandidaten der schnellen Vorauswahl mit einem präziseren, aber teureren Modell neu, um die tatsächlich besten Treffer nach oben zu bringen.

Am Ende steht das Zusammenbauen des Prompts: Die gefundenen Ausschnitte werden zusammen mit der Frage und einer Anweisung eingefügt, sich auf den mitgelieferten Kontext zu stützen und die Quelle zu benennen. Die Quellenangabe ist kein Beiwerk, sondern der Teil, der eine Antwort überhaupt nachprüfbar macht.

Wann RAG sich lohnt, und wann nicht

RAG lohnt sich, wenn die Wissensbasis groß, dynamisch, privat oder belegpflichtig ist, wenn also nachvollziehbare Quellen und Faktentreue gefragt sind und der Bestand zu groß oder zu wechselhaft für das Kontextfenster ist.

Es lohnt sich nicht in zwei Fällen. Erstens, wenn die Wissensbasis klein und stabil ist und direkt in das Kontextfenster passt: Dann kann man sie einfach mitgeben und spart sich die gesamte Retrieval-Maschinerie. Zweitens, wenn die Aufgabe reines Reasoning oder eine reine Text-Transformation ist, etwa Umformulieren, Übersetzen oder Ableiten aus dem Gegebenen. Dort gibt es nichts nachzuschlagen, und Retrieval fügt nur Komplexität und zusätzliche Fehlerquellen hinzu.

Hilfreich ist die Einordnung als drei Werkzeuge für drei Probleme. RAG liefert aktuelles und faktisches Wissen. Fine-Tuning prägt Stil, Format und Verhalten. Ein großes Kontextfenster erlaubt mehr Material pro Anfrage. Sie sind orthogonal, keine Konkurrenten, und werden oft kombiniert. Insbesondere macht ein größeres Kontextfenster RAG nicht überflüssig: Mehr Kontext kostet mehr Tokens und mehr Latenz, und gezielt die relevanten Ausschnitte zu liefern schlägt das Vollstopfen häufig auch deshalb, weil Modelle Information am Anfang und Ende des Kontexts zuverlässiger nutzen als in der Mitte.

Typische Fehlerquellen

Auffällig ist, dass fast alle RAG-Probleme im Retrieval sitzen, nicht im Modell. Die häufigsten Fallen sind:

• Schlechtes Chunking, das Zusammenhänge zerreißt oder verwässert.
• Irrelevante oder unvollständige Treffer, weil die Suche daneben greift.
• Ein veralteter Index, der nicht mit der Wissensbasis Schritt hält.
• Fehlende oder falsche Quellenangaben, sodass die Antwort nicht überprüfbar ist.
• Das Modell fällt trotz mitgeliefertem Kontext auf sein Eigenwissen zurück oder interpretiert das Gefundene falsch (Halluzination trotz RAG).
• Reihenfolge-Effekte: In der Mitte des Kontexts platzierte Treffer werden schlechter genutzt.

Wer eine RAG-Anwendung debuggt, sollte deshalb zuerst prüfen, was das Retrieval tatsächlich zurückgibt, bevor er am Modell oder am Prompt dreht.

Fazit

RAG ist ein Architekturmuster, kein Zauber: Es verbessert die Information, mit der das Modell startet, garantiert aber keine korrekte Antwort und ersetzt weder Reasoning noch die Validierung der Ausgabe. Es lohnt sich bei großen, dynamischen, privaten oder belegpflichtigen Wissensbeständen und ist verzichtbar, wenn die Daten ohnehin in den Kontext passen oder es nichts nachzuschlagen gibt. Wer es einsetzt, sollte im Blick behalten, dass die meisten Probleme Retrieval-Probleme sind. Und die Ausgabe bleibt, wie bei jedem LLM, eine unsichere Eingabe, die geprüft gehört.