Context rot: większe okno kontekstowe nie znaczy mądrzejszy model - poradnik dobrych praktyk

TL;DR

• Duże okno kontekstowe to pojemność wejścia, nie gwarancja jakości rozumowania. Reklamowane okno to nie to samo co efektywne okno.
• Degradacja zaczyna się długo przed zapełnieniem okna i najmocniej uderza w zadania wieloetapowe - to zjawisko nazwano context rot.
• Modele faworyzują początek i koniec kontekstu, a informacja zakopana w środku ginie („lost in the middle”).
• Zasada nadrzędna: daj modelowi minimum wystarczającego kontekstu, nie maksimum dostępnego.
• Dla użytkownika czatu: świeży czat, kluczowe fakty na końcu, najpierw ekstrakcja - potem rozumowanie.
• Dla deva: RAG jako filtr + reranking, kompakcja, structured notes, sub-agenty i twardy limit efektywnego okna mierzony na własnych zadaniach.

🚀 Intro: „zmieści się” to nie to samo co „zrozumie”

Dostajesz model z oknem kontekstowym na milion tokenów i pierwsza myśl jest oczywista: wreszcie mogę wrzucić wszystko. Całe repo, cały wątek mailowy, komplet umów, sześć PDF-ów naraz. Model to przyjmie - zmieści się bez problemu. Kłopot w tym, że „zmieści się” i „zrozumie” to dwie zupełnie różne rzeczy.

To trochę jak wysypanie całej zawartości szafy z dokumentami na biurko. Niby wszystko masz pod ręką, ale znalezienie właściwej kartki i wyciągnięcie z niej poprawnego wniosku robi się coraz trudniejsze. Im więcej papieru, tym gorzej - mimo że teoretycznie „widzisz” każdą stronę.

Dokładnie to dzieje się z modelami językowymi. Słabnięcie ich rozumowania w miarę zapełniania okna kontekstowego zyskało nazwę context rot (gnicie kontekstu). I co najważniejsze - to nie jest twardy klif, na którym model nagle przestaje działać przy 999 999 tokenach. To gradient: jakość spada stopniowo, często długo przed zapełnieniem okna.

Pokazał to już raport Chroma z lipca 2025: 18 ówczesnych modeli frontier (GPT-4.1, Claude 4, Gemini 2.5) degradowało się wraz z długością wejścia - każdy bez wyjątku [1]. I nie, nowa generacja tego nie naprawiła. Benchmark LOCA-bench z lutego 2026 przetestował obecne flagowce - Claude Opus 4.5, GPT-5.2, Gemini 3 - i spadki bywają jeszcze ostrzejsze: trafność Opusa 4.5 leci z 96% przy 8K tokenów do 14,7% przy 256K, a GPT-5.2 z 72% do 21,3% [2]. Okna liczone są już w milionach tokenów, ale to nie likwiduje problemu - co najwyżej przesuwa próg, od którego zaczyna boleć.

Dobra wiadomość: to zjawisko jest dobrze rozpoznane i w dużej mierze da się je obejść. Ten wpis to podręczny poradnik - najpierw krótko co się psuje i dlaczego, a potem konkretne praktyki: osobno dla osoby pracującej w czacie i osobno dla deva budującego systemy agentowe.

Im dalej od skraju kontekstu, tym trudniej modelowi sięgnąć po informację. Klasyczny efekt „lost in the middle”.

🧠 Co się właściwie psuje (i dlaczego)

Zanim przejdziemy do praktyk, warto zrozumieć mechanizm - bo dobre praktyki wynikają wprost z tego, jak działa transformer. To nie jest problem pojemności pamięci, tylko sposobu, w jaki model rozkłada uwagę.

Definicja: Context rot to stopniowy spadek jakości wyszukiwania i rozumowania modelu w miarę wzrostu długości wejścia - występujący nawet wtedy, gdy model ma techniczny, bezbłędny dostęp do wszystkich potrzebnych informacji.

