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:

  1. 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
  2. Nieznane słowa (OOV) — nowe słowa, literówki, nazwy własne nie istnieją w słowniku. Co z „GPT-4o"? „Antropic"? „xD"?
  3. Morfologia — „run", „running", „runner" to trzy osobne słowa, ale dzielą rdzeń „run". Słownik słowny ignoruje tę strukturę
  4. 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):

  1. Zacznij od słownika znaków (a, b, c, ..., z, A, ..., Z, 0, ..., 9, ...)
  2. Policz częstość każdej pary sąsiednich tokenów w korpusie
  3. Połącz najczęstszą parę w nowy token (np. „t" + „h" → „th")
  4. 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:

  1. Odmiana — „programować", „programuję", „programowałem", „zaprogramowany" to różne formy, często wymagające wielu tokenów
  2. Złożenia — „przeciwdeszczowy", „dalekowzroczny" to długie, rzadkie słowa dzielone na wiele fragmentów
  3. Diakrytyki — ą, ć, ę, ł, ń, ó, ś, ź, ż mogą tworzyć osobne tokeny lub dzielić słowo w nieoczekiwanych miejscach
  4. 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.