05·Tokenizacja i BPE — dlaczego tekst nie jest znakami ani słowami

Wprowadzenie

Transformer nie operuje na znakach ani na słowach — operuje na tokenach z ustalonego vocabulary o rozmiarze typowo 30k–200k. Wybór tokenizacji to nie detal techniczny, tylko decyzja architektoniczna, która wpływa na: (1) długość kontekstu mierzoną w tokenach, (2) jakość modelu na rzadkich słowach i językach z bogatą fleksją, (3) liczbę parametrów embeddingu (vocab × d_model), (4) cenę API (zwykle płacona za token). Najprostsze podejścia są skrajne: char-level (vocab ≈ 100, ale sekwencje koszmarnie długie) i word-level (vocab miliony, OOV problem dla nowych słów). Złoty środek to subword tokenization. Kluczowe algorytmy: Byte Pair Encoding (BPE — Sennrich et al. 2016, GPT-2/3/4, LLaMA), WordPiece (Schuster & Nakajima 2012, BERT), Unigram (Kudo 2018, T5, ALBERT), SentencePiece (Kudo & Richardson 2018 — implementacja agnostyczna względem języka i białych znaków). BPE startuje od poziomu znaków/bajtów i łączy iteracyjnie najczęstsze pary, aż osiągnie zadany vocab_size. GPT-2 wprowadził byte-level BPE: traktuje wszystkie 256 bajtów UTF-8 jako bazowe tokeny, dzięki czemu nigdy nie ma OOV — można reprezentować każdy ciąg bajtów. Konsekwencje praktyczne: 1 token ≈ 4 znaki ang., ≈ 0.75 słowa; polski tekst ma ≈30% więcej tokenów niż ekwiwalent angielski (mniej obecny w treningu), a kod źródłowy specjalnie wytrenowane tokenizery (Code Llama) skompresują efektywniej.