Najgłośniejszy objaw to „lost in the middle”. Klasyczne badanie Liu i in. pokazało, że wydajność modelu układa się w funkcję U względem pozycji informacji: jest najwyższa, gdy istotny fragment leży na początku albo na końcu kontekstu, i wyraźnie spada, gdy trzeba sięgnąć po coś ze środka [3]. Co ciekawe, dotyczy to nawet modeli reklamowanych jako „long-context”.

Pod spodem siedzi kilka nakładających się przyczyn. Nie musisz znać ich na pamięć, ale warto wiedzieć, że to nie przypadek ani „zła wola” modelu:

Mechanizm	Co się dzieje	Skutek praktyczny
Lost in the middle	Model faworyzuje skraje wejścia	Fakt zakopany w środku po prostu ginie
Rozmycie softmax	Skończona „pula uwagi” rozkłada się na coraz więcej tokenów	Stosunek sygnału do szumu spada
Zanik RoPE	Słabsza „łączność” między odległymi tokenami	Model gubi relacje przyczynowo-skutkowe na dystans
Efektywne okno < reklamowane	Jakość siada przed osiągnięciem limitu	Nie ufaj liczbie z marketingu
Dystraktory i szum	Fragmenty „prawie istotne” mylą model	Dosypanie kontekstu pogarsza, nie poprawia wynik
Reasoning shift	Przy długim kontekście model skraca własne myślenie	Mniej self-checku tam, gdzie jest najpotrzebniejszy

Dwa ostatnie wiersze są szczególnie podstępne. Badanie Du i in. pokazało coś mocniejszego niż samo „lost in the middle”: sama długość wejścia degraduje wyniki nawet przy doskonałym retrievalu i w granicach deklarowanego okna - z odnotowanymi spadkami od 13,9% do nawet 85% na zadaniach matematycznych, QA i kodowaniu [4]. A świeży preprint o zjawisku nazwanym reasoning shift opisuje, że przy długim lub rozpraszającym kontekście modele rozumujące potrafią generować nawet o 65% krótsze ślady rozumowania, rzadziej sprawdzając same siebie [5].

Innymi słowy: długi kontekst nie tylko utrudnia znalezienie faktu, ale też skłania model do płytszego myślenia nad nim.

🎯 Zasada nadrzędna: minimum wystarczające, nie maksimum dostępne

Jeśli masz zapamiętać z tego wpisu jedno zdanie, niech będzie to:

Daj modelowi minimum niezbędnych informacji potrzebnych do wykonania zadania - nie maksimum, które akurat masz pod ręką.

To kontraintuicyjne, bo instynkt podpowiada „dorzucę jeszcze ten dokument, na wszelki wypadek”. Ale każdy dodany token to mniejszy budżet uwagi na pozostałe i większa szansa, że krytyczna informacja wyląduje w strefie niskiej uwagi. Zespół Anthropic opisuje to wprost: transformer tworzy relacje „każdy token z każdym”, więc wraz z długością kontekstu zdolność modelu do uchwycenia tych relacji „rozciąga się zbyt cienko” - jest to ograniczony budżet uwagi [6].

Z tej zasady wynika druga, równie ważna: reklamowane okno to nie efektywne okno. Benchmark RULER od NVIDIA pokazał, że choć badane modele deklarują kontekst 32K lub więcej, tylko mniej więcej połowa faktycznie utrzymuje zadowalającą jakość przy realnym 32K - mimo że prawie wszystkie zaliczają na bank proste testy typu „igła w stogu siana” [7]. Prosty test zawyża faktyczne możliwości; degradacja ujawnia się dopiero przy zadaniach złożonych.

Dlatego część zespołów stosuje twardy sufit - traktuje model reklamujący milion tokenów tak, jakby realnie miał ich np. 200 tysięcy - i dobiera ten próg testami na własnych zadaniach. Konkretna liczba jest umowna i zależy od modelu oraz typu pracy. Ważna jest zasada: zmierz, gdzie Twój model przestaje być wiarygodny, zamiast ufać liczbie z noty prasowej.

Reklamowana pojemność to górna granica wejścia. Efektywne okno - czyli zakres, w którym model wciąż wiarygodnie rozumuje - bywa znacznie krótsze.

