Ihr API-Aufruf wird abgeschlossen. Claude oder GPT-4o liefert eine Antwort. Aber irgendwo in der Mitte Ihres 8.000 Wörter langen Dokuments hat es aufgehört, darauf zu achten. Nicht weil das Modell kaputt ist – sondern weil Ihnen das Kontextfenster ausgegangen ist.
Das Kontextfenster ist die maximale Anzahl von Tokens, die ein LLM in einer einzigen Anfrage verarbeiten kann. Claude 3.5 Sonnet verarbeitet 200.000 Tokens. GPT-4o verarbeitet 128.000. Llama 3 70B verarbeitet 8.000. Überschreiten Sie dieses Limit, schlägt Ihre Anfrage fehl. Bleiben Sie darunter, aber quetschen Sie zu viel hinein, verschlechtert sich die Aufmerksamkeit des Modells auf im mittleren Bereich vergrabene Inhalte – ein Phänomen, das als „Lost in the Middle“-Problem bezeichnet wird.
Dies ist keine theoretische Einschränkung. Es zerstört reale Produktionssysteme: Kundensupport-Chatbots, die sich frühe Gesprächsrunden nicht merken können, Dokumentenanalyse-Pipelines, die kritische Abschnitte übersehen, und Forschungsabläufe, die bei PDFs ins Stocken geraten.
Wie das Kontextfenster tatsächlich funktioniert
Jedes Wort, jede Zahl, jedes Satzzeichen und jeder Leerraum wird in Tokens umgewandelt, bevor das Modell es verarbeitet. Ein Token entspricht ungefähr 4 Zeichen im Englischen, variiert aber je nach Sprache und Struktur.
Ein 200.000-Token-Fenster von Claude Sonnet gliedert sich wie folgt auf:
- System-Prompt: 500 Tokens
- Benutzereingabe (Ihr Dokument): 150.000 Tokens
- Konversationsverlauf: 30.000 Tokens
- Reserviert für Ausgabe: 19.500 Tokens
Ihnen bleiben 19.500 Tokens für die Antwort des Modells. Wenn Sie eine detaillierte Analyse benötigen, ist das genug. Wenn Sie mehrere logische Schritte benötigen, wird es knapp.
Die Mathematik ist starr: Eingabe-Tokens + Ausgabe-Tokens ≤ Kontextfenster. Überschreiten Sie dies, lehnen die meisten API-Anbieter die Anfrage mit einem 400er-Fehler ab. Einige Dienste reihen sie in die Warteschlange. Keiner von ihnen kürzt sie stillschweigend.
Das „Lost in the Middle“-Problem ist real
Im September 2023 testeten Forscher des MIT, ob LLMs tatsächlich den gesamten Kontext nutzen, den sie angeblich unterstützen. Sie fügten eine Schlüsselinformation an verschiedenen Stellen eines langen Dokuments ein und baten das Modell, sie abzurufen.
Das Ergebnis: Modelle erzielen die besten Ergebnisse bei Informationen am Anfang und Ende des Kontexts. Informationen in der Mitte – Positionen 40–60 % des Dokuments – werden mit 25–35 % geringerer Genauigkeit verarbeitet als dieselben Informationen am Anfang.
Dies ist kein spezifisches Problem von Claude oder GPT-4o. Es betrifft alle Transformer-basierten Modelle. Der Grund: Aufmerksamkeitsmuster in Sprachmodellen gewichten frühere Tokens standardmäßig stärker, und das Modell „spart“ Kapazität für die endgültige Zusammenfassung und Antwort.
Praktische Auswirkungen: Wenn Ihr Kundensupport-Bot eine Konversation mit 5 Nachrichten verarbeitet, erhalten frühe Nachrichten eine verschlechterte Behandlung. Wenn Ihr Dokumentenanalysator ein 50-seitiges PDF verarbeitet, werden die Seiten 20–30 unsichtbar.
Technik 1: Vor der Verarbeitung zusammenfassen
Anstatt das gesamte Dokument zu senden, komprimieren Sie es zuerst.
# Schlechter Ansatz: vollständiges Dokument senden
Benutzer: „Analysiere diesen 30-seitigen Vertrag. Was sind die wichtigsten Verpflichtungen?“
[gesamten 30-seitigen Vertrag als Eingabe senden]Das Modell verwendet wertvolles Kontextfenster für Formulierungen, die nicht wichtig sind.
# Verbesserter Ansatz: zweistufiger Prozess
Schritt 1: Dokument zusammenfassen
Prompt: „Fasse diesen Vertrag in 500 Tokens zusammen. Behalte Verpflichtungen, Zeitplan und Zahlungsbedingungen bei. Entferne Standardformulierungen.“
[vollständigen Vertrag senden]
Ausgabe: 500-Token-Zusammenfassung
Schritt 2: Zusammenfassung analysieren
Prompt: „Liste basierend auf dieser Zusammenfassung alle Gegenparteiverpflichtungen auf und bestimme, welche Partei jedes Risiko trägt.“
[die 500-Token-Zusammenfassung senden]
Ausgabe: Strukturierte AnalyseWarum das funktioniert: Sie nutzen das Kontextfenster im ersten Aufruf, um Signale zu extrahieren, und verarbeiten dann nur das Signal im zweiten Aufruf. Der zweite Aufruf ist schneller, günstiger und genauer, da das Modell mit destillierten Informationen arbeitet.
Echte Token-Einsparungen: Ein 50-seitiger Vertrag (ca. 25.000 Tokens) wird zu einer 500-Token-Zusammenfassung. Ihr zweiter Analyseaufruf sinkt von 25.500 Tokens auf 1.000.
Technik 2: Chunks und Neu-Ranking für den Konversationsverlauf
Lange Konversationen sind das schwierigste Kontextproblem, da jede neue Nachricht an den Verlauf angehängt wird. Nach 15 Austauschen haben Sie 8.000–15.000 Tokens allein für die Gesprächserinnerung verbraucht.
# Problem: Konversationsverlauf bläht sich auf
Gesprächsrunde 20:
System: [ursprünglicher System-Prompt]
Benutzer: [Runde 1]
Assistent: [Antwort]
Benutzer: [Runde 2]
Assistent: [Antwort]
... [Runden 3–19] ...
Benutzer: [Runde 20] <- neue Nachricht
Assistent: [Modell antwortet]Bis zur Runde 20 hat das Modell 15+ irrelevante Austausche gesehen, bevor es zur aktuellen Frage gelangt. Bis zur Runde 50 ist der Kontext größtenteils totes Gewicht.
Lösung: Verwenden Sie einen Neu-Ranking-Ansatz.
Bewerten Sie nach jeweils 8–10 Runden jede historische Nachricht anhand ihrer Relevanz für den aktuellen Gesprächsverlauf mithilfe von Embeddings oder einem leichten Sprachmodell. Behalten Sie nur die 5–7 relevantesten vergangenen Runden sowie die 2 aktuellsten Runden bei. Verwerfen Sie den Rest.
import openai
from sklearn.metrics.pairwise import cosine_similarity
import numpy as np
def prune_conversation_history(history, current_message, max_turns=7):
# Embed all past user messages
past_messages = [h[
