RAG vs. Kontextfenster: Wann brauche ich was?

Was dieser Artikel über RAG vs. Kontextfenster behandelt

• Die Unterschiede zwischen RAG und einem großen Kontextfenster, einfach erklärt
• Vor- und Nachteile beider Ansätze bei Kosten, Geschwindigkeit und Genauigkeit
• Konkrete Szenarien, wann RAG sinnvoller ist und wann das Kontextfenster reicht
• Ein durchgerechnetes Beispiel mit 500 Seiten Dokumentation und echten Zahlen
• Typische Stolpersteine und wie Du sie vermeidest

Einleitung: RAG vs. Kontextfenster verständlich erklärt

Sprachmodelle haben ein begrenztes Gedächtnis, das Kontextfenster. In den letzten Jahren sind diese Fenster deutlich größer geworden. Modelle wie Llama 3 oder Qwen2 unterstützen mittlerweile 128.000 Token und mehr. Das wirft eine Frage auf: Brauche ich überhaupt noch RAG, wenn ich alles in den Kontext passen kann?

Die kurze Antwort: Ja, in vielen Fällen schon. Ein großes Kontextfenster ersetzt RAG nicht vollständig, es ergänzt ihn. Beide Ansätze haben ihre Stärken und Schwächen. Dieser Artikel hilft Dir, die richtige Entscheidung für Deinen Anwendungsfall zu treffen.

Wenn Du neu bei lokaler KI bist, lies zuerst Was ist lokale KI?. Die Grundlagen zu RAG findest Du unter RAG Grundlagen.

Warum brauche ich diesen Vergleich?

Stell Dir vor, Du hast 500 Seiten technische Dokumentation. Eine neue Kollegin hat eine konkrete Frage zur API-Authentifizierung. Du könntest jetzt alle 500 Seiten in das Kontextfenster des Modells laden und hoffen, dass es die Antwort findet. Oder Du nutzt RAG, suchst vorher die relevanten drei Seiten heraus und übergibst nur diese.

Beide Wege funktionieren, aber sie unterscheiden sich massiv in Kosten, Geschwindigkeit und Zuverlässigkeit. Ohne diesen Vergleich riskierst Du, entweder zu viel Rechenleistung zu verschwenden oder schlechte Antworten zu bekommen, weil das Modell in einer Flut von Text die wichtige Stelle übersieht.

RAG vs. Kontextfenster kurz erklärt

Ein Bild zum Verständigen: Stell Dir vor, Du sollst eine Frage aus einem 800-Seiten-Buch beantworten.

Kontextfenster-Ansatz: Du liest das gesamte Buch in einem Rutsch durch und suchst dann nach der Antwort. Das dauert lange und am Ende bist Du so erschöpft, dass Du Details übersiehst.

RAG-Ansatz: Du schlägst im Index nach, welche Seiten relevant sind, liest nur diese drei Seiten und beantwortest die Frage. Das geht schneller und Du behältst den Überblick.

Genau so arbeiten Sprachmodelle. Ein großes Kontextfenster liest alles, RAG sucht vorher die passenden Stellen heraus.

Für wen ist dieser Vergleich gedacht?

Dieser Artikel richtet sich an alle, die lokale KI für Dokumente einsetzen wollen und sich fragen, welcher Ansatz der richtige ist. Ob Du eine interne Wissensdatenbank aufbaust, Kundendokumentation durchsuchbar machst oder einfach Deine Notizen intelligenter abfragen willst, hier findest Du die Entscheidungshilfe.

Vorkenntnisse in RAG sind hilfreich, aber nicht zwingend. Die wichtigsten Begriffe werden im nächsten Abschnitt erklärt.

Wichtige Begriffe rund um RAG und Kontextfenster

