RAG vs. Long-Context-Fenster
Wissen
2023 hatten die meisten Modelle maximal 128K Tokens. 2026 bieten Claude Opus 5, GPT-5.6 und Gemini 3.1 Kontextfenster von 1 Million Tokens und mehr. Das wirft eine fundamentale Frage auf:
Wenn ich eine Million Tokens in den Kontext laden kann -- brauche ich dann überhaupt noch RAG?
Die kurze Antwort: Es kommt darauf an. Die lange Antwort ist das Thema dieser Lektion.
Verstehen
Long Context: Alles rein, LLM findet es
Der Long-Context-Ansatz ist radikal einfach: Lade alle relevanten Dokumente in den Kontext und lass das LLM die Antwort finden. Kein Embedding, kein Chunking, keine Vector Database, kein Retrieval-Schritt.
Vorteile:
- Keine Pipeline-Komplexität: Kein Chunking-Tuning, kein Embedding-Modell, keine Vector DB
- Kein Retrieval-Verlust: Das LLM sieht alle Informationen, nichts geht beim Retrieval verloren
- Cross-Referenz: Das LLM kann Zusammenhänge über das gesamte Dokument erkennen
- Einfache Implementierung: Dokument laden, Frage stellen, fertig
Grenzen:
- Kosten: 1M Token Input bei GPT-5.6 kostet signifikant mehr als ein Retrieval-Aufruf mit 5 Chunks
- Latenz: Mehr Tokens = langsamere Verarbeitung, besonders bei der ersten Token-Latenz
- "Needle in a Haystack"-Effekt: LLMs können Informationen in der Mitte langer Kontexte übersehen
- Skalierung: 1M Tokens klingt viel, sind aber nur ~750K Wörter oder ~1.500 Seiten. Für 50.000 Dokumente reicht das nicht
- Keine Persistenz: Jede Query muss alles neu laden -- keine inkrementelle Indexierung
RAG: Gezielt suchen, wenig laden
RAG folgt dem umgekehrten Prinzip: Lade nur die relevantesten Chunks in den Kontext. Der Retrieval-Schritt filtert tausende Dokumente auf die 5--20 relevantesten Abschnitte.
Vorteile:
- Skalierung: Funktioniert mit Millionen von Dokumenten
- Kosten-Effizienz: Nur relevante Chunks werden an das LLM gesendet
- Latenz: Weniger Tokens im Kontext = schnellere Antworten
- Persistenz: Einmal indexiert, immer durchsuchbar
- Inkrementelle Updates: Neue Dokumente können einzeln hinzugefügt werden
Grenzen:
- Retrieval-Verlust: Wenn der relevante Chunk nicht gefunden wird, fehlt die Information
- Pipeline-Komplexität: Chunking, Embedding, Vector DB, Re-Ranking -- alles muss funktionieren
- Kontext-Fragmentierung: Chunks zeigen Ausschnitte, nicht das Gesamtbild
Dokumenten-Korpus (7 Dokumente)
Neuronale Netze
Neuronale Netze bestehen aus künstlichen Neuronen, die in Schichten angeordnet sind und durch Training Muster erkennen.
Transformer-Architektur
Transformer nutzen Self-Attention, um Beziehungen zwischen allen Tokens gleichzeitig zu erfassen. GPT und BERT basieren darauf.
Vektordatenbanken
Vektordatenbanken wie Pinecone oder Weaviate speichern Embeddings und ermöglichen schnelle Nearest-Neighbor-Suche.
Prompt Engineering
Durch geschicktes Formulieren von Prompts können LLMs präzisere und nützlichere Antworten generieren.
RAG-Pipelines
Retrieval Augmented Generation kombiniert Dokumentensuche mit Textgenerierung, um fundierte Antworten zu liefern.
Tokenisierung
Tokenizer zerlegen Text in Subwort-Einheiten. BPE und SentencePiece sind gängige Verfahren für moderne Sprachmodelle.
Fine-Tuning
Beim Fine-Tuning wird ein vortrainiertes Modell auf einem spezifischen Datensatz weiter trainiert, um es an eine Aufgabe anzupassen.
Simulierte Embedding-Suche. Die Scores sind vereinfacht berechnet, um das Prinzip zu demonstrieren.
Die Entscheidungsmatrix
| Faktor | Long Context bevorzugt | RAG bevorzugt |
|---|---|---|
| Dokumentenmenge | < 500 Seiten | > 500 Seiten |
| Update-Frequenz | Selten (statische Dokumente) | Häufig (täglich/wöchentlich) |
| Kostenbudget | Hoch (Enterprise) | Kostenbewusst |
| Latenz-Anforderung | Tolerant (> 5s akzeptabel) | Streng (< 2s) |
| Fragetyp | Analytisch, cross-referenziell | Fokussiert, faktenbasiert |
| Dokumenten-Beziehungen | Stark vernetzt | Unabhängig voneinander |
Der Hybrid-Ansatz: RAG + Long Context
In der Praxis 2026 nutzen viele Systeme beides:
- RAG als Vorfilter: Retrieval reduziert 50.000 Dokumente auf die 50 relevantesten
- Long Context für Synthese: Die 50 Dokumente (statt nur 5 Chunks) werden vollständig in den Kontext geladen
- Das LLM hat genug Kontext für tiefe Analyse, ohne für irrelevante Informationen zu zahlen
Dieser Ansatz kombiniert die Skalierung von RAG mit der Tiefe von Long Context.
iDer Trend geht zu Hybrid
Die Frage ist nicht mehr "RAG oder Long Context", sondern "wie kombiniere ich beides optimal?" RAG für den Recall, Long Context für die Analyse.
Ein Anwaltsbüro will einen AI-Assistenten, der Fragen zu einem einzelnen, 200-seitigen Vertrag beantwortet. Der Vertrag ändert sich nicht. Was ist der beste Ansatz?
Anwenden
Kosten-Vergleich (Richtwerte 2026)
Annahme: 1.000 Fragen pro Tag an eine Wissensbasis mit 10.000 Dokumenten.
| Ansatz | Input-Tokens/Query | Kosten/Query (ca.) | Infrastruktur |
|---|---|---|---|
| RAG (5 Chunks) | ~2.500 | ~$0.004 | Vector DB + Embedding |
| RAG (20 Chunks) | ~10.000 | ~$0.015 | Vector DB + Embedding |
| Long Context (100 Seiten) | ~40.000 | ~$0.060 | Keine |
| Long Context (1.000 Seiten) | ~400.000 | ~$0.600 | Keine |
| Hybrid (RAG-Filter + 50 Docs) | ~100.000 | ~$0.150 | Vector DB + Embedding |
Bei 1.000 Queries/Tag:
- RAG (5 Chunks): ~$4/Tag = ~$120/Monat
- Long Context (1.000 Seiten): ~$600/Tag = ~$18.000/Monat
- Hybrid: ~$150/Tag = ~$4.500/Monat
Wann der Kostenunterschied egal ist
- Low-Volume: Bei 10 Queries pro Tag sind die Unterschiede vernachlässigbar
- High-Value: Wenn eine falsche Antwort $10.000 kostet, ist der Unterschied zwischen $0.004 und $0.60 irrelevant
- Prototyp/MVP: Long Context ist schneller implementiert, die Kosten sind im Prototyp-Stadium egal
Reflektieren
Berechne für deinen Use Case: Wie viele Dokumente, wie viele Queries pro Tag, wie hoch sind die Kosten? Oft zeigt die Rechnung, dass die intuitive Antwort nicht die wirtschaftlichste ist.