Okno kontekstu: dlaczego model gubi informacje ze środka tekstu

Okno kontekstu to jedno z tych pojęć, które w materiałach marketingowych brzmi jak obietnica: skoro model przyjmuje dwieście tysięcy tokenów, to znaczy, że potrafi je przeczytać i wykorzystać. W praktyce jest inaczej. Rozmiar okna mówi tylko, ile tekstu zmieści się w jednym wywołaniu. Nie mówi, jak dobrze model znajdzie w nim potrzebną informację. Badania pokazują, że treść umieszczona w środku długiego wejścia bywa traktowana gorzej niż ta na początku albo na końcu, nawet w modelach reklamowanych jako długokontekstowe.

Czym jest okno kontekstu

Okno kontekstu to liczba tokenów, które model przetwarza w jednym przebiegu: instrukcja, wklejone dokumenty, historia rozmowy i miejsce na odpowiedź mieszczą się w jednym limicie. Token to kawałek tekstu, zwykle krótszy niż słowo, więc polski tekst zajmuje więcej tokenów niż angielski o podobnej treści. Limit obejmuje całość, także to, co model ma dopiero napisać.

Historycznie ten limit rósł szybko. Pierwszy Transformer pracował na sekwencjach o długości 512 tokenów i już wtedy zwracano uwagę, że sam mechanizm uwagi porównuje każdy token z każdym innym, więc koszt obliczeń rośnie w przybliżeniu z kwadratem długości wejścia ^[1]. To założenie nadal wyjaśnia, dlaczego długi kontekst jest drogi w obliczeniach, choć dziś liczy się przede wszystkim pamięć, nie sam czas mnożenia macierzy.

Pozycję tokenu model musi znać, inaczej widzi zbiór słów bez kolejności. We współczesnych modelach odpowiada za to najczęściej rotary position embedding: wektory zapytań i kluczy są obracane o kąt zależny od pozycji, dzięki czemu uwaga staje się wrażliwa na odległość między tokenami, a nie tylko na ich absolutny numer ^[2]. Ten mechanizm ma bezpośredni związek z tym, co dzieje się, gdy wejście jest znacznie dłuższe niż to, na którym model się uczył.

Efekt środka, czyli dlaczego początek i koniec wygrywają

Najczęściej cytowane badanie na ten temat pochodzi z 2023 roku i trafiło później do Transactions of the Association for Computational Linguistics. Nelson Liu i współpracownicy sprawdzali dwa zadania: odpowiadanie na pytania na podstawie wielu dokumentów oraz odszukiwanie wartości w parach klucz i wartość. W obu przypadkach zmieniali wyłącznie miejsce, w którym znajdowała się potrzebna informacja, zostawiając resztę tekstu bez zmian ^[3].

Wynik miał kształt litery U. Model radził sobie dobrze, gdy odpowiedź była na początku, i dobrze, gdy była na końcu. Gdy lądowała w środku, jakość odpowiedzi spadała, czasem znacznie. Autorzy nazwali to odpowiednio skłonnością do początku i do końca. Co ważne, efekt występował także w modelach zaprojektowanych do obsługi długich wejść, a nie tylko w tych, które przekraczały swoje pierwotne możliwości ^[3].

To tłumaczy częsty scenariusz z pracy z dokumentami. Wrzucasz dwadzieścia plików, pytanie stawiasz na końcu i dostajesz odpowiedź, która pomija dokument numer dziesięć, choć właśnie w nim była potrzebna liczba. Model nie zgubił pliku w sensie technicznym. Po prostu rozłożył uwagę nierówno.

Skąd bierze się nierówność

Jedno wyjaśnienie jest treningowe. Jeśli model przez większość życia widział krótkie teksty, w których istotna informacja pojawiała się blisko początku lub blisko końca, to nauczył się wzorców, które działają dobrze w takich układach. Mechanizm uwagi nie ma wbudowanej reguły, która każe sprawdzać wszystkie pozycje równie dokładnie.

Drugie wyjaśnienie jest geometryczne i wiąże się z rozciąganiem okna. Metoda position interpolation polega na tym, że pozycje spoza zakresu treningowego są ściskane do zakresu znanego modelowi. W pracy Meta z 2023 roku pokazano, że takie przeskalowanie pozwala wydłużyć okno z 2048 do 32768 tokenów przy minimalnym dostrajaniu, ale jednocześnie przyznano, że model zachowuje się inaczej niż ten trenowany od początku na długich sekwencjach ^[4]. Rozciągnięcie zakresu pozycji nie tworzy nowych zdolności. Zmienia rozdzielczość, z jaką model rozróżnia odległe fragmenty.

Trzecie wyjaśnienie jest pamięciowe i najlepiej je policzyć. Przy generowaniu tekstu model przechowuje tak zwany cache kluczy i wartości, czyli to, co już przetworzył, żeby nie liczyć wszystkiego od nowa przy każdym kolejnym tokenie. Rozmiar tego cache na jeden token wynosi w przybliżeniu: dwa razy liczba warstw, razy liczba głów kluczy i wartości, razy wymiar głowy, razy liczba bajtów na liczbę. Dla modelu z 32 warstwami, 8 głowami kluczy i wartości oraz wymiarem głowy 128, przy połowie precyzji, daje to około 128 KiB na token. Przy 128 tysiącach tokenów jest to około 16 GiB, i to tylko na kontekst, bez wag modelu.