Begriff	Bedeutung
RAG	Retrieval Augmented Generation, Suche nach passenden Textstellen vor der Antwortgenerierung
Kontextfenster	Maximale Textmenge, die ein Modell in einem Aufruf verarbeiten kann
Context Window	Englischer Begriff für Kontextfenster
Token	Verarbeitungseinheit des Modells, etwa drei Viertel eines Wortes
Embedding	Zahlenvektor, der den Inhalt eines Textabschnitts repräsentiert
Retrieval	Suche nach passenden Dokumentenabschnitten in einer Vektordatenbank
Chunking	Aufteilen von Dokumenten in kleinere Abschnitte
Vektordatenbank	Speicher, der Textabschnitte als Vektoren ablegt und durchsucht
Long Context	Modelle mit besonders großem Kontextfenster, oft über 100.000 Token
Needle in Haystack	Test, bei dem eine Information in viel Text versteckt wird, um die Treffsicherheit zu prüfen

Mehr zu den Grundlagen findest Du unter RAG Grundlagen und Kontextlänge.

Was ist RAG?

RAG steht für Retrieval Augmented Generation. Das System durchsucht zuerst eine Vektordatenbank nach Textabschnitten, die zur Frage passen. Diese Abschnitte werden zusammen mit der Frage an das Sprachmodell übergeben. Das Modell formuliert die Antwort auf Basis der gelieferten Informationen.

Die Pipeline besteht aus mehreren Schritten: Dokumente laden, in Chunks teilen, Embeddings erzeugen, in einer Vektordatenbank speichern und bei einer Frage die relevanten Chunks suchen. Mehr dazu findest Du in den Artikeln zu Chunking, Embedding-Modelle und Vektordatenbanken.

Der Vorteil: Das Modell bekommt nur die relevanten Stellen und nicht das gesamte Dokument. Das spart Token, reduziert Kosten und verbessert die Genauigkeit.

Was ist das Kontextfenster?

Das Kontextfenster ist der Speicherplatz, den ein Modell für einen einzelnen Aufruf zur Verfügung hat. Es begrenzt, wie viel Text Du in einem Prompt übergeben kannst. Frühe Modelle hatten 2.000 oder 4.000 Token. Heute sind 8.000 Token der Standard, viele Modelle unterstützen 32.000, 128.000 oder sogar 200.000 Token.

Bei 128.000 Token passen etwa 300 bis 400 Druckseiten Text in einen einzigen Aufruf. Das klingt nach viel, bringt aber eigene Probleme mit sich. Je mehr Text im Kontext steht, desto langsamer wird das Modell. Außerdem sinkt die Genauigkeit, weil das Modell dazu neigt, Informationen in der Mitte eines langen Kontexts zu übersehen. Dieses Phänomen ist als “Lost in the Middle” bekannt.

Details dazu findest Du im Artikel Kontextlänge.

Direkter Vergleich

Eigenschaft	RAG	Großes Kontextfenster
Kosten pro Anfrage	Gering, nur relevante Chunks werden verarbeitet	Hoch, jeder Token im Kontext kostet
Geschwindigkeit	Schnell, wenig Text für das Modell	Langsamer, mehr Text muss verarbeitet werden
Genauigkeit	Hoch bei guter Retrieval-Qualität	Sinkt bei sehr langem Kontext (Lost in the Middle)
Skalierbarkeit	Sehr gut, tausende Dokumente möglich	Begrenzt durch Kontextgröße
Setup-Aufwand	Höher, Vektordatenbank und Pipeline nötig	Gering, Text direkt in den Prompt
Wartung	Embeddings müssen aktualisiert werden	Keine zusätzliche Wartung
Quellennachweis	Ja, gefundene Chunks sind sichtbar	Schwer nachvollziehbar bei langem Kontext
Aktualität	Neue Dokumente einfach hinzufügbar	Gesamten Text neu laden

Wann reicht ein großes Kontextfenster?

Ein großes Kontextfenster reicht in mehreren Situationen:

