Milion tokenów kontekstu to nie milion tokenów uwagi

Producenci modeli licytują się rozmiarem okna kontekstowego, a odbiorcy czytają tę liczbę jak pojemność dysku. Dwa razy więcej tokenów, dwa razy więcej materiału do wrzucenia. Tak to nie działa, i jest to zmierzone.

Zespół badawczy Chroma przetestował 18 modeli, wśród nich Claude Opus 4 i Sonnet 4, o3, GPT-4.1, Gemini 2.5 Pro oraz Qwen3. Sprawdzał jedno: jak zmienia się jakość odpowiedzi wraz z długością wejścia. Wynik jest niewygodny dla całej narracji o dużych oknach. Trafność spada nierównomiernie i robi to nawet przy zadaniach tak prostych jak odszukanie zdania albo powtórzenie listy słów.

To nie jest ciekawostka dla badaczy. To wyjaśnienie, dlaczego „wrzuć mu cały plik i zobacz, co powie” działa gorzej niż wysłanie trzech wybranych funkcji.

Co dokładnie sprawdzono

Badanie rozszerzyło popularny benchmark needle in a haystack, czyli szukanie jednego zdania w długim tekście, o warianty bliższe realnym zastosowaniom. Doszły do tego dwa inne zadania: LongMemEval, czyli pytania do rozmowy o długości około 113 tysięcy tokenów, oraz syntetyczne powtarzanie ciągu słów.

Cztery wnioski są istotne w codziennej pracy.

Dosłowność ratuje, parafraza szkodzi. Gdy szukana informacja jest sformułowana podobnie do pytania, modele radzą sobie długo. Gdy trzeba zrobić skok znaczeniowy, na przykład „ta klasa robi to samo, co opisujesz, tylko nazywa się inaczej”, jakość spada wraz z długością wejścia znacznie szybciej.

Wystarczy jeden dystraktor. Nawet pojedyncza treść tematycznie zbliżona, ale nietrafiona, obniżała wynik względem czystego materiału. Wpływ nie był przy tym równomierny: niektóre dystraktory szkodziły dużo bardziej niż inne. To dotyczy wprost pracy z repozytorium, w którym leżą trzy wersje tej samej funkcji: stara, nowa i ta z gałęzi eksperymentalnej.

Chaos bywa lepszy od porządku. Modele wypadały lepiej, gdy materiał był losowo pomieszany, niż gdy zachowywał logiczny tok wywodu. Efekt wystąpił konsekwentnie w całej stawce. Nikt nie ma na to dobrego wyjaśnienia i autorzy tego nie ukrywają. Praktyczny wniosek jest za to jasny: intuicja „im ładniej ułożę materiał, tym lepiej model zrozumie” nie ma pokrycia w danych.

Modele różnią się tym, jak zawodzą. Przy zadaniu z dystraktorami rodzina Claude konfabulowała najrzadziej, a modele OpenAI najczęściej. To jest argument za tym, żeby przy zadaniach opartych o dokumenty testować konkretny model na własnym materiale, zamiast ufać benchmarkom ogólnym.

Do tego dochodzi uwaga metodologiczna, przydatna przy czytaniu materiałów dostawców. Standardowy NIAH mierzy przede wszystkim wyszukiwanie dosłowne, a nie rozumienie. Wysoki wynik w tym benchmarku nie oznacza, że model utrzyma sens na dwustu tysiącach tokenów Twojej dokumentacji.

Jak to wygląda w zespole

Trzy wzorce, które widzę najczęściej. Wszystkie są bezpośrednim skutkiem powyższego.

Zrzut całego repozytorium. Ktoś wkleja 40 plików, bo „model sobie wybierze”. Chroma nie testowała repozytoriów kodu, więc dalej idzie moja hipoteza, nie wynik. Dystraktory szkodzą, a podobieństwo dosłowne pomaga. Zrzut wszystkiego premiuje więc pliki podobne słownikowo do pytania kosztem tych, które faktycznie rozstrzygają. Zgadza się to z tym, co widzę na warsztatach, ale nikt tego nie zmierzył.

Sesja, która trwa trzy godziny. W historii siedzi pięć sprzecznych wersji wymagania, dwie porzucone ścieżki i jedna poprawka, o której człowiek już zapomniał. Model widzi wszystko naraz i nie ma jak rozstrzygnąć, co obowiązuje. Objaw: „przecież mówiłem, żeby tego nie robić”.

Poprawianie zamiast restartu. Po trzeciej nieudanej próbie ludzie dopisują kolejne „nie, jednak inaczej”, zamiast zacząć nową rozmowę z lepszym pierwszym promptem. Każda taka korekta dokłada dystraktorów. Anthropic opisuje ten sam problem od strony inżynierskiej i powołuje się wprost na context rot. Proponuje trzy techniki: kompaktowanie historii do streszczenia, trzymanie notatek poza oknem kontekstowym oraz delegowanie zadań podagentom. Zasada restartu, którą podaję niżej, to mój warsztatowy skrót do tego samego celu, a nie zalecenie Anthropica.

Anatomia zapytania, które działa

Poniżej porównanie na zadaniu z warsztatów: analizie awarii produkcyjnej. Przypadek jest zmyślony, żeby dało się go pokazać publicznie, ale struktura promptu pochodzi z realnej pracy. Różnica bierze się z tego, ile pracy decyzyjnej zrzucasz na model.

Wersja, którą pisze się odruchowo:

Sprawdź te logi i powiedz, dlaczego baza przestała odpowiadać.
[wklejone 4000 linii logów]