Ta arytmetyka wyjaśnia, dlaczego dostawcy liczą długie wejścia osobno i dlaczego w praktyce opłaca się wysyłać krótszy, dobrze wybrany fragment zamiast całej dokumentacji. Nie jest to spisek przeciw użytkownikowi, tylko fizyka pamięci.

Jak sprawdzić, czy model naprawdę korzysta z kontekstu

Odrębne zjawisko to halucynacje modeli językowych, gdy model wymyśla treść zamiast ją pominąć. Skutek bywa podobny: odpowiedź brzmi wiarygodnie i jest błędna.

Popularny test igły w stogu siana polega na ukryciu jednego zdania w długim tekście i sprawdzeniu, czy model je znajdzie. Ten test jest zbyt łatwy. Model może go przejść niemal bezbłędnie, a mimo to źle radzić sobie z zadaniami, które wymagają połączenia kilku fragmentów albo policzenia czegoś na podstawie całego wejścia.

Dlatego powstał RULER, zestaw trzynastu zadań o regulowanej długości i trudności, obejmujący między innymi śledzenie wielu powiązań i agregację informacji z całego tekstu. W badaniu z 2024 roku sprawdzono siedemnaście modeli deklarujących co najmniej 32 tysiące tokenów kontekstu. Wszystkie wypadały dobrze w prostym teście igły, ale gdy rosła długość wejścia, ich wyniki spadały. Tylko połowa utrzymywała zadowalającą jakość przy 32 tysiącach tokenów ^[5].

Wniosek dla użytkownika jest prosty: deklarowany rozmiar okna to górny limit, a nie miara jakości. Dwie liczby podane w karcie produktu, na przykład 128 tysięcy i milion tokenów, nie mówią nic o tym, jak model zachowa się na twoim materiale.

Co z tym zrobić w praktyce

• Stawiaj pytanie lub polecenie na końcu wiadomości, po dokumentach. To wykorzystuje skłonność do końca i porządkuje odpowiedź.
• Najważniejszy dokument umieszczaj na początku, nie w środku stosu. Jeśli masz ich wiele, sortuj według znaczenia, a nie alfabetycznie.
• Proś o cytat i numer dokumentu przy każdym twierdzeniu. Łatwiej wtedy zauważyć, że model pominął fragment, niż przy gładkiej odpowiedzi bez odwołań.
• Dziel zadania. Trzy osobne wywołania po kilka dokumentów często dają lepszy wynik niż jedno z całością, nawet jeśli wszystko mieści się w limicie.
• Nie zakładaj, że model zapamiętał wcześniejszą część rozmowy tylko dlatego, że była długa. Przy długich sesjach powtarzaj ustalenia, które mają znaczenie.

Osobna sprawa to koszt. Jeśli płacisz za tokeny wejścia, wysyłanie całej bazy wiedzy przy każdym pytaniu jest wygodne, ale rzadko konieczne. Wybór pięciu trafnych dokumentów przez wyszukiwanie po słowach kluczowych często bije wrzucenie pięćdziesięciu przypadkowych, i to nie tylko ceną.

Gdzie kończy się obietnica

Okno kontekstu jest realnym osiągnięciem inżynierii. Modele potrafią dziś pracować z materiałem, który kilka lat temu nie mieścił się w pamięci karty graficznej. Ale to narzędzie, nie gwarancja. Badania nad efektem środka i nad rzeczywistą długością kontekstu pokazują, że jakość korzystania z tekstu zależy od jego układu, od treningu i od tego, jak precyzyjnie sformułowano zadanie.

Najbezpieczniejsza strategia jest nudna: krótsze wejścia, lepsza selekcja, pytanie na końcu i sprawdzanie odpowiedzi na fragmentach źródłowych. Model, który deklaruje milion tokenów, nadal jest modelem, który potrafi przeoczyć zdanie w środku dokumentu. Wiedza o tym jest tańsza niż zaufanie do liczby na stronie sprzedażowej.

Źródła

1. Ashish Vaswani i in., „Attention Is All You Need”, czerwiec 2017, arXiv:1706.03762. https://arxiv.org/abs/1706.03762
2. Jianlin Su i in., „RoFormer: Enhanced Transformer with Rotary Position Embedding”, kwiecień 2021, arXiv:2104.09864. https://arxiv.org/abs/2104.09864
3. Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang, „Lost in the Middle: How Language Models Use Long Contexts”, Transactions of the Association for Computational Linguistics, tom 12, 2024, str. 157–173. https://aclanthology.org/2024.tacl-1.9/
4. Shouyuan Chen, Sherman Wong, Liangjian Chen, Yuandong Tian, „Extending Context Window of Large Language Models via Positional Interpolation”, czerwiec 2023, arXiv:2306.15595. https://arxiv.org/abs/2306.15595
5. Cheng-Ping Hsieh i in., „RULER: What’s the Real Context Size of Your Long-Context Language Models?”, kwiecień 2024, arXiv:2404.06654. https://arxiv.org/abs/2404.06654