Kleine Dokumente: Wenn Du ein 20-seitiges PDF oder eine kurze Anleitung hast, passt das locker in den Kontext. RAG wäre hier übertrieben.

Einmalige Fragen: Wenn Du eine einzige Frage zu einem Dokument hast und keine wiederkehrenden Abfragen planst, ist es einfacher, den Text direkt in den Prompt zu kopieren.

Schnelles Prototyping: Für einen ersten Test oder einen Proof of Concept ist der Kontextfenster-Ansatz schneller aufgesetzt. Du brauchst keine Vektordatenbank und keine Embedding-Pipeline.

Zusammenfassungen: Wenn Du ein Dokument zusammenfassen oder übersetzen willst, braucht das Modell den gesamten Text. RAG hilft hier nicht, weil es nur Teile liefert.

Wenige Dokumente: Bei fünf bis zehn kurzen Dokumenten ist der Aufwand für RAG oft größer als der Nutzen.

Wann brauche ich RAG?

RAG wird notwendig, wenn folgende Bedingungen zutreffen:

Große Wissensbasis: Ab etwa 50 bis 100 Seiten lohnt sich RAG. Bei mehreren tausend Dokumenten ist RAG unverzichtbar.

Häufige Abfragen: Wenn viele Nutzer regelmäßig Fragen stellen, addieren sich die Kosten für lange Kontexte schnell. RAG hält jede Anfrage klein und günstig.

Kosten spielen eine Rolle: Jeder Token im Kontext kostet Rechenleistung. Bei lokaler KI bedeutet das mehr RAM und langsamere Antworten. RAG reduziert die Token-Anzahl pro Anfrage drastisch.

Mehrere Nutzer: Wenn mehrere Personen gleichzeitig Fragen stellen, belasten lange Kontexte den Rechner stärker. RAG verteilt die Last besser.

Quellennachweis wichtig: In rechtlichen oder medizinischen Bereichen musst Du nachweisen, woher eine Antwort stammt. RAG liefert die Quell-Chunks direkt mit.

Dokumente ändern sich oft: Neue Versionen, aktualisierte Handbücher oder hinzugefügte Notizen lassen sich bei RAG einfach in die Datenbank aufnehmen. Ohne RAG müsstest Du jedes Mal den gesamten Text neu laden.

Kann ich beides kombinieren?

Ja, und das ist oft die beste Lösung. Der Hybrid-Ansatz nutzt RAG für die Suche und ein großes Kontextfenster für die Verarbeitung der gefundenen Chunks.

So funktioniert es: RAG sucht die relevantesten 10 bis 20 Chunks aus der Datenbank. Diese werden nicht sofort an das Modell übergeben, sondern zuerst gefiltert und neu geordnet. Dann landen nur die besten 5 Chunks im Kontext. Das Modell hat genug Platz, um sie gründlich zu analysieren, ohne von irrelevantem Text abgelenkt zu werden.

Ein anderer Ansatz ist RAG mit Re-Ranking. Die Vektordatenbank liefert 20 Kandidaten, ein Re-Ranker sortiert sie nach Relevanz und das Modell bekommt nur die Top 5. Das kombiniert die Skalierbarkeit von RAG mit der Genauigkeit eines fokussierten Kontexts.

Beispiel: 500 Seiten Dokumentation

Nehmen wir das Beispiel von oben: 500 Seiten technische Dokumentation, etwa 250.000 Token.

Ansatz 1: Alles in den Kontext

Ein Modell mit 256.000 Token Kontext könnte das gesamte Dokument auf einmal laden. Bei jeder Frage werden 250.000 Token verarbeitet. Bei 100 Fragen am Tag sind das 25 Millionen Token pro Tag. Die Antwortzeit liegt bei mehreren Minuten pro Frage, weil das Modell den gesamten Text durchgehen muss. Außerdem steigt das Risiko, dass das Modell wichtige Details übersieht.

Ansatz 2: RAG

