LLM-Kontextfenster erklärt: Limits, Strategien und der richtige Umgang

Eine der häufigsten Frustrationsquellen für Entwickler, die mit LLMs bauen, ist das Aufprallen auf eine unsichtbare Wand – eine Anfrage, die ohne Erklärung scheitert, ein Gespräch, das plötzlich den Kontext verliert, oder ein Dokument, das unvollständig verarbeitet wird. In fast jedem Fall ist das Kontextfenster der Schuldige. Zu verstehen, was ein Kontextfenster ist, was seine Grenzen in der Praxis bedeuten und wie man geschickt damit umgeht, ist grundlegend für den Aufbau zuverlässiger KI-Anwendungen.

Mit dem BrowseryTools Kontextfenster-Tool – kostenlos, keine Anmeldung, alles bleibt im Browser – kann man visualisieren, wie viel vom Kontextfenster eines Modells der eigene Inhalt belegt, bevor er an eine API gesendet wird.

Was ist ein Kontextfenster?

Ein Kontextfenster ist die maximale Textmenge – in Token gemessen –, die ein Sprachmodell in einer einzigen Anfrage „sehen" und darüber nachdenken kann. Es ist das Arbeitsgedächtnis des Modells. Alles, was für die Generierung des nächsten Tokens relevant ist, muss in dieses Fenster passen: die System-Eingabeaufforderung, der vollständige Gesprächsverlauf, alle eingeschlossenen Dokumente und die Token, die das Modell gerade generiert.

Anders als das menschliche Arbeitsgedächtnis, das bei Überlastung schrittweise nachlässt, haben Kontextfenster eine harte Grenze. Wird sie überschritten, gibt die API einen Fehler zurück. Es gibt keinen Teilerfolg – die Anfrage scheitert einfach, und die Anwendung muss damit umgehen.

Das Kontextfenster ist ein gemeinsamer Pool für Eingabe und Ausgabe. Hat ein Modell ein 128K-Token-Kontextfenster und die Eingabe beträgt 120K Token, verbleiben nur 8K Token für die Antwort des Modells. Das ist eine wichtige Einschränkung beim Entwerfen von Aufgaben, die lange Ausgaben erfordern.

Aktuelle Kontextfenster-Limits nach Modell

Kontextfenster sind in den letzten Jahren dramatisch gewachsen, und die Zahlen steigen weiter mit der Verbesserung der Modelle:

• GPT-4o – 128.000 Token (~96.000 Wörter). Genug für einen vollständigen Roman oder eine große Codebasis.
• Claude 3.5 Sonnet / Claude 3 Opus – 200.000 Token (~150.000 Wörter). Anthropic hat diese Grenze konsequent weiter verschoben als OpenAI.
• Gemini 1.5 Pro – 1.000.000 Token (~750.000 Wörter). Ein wirklich beispielloses Kontextfenster, das ganze Codebasen oder stundenlange Meeting-Transkripte aufnehmen kann.
• Gemini 1.5 Flash – 1.000.000 Token, für Geschwindigkeit und niedrigere Kosten optimiert.
• Llama 3.1 (70B / 405B) – 128.000 Token, verfügbar über verschiedene Anbieter wie together.ai und Groq.
• Mistral Large – 128.000 Token.

Zum Vergleich: Dieser gesamte Blog-Beitrag hat etwa 1.200 Token. Selbst das „kleine" 128K-Fenster von GPT-4o ist groß genug, um die meisten praktischen Dokumente vollständig zu verarbeiten. Die Frage lautet nicht nur, ob der Inhalt hineinpasst – sondern wie das Modell mit Inhalten an verschiedenen Positionen innerhalb dieses Fensters umgeht.

Was passiert, wenn man das Kontextfenster überschreitet

Wenn die Eingabe die maximale Kontextlänge des Modells überschreitet, gibt die API einen Fehler zurück. Häufige Fehlermeldungen sind:

// OpenAI
{
  "error": {
    "type": "invalid_request_error",
    "code": "context_length_exceeded",
    "message": "This model's maximum context length is 128000 tokens. However, your messages resulted in 134291 tokens."
  }
}

// Anthropic
{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "prompt is too long: 201483 tokens > 200000 maximum"
  }
}

In einer Chat-Anwendung tritt das häufig nach genug Turns in einem langen Gespräch auf. Da jede Nutzernachricht und jede Assistentenantwort an den Verlauf angehängt wird, wächst die Gesamt-Token-Anzahl, bis sie das Limit erreicht. Ohne proaktives Management stürzt die Anwendung beim nächsten Turn ab. Nutzer erleben das als plötzliche Verweigerung des KI zu antworten oder als Fehler mitten im Gespräch – eine zutiefst frustrierende Erfahrung.

Das „Lost in the Middle"-Problem

Ein großes Kontextfenster zu haben bedeutet nicht, dass das Modell allem darin gleich aufmerksam folgt. Forschungen haben konsistent gezeigt, dass transformerbasierte Modelle bei Informationen am Anfang oder Ende des Kontexts besser abschneiden – ein Phänomen bekannt als das Lost in the Middle-Problem.

