Das Kontextfenster von LLMs — was reinpasst und was nicht
Das Kontextfenster ist eine der wichtigsten und am häufigsten missverstandenen Eigenschaften eines Sprachmodells. Kurz gesagt: Es ist der Arbeitsspeicher des Modells für eine einzelne Anfrage — die maximale Menge an Tokens, die es gleichzeitig berücksichtigen kann. Alles, was reinpasst, kann das Modell verarbeiten. Alles darüber hinaus muss anders gelöst werden. Dieser Artikel erklärt, was das Fenster ist, wie groß es heute ist, wo seine Grenzen liegen und wann du stattdessen RAG brauchst.
Was das Kontextfenster ist
Ein LLM hat kein Gedächtnis im menschlichen Sinn. Bei jeder Anfrage bekommt es einen Block Text — System-Prompt, Konversationsverlauf, deine Frage, eingebettete Dokumente — und produziert daraus eine Antwort. Das Kontextfenster ist die Obergrenze für diesen Block plus die Antwort, gemessen in Tokens.
Wichtig: Das Fenster umfasst Input und Output zusammen. Wenn ein Modell ein Fenster von 200.000 Tokens hat und dein Input bereits 195.000 Tokens belegt, bleiben nur 5.000 für die Antwort. Wer den ganzen Platz mit Kontext vollstopft, lässt dem Modell keinen Raum zum Antworten.
Ein Token ist dabei nicht ein Wort, sondern ein Textfragment — als grobe Faustregel etwa 0,75 Wörter im Englischen, im Deutschen wegen Komposita oft weniger. 200.000 Tokens entsprechen ungefähr einem dicken Buch.
Wie groß moderne Fenster sind
Die Größen sind in den letzten Jahren explodiert. Eine Momentaufnahme (Stand 2026):
- Frühe LLMs hatten Fenster von einigen Tausend Tokens (4k, 8k).
- Die mittlere Generation lag bei 32k bis 128k Tokens.
- Aktuelle Spitzenmodelle reichen bis 1 Million Tokens und mehr — genug für ganze Codebasen, mehrere lange PDFs oder umfangreiche Gesprächsverläufe.
Diese Zahlen verschieben sich schnell, deshalb ist jede konkrete Angabe eine Momentaufnahme. Der Trend ist aber eindeutig: größer. Trotzdem heißt „passt rein” nicht automatisch „wird gut genutzt” — und genau da kommt das nächste Phänomen ins Spiel.
Lost in the Middle
Ein großes Fenster ist keine Garantie dafür, dass das Modell alles darin gleich gut verwertet. Die Studie Lost in the Middle (Liu et al., 2023) zeigte ein robustes Muster: Modelle nutzen Informationen am Anfang und Ende eines langen Kontexts deutlich besser als die in der Mitte. Die Trefferleistung folgt einer U-Kurve — relevante Fakten, die in der Mitte eines langen Dokuments stehen, werden schlechter gefunden als dieselben Fakten am Rand.
Praktische Konsequenz: Nur weil du 500.000 Tokens reinwirfst, heißt das nicht, dass das Modell den entscheidenden Satz auf Seite 300 findet. Die wichtigsten Informationen gehören an den Anfang oder das Ende deines Prompts, nicht in die Mitte einer Textwüste. Neuere Modelle haben dieses Problem abgemildert, aber verschwunden ist es nicht.
Kosten und Latenz
Lange Kontexte sind nicht gratis. Zwei Effekte:
Kosten. Du zahlst pro Input-Token. Ein Prompt mit 800.000 Tokens kostet pro Anfrage das Hundertfache eines Prompts mit 8.000 Tokens. Wer aus Bequemlichkeit das halbe Wiki in jeden Prompt kippt, verbrennt Geld für Kontext, den das Modell oft gar nicht braucht.
Latenz. Mehr Input bedeutet mehr Rechenarbeit, bevor das erste Antwort-Token erscheint. Lange Kontexte machen die Antwort spürbar langsamer. Für interaktive Anwendungen (Chat, Voice) ist das ein echtes Problem.
Eine verbreitete Gegenmaßnahme ist Prompt-Caching: Der stabile Teil eines Prompts (etwa ein langer System-Prompt oder ein fixes Dokument) wird vom Anbieter zwischengespeichert und bei Folgeanfragen günstiger und schneller verarbeitet. Das senkt Kosten und Latenz für wiederkehrende Kontexte deutlich.
Abgrenzung: Kontext vs. Langzeitgedächtnis und RAG
Hier liegt das zentrale Missverständnis. Das Kontextfenster ist flüchtig: Es existiert nur für die Dauer einer Anfrage. Nach der Antwort ist es weg. Das Modell „erinnert” sich an nichts — bei jeder neuen Anfrage musst du den relevanten Kontext erneut mitschicken.
Wenn dein Wissensbestand größer ist als das Fenster (eine ganze Dokumentensammlung, eine Datenbank, ein Firmen-Wiki), kannst du nicht einfach alles reinpacken. Die Lösung ist RAG (Retrieval-Augmented Generation): Statt das gesamte Wissen ins Fenster zu zwingen, wird zu jeder Anfrage nur das Relevante aus einem externen Speicher geholt und in den Kontext eingefügt.
Die Praxis-Regel lautet also:
- Ins Kontextfenster gehört, was für diese konkrete Aufgabe gebraucht wird: die aktuelle Frage, der relevante Gesprächsverlauf, die paar Dokumente, auf die es jetzt ankommt.
- Per RAG geholt wird, was zu groß, zu volatil oder zu selten gebraucht ist, um es dauerhaft mitzuschleppen: die Wissensdatenbank, aus der nur passende Ausschnitte abgerufen werden.
Das größere Fenster macht RAG nicht überflüssig — es verschiebt nur die Grenze, ab der du es brauchst. Selbst ein 1-Million-Token-Fenster ist gegenüber einer wachsenden Dokumentensammlung endlich, teuer und vom Lost-in-the-Middle-Effekt betroffen.
FAQ
Ist ein größeres Kontextfenster immer besser? Nicht automatisch. Es erlaubt mehr Input, aber lange Kontexte kosten mehr, sind langsamer und leiden unter Lost in the Middle. Ein präziser, kurzer Kontext schlägt oft einen riesigen, vollgestopften. Größer ist eine Option, kein Selbstzweck.
Was bedeutet, dass Input und Output sich das Fenster teilen? Die Tokens deines Prompts und die Tokens der Antwort zählen zusammen gegen das Limit. Füllst du das Fenster fast komplett mit Input, bleibt kaum Platz für eine ausführliche Antwort — das Modell wird mittendrin abgeschnitten.
Erinnert sich das Modell an frühere Gespräche? Nein, nicht von sich aus. Das Kontextfenster ist flüchtig und existiert nur pro Anfrage. „Gedächtnis” über Sitzungen hinweg entsteht nur, wenn die Anwendung frühere Inhalte erneut mitschickt oder über RAG/externe Speicher bereitstellt.
Wann brauche ich RAG statt eines großen Fensters? Sobald dein Wissensbestand größer ist als das Fenster, sich häufig ändert oder zu teuer wäre, ihn jedes Mal komplett mitzusenden. RAG holt zu jeder Anfrage nur die relevanten Ausschnitte — das ist günstiger, schneller und umgeht den Lost-in-the-Middle-Effekt.
Was ist Lost in the Middle konkret? Ein empirisch belegtes Muster: Modelle verwerten Informationen am Anfang und Ende eines langen Kontexts besser als die in der Mitte. Praktisch heißt das: Wichtiges nicht in die Mitte einer langen Texteingabe vergraben, sondern an den Rand setzen.
Entdecke mehr
RAG verstehen — von der Idee bis zum produktiven System
Wie eine RAG-Pipeline funktioniert: Embedding, Vektor-DB, Retrieval, Reranking, Prompt — und welche Stolperfallen typisch sind.
BlogKI-Workflows per Keyword: Wie wir wiederkehrende Abläufe erzwingbar machen
Ein getipptes Keyword löst bei uns einen festen KI-Ablauf aus — und jeder Schritt muss committet werden, bevor der nächste kommt. Warum das der Trick ist.
GlossarReasoning Effort
Reasoning Effort ist ein Steuerparameter moderner Reasoning-Modelle, der festlegt, wie viel internes Schritt-für-Schritt-Denken (Thinking-Tokens) ein Modell vor der Antwort aufwendet — höhere Stufen erhöhen Qualität, aber auch Latenz und Kosten.