Die 500 Seiten werden in etwa 1.000 Chunks zu je 250 Token geteilt. Bei einer Frage sucht die Vektordatenbank die 5 relevantesten Chunks. Das Modell verarbeitet nur etwa 1.500 Token plus die Frage. Bei 100 Fragen am Tag sind das 150.000 Token, also 0,6 Prozent der Menge vom Kontext-Ansatz. Die Antwort kommt in Sekunden statt Minuten.

Vergleich

Metrik	Kontextfenster	RAG
Token pro Anfrage	250.000	1.500
Token pro Tag (100 Fragen)	25.000.000	150.000
Antwortzeit	Minuten	Sekunden
Setup-Aufwand	Keiner	Vektordatenbank nötig
Genauigkeit bei gezielten Fragen	Sinkt mit Länge	Bleibt hoch

Die Zahlen zeigen es deutlich: Bei großen Dokumentenmengen ist RAG nicht nur günstiger, sondern auch schneller und zuverlässiger.

Typische Stolpersteine bei RAG vs. Kontextfenster

1. Lost in the Middle: Lange Kontexte führen dazu, dass Informationen in der Mitte übersehen werden. RAG vermeidet dieses Problem, weil nur kurze, relevante Abschnitte übergeben werden.

2. Schlechtes Chunking zerstört RAG: Wenn Chunks mitten im Satz enden oder wichtige Zusammenhänge trennen, findet die Suche schlechte Treffer. Investiere Zeit in gutes Chunking.

3. Falsches Embedding-Modell: Ein englisches Embedding-Modell funktioniert schlecht mit deutschen Texten. Wähle ein mehrsprachiges oder deutsches Modell, siehe Embedding-Modelle.

4. Kontextfenster als Allheilmittel: Ein großes Fenster löst nicht automatisch das Problem. Bei tausenden Dokumenten reicht auch 128K Token nicht aus, und die Qualität sinkt.

5. Keine Quellenprüfung bei RAG: RAG liefert Quellen, aber wenn die gefundenen Chunks nicht zur Frage passen, ist die Antwort trotzdem falsch. Prüfe die Retrieval-Qualität regelmäßig.

6. Vergessene Aktualisierung: Neue Dokumente müssen in die Vektordatenbank aufgenommen werden. Vergisst Du das, fehlen aktuelle Informationen in den Antworten.

7. Zu viele Chunks im Kontext: Auch bei RAG kannst Du zu viel übergeben. Wenn Du 20 Chunks in den Prompt lädst, sinkt die Genauigkeit ähnlich wie bei langem Kontext. Weniger ist oft mehr.

8. Keine Evaluation: Ohne systematisches Testen mit bekannten Fragen weißt Du nicht, ob RAG oder Kontextfenster besser funktioniert. Baue einen Testsatz ein.

Hardware, Kosten und Sicherheit bei RAG vs. Kontextfenster

Hardware: RAG benötigt ein Embedding-Modell und eine Vektordatenbank. Das Embedding-Modell ist klein, oft unter 500 MB. Die Vektordatenbank braucht Speicherplatz für die Vektoren, bei 1.000 Dokumenten sind das wenige Megabyte. Der Kontextfenster-Ansatz braucht kein zusätzliches Setup, aber ein Modell mit großem Kontextfenster benötigt deutlich mehr RAM während der Verarbeitung.

Kosten: Bei lokaler KI mit Ollama kostet jeder Token Rechenzeit. RAG reduziert die Token-Anzahl pro Anfrage auf ein Bruchteil. Bei häufigen Abfragen amortisiert sich der Setup-Aufwand schnell. Für einmalige Fragen ist der Kontextfenster-Ansatz günstiger, weil kein Pipeline-Setup nötig ist.

