Okna kontekstu: rozmiar i znaczenie

Okno kontekstu to maksymalna liczba tokenów, które LLM może przetworzyć w ramach pojedynczego wywołania API. Obejmuje ono wszystko: prompt systemowy, wszystkie wcześniejsze wypowiedzi w konwersacji, wszelkie dokumenty dołączone na potrzeby RAG oraz miejsce zarezerwowane na odpowiedź modelu. Jeśli łączna liczba tokenów przekroczy rozmiar okna kontekstu, API zwróci błąd.

Proszę traktować okno kontekstu jako pamięć roboczą modelu. W przeciwieństwie do człowieka, który może pamiętać wcześniejsze rozmowy między sesjami, LLM nie ma trwałej pamięci — może „wiedzieć” tylko to, co znajduje się w bieżącym oknie kontekstu. Gdy konwersacja przekroczy rozmiar okna, najstarsze treści muszą zostać usunięte, przez co model może stracić istotny wcześniejszy kontekst.

Okna kontekstu znacznie się powiększyły. W 2020 roku GPT-3 oferował 4096 tokenów. Do 2025 roku czołowe modele oferują:

• GPT-4o i GPT-4o-mini: 128 000 tokenów (~100 000 słów)
• Claude 3.5 Sonnet / Opus: 200 000 tokenów
• Gemini 1.5 Pro: 1 000 000 tokenów (milion)
• Gemini 1.5 Flash: 1 000 000 tokenów

Okno kontekstu o rozmiarze 128K może pomieścić około 300 stron tekstu, kompletną powieść lub całą bazę kodu średniej wielkości. Mimo to nieskończony kontekst nie jest rozwiązanym problemem: koszt mechanizmu attention rośnie kwadratowo wraz z długością sekwencji, przez co bardzo długie konteksty są kosztowne, a czasami mniej dokładne niż krótsze i bardziej skoncentrowane konteksty.

Badania wykazały, że LLM nie skupiają uwagi w równym stopniu na wszystkich częściach okna kontekstu. Zwykle poświęcają najwięcej uwagi treści na samym początku (efekt pierwszeństwa) i samym końcu (efekt świeżości) kontekstu, natomiast treści ze środka są przetwarzane mniej niezawodnie.

Nazywa się to problemem zagubienia w środku. Ma to praktyczne znaczenie dla systemów RAG: jeśli połączy Pan/Pani 10 pobranych dokumentów, a najbardziej istotny z nich znajdzie się w środku, model może nie wykorzystać go skutecznie. Najlepszą praktyką jest umieszczanie najważniejszego kontekstu na początku lub na końcu dołączanych dokumentów, a nie w środku.

W aplikacji czatowej pełna historia konwersacji jest dołączana do każdego wywołania API. Wraz z rozwojem konwersacji rośnie także liczba tokenów. Konwersacja obejmująca 50 wiadomości, z których każda ma średnio 100 tokenów, już sama w sobie zużywa 5000 tokenów na historię. Po dodaniu promptu systemowego o długości 2000 tokenów i kontekstu RAG o długości 10 000 tokenów otrzymujemy 17 000 tokenów, zanim użytkownik zada kolejne pytanie.

Duże okno kontekstu nie oznacza, że należy wypełniać je w całości. Badania konsekwentnie pokazują, że dokładność modelu spada w miarę zapełniania kontekstu, zwłaszcza w zadaniach wymagających precyzyjnego wyszukania konkretnych faktów z długiego kontekstu. Skoncentrowany i istotny kontekst o długości 5000 tokenów często prowadzi do lepszych odpowiedzi niż niespójny kontekst o długości 50 000 tokenów.

To główny argument za stosowaniem RAG zamiast prostego umieszczania wszystkich dokumentów w kontekście: system RAG pobiera tylko 2–5 najbardziej istotnych fragmentów, dzięki czemu kontekst pozostaje skoncentrowany, a uwaga modelu skupia się na tym, co ważne. Można to porównać do przeszukiwania indeksu książki zamiast czytania całej książki w celu znalezienia odpowiedzi na jedno pytanie.

Długie okna kontekstu umożliwiają zaawansowane przepływy pracy związane z przetwarzaniem dokumentów, które wcześniej były niemożliwe. Można teraz wysłać cały 50-stronicowy plik PDF do GPT-4o i zadawać pytania na jego temat, poprosić model o jednoczesne podsumowanie i porównanie wielu umów albo przeanalizować całą bazę kodu pod kątem wzorców i antywzorców.

Jednak przy koszcie około 0,15 USD za milion tokenów wejściowych przetworzenie dokumentu zawierającego 100 000 tokenów w ramach jednego zapytania kosztuje około 0,015 USD. Przy 10 000 zapytań dziennie dotyczących dokumentu, który rzadko się zmienia, płacą Państwo 150 USD dziennie za redundantne przetwarzanie. Dlatego strategie buforowania i wstępnego przetwarzania mają ogromne znaczenie w produkcyjnych systemach analizy dokumentów.

