Was ist ein Kontextfenster, und warum ist es ausgeschöpft?
Das Kontextfenster ist alles, was ein Modell auf einmal sehen kann — Ihre Anfrage, das Gespräch, abgerufene Dokumente und seine eigene Antwort. Hier wird erklärt, wie es gemessen wird, warum längere nicht automatisch besser sind, und was zu tun ist, wenn Sie die Grenze erreichen.
Kurze Antwort
Was ist ein Kontextfenster in einem KI-Modell?
Ein Kontextfenster ist die maximale Menge an Text, gemessen in Token, die ein Modell in einer einzelnen Anfrage berücksichtigen kann. Es enthält die Systemanweisungen, die aktuelle Konversation, beliebige Dokumente, die Sie einfügen, und die gerade erzeugte Antwort. Wenn die Gesamtsumme die Grenze überschreitet, muss etwas verworfen oder zusammengefasst werden.
Das Wichtigste
- Das Fenster wird in Tokens gemessen, nicht in Wörtern – ungefähr 0,75 Wörter pro Token im Englischen und weitaus weniger Zeichen pro Token im Koreanischen oder Japanischen.
- Alles teilt sich dasselbe Budget: Anweisungen, Verlauf, angehängte Dateien, Tool-Definitionen und die Ausgabe.
- Modelle nutzen den Anfang und das Ende eines langen Kontexts zuverlässiger als die Mitte, daher ist die Platzierung wichtig.
- Kosten und Latenz skalieren mit den tatsächlich gesendeten Tokens, weshalb Caching und Abruf normalerweise besser sind, als alles einzufügen.
Jede Konversation mit einem Sprachmodell hat eine harte Obergrenze dafür, wie viel es auf einmal sehen kann. Diese Obergrenze ist das Kontextfenster, und fast jedes seltsame Verhalten, das Menschen berichten – das Modell "vergisst", was Sie gesagt haben, ignoriert eine angehängte Datei, verliert den Faden auf halbem Weg – lässt sich darauf zurückführen.
Tokens, nicht Wörter
Modelle lesen keine Zeichen oder Wörter. Text wird zuerst in Tokens aufgeteilt: gängige Fragmente, die der Tokenizer gelernt hat. Im Englischen hat ein Token durchschnittlich etwa vier Zeichen, sodass 1.000 Tokens ungefähr 750 Wörtern entsprechen.
Dieses Verhältnis ist nicht universell. Skripte, die außerhalb der Trainingsverteilung des Tokenizers liegen, werden stärker fragmentiert:
| Text | Ungefähre Tokens |
|---|---|
The quick brown fox (19 Zeichen, Englisch) | ~4 |
안녕하세요 반갑습니다 (11 Zeichen, Koreanisch) | ~10 |
こんにちは、はじめまして (12 Zeichen, Japanisch) | ~11 |
| Eine Codezeile mit 4 Leerzeichen Einrückung | 1 Token pro Einrückungsebene |
Die praktische Konsequenz: Ein koreanisches oder japanisches Dokument verbraucht spürbar mehr vom Fenster als ein englisches Dokument gleicher sichtbarer Länge und kostet proportional mehr pro Anfrage.
Was um den Platz konkurriert
Es ist verlockend, das Fenster als "wie lang ein Dokument ich einfügen kann" zu betrachten. Es ist eigentlich ein gemeinsames Budget:
- Der System-Prompt – die Anweisungen, die das Verhalten des Assistenten definieren.
- Tool-Definitionen, falls das Modell Tools aufrufen kann. Ein Dutzend Tools mit detaillierten Schemata können Tausende von Tokens beanspruchen, bevor Sie überhaupt etwas gesagt haben.
- Der Konversationsverlauf, der normalerweise bei jeder Runde vollständig erneut gesendet wird.
- Angehängte oder abgerufene Dokumente.
- Die Ausgabe. Generierte Tokens werden bei den meisten APIs aus demselben Budget entnommen, weshalb eine sehr lange Eingabe keinen Platz für eine lange Antwort lässt.
Wenn Sie jemals eine große PDF-Datei angehängt und eine gekürzte Antwort erhalten haben, liegt es daran.
Lang bedeutet nicht gleichmäßig gut
Forschung zum Verhalten bei langem Kontext – am einflussreichsten Lost in the Middle – hat ein konsistentes Muster ergeben: Modelle rufen Fakten, die sich am Anfang oder Ende einer langen Eingabe befinden, weitaus zuverlässiger ab als Fakten, die in der Mitte vergraben sind. Die Kurve ist U-förmig und flacht sich bei größeren Fenstern nicht vollständig ab.
Drei Regeln ergeben sich direkt daraus:
- Stellen Sie Anweisungen zuerst und die unmittelbare Frage zuletzt. Die beiden Positionen, auf die das Modell am besten achtet.
- Füllen Sie nicht auf. Zwanzig relevante Seiten schlagen zweihundert Seiten, die dieselben zwanzig enthalten.
- Testen Sie bei realistischer Länge. Ein Prompt, der bei 5.000 Tokens funktioniert, kann bei 100.000 leise schlechter werden.
"Needle in a Haystack"-Benchmarks von Anbietern – bei denen ein Satz in einem langen Dokument versteckt und das Modell gebeten wird, ihn zu finden – messen den einfachen Fall. Das Abrufen einer einzelnen, unterscheidbaren Tatsache ist viel einfacher als das Schlussfolgern über Material, das über die gesamte Eingabe verteilt ist.
Kosten, Latenz und Caching
Sie bezahlen für die Tokens, die Sie senden, bei jeder Anfrage. Ein 100.000-Token-Kontext, der über eine 20-Runden-Konversation erneut gesendet wird, sind zwei Millionen Eingabe-Tokens, auch wenn der Benutzer zwanzig kurze Fragen getippt hat.
Zwei Mechanismen mildern dies ab:
- Prompt-Caching. Anbieter können das unveränderte Präfix einer Anfrage – System-Prompt, Tool-Definitionen, ein langes Dokument – cachen und für Cache-Treffer viel weniger berechnen. Es funktioniert nur, wenn das Präfix byte-identisch ist, also stellen Sie stabile Materialien zuerst und volatile Materialien (Zeitstempel, Benutzernamen) zuletzt.
- Batching. Für nicht-interaktive Arbeiten kosten Batch-APIs in der Regel deutlich weniger, im Austausch für verzögerte Ergebnisse.
Die Latenz folgt einer ähnlichen Form: Die Zeit bis zum ersten Token steigt mit der Eingabelänge, sodass ein Chat, der sich mit einem kurzen Prompt sofort anfühlt, träge wird, sobald Sie eine große Datei anhängen.
Was tun, wenn Sie das Limit erreichen
Abrufen statt einfügen. Indizieren Sie Ihre Dokumente, rufen Sie die Handvoll Passagen ab, die für die Frage relevant sind, und senden Sie diese. Anfragen bleiben klein, günstig und genau. Dies ist das gesamte Argument für Retrieval-Augmented Generation.
Fassen Sie die Historie zusammen. Ersetzen Sie alte Runden durch eine kompakte Zusammenfassung der bisher getroffenen Entscheidungen und etablierten Fakten. Behalten Sie die aktuellsten Runden wörtlich bei – dort lebt der unmittelbare Faden.
Teilen Sie die Aufgabe auf. Zwei fokussierte Anfragen übertreffen normalerweise eine riesige Anfrage. Extraktion dann Analyse; pro Dokument dann kombinieren.
Trimmen Sie Ihre Tools. Wenn das Modell für diese Aufgabe nur drei Tools benötigt, senden Sie nicht dreißig.
Messen Sie vor der Optimierung. Zählen Sie die Tokens bei einer echten Anfrage. Teams sind routinemäßig überrascht festzustellen, dass der System-Prompt oder ein ungenutztes Tool-Schema, nicht das Dokument des Benutzers, den größten Teil des Fensters verbraucht.
Das Kontextfenster ist keine Funktion, die maximiert werden soll. Es ist ein Budget, das bewusst ausgegeben werden muss.
Häufige Fragen
- Wie viele Wörter passen in ein 200.000-Token-Kontextfenster?
- Etwa 150.000 englische Wörter, oder ungefähr 500 Seiten normaler Prosa. Koreanische, japanische und chinesische Texte verwenden mehr Tokens pro Zeichen, daher sind bei gleichem Limit deutlich weniger Seiten zu erwarten.
- Entfernt ein größeres Kontextfenster die Notwendigkeit von RAG?
- Nein. Ein großes Fenster macht den Abruf weniger fummelig, aber das Senden von 500 Seiten bei jeder Anfrage ist langsam und teuer, und die Genauigkeit verschlechtert sich immer noch in der Mitte sehr langer Eingaben. Retrieval hält Anfragen klein und zielgerichtet.
- Was passiert, wenn eine Konversation das Fenster überschreitet?
- Die Anwendung muss eingreifen – normalerweise, indem sie die ältesten Turns verwirft, zusammenfasst oder in einen Retrieval-Speicher verschiebt. Das Modell selbst kann einfach nichts außerhalb des Fensters sehen.
- Warum wird mein langes Gespräch mit der Zeit teurer?
- Die meisten APIs senden die gesamte Konversation bei jedem Durchgang erneut, sodass die Eingabe mit jedem Austausch wächst. Prompt-Caching reduziert die Kosten für das wiederholte Präfix, aber die Tokens werden immer noch verarbeitet.