---
title: "Context rot: większe okno kontekstowe nie znaczy mądrzejszy model - poradnik dobrych praktyk"
date: 2026-06-07
description: "Model przyjmie milion tokenów, ale nie zrozumie ich tak, jak myślisz. Context rot to realna degradacja rozumowania przy długim kontekście. Oto praktyczny poradnik: jak układać, ciąć i pielęgnować kontekst, żeby model nie głupiał - dla użytkownika czatu i dla deva."
tags: ["context rot", "kontekst", "ai", "promptowanie", "agenty", "rag"]
---

## 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.

<!-- GRAFIKA: krzywa U uwagi / "lost in the middle". Oś X = pozycja informacji w kontekście (początek -> środek -> koniec), oś Y = dokładność. Wyraźny dołek w środku. Styl spójny z blogiem (czysty, minimalistyczny diagram). -->
![Krzywa U: dokładność modelu w zależności od pozycji informacji w kontekście - najwyższa na początku i końcu, najniższa w środku](/media/context-rot-krzywa-u.webp)
_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.

<!-- GRAFIKA: "efektywne vs reklamowane okno". Dwa paski/słupki: górny "reklamowane: 1M tokenów" (pełny), dolny "efektywne: jakość trzyma do ~X" (krótszy, z gradientem przechodzącym w czerwień przy końcu). Podpis o teście na własnych zadaniach. -->
![Porównanie reklamowanego okna kontekstowego z faktycznym efektywnym oknem, w którym jakość rozumowania pozostaje wysoka](/media/context-rot-efektywne-okno.webp)
_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ę.

<!-- GRAFIKA: "czysty vs zatruty kontekst agenta". Po lewej agent z czystym, krótkim kontekstem (zielony, ostry). Po prawej agent po wielu turach z narastającym szumem/dystraktorami (czerwony, rozmyty). Strzałka pokazująca, jak sub-agenty / kompakcja przywracają czystość. -->
![Porównanie czystego kontekstu agenta z kontekstem zatrutym przez akumulację szumu po wielu turach](/media/context-rot-czysty-vs-zatruty.webp)
_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.

<!-- GRAFIKA: pipeline "ekstrakcja -> rozumowanie". Poziomy diagram: [długi, zaszumiony kontekst] -> [EKSTRAKCJA: krótka lista dowodów] -> [ROZUMOWANIE na krótkim kontekście] -> [WERYFIKACJA]. Pokazać, jak długi kontekst kurczy się do paczki dowodów. -->
![Pipeline przetwarzania: od długiego zaszumionego kontekstu, przez ekstrakcję dowodów, do rozumowania na krótkim kontekście i weryfikacji](/media/context-rot-ekstrakcja-rozumowanie.webp)
_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.**

<!-- GRAFIKA: podsumowanie wizualne. Infografika zbierająca: zasada "minimum wystarczające", krzywa U, pipeline ekstrakcja->rozumowanie, ikony 6 praktyk dev + 5 praktyk user. Spójna kolorystycznie z blogiem. -->
![Podsumowanie wizualne dobrych praktyk pracy z dużym kontekstem i przeciwdziałania context rot](/media/context-rot-podsumowanie.webp)
_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](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](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/](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](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](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](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](https://arxiv.org/abs/2404.06654)

[8] Ford, D. (2024). *„Introducing Contextual Retrieval"*. Anthropic. [https://www.anthropic.com/news/contextual-retrieval](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](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](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](https://arxiv.org/abs/2406.16008)