Zadanie jest nieokreślone, kontekst nieprzefiltrowany. Odpowiedź będzie ogólnikiem o restarcie usługi i sprawdzeniu sieci, bo statystycznie tak wygląda większość tekstów o niedostępnej bazie danych.

Wersja inżynierska:

ROLA
Inżynier SRE utrzymujący system płatności w Spring Boot.

ZADANIE
Wskaż bezpośrednią przyczynę serii błędów HTTP 500 między 14:00 a 14:10.

KONTEKST
- Architektura: 6 mikroserwisów, pula połączeń HikariCP do PostgreSQL 15.
- Załączam wyłącznie logi serwisu payment-api z okna 13:55–14:15 (312 linii)
  oraz konfigurację puli połączeń.
- Wdrożenie na produkcję było 4 dni temu, wcześniej problem nie występował.

OGRANICZENIA
- Nie tłumacz, czym jest pula połączeń.
- Jeśli w logach brakuje danych do rozstrzygnięcia, napisz jakich.
  Nie zgaduj.
- Maksymalnie 3 punkty.

SPOSÓB PRACY
Najpierw uszereguj zdarzenia chronologicznie, potem znajdź pierwszy wyjątek
niebędący skutkiem poprzedniego, dopiero na końcu formułuj wniosek.

Pięć bloków, każdy usuwa inną klasę błędu:

Najważniejszy jest trzeci wiersz. Zawężenie logów z 4000 linii do 312 z właściwego okna czasowego robi dla jakości odpowiedzi więcej niż cała reszta promptu razem wzięta. I jest to praca, której model za Ciebie nie wykona.

Sześć zasad higieny kontekstu

To są moje reguły warsztatowe, nie wnioski z badania. Żadna nie ma za sobą pomiaru, każdą da się wdrożyć w zespole od ręki.

1. Selekcjonuj, nie zrzucaj. Zanim wkleisz, sprawdź: czy człowiek rozwiązałby to zadanie, mając tylko ten materiał? Jeśli tak, wystarczy. Jeśli nie wiesz, to znak, że najpierw trzeba zrozumieć problem samemu.
2. Jedno źródło prawdy na prompt. Nie podawaj dwóch wersji tej samej funkcji ani starej i nowej specyfikacji naraz. Gdy naprawdę musisz, zaznacz wyraźnie, która obowiązuje, a o drugiej napisz, że jest tylko tłem.
3. Restartuj zamiast poprawiać. Reguła kciuka: po drugiej nieudanej korekcie otwórz nową rozmowę i napisz lepszy pierwszy prompt. Taniej i skuteczniej niż trzecia poprawka.
4. Powtarzalny kontekst przenieś z czatu do pliku. Gdy dziesięć osób co tydzień tłumaczy modelowi te same konwencje projektu, to jest złamanie zasady DRY. Miejsce na to jest w instrukcjach repozytorium, w GEM-ie albo w konfiguracji agenta, a nie w głowie i w schowku.
5. Ograniczenia formułuj negatywnie i konkretnie. „Bądź precyzyjny” nie znaczy nic. „Nie proponuj bibliotek spoza tych w package.json” znaczy dokładnie tyle, ile trzeba.
6. Zmierz to na dziesięciu zadaniach. Wybierz dziesięć typowych zadań zespołu, zapisz oczekiwany wynik i przepuść przez nie dwa warianty promptu. To jedyny sposób, żeby rozstrzygnąć spór o promptowanie faktami. Zajmuje pół dnia, a kończy dyskusje na kwartały.

Trzy zasoby, które opłaca się mieć na stałe

Skoro powtarzalny kontekst ma mieszkać poza czatem, przydaje się wiedzieć, co standaryzować najpierw. Z mojego doświadczenia zawsze wychodzą te same trzy rzeczy.

• Instrukcje repozytorium. Konwencje, stos technologiczny, czego w tym projekcie nie robimy. Jeden plik czytany przez asystenta przy każdej sesji. Zwykle najszybszy zwrot z całej listy.
• Recenzent kodu. Stały prompt sprawdzający zmianę pod kątem OWASP Top 10, zgodności z konwencją projektu i duplikacji istniejącej logiki. Nie zastępuje człowieka, zdejmuje z niego rutynę.
• Generator decyzji architektonicznych. Zamienia notatkę ze spotkania w dokument ADR z rozważanymi alternatywami. Dokumentacja decyzji to pierwsza rzecz, która ginie pod presją terminu, i pierwsza, której brakuje pół roku później.

Wspólny mianownik: kontekst jest wersjonowany, przeglądany i wspólny dla zespołu, zamiast być odtwarzany od zera przez każdego osobno.

Dlaczego to jest ważniejsze, niż wygląda

W ankiecie Stack Overflow 2025 największą bolączką deweloperów były odpowiedzi „prawie dobre, ale nie do końca”. Wskazało je 66% z 31 476 osób, które odpowiedziały na to pytanie. Ankieta nie bada, skąd te „prawie” się biorą, więc moja teza jest tylko tezą: częściej z kontekstu, który był jednocześnie za duży i niekompletny, niż z ograniczeń samego modelu. Pięćdziesiąt plików bez tego jednego, który rozstrzygał.

Dobra wiadomość jest taka, że to jedyna część układanki, na którą masz pełny wpływ. Nie kontrolujesz wag modelu ani polityki cenowej dostawcy. Kontrolujesz to, co wysyłasz, i akurat ta dźwignia ma zaskakująco duże przełożenie.