In der Praxis bedeutet das: Wenn man RAG (Retrieval Augmented Generation) verwendet und 20 abgerufene Dokument-Chunks in die Mitte eines langen Kontexts einfügt, kann das Modell die Chunks in den Positionen 8–14 möglicherweise nicht berücksichtigen, selbst wenn sie am relevantesten sind. Die für die Aufgabe wichtigsten Informationen sollten entweder ganz am Anfang (nahe der System-Eingabeaufforderung) oder ganz am Ende (unmittelbar vor der Frage des Nutzers) des Kontexts platziert werden.

Das bedeutet auch, dass es nicht immer die richtige Strategie ist, dem Modell ein 1-Million-Token-Kontextfenster zu geben und alles hineinzuschütten. Ein fokussierter 10K-Kontext mit genau den richtigen Informationen übertrifft oft einen 500K-Kontext, der mit lose relevantem Material gefüllt ist.

Strategien für den Umgang mit Kontextgrenzen

Chunking

Bei Dokumenten, die das Kontextfenster überschreiten, diese in überlappende Chunks aufteilen und jeden Chunk unabhängig verarbeiten. Eine kleine Überlappung (z. B. 20 % der Chunk-Größe) verwenden, um Kontinuität an Chunk-Grenzen zu erhalten. Das funktioniert gut für Aufgaben wie Zusammenfassung, Extraktion und Klassifizierung, bei denen jeder Chunk relativ in sich geschlossen ist.

Zusammenfassung / Komprimierung

Bei langen Gesprächen oder Dokumentenverläufen ältere Inhalte periodisch zusammenfassen und durch die Zusammenfassung ersetzen. Ein Gespräch mit 50 Turns lässt sich oft zu einer 300-Token-Zusammenfassung komprimieren, die den Schlüsselkontext beibehält, ohne den vollständigen Verlauf zu konsumieren. Das ist besonders effektiv in Chat-Anwendungen, wo die frühen Turns des Gesprächs mit dessen Fortschritt weniger relevant werden.

Retrieval-Augmented Generation (RAG)

Statt ganze Dokumente in den Kontext zu legen, diese in eine Vektordatenbank einbetten und nur die relevantesten Passagen zur Abfragezeit abrufen. Ein gut gestaltetes RAG-System kann ein Modell mit einem 128K-Kontextfenster effektiv auf Millionen von Token Dokumentation „wissend" machen – es ruft nur das pro Abfrage Benötigte ab. Das senkt auch die Kosten erheblich gegenüber dem Einsatz eines vollständigen Langkontext-Modells bei jeder Anfrage.

Selektive Kontext-Einbeziehung

Bewusst auswählen, was einbezogen wird. In einem Coding-Assistenten müssen nicht alle Dateien des Projekts einbezogen werden – nur die für die aktuelle Aufgabe relevanten. In einem Dokument-Q&A-System muss das gesamte Dokument nicht einbezogen werden, außer die Frage betrifft etwas, das das gesamte Dokument umspannt. Logik aufbauen, die den Kontext intelligent auswählt, statt standardmäßig alles einzubeziehen.

So überwacht man die Kontextnutzung

Die meisten KI-Anbieter-APIs geben die Token-Nutzung in ihren Antworten zurück. Das Antwortobjekt von OpenAI enthält ein usage-Feld mit prompt_tokens, completion_tokens und total_tokens. Anthropic gibt input_tokens und output_tokens zurück. Das Protokollieren dieser Zählungen für jede Anfrage gibt Einblick in Wachstumstrends, bevor man das Limit erreicht.

Für Vor-Anfrage-Prüfungen, bevor eine Anfrage gesendet wird, verwendet man das BrowseryTools Kontextfenster-Tool, um die Eingabeaufforderung einzufügen und genau zu sehen, wie viele Token sie belegt und welchen Prozentsatz des Kontextfensters jedes Modells das ausmacht. Das ist besonders nützlich beim Aufbau von System-Eingabeaufforderungen oder beim Entwerfen von RAG-Abrufstrategien – man kann die Auswirkungen seiner Entscheidungen sehen, bevor auch nur ein API-Aufruf getätigt wird.

Größer ist nicht immer besser

Die Erweiterung der Kontextfenster ist eine echte technische Leistung, und Millionen-Token- Kontexte eröffnen wirklich neue Anwendungsfälle. Aber für die meisten Anwendungen ist die gewinnende Strategie nicht, das Kontextfenster so weit wie möglich zu füllen – sondern die richtigen Informationen an der richtigen Position in einem gut abgegrenzten Kontext zu platzieren. Kombiniert mit dem Verständnis, wie viel Kontext man zu einem beliebigen Zeitpunkt verwendet, baut man Anwendungen, die schneller, günstiger und zuverlässiger sind als solche, die das Kontextfenster als Sammelsurium behandeln.