Sicherheit: Beide Ansätze können vollständig lokal laufen. Deine Dokumente verlassen Deinen Rechner nicht. Das ist der große Vorteil lokaler KI gegenüber Cloud-Diensten. RAG speichert zusätzlich Vektoren in einer lokalen Datenbank, aber auch diese bleibt auf Deinem System. Mehr dazu unter Was ist lokale KI?.

Weiterführende Links und Infos zu RAG vs. Kontextfenster

• Lokales RAG als Übersichtsseite
• RAG Grundlagen für die Pipeline im Detail
• Chunking für die Textaufteilung
• Embedding-Modelle für die Vektorisierung
• Vektordatenbanken für die Speicherung
• Kontextlänge für die Details zum Kontextfenster
• Ollama als lokaler Modell-Runner

FAQ: RAG vs. Kontextfenster - Typische Fragen

Ist RAG noch nötig bei 128K Token Kontextfenster?

Ja. 128K Token reichen für etwa 300 Seiten. Bei größeren Dokumentenmengen oder häufigen Abfragen ist RAG effizienter und genauer. Außerdem sinkt die Qualität bei langen Kontexten.

Was kostet RAG im Vergleich zum Kontextfenster?

Bei lokaler KI kostet RAG Rechenzeit für das Embedding-Modell und Speicher für die Datenbank. Pro Anfrage verarbeitet RAG aber viel weniger Token, was bei häufigen Fragen deutlich günstiger ist.

Kann ich RAG ohne Vektordatenbank nutzen?

Theoretisch ja, mit einer Volltextsuche. Die Qualität ist dann aber schlechter, weil keine semantische Suche stattfindet. Eine Vektordatenbank ist empfehlenswert.

Welches Modell hat das größte Kontextfenster?

Modelle wie Qwen2 unterstützen bis zu 128.000 Token. Llama 3.1 bietet ebenfalls 128.000 Token. Claude 3 erreicht 200.000 Token, ist aber kein lokales Modell.

Was ist “Lost in the Middle”?

Ein Effekt, bei dem Sprachmodelle Informationen am Anfang und Ende eines langen Kontexts besser erkennen als in der Mitte. RAG umgeht dieses Problem durch kurze, fokussierte Kontexte.

Wie viele Chunks sollte ich bei RAG übergeben?

3 bis 5 Chunks sind ein guter Startwert. Mehr als 10 Chunks verschlechtern oft die Qualität, weil das Modell wieder zu viel Kontext verarbeiten muss.

Lohnt sich RAG für ein einzelnes PDF?

Bei einem kurzen PDF unter 20 Seiten reicht das Kontextfenster. Bei einem langen PDF ab 50 Seiten oder bei häufigen Abfragen lohnt sich RAG.

Kann ich beides kombinieren?

Ja. RAG sucht die relevanten Chunks, das Kontextfenster verarbeitet sie. Das ist oft die beste Lösung, weil sie Skalierbarkeit mit Genauigkeit verbindet.

Wie teste ich, welcher Ansatz besser ist?

Erstelle einen Satz von 20 bis 50 typischen Fragen mit bekannten Antworten. Teste beide Ansätze und vergleiche Genauigkeit, Geschwindigkeit und Token-Verbrauch.

Brauche ich eine GPU für RAG?

Nicht zwingend. Das Embedding-Modell läuft oft auch auf der CPU. Für das Sprachmodell selbst ist eine GPU empfehlenswert, besonders bei längeren Kontexten.

Was passiert, wenn RAG die falschen Chunks findet?

Dann ist die Antwort falsch, obwohl das Modell gut funktioniert. Prüfe die Retrieval-Qualität mit Testfragen und verbessere Chunking und Embedding-Modell.

Quellen und weiterführende Literatur

• LangChain RAG-Tutorials
• LlamaIndex Dokumentation
• Qdrant und Chroma Vektordatenbank-Dokumentation
• Forschung zum Thema “Lost in the Middle” (Liu et al., 2024)
• Hugging Face Embedding-Modelle Übersicht
• Ollama Modellübersicht