Parametr max_tokens w API ogranicza długość wyjścia, a nie całkowity kontekst. Całkowite okno kontekstu jest równe liczbie tokenów wejściowych powiększonej o liczbę tokenów wyjściowych. Jeśli okno kontekstu ma 128 000 tokenów, a dane wejściowe zajmują 120 000 tokenów, na odpowiedź pozostaje tylko 8000 tokenów — niezależnie od wartości ustawionej dla max_tokens.

Zawsze należy zarezerwować wystarczający budżet na dane wyjściowe. W przypadku asystenta konwersacyjnego zwykle wystarczy zarezerwować na wyjście 2000–4000 tokenów. W generowaniu kodu lub dłuższych treści może być potrzebne 8000–16 000 tokenów. Obliczanie budżetu tokenów należy uwzględnić w logice składania kontekstu.

Rozmiar okna kontekstu powinien być jednym z kluczowych kryteriów wyboru modelu. Należy dopasować okno kontekstu modelu do rzeczywistego przypadku użycia:

• Asystenci czatowi z krótkimi sesjami: zwykle wystarczy 8K–16K; warto użyć gpt-4o-mini ze względu na efektywność kosztową
• Pytania i odpowiedzi dotyczące średnich dokumentów: 32K–128K; gpt-4o dobrze równoważy jakość i koszt
• Analiza dokumentów prawnych i umów obejmujących setki stron: 128K–200K; warto rozważyć Claude ze względu na skuteczność przy długim kontekście
• Analiza całej bazy kodu lub książki: 500K–1M; obecnie liderem jest Gemini 1.5 Pro

Płacenie za okno kontekstu o rozmiarze 1M tokenów, gdy potrzebują Państwo tylko 8K, to kosztowna przesada. Należy dobrać model do rzeczywistych wymagań dotyczących kontekstu.

Gdy wielokrotnie wysyłają Państwo zapytania dotyczące tego samego dużego dokumentu lub promptu systemowego, za każdym razem płacą Państwo za tokenizację i przetworzenie tej samej treści. Funkcja prompt caching firmy OpenAI automatycznie obniża o 50% cenę tokenów wejściowych dla powtarzających się prefiksów promptu, gdy ten sam prefiks przekracza 1024 tokeny.

Aby zmaksymalizować liczbę trafień w pamięci podręcznej, należy tak strukturyzować wiadomości, aby stała treść znajdowała się na początku: najpierw prompt systemowy, następnie duży dokument lub kontekst, a na końcu zmienne pytanie użytkownika. Dzięki temu długi, stały prefiks jest buforowany, a przy każdym żądaniu pełną cenę płaci się tylko za małe, zmienne zapytanie.

Mając do dyspozycji duże okno kontekstu, mają Państwo dwie strategie obsługi rozrastających się konwersacji lub dużych dokumentów: rozszerzanie (zachowanie wszystkiego w kontekście) albo podsumowywanie (kompresowanie starszych treści w celu oszczędzania tokenów). Właściwy wybór zależy od przypadku użycia.

Należy wybrać rozszerzanie, gdy trzeba odwoływać się do konkretnych faktów z wcześniejszej części konwersacji, analizowany dokument wymaga cytowania konkretnych fragmentów lub podsumowanie spowodowałoby utratę istotnych niuansów. Należy wybrać podsumowywanie, gdy ważniejsze są ogólne tematy wcześniejszej konwersacji niż konkretne sformułowania, zbliżają się Państwo do limitu kontekstu lub ten sam kontekst będzie wielokrotnie wykorzystywany, dzięki czemu podsumowanie stanie się kosztem jednorazowym.

W środowisku produkcyjnym należy śledzić długość kontekstu dla każdego żądania jako kluczową metrykę. Nagłe skoki średniej długości kontekstu mogą wskazywać na błąd w kodzie składania kontekstu, wklejanie przez użytkowników bardzo długich danych wejściowych lub pętlę zwrotną, w której długie odpowiedzi modelu są ponownie dodawane do kontekstu. Należy ustawić alerty, gdy długość kontekstu przekroczy 80% maksymalnej wartości modelu.

Należy również śledzić zdarzenia obcinania — sytuacje, w których trzeba skrócić kontekst, aby zmieścić się w oknie. Częste obcinanie oznacza, że potrzebują Państwo lepszej strategii zarządzania kontekstem, modelu z większym kontekstem albo podejścia opartego na RAG, które pobiera tylko istotne treści zamiast wysyłać wszystko.

Sprawdź swoją wiedzę na temat koncepcji inżynierii AI z tej lekcji.

W tej lekcji dowiedzieli się Państwo, że: okno kontekstu to łączny budżet tokenów na dane wejściowe i wyjściowe w ramach pojedynczego wywołania API, problem zagubienia w środku oznacza, że treści na początku i końcu kontekstu są przetwarzane bardziej niezawodnie, a mały, skoncentrowany kontekst często przewyższa duży i niespójny, dlatego RAG jest lepszym rozwiązaniem niż upychanie wszystkich dokumentów w kontekście. W następnej części omówimy obliczanie i prognozowanie kosztów API przed wysłaniem żądań.