Czym jest okno kontekstowe?
Okno kontekstowe (context window) to maksymalna ilość informacji, którą duży model językowy (LLM) potrafi przetworzyć w obrębie jednego zapytania. Mieści się w nim wszystko, co model „widzi" w danym momencie: instrukcja systemowa, polecenie użytkownika, załączone dokumenty, historia rozmowy oraz odpowiedź, którą model dopiero generuje. To nie jest baza wiedzy ani trwała pamięć — to raczej blat roboczy, na którym model rozkłada materiał potrzebny do jednej konkretnej odpowiedzi.
Kluczowa konsekwencja: gdy treść przekroczy limit okna, model bezpowrotnie „zapomina" to, co znalazło się poza zakresem — zwykle najstarsze fragmenty rozmowy. Nie ma tu cofania się do wcześniejszych wiadomości tak, jak człowiek wraca myślą do początku rozmowy. Liczy się wyłącznie to, co aktualnie mieści się w oknie.
Pojemność okna nie jest mierzona w słowach ani znakach, lecz w tokenach. Token to najmniejsza jednostka tekstu, na jaką model dzieli wejście podczas tokenizacji. W języku angielskim jeden token to średnio około 0,75 słowa (mniej więcej cztery znaki), bo tokenizery trenuje się głównie na anglojęzycznych tekstach zapisanych alfabetem łacińskim. Ten sam sens kosztuje znacznie więcej tokenów w językach słabiej reprezentowanych — pismach niełacińskich, jak chiński, japoński, arabski czy hindi, oraz w językach o bogatej morfologii, jak polski czy turecki — a także w kodzie źródłowym, przez co każde takie zapytanie jest dłuższe i droższe. Ponieważ dostawcy modeli rozliczają się właśnie za tokeny, rozmiar i efektywność wykorzystania okna przekładają się bezpośrednio na koszt każdego zapytania. Sam mechanizm dzielenia tekstu na tokeny rozkładamy szczegółowo w opracowaniu Tokeny AI — jak modele językowe rozkładają i liczą tekst.
Kto za tym stoi?
Pojęcie okna kontekstowego wynika wprost z architektury Transformer, opisanej w pracy „Attention Is All You Need" (2017) przez zespół badaczy Google. To właśnie mechanizm uwagi (attention) zdefiniował sposób, w jaki model patrzy na wszystkie tokeny jednocześnie — i jednocześnie narzucił praktyczne ograniczenia rozmiaru okna.
Dziś o powiększanie i uefektywnianie okna rywalizują największe laboratoria. OpenAI rozszerzyło okno modeli z linii GPT-4 z początkowych 8 tysięcy do 128 tysięcy tokenów. Anthropic w modelach Claude oferuje standardowo 200 tysięcy tokenów, a w wariantach korporacyjnych nawet więcej. Google z modelami Gemini przesunęło granicę do 1, a następnie 2 milionów tokenów. Równolegle środowisko naukowe i open source (m.in. autorzy FlashAttention oraz metody YaRN) dostarcza technik, które sprawiają, że długie okna w ogóle dają się policzyć na dostępnym sprzęcie.
Jak to działa?
Sercem Transformera jest mechanizm self-attention. Aby zrozumieć zdanie, model dla każdego tokenu wylicza, jak silnie wiąże się on z każdym innym tokenem w sekwencji. To daje modelowi obraz zależności w tekście, ale ma swoją cenę: liczba tych porównań rośnie kwadratowo wraz z długością wejścia. Złożoność obliczeniowa i pamięciowa pełnej uwagi to O(n²).
W praktyce oznacza to, że dziesięciokrotne wydłużenie tekstu nie zwiększa nakładu dziesięciokrotnie, lecz stukrotnie. Podwojenie kontekstu czterokrotnie podnosi liczbę operacji. Dla setek tysięcy tokenów pełne wyliczenie uwagi staje się ekstremalnie kosztowne i głodne pamięci karty graficznej — to przez lata była „żelazna bariera" skalowania.
Drugim filarem jest KV cache (pamięć klucz–wartość). Modele autoregresyjne, jak rodzina GPT, generują tekst token po tokenie. Żeby nie przeliczać w kółko tych samych wartości historycznych, zapisują w pamięci GPU wcześniej obliczone wektory kluczy i wartości. Dzięki temu koszt dołożenia kolejnego tokenu spada lokalnie do liniowego. Problem w tym, że rozmiar KV cache rośnie wraz z długością sekwencji, liczbą warstw sieci i liczbą równoległych zapytań. Przy bardzo długich kontekstach to właśnie cache potrafi zapełnić całą pamięć GPU — model staje się ograniczony przepustowością pamięci, a nie mocą obliczeniową.
Dwa filary pracy modelu w oknie kontekstowym. Przełącz zakładkę i zmieniaj liczbę tokenów.
Aby zrozumieć zdanie, model porównuje każdy token z każdym innym. Liczba porównań to N × N.
Z jakich elementów się składa?
Na zawartość okna kontekstowego składa się kilka warstw, które łącznie zużywają dostępny budżet tokenów:
- Instrukcja systemowa — ukryte polecenia definiujące rolę i zachowanie modelu.
- Polecenie użytkownika (prompt) — bieżące pytanie lub zadanie.
- Materiał dołączony — dokumenty, fragmenty kodu, dane wklejone do zapytania.
- Historia rozmowy — wcześniejsze wymiany w tej samej sesji.
- Generowana odpowiedź — tekst, który model dopiero tworzy, też zajmuje miejsce w oknie.
Każda z tych warstw konkuruje o ten sam, skończony limit. Im więcej miejsca zajmie historia i załączniki, tym mniej zostaje na odpowiedź — i tym szybciej najstarsze fragmenty wypadają poza okno.
Po stronie technicznej okno opiera się też na sposobie kodowania pozycji tokenów. Technika RoPE (Rotary Positional Encoding) zapisuje informację o położeniu słowa jako obrót wektora, co pozwala modelowi rozumieć odległości między tokenami. Modele uczone na limicie np. 4 tysięcy tokenów same z siebie nie radzą sobie z dłuższym tekstem, bo trafiają na wartości pozycyjne, których nie widziały podczas treningu.
Do czego może być używane?
Duże okno kontekstowe otwiera zastosowania, które przy krótkim oknie były niewykonalne lub wymagały sztucznego cięcia danych. Model z oknem rzędu 128–200 tysięcy tokenów potrafi przyjąć całą obszerną umowę, kilkusetstronicowy raport albo dużą bazę kodu i odpowiadać na pytania w kontekście całości, a nie wyrwanego fragmentu.
W praktyce przekłada się to na analizę dokumentów prawnych i finansowych bez ręcznego dzielenia ich na kawałki, przegląd i refaktoryzację kodu obejmującego wiele plików naraz, podsumowywanie długich transkrypcji czy prowadzenie wielogodzinnych rozmów, w których model pamięta wcześniejsze ustalenia. Okna milionowe, jak w Gemini, pozwalają wczytać jednorazowo gigabajty logów lub wiele godzin materiału. Kluczowa zaleta długiego okna nad cięciem danych to zdolność dostrzegania powiązań rozsianych po całym dokumencie — relacji, które giną, gdy materiał potniemy na niezależne fragmenty.
Czym różni się od innych rozwiązań?
Gdy trzeba dać modelowi dostęp do dużej zewnętrznej wiedzy, konkurują dwa podejścia: RAG (Retrieval-Augmented Generation) oraz długi kontekst.
RAG nie wrzuca całego zbioru do okna. Dokumenty są dzielone na fragmenty i indeksowane w wektorowej bazie danych, a do modelu trafiają tylko te kawałki, które semantycznie najlepiej pasują do pytania. To rozwiązanie szybkie i tanie — wysyłamy mało tokenów — i znakomite dla danych dynamicznych, często aktualizowanych, jak wiadomości czy logi. Słabość RAG ujawnia się wtedy, gdy sens odpowiedzi rozkłada się na fragmenty, które algorytm wyszukiwania potnie i rozdzieli.
Długi kontekst działa odwrotnie: cała treść wchodzi do okna, więc model widzi ją naraz i wychwytuje nieliniowe zależności między odległymi fragmentami. Ceną jest koszt i opóźnienie — przy milionowych wejściach czas do pierwszego tokenu liczy się w sekundach, a rachunek rośnie wraz z kwadratową złożonością uwagi.
W praktyce te podejścia coraz częściej się łączą. Hybryda używa RAG do zgrubnego zawężenia ogromnego korpusu, a następnie przesyła wybrane dokumenty do modelu z umiarkowanie długim oknem, gdzie odbywa się właściwa, dogłębna analiza.
Najważniejsze ograniczenia i wyzwania
Największą pułapką długich okien jest rozbieżność między ich rozmiarem deklarowanym a faktyczną użytecznością. Badanie „Lost in the Middle" (Liu i in., 2023) wykazało, że modele najlepiej wykorzystują informacje umieszczone na początku i na końcu wejścia, a fakty schowane w środku długiego dokumentu bywają pomijane. Skuteczność układa się w krzywą w kształcie litery U: silny efekt świeżości i pierwszeństwa, słaby środek. To znaczy, że model z oknem dwóch milionów tokenów wcale nie korzysta z nich równomiernie.
Z tym wiąże się zjawisko określane jako „context rot" — degradacja jakości wraz z zapełnianiem okna. Inżynierowie obserwują, że choć dostawcy chwalą się ogromnymi maksymalnymi rozmiarami okna, sprawność modelu potrafi gwałtownie spaść już przy wykorzystaniu niewielkiego procentu pojemności, zwłaszcza przy trudniejszych zadaniach. Stąd pojęcie maksymalnego efektywnego okna (MECW), które bywa znacznie mniejsze niż okno deklarowane. Nadmiar nieistotnego tekstu działa jak szum i rozprasza model.
Do tego dochodzą twarde ograniczenia infrastrukturalne: kwadratowy koszt uwagi, presja na pamięć GPU ze strony KV cache oraz opóźnienia przy długim wejściu. Techniki takie jak FlashAttention (optymalizacja zarządzania pamięcią GPU), sliding window i sparse attention (ograniczanie zakresu uwagi) czy YaRN (rozszerzanie zasięgu pozycji) łagodzą te bariery, ale ich nie znoszą.
Dlaczego to jest istotne?
Rozmiar okna kontekstowego stał się jednym z głównych parametrów, którymi laboratoria reklamują swoje modele — i dlatego łatwo go źle zinterpretować. Liczba „dwa miliony tokenów" brzmi jak obietnica, że model przeczyta i zrozumie dowolnie dużą całość. Badania nad „lost in the middle" i context rot pokazują, że to uproszczenie: pojemność okna to nie to samo co zdolność jego efektywnego wykorzystania. Dla każdego, kto buduje produkty na LLM, ma to bezpośrednie konsekwencje — wrzucanie do okna wszystkiego „na wszelki wypadek" podnosi koszty i może obniżać jakość odpowiedzi.
Dlatego ciężar przesuwa się z surowego powiększania okna na inżynierię kontekstu: świadome dobieranie, kompresowanie i porządkowanie tego, co trafia do modelu. Zamiast traktować okno jak nieograniczone wysypisko danych, dojrzałe systemy filtrują materiał, układają najważniejsze informacje na brzegach okna i usuwają zbędną historię w długich scenariuszach agentowych. Okno kontekstowe pozostanie więc miarą surowej pojemności, ale o realnej inteligencji modelu coraz częściej decyduje to, jak dobrze tę pojemność zagospodarujemy — a nie samo to, jak jest duża.
Okno kontekstowe najlepiej rozumieć nie jako rozmiar pamięci, lecz jako pole uwagi o nierównej ostrości. Im lepiej rozumiemy jego mechanikę — tokeny, koszt kwadratowy, KV cache i efekt środka — tym trafniej projektujemy zapytania i systemy, które z modeli korzystają.
Źródła
- IBM — „What is a context window?" — link
- arXiv — Vaswani i in., „Attention Is All You Need" (2017) — link
- arXiv — Liu i in., „Lost in the Middle: How Language Models Use Long Contexts" (2023) — link
- arXiv — Dao i in., „FlashAttention" (2022) — link
- arXiv — Peng i in., „YaRN: Efficient Context Window Extension" (2023) — link
- Google AI for Developers — „Long context" (Gemini API) — link
- Anthropic — „Context windows" — link