Zanim duży model językowy przetworzy tekst, musi go zamienić na liczby. Komputery nie rozumieją słów — rozumieją wektory liczbowe. Tokenizacja to proces dzielenia tekstu na elementarne jednostki (tokeny) i mapowania ich na identyfikatory numeryczne. To pierwszy i fundamentalny krok przetwarzania tekstu przez każdy LLM.
Czym jest token?
Token to podstawowa jednostka tekstu przetwarzana przez model. To nie jest to samo co słowo. Token może być:
- Całym słowem: „hello" → 1 token
- Częścią słowa: „unbelievable" → „un" + „believ" + „able" = 3 tokeny
- Pojedynczym znakiem: „!" → 1 token
- Sekwencją znaków: „
" → 1 token
Kluczowe: słownik tokenów jest skończony i ustalony podczas treningu. Typowy LLM ma słownik 30 000–100 000 tokenów. GPT-4 używa słownika ~100K tokenów; Claude — podobnej skali.
Tokeny vs. słowa
| Tekst | Słowa | Tokeny (GPT-4) |
|---|---|---|
| „Hello world" | 2 | 2 |
| „Konstantynopolitańczykowianeczka" | 1 | ~8 |
| „let x = 42;" | 4 | 5 |
| „🤖" | 0 | 1 |
W języku angielskim: 1 token ≈ 0,75 słowa (lub ~4 znaki). W języku polskim: 1 token ≈ 0,5–0,6 słowa — polski jest „droższy" tokenowo z powodu odmiany (przypadków, koniugacji, deklinacji).
Dlaczego nie dzielić po prostu na słowa?
Podejście „1 słowo = 1 token" ma fundamentalne problemy:
- Ogromny słownik — język angielski ma ~170 000 słów, polski ~500 000 (z odmianami). Każde słowo to osobny wektor embeddingu — astronomiczne koszty pamięci
- Nieznane słowa (OOV) — nowe słowa, literówki, nazwy własne nie istnieją w słowniku. Co z „GPT-4o"? „Antropic"? „xD"?
- Morfologia — „run", „running", „runner" to trzy osobne słowa, ale dzielą rdzeń „run". Słownik słowny ignoruje tę strukturę
- Wielojęzyczność — obsługa 100 języków wymaga milionów słów
Tokenizacja subword (na poziomie podwyrazowym) rozwiązuje te problemy: częste słowa mają swoje tokeny, rzadkie są dzielone na mniejsze części.
Algorytmy tokenizacji
BPE (Byte Pair Encoding)
Najpopularniejszy algorytm tokenizacji, używany przez GPT-2, GPT-3, GPT-4, Llama.
Proces budowania słownika (trening):
- Zacznij od słownika znaków (a, b, c, ..., z, A, ..., Z, 0, ..., 9, ...)
- Policz częstość każdej pary sąsiednich tokenów w korpusie
- Połącz najczęstszą parę w nowy token (np. „t" + „h" → „th")
- Powtarzaj krok 2–3 aż do osiągnięcia docelowego rozmiaru słownika
Proces tokenizacji (inference):
Dla nowego tekstu: zastosuj wyuczone reguły łączenia od najczęstszych do najrzadszych.
Przykład BPE w akcji:
- „lowest" → „low" + „est" (bo „low" i „est" to częste segmenty)
- „newer" → „new" + „er"
- „wider" → „wid" + „er"
WordPiece
Wariant używany przez BERT (Google). Podobny do BPE, ale wybiera parę do połączenia na podstawie prawdopodobieństwa (likelihood), nie częstości. Prefiksy podwyrazów oznaczane są jako „##" (np. „playing" → „play" + „##ing").
SentencePiece
Biblioteka Google'a umożliwiająca tokenizację bez wstępnej segmentacji na słowa (whitespace-agnostic). Traktuje tekst jako surowy ciąg znaków (lub bajtów), co jest kluczowe dla języków bez wyraźnych granic między słowami (chiński, japoński). Używana przez T5, Llama, ALBERT.
Byte-level BPE
Wariant BPE operujący na bajtach zamiast znaków Unicode. Gwarantuje obsługę dowolnego tekstu (emoji, znaki specjalne, kod binarny) bez tokenów OOV. Używany przez GPT-2/3/4.
Tokenizacja a polski język
Polskie modele tokenizacji (np. w GPT-4, Claude) radzą sobie z polskim gorzej niż z angielskim, bo:
- Odmiana — „programować", „programuję", „programowałem", „zaprogramowany" to różne formy, często wymagające wielu tokenów
- Złożenia — „przeciwdeszczowy", „dalekowzroczny" to długie, rzadkie słowa dzielone na wiele fragmentów
- Diakrytyki — ą, ć, ę, ł, ń, ó, ś, ź, ż mogą tworzyć osobne tokeny lub dzielić słowo w nieoczekiwanych miejscach
- Rzadkość w danych treningowych — angielski stanowi 60–80% danych treningowych LLM; polski 1–3%
Konsekwencja: ten sam tekst po polsku zużywa 1,5–2× więcej tokenów niż po angielsku. To oznacza wyższe koszty API, krótszy efektywny kontekst i nieco gorszą jakość.
Tokenizacja a działanie modelu
Wpływ na rozumowanie matematyczne
LLM przetwarzają liczby jako tokeny, nie jako wartości liczbowe. „1234" może być jednym tokenem, ale „12345" może być rozbite na „123" + „45". Model musi „nauczyć się" arytmetyki na tokenach — dlatego LLM mają problemy z dużymi liczbami i precyzyjnymi obliczeniami.
Wpływ na generowanie kodu
Popularne wzorce kodu (np. „def ", „return ", „for i in range") to często pojedyncze tokeny — model generuje je „automatycznie". Rzadsze konstrukcje wymagają więcej tokenów i mogą być generowane mniej stabilnie.
Wpływ na cenę API
Modele rozliczane są za tokeny, nie za słowa. Wiedza o tokenizacji pozwala:
- Szacować koszty promptów
- Optymalizować tekst (np. skracanie zbędnych fraz)
- Rozumieć limity kontekstu (128K tokenów ≈ 96K słów angielskich ≈ ~65K słów polskich)
Embeddyngi — od tokenów do wektorów
Po tokenizacji każdy token jest mapowany na embedding — wektor liczbowy w wielowymiarowej przestrzeni (typowo 768–12288 wymiarów). Embedding koduje „znaczenie" tokenu — podobne tokeny mają bliskie wektory.
Embeddyngi są uczone podczas treningu modelu. Początkowo losowe, stopniowo organizują się w strukturę semantyczną: „kot" jest bliżej „kota" niż „samochodu".
Embedding pozycyjny
Tokeny w tekście mają kolejność, ale mechanizm atencji jest z natury permutacyjnie inwariantny — nie „widzi" pozycji. Rozwiązanie: do embeddingu tokenu dodawany jest embedding pozycyjny (positional encoding), kodujący pozycję tokenu w sekwencji. Warianty: sinusoidalny (oryginalny transformer), wyuczony (GPT), RoPE (Rotary Position Embedding — Llama, Qwen).
Podsumowanie
Tokenizacja to cichy bohater LLM — niewidoczna dla użytkownika, ale fundamentalna dla działania modelu. Jakość tokenizera wpływa na koszty, efektywność, wielojęzyczność i jakość generowania. Gdy rozmawiasz z ChatGPT, Claude czy Gemini, każde Twoje słowo jest najpierw dzielone na tokeny, zamieniane na wektory, przetwarzane przez setki warstw atencji, aż model wygeneruje kolejny token — i cykl się powtarza.