- Die Grenze für Eingabe-Token (Kontextfenster) moderner LLMs wurde zwar auf mehrere Millionen erweitert, doch selbst bei hohen Werten in einfachen Retrieval-Benchmarks (Needle in a Haystack, NIAH) gibt es klare Leistungseinbußen bei realen langen Eingaben
- Das Forschungsteam führte mit 18 Modellen verschiedene Experimente durch und bestätigte wiederholt Leistungsabfall und inkonsistente Muster, selbst wenn ausschließlich die Eingabelänge kontrolliert variiert wurde
- Besonders auffällig war, dass sich der Leistungsabfall je nach sinkender Frage-Antwort-Ähnlichkeit, hinzugefügten Störsätzen (Distraktoren) und Veränderungen der Textstruktur beschleunigte oder unvorhersehbar veränderte
- Selbst die Beibehaltung eines strukturellen Kontexts (logischer Absatzfluss) wirkte sich teils negativ auf die Leistung aus, was zeigt, dass Anordnung und Darbietung der Eingaben einen großen Einfluss auf die Leistung von LLMs haben
- Sogar bei sehr einfachen Aufgaben wie dem Kopieren von rein repetitivem Text zeigte sich die Grenze, mit wachsender Eingabelänge keine konsistenten Ergebnisse mehr zu liefern, was die Bedeutung von Kontextdesign (Context Engineering) für den Praxiseinsatz unterstreicht
Forschungshintergrund und Zielsetzung
- Da sich die Kontextfenster moderner LLMs zuletzt auf 1 bis 10 Millionen Token vergrößert haben, hat sich die Wahrnehmung verbreitet, dass die „Leistung auch bei langen Eingaben garantiert“ sei
- Zu den repräsentativen Beispielen zählen Gemini 1.5 Pro, GPT-4.1 und Llama 4
- Der verbreitete Benchmark Needle in a Haystack (NIAH) beschränkt sich jedoch auf einfache Satzsuche und bildet Leistungseinbußen bei komplexeren Aufgaben mit langen Dokumenten wie Zusammenfassung oder Frage-Antwort-Systemen nicht angemessen ab
- Diese Studie überprüft Leistungsänderungen systematisch, indem nur die Eingabelänge variiert und die Aufgabenschwierigkeit konstant gehalten wird
Wichtige Experimente und Ergebnisse
- Für 18 aktuelle LLMs (Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen usw.) wurden insgesamt vier Versuchsaufbauten verwendet:
- Veränderung der semantischen Ähnlichkeit zwischen Frage und Antwort (Needle-Question)
- Hinzufügen von Störsätzen (Distraktoren)
- Veränderung von Thema/Struktur des Textkorpus (Haystack)
- Kopieren wiederholter Wörter (gleichzeitige Ausweitung von Ein- und Ausgabelänge)
- In allen Experimenten fiel die Leistung mit zunehmender Eingabelänge stark ab, besonders deutlich bei geringer semantischer Ähnlichkeit oder vielen Distraktoren
- Je geringer die Frage-Antwort-Ähnlichkeit, desto stärker stieg bei langen Eingaben die Fehlerrate
- Schon ein einziger zusätzlicher Distraktor senkte die Trefferquote sofort; ab vier oder mehr Distraktoren nahmen Verwechslungen und Halluzinationen je nach Modell deutlich zu
- Beispiel: Modelle der Claude-Familie neigten eher dazu, statt einer falschen Antwort auszuweichen und „keine richtige Antwort gefunden“ zu sagen, während GPT-Modelle häufiger selbstsichere Falschantworten erzeugten
- Beobachtet wurde auch ein ungewöhnliches Phänomen, bei dem sich die Leistung je nach Textstruktur (logischer Fluss/zufällige Anordnung) umkehrte
- Beim ursprünglichen Text mit logisch kohärentem Ablauf (Original) war die Modellleistung sogar schlechter
- Bei zufällig durchmischten Sätzen (Shuffled) war die Retrieval-Leistung dagegen höher
- Auch im Experiment zum Kopieren wiederholter Wörter nahmen mit wachsender Ein- und Ausgabelänge unvorhersehbare Muster wie Fehlantworten, Aufgabenverweigerung oder das Erzeugen beliebiger Wörter zu
- Beispiel: Nach 2.500 bis 5.000 Wörtern stieg bei bestimmten Modellen die Zahl anormaler Ergebnisse wie Kopierverweigerung oder frei erzeugtem Text stark an
LongMemEval: praxisnahe Bewertung langfristiger Gespräche
- Im LongMemEval-Benchmark mit echten Gesprächsprotokollen wurde fokussierte Eingabe (nur für die Antwort relevante Teile) mit vollständiger Eingabe (einschließlich irrelevanter Kontexte) verglichen
- Bei allen Modellen zeigte die fokussierte Eingabe eine deutlich höhere Trefferquote; bei vollständiger Eingabe wurde bereits das Auffinden relevanter Inhalte selbst zu einer Zusatzaufgabe, was die Leistung stark verringerte
- Modelle der Claude-Familie zeigten besonders in mehrdeutigen Situationen eine klare Tendenz, auf „keine Antwort“ auszuweichen
Zusätzliche Analyse und Implikationen
- Unterschiede in den internen Verhaltensmustern einzelner Modelle wurden mithilfe verschiedener Diagramme detailliert analysiert, etwa Verwechslungsraten pro Distraktor, Genauigkeit der Antwortposition und Positionen zufällig erzeugter Wörter
- Im Experiment zum Kopieren wiederholter Wörter zeigte sich zudem eine positionsabhängige Eigenschaft: Je weiter vorn das richtige Wort stand, desto höher war die Genauigkeit
- Da Kontextdesign (Informationsanordnung, Steuerung logischer Abläufe usw.) einen sehr großen Einfluss auf die Modellleistung hat, deutet die Studie darauf hin, dass sich in realen Diensten durch bloße Erweiterung des Kontexts keine konsistente Leistung erwarten lässt
Fazit
- Die Fähigkeit von LLMs zur Verarbeitung langer Eingaben ist durch Benchmark-Werte nicht garantiert; allein mit zunehmender realer Eingabelänge treten bereits inkonsistente Leistungseinbußen auf
- Die bloße Einbeziehung relevanter Informationen reicht nicht aus; Anordnung, Struktur, Distraktoren und Ähnlichkeit der Informationen beeinflussen die Leistung entscheidend
- Beim Einsatz von LLMs ist Management und Gestaltung langer Kontexte (Context Engineering) zwingend erforderlich
2 Kommentare
2.5 ist schon seit geraumer Zeit draußen, warum also 1.5?
Hacker-News-Kommentare
Ich habe ganz ähnliche Erfahrungen gemacht. Vor allem bei Gemini Pro konnte ich bei langen Textreferenzen deutlich bessere Antworten bekommen, wenn ich nicht mehrere Dokumente auf einmal in das Kontextfenster gelegt habe, sondern jedes Dokument erst zusammenfassen ließ und dann Fragen dazu stellte; bei Bedarf habe ich anschließend die vollständigen Detaildokumente im RAG-Stil oder über eine einfache Agenten-Schleife nachgereicht. Ähnlich war es auch bei Claude Code mit Opus oder Sonnet: Je mehr Kompaktierung stattfand, desto schlechter wurden die Ergebnisse. Ich weiß nicht sicher, ob das an der nachlassenden Qualität der Zusammenfassungen lag oder daran, dass der Anteil weniger relevanter Daten im Kontextfenster zunahm, aber wenn ich den Kontext geleert und nur die relevanten Dateien erneut einlesen ließ, waren die Resultate deutlich besser, selbst wenn sie in einer früheren Zusammenfassung schon erwähnt worden waren.
Gemini beginnt schon vor Erreichen der Chat-Kontextgrenze bei Konsistenz und Schlussfolgerungsvermögen einzubrechen. Laut diesem Bericht ist es in vieler Hinsicht trotzdem das beste Modell. Das Fazit ist, dass Context Engineering weiterhin wichtig ist und RAG-Ansätze nach wie vor sinnvoll sind.
Ist „Kompaktierung“ am Ende nicht einfach das Kürzen des Transkripts zu einer Zusammenfassung? Dann ist es doch selbstverständlich, dass die Leistung schlechter wird, weil tatsächlich Information verloren geht. Aber das liegt dann nicht an Context Rot. Das eigentliche Signal für Context Rot zeigt sich doch erst, wenn man sich dem Auto-Compact-Schwellenwert nähert. Verstehe ich das richtig?
Ein optimaler Coding-Agent würde so etwas wohl automatisch erledigen. Er würde den benötigten Code, MCP-Antworten, Repo-Maps usw. einsammeln, gelegentlich zusammenfassen und alles zu einer neuen Chat-Nachricht verdichten, sodass nur das wirklich Nötige übrig bleibt. Ich nutze mit dem Tool aider bereits einen ähnlichen Stil, und in Situationen mit viel benötigtem Kontext war das deutlich leistungsfähiger als agentische oder automatisierte Workflows. Allerdings ist es sehr arbeitsintensiv.
Hast du NotebookLM ausprobiert? Diese App zerlegt und fasst Dokumente im Hintergrund zusammen und erlaubt es, per RAG im Chat-Format Fragen zum gesamten Dokument zu stellen.
Ich habe in Cursor erlebt, dass die Ergebnisse mit der Zeit immer schlechter wurden, je länger man über neue Funktionen oder Codeänderungen gesprochen hat. Die besten Resultate bekam ich, wenn ich zuerst klare und konkrete Anweisungen sowie einen Plan festgelegt und die zu ändernden Dateien direkt in den Kontext-Prompt gezogen habe.
Der Ablauf „Explore → plan → code → test → commit“ hat mir viel mehr geholfen. Falls nötig, kann man in jeder Phase den Kontext leeren, um die Wirkung zu verbessern.
Sobald genug Informationen für eine bestimmte Aufgabe zusammen sind, speichere ich den Kontext. Wenn ich Qualitätsverlust bemerke, fasse ich die bisherige Arbeit noch einmal zusammen und hänge sie an einen früheren Checkpoint an.
Dieses Phänomen ist zwar bekannt, aber kaum irgendwo sauber dokumentiert, daher freut mich dieser Artikel sehr. Ich glaube, die praktische Auswirkung ist noch größer, als man sie mit Benchmarks leicht messen kann. Wirklich nützliche LLM-basierte Apps bewegen sich genau an der Grenze dessen, was das Modell leisten kann. Das heißt: Der Wert zeigt sich vor allem dann, wenn man bei echten Fragen oder Aufgaben einem Kontext folgen muss, der logisch mehrfach „springen“ muss. Je mehr solche logischen „Sprünge“ nötig sind, desto explosiver wird das Context-Rot-Problem, denke ich, weil sich bei jedem Sprung die Zahl der Dinge erhöht, auf die man achten muss.
Es braucht unbedingt eine einfache Möglichkeit, Kontext abzuschneiden. Wenn ich das gesamte Gespräch mit dem Modell selbst verwalten könnte, würde ich aus einer Coding-Session mit ungefähr 200.000 Tokens vermutlich deutlich mehr Leistung herausholen. In der Praxis wird das Modell aber selbst mit einer guten Instanz ab etwa 20.000 Tokens ständig seltsam, und die Session ist dann komplett verrottet. Ich wünschte, man könnte diesen Teil einfach herausschneiden.
Lokale LLMs erlauben es, den Kontext nach Belieben zu bearbeiten. Wenn man also die Antwort des LLM selbst verändert, kann das Modell später glauben, es habe das ursprünglich so gesagt. Das ist nützlich, wenn man es in eine gewünschte Richtung lenken will. LLM-as-a-service-Modelle bieten so etwas dagegen nicht an, weil es die Umgehung von Zensur erleichtern würde.
Ich habe damit experimentiert, Claude zu sagen: „Hey Claude, ich werde jetzt den Kontext zurücksetzen, also gib mir bitte einen Prompt, mit dem wir danach weiterarbeiten können.“ Dann habe ich mir den von Claude vorgeschlagenen Prompt vorher angesehen, nachbearbeitet und wieder eingefügt.
Es wäre wirklich die beste Funktion überhaupt, wenn man leicht zu einem früheren Checkpoint zurückrollen könnte.
Bei den meisten CLI-Agenten kann man so etwas mit dem Befehl
/compressmachen.Bei Claude code merkt man mit der Zeit, dass es seine eigenen Fehler und meine Anweisungen nicht mehr auseinanderhalten kann. Wenn es einmal durcheinanderkommt, hilft nur eine neue Session. Je länger die Session wird, desto eher landet es in derselben Schleife oder behauptet beharrlich, Tests seien schon kaputt und ignoriert sie dann einfach, obwohl sie tatsächlich erst in dieser Session kaputtgegangen sind. Vielleicht liegt es an meinen schlechten Prompts, aber ich habe in letzter Zeit das Gefühl, Claude sei plötzlich um etwa 30 IQ-Punkte dümmer geworden.
Geht mir genauso. Selbst mit dem Max-Plan gibt es klar spürbare gute und schlechte Phasen bei der Leistung.
Dieses „Es liegt bestimmt an meinem Prompt und meinem Kontext“ fühlt sich an wie verinnerlichtes Gaslighting, das wir alle mit uns herumtragen.
Das ist eine Art Problem der Informationssuche, aber ich glaube, dass sich der Leistungsabfall bei veränderter Kontextlänge anders verhalten kann als bei einfachen Retrieval-Antworten. Bei Fragen wie „Wie ändere ich diesen Button zu Rot?“ oder Problemen wie „Zu welcher Kategorie gehören die obigen Sätze?“ kann es zum Beispiel anders funktionieren. Eine ältere, eindrucksvolle Arbeit dazu war Many-Shot In-Context Learning. Diese Studie zeigt, dass die Leistung stark steigt, je mehr man den Kontext mit Beispielen füllt. Letztlich muss man für jedes Problem selbst testen, wie sich ein LLM je nach Inhalt und Länge des Kontexts verändert. Man sollte nicht immer davon ausgehen, dass längerer Kontext automatisch zu schlechterer Leistung führt.
Ein sehr cooler und aufschlussreicher Artikel. Aus Sicht der Medienkompetenz ist es allerdings gut zu wissen, dass Chroma ein Vector-DB-Unternehmen ist.
Ich habe kürzlich mit Gemini 2.5 Flash mehrere längere Romane geschrieben. Context Rot ist definitiv spürbar, tritt bei mir aber viel später auf, als es dieser Artikel nahelegt. In meinem Fall begann das Modell erst nach etwa 50.000 bis 100.000 Tokens, frühen Kontext wie etwa die Ausgabesprache zu ignorieren. Möglicherweise sind komplexe Aufgaben wie kreatives Schreiben schwieriger zu messen oder der Effekt zeigt sich weniger deutlich. Wie auch immer: Wenn ich gelegentlich fehlenden Kontext wieder einfüge, bleibt es auf einem brauchbaren Niveau.
Ich habe etwas Ähnliches erlebt. In einem Projekt habe ich eine Suchfunktion für Video-Transkripte entwickelt, und die Texte waren sehr lang. Ich dachte, bei Modellen wie GPT 4.1 mit großem Kontextfenster sei RAG nicht nötig, aber gerade bei kleineren Modellen traten häufig seltsame Effekte auf. Manchmal beantworteten sie die Frage nicht richtig, sondern gaben einfach nur eine Zusammenfassung des gesamten Inhalts aus.
Interessanter Bericht. Ich frage mich, ob es modellabhängige Empfehlungen für die Kontextgröße gibt. Ich würde gern wissen, wie man herausfinden kann, bis zu welchem Punkt es für meinen Use Case sinnvoll ist.