🔧 Ćwiczenie (test efektywnego okna): Weź realne zadanie, które robisz regularnie, i odpal je na rosnących długościach kontekstu: 20K, 50K, 100K, 300K tokenów. Notuj, od którego progu jakość zaczyna siadać. Ten punkt - a nie liczba z marketingu - jest Twoim prawdziwym oknem roboczym dla tego typu pracy.

💬 Praktyki dla użytkownika czatu (ChatGPT, Claude.ai, Gemini)

Pracujesz w okienku czatu, bez dostępu do API? Masz mniej dźwigni, ale i tak sporo. Oto najważniejsze nawyki.

1. Zaczynaj świeży czat częściej, niż myślisz. Bez API restart to Twoje główne narzędzie higieny kontekstu. Otwieraj nowy wątek, gdy zmieniasz temat, gdy model zaczyna błądzić lub zapętlać się, albo gdy rozmowa robi się długa (orientacyjnie powyżej kilkunastu wiadomości). Każda kolejna tura dokłada szum, który degraduje następne odpowiedzi.

2. Kluczowe instrukcje i pytanie - na końcu (i ewentualnie na początku). Skoro skraje mają najwyższą uwagę, nie zakopuj polecenia w środku ściany tekstu. Jeśli wklejasz długi dokument, daj sekcję „Zadanie i kryteria odpowiedzi” pod nim, tuż przed wysłaniem. Przy bardzo długim wejściu powtórz najważniejsze ograniczenie na końcu - to realnie ogranicza dryf.

3. Najpierw ekstrakcja, potem rozumowanie. To jedna z najskuteczniejszych sztuczek i działa nawet w czystym czacie. Zamiast jednego gigantycznego promptu, rozbij go na dwa kroki:

Krok 1: „Wypisz tylko te fakty z poniższego tekstu, które są potrzebne do odpowiedzi na pytanie X. Zignoruj resztę.”

Krok 2: „Na podstawie wyłącznie tej listy faktów rozwiąż problem.”

Du i in. przetestowali wręcz prostą wersję tego podejścia - kazanie modelowi najpierw odtworzyć istotne dowody, a dopiero potem rozwiązać zadanie - i uzyskali stałą poprawę na benchmarku RULER [4]. Zamieniasz długie zadanie w krótkie, a krótki kontekst to silniejsze rozumowanie.

4. Nie wklejaj całej szafy. Zanim wrzucisz dokument, odsiej oczywiste śmieci: stopki, changelogi, powtarzające się nagłówki, duplikaty, mało istotne załączniki. Im mniej szumu na wejściu, tym mniej dystraktorów, które mogą zmylić model.

5. Dla ważnych zadań wymuszaj weryfikację. Przy prawie, finansach, kodzie czy matematyce długi kontekst zwiększa ryzyko, że model znajdzie dobry fragment, ale źle go połączy z resztą. Pomaga prompt wieloetapowy: „najpierw wypisz przesłanki, potem rozwiąż, na końcu sprawdź wynik pod kątem sprzeczności”. To kontruje reasoning shift - czyli tendencję do skracania myślenia przy długim wejściu [5].

🛠️ Praktyki dla devów i agentów (API, RAG, Claude Code)

Tu masz pełen arsenał. Te techniki Anthropic sformalizował jako komplementarne strategie dla długodystansowych agentów [6] - dorzucam do nich kilka z praktyki RAG i kompresji.

1. RAG jako filtr, nie jako wysypisko. Sens retrievalu polega na tym, żeby podać modelowi tylko najbardziej istotne fragmenty - ale jakość wyszukiwania musi być wysoka, inaczej wciągasz „prawie istotne” dystraktory, które pogarszają sprawę. Anthropic w Contextual Retrieval pokazał konkretne liczby (metryka: odsetek nieudanych pobrań): same kontekstowe embeddingi redukują błędy o 35%, w połączeniu z kontekstowym BM25 o 49%, a po dołożeniu rerankingu o 67% [8]. Reranking - czyli drugi etap, w którym wyspecjalizowany model wybiera 3-5 absolutnie najlepszych fragmentów z szerszej puli - to dziś standard, a nie luksus.

2. Ustaw twardy limit efektywnego okna i mierz go. Nie capuj „na czuja”. Zbuduj mały zestaw ewaluacyjny ze swoich realnych zadań i sprawdź, gdzie jakość siada (patrz ćwiczenie wyżej, w duchu RULER [7]). Potem trzymaj się tego progu w produkcji.

3. Kompakcja (compaction). Gdy rozmowa zbliża się do limitu okna, streść jej starszą część i zacznij nową z tym podsumowaniem. W API Anthropic kompakcja jest wbudowana i domyślnie wyzwala się przy ~150K tokenów wejściowych (próg konfigurowalny). W Claude Code auto-compact włącza się automatycznie przy wysokim zapełnieniu okna [9] - a ponieważ domyślny dziś Opus 4.8 pracuje na oknie rzędu miliona tokenów, samo duże okno tym bardziej nie zwalnia z higieny kontekstu. Uwaga praktyczna: kompresja gubi szczegóły (ścieżki plików, dokładne nazwy, komunikaty błędów), więc zwykle lepiej odpalić /compact proaktywnie przy 50-60% zapełnienia, niż czekać na automat.

4. Structured note-taking. Niech agent regularnie zapisuje notatki do trwałej pamięci poza oknem kontekstowym i pobiera je, gdy są potrzebne. To tania pamięć długoterminowa, która nie obciąża budżetu uwagi - stan żyje na dysku, a nie w każdym kolejnym wywołaniu.

5. Architektury sub-agentów. Deleguj wąskie podzadania do wyspecjalizowanych sub-agentów, z których każdy pracuje w czystym oknie i zwraca tylko skondensowany destylat swojej pracy. Główny agent koordynuje, ale nie nosi w kontekście całego śmietnika z eksploracji. To bezpośrednio adresuje główny tryb awarii agentów: akumulację szumu w trakcie wyszukiwania, prób i cofania się.

Agent rozwiązuje problem, dopóki kontekst pozostaje czysty. Kompakcja i sub-agenty przywracają tę czystość, zanim szum zdąży go zepsuć.

6. Ekstrakcja przed rozumowaniem - jako etap pipeline’u. Ta sama zasada co w czacie, ale zautomatyzowana: rozbij zadanie na ekstrakcję → konsolidację → rozumowanie → weryfikację, zamiast jednego promptu na 300K tokenów. Dla trudnych zadań rozdziel role na osobne wywołania: ekstraktor → analityk → krytyk.

7. Kompresja promptów (opcjonalnie). Gdy naprawdę musisz zmieścić dużo, narzędzia jak LLMLingua usuwają „nieważne” tokeny przed wysłaniem do modelu. Raportowana kompresja sięga 20x przy minimalnej utracie jakości - na zadaniach rozumowania ok. 1,5 punktu straty przy 20-krotnej kompresji [10]. To rozwiązanie dla specyficznych przypadków, nie domyślny krok.

8. Pozycjonowanie i powtarzanie. Tak jak w czacie: krytyczne instrukcje i ograniczenia umieszczaj na skrajach, a przy bardzo długim promptcie powtarzaj kluczowe reguły blisko końca. To tania interwencja o realnym efekcie.

Najlepszy schemat pracy z długim kontekstem: najpierw znajdź materiały, zrób krótką paczkę dowodów, dopiero potem rozumuj.

🗺️ Ściąga decyzyjna

Nie każda sytuacja wymaga ciężkiej artylerii. Krótka mapa, co kiedy stosować:

Sytuacja	Najlepsze podejście
Proste znalezienie faktu w jednym dokumencie	Długi kontekst zwykle wystarczy
Dużo dokumentów, maili, umów, całe repo	RAG + reranking + krótkie streszczenie globalne
Zadanie wymagające rozumowania wieloetapowego	Ekstrakcja faktów → krótki kontekst → rozumowanie
Ważna informacja może być w środku promptu	Przenieś ją na koniec lub do sekcji „kluczowe fakty”
Model reklamuje 1M, ale zadanie jest trudne	Nie ufaj samemu oknu - zmierz efektywny próg
Wynik ma wagę biznesową lub prawną	Dodaj etap weryfikacji i cytowania źródeł
Długa rozmowa zaczyna dryfować	Świeży czat (UI) albo kompakcja (API/agent)

⚠️ Trzy pułapki, w które łatwo wpaść

„Więcej kontekstu = lepiej”. Najczęstszy błąd. Dosypywanie dokumentów spycha krytyczne informacje do stref niskiej uwagi. Mniej, ale trafniej, prawie zawsze wygrywa.

Ślepa wiara w reklamowane okno. „Skoro mieści milion tokenów, to przeczyta milion tokenów ze zrozumieniem” - nie. Pojemność wejścia i jakość rozumowania to dwie różne osie.

Chain-of-thought na siłę przy skrajnie długim wejściu. Klasyczne „myśl krok po kroku” generuje więcej tokenów, co przy i tak przeładowanym oknie potrafi pogłębić rozmycie. Lepiej najpierw skrócić kontekst (ekstrakcja), a dopiero potem prosić o rozumowanie.

🏁 Podsumowanie

Przy obecnych modelach długie okno kontekstowe jest świetne jako magazyn, ale kiepskie jako jedyny mechanizm myślenia. Context rot to nie usterka konkretnego modelu - to gradient wpisany w architekturę transformera, który dotyka wszystkich i zaczyna się długo przed zapełnieniem okna.

Najlepsze systemy - i najlepsi użytkownicy - działają więc jak dobrze zorganizowany analityk: najpierw znajdują właściwe materiały, potem robią z nich krótką paczkę dowodów, a dopiero na końcu rozumują. Cała reszta tego poradnika to warianty tej jednej myśli, dostrojone do tego, czy klikasz w czacie, czy budujesz agenta.

Jedno zdanie na drogę: nie pytaj, ile zmieścisz - pytaj, ile model naprawdę uniesie.

Context rot w pigułce: zasada minimum wystarczającego kontekstu plus zestaw praktyk dla użytkownika i deva.

📚 Źródła

[1] Hong, K., Troynikov, A., Huber, J. (2025). „Context Rot: How Increasing Input Tokens Impacts LLM Performance”. Chroma. https://www.trychroma.com/research/context-rot

[2] Zeng, W., Huang, Y., He, J. (2026). „LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth”. arXiv:2602.07962. https://arxiv.org/abs/2602.07962

[3] Liu, N. F. i in. (2024). „Lost in the Middle: How Language Models Use Long Contexts”. Transactions of the ACL, 12, 157-173. https://aclanthology.org/2024.tacl-1.9/

[4] Du, Y. i in. (2025). „Context Length Alone Hurts LLM Performance Despite Perfect Retrieval”. Findings of EMNLP 2025. https://arxiv.org/abs/2510.05381

[5] Rodionov, G., Garipov, R., Yakushev, G. (2026). „Reasoning Shift: How Context Silently Shortens LLM Reasoning”. arXiv:2604.01161. https://arxiv.org/abs/2604.01161

[6] Anthropic Applied AI (2025). „Effective context engineering for AI agents”. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[7] Hsieh, C.-P. i in. (2024). „RULER: What’s the Real Context Size of Your Long-Context Language Models?”. COLM 2024, arXiv:2404.06654. https://arxiv.org/abs/2404.06654

[8] Ford, D. (2024). „Introducing Contextual Retrieval”. Anthropic. https://www.anthropic.com/news/contextual-retrieval

[9] Anthropic. Compaction (dokumentacja API) oraz Context window (dokumentacja Claude Code). https://platform.claude.com/docs/en/build-with-claude/compaction

[10] Jiang, H. i in. (2023). „LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models”. EMNLP 2023, arXiv:2310.05736. https://arxiv.org/abs/2310.05736

[11] Hsieh, C.-Y. i in. (2024). „Found in the Middle: Calibrating Positional Attention Bias Improves Long Context Utilization”. Findings of ACL 2024, arXiv:2406.16008. https://arxiv.org/abs/2406.16008