W artykule pierwszym padło zdanie, że model dostaje ciąg tokenów. Teraz pytanie, które zadaje się samo: skąd te tokeny się biorą i kto je robi.
Odpowiedź jest zaskakująco prozaiczna. Robi je zwykły algorytm, który niczego się nie nauczył i nigdy się nie nauczy. A mimo to jest jednym z niewielu miejsc w całym stosie, które bezpośrednio przekładają się na twój rachunek.
Model nigdy nie widzi twojego tekstu
To warto powiedzieć wprost, bo brzmi nieintuicyjnie. Model nie dostaje liter. Nie dostaje słów. Dostaje ciąg numerów.
Zanim cokolwiek trafi do sieci neuronowej, tekst przechodzi przez tokenizację: zostaje pocięty na kawałki, a każdy kawałek zamieniony na swój numer w stałym słowniku. Słownik ma zwykle od kilkudziesięciu do kilkuset tysięcy pozycji i został wyliczony raz, przed treningiem modelu. Potem już się nie zmienia.
Numer, nie znaczenie. To ważne rozróżnienie i za chwilę do niego wrócimy.
Jak powstaje słownik
Najpopularniejsza metoda nazywa się BPE i działa na zasadzie, którą da się opisać bez jednego wzoru.
Zaczynasz od pojedynczych znaków. Przeglądasz ogromny zbiór tekstów i szukasz pary znaków, która występuje obok siebie najczęściej. Sklejasz ją w jeden nowy element i dopisujesz do słownika. Potem szukasz kolejnej najczęstszej pary — tym razem także wśród sklejonych już elementów. I tak kilkadziesiąt tysięcy razy.
Efekt jest taki, że częste sekwencje znaków dostają własne miejsce w słowniku, a rzadkie muszą składać się z kawałków. Popularne angielskie słowo bywa jednym tokenem. Rzadkie nazwisko rozpada się na cztery czy pięć.
Podział nie idzie więc ani po słowach, ani po sylabach, ani po żadnej regule gramatycznej. Idzie po statystyce tego, co algorytm zobaczył w danych. Dlatego liczba tokenów nie wynika wprost z liczby znaków ani wyrazów — i dlatego ten sam tekst policzony słownikami dwóch różnych modeli da dwa różne wyniki.
Gdzie kończy się algorytm, a zaczyna sieć
Tu jest granica, którą warto zapamiętać, bo porządkuje resztę serii.
Tokenizer nie ma wag. Niczego się nie uczy, niczego nie rozumie i nie zmienia się podczas pracy — ten sam tekst zawsze da ten sam wynik. To czysta mechanika: przeszukanie listy i zwrócenie numerów.
Znaczenie pojawia się dopiero krok dalej. Numer tokenu służy do wyciągnięcia jednego wiersza z macierzy embeddingów — i dopiero ta macierz jest częścią modelu, wyuczoną w treningu. To tam „5847″ staje się listą kilku tysięcy liczb, które coś znaczą.
Rozbijanie jest algorytmem. Nadawanie znaczenia jest siecią.
Z tego wynika własność, która bywa zaskoczeniem: tokenizer jest przyspawany do modelu i nie da się go wymienić. Numer tokenu to w praktyce adres wiersza w macierzy embeddingów. Podmień słownik, a te same numery wskażą inne wiersze — model nie zacznie działać gorzej, tylko zacznie produkować śmieci. Dlatego tokenizer nie jest narzędziem w sensie, w jakim mówimy o narzędziach agenta. Jest integralną częścią wydania modelu.
Dlaczego polski kosztuje więcej
Tu dochodzimy do rzeczy, która ma bezpośrednie przełożenie na budżet, a po polsku pisze się o niej rzadko.
Słowniki tokenizerów powstały na danych treningowych, w których angielski dominuje. Skoro słownik premiuje sekwencje częste w danych, angielskie słowa częściej mieszczą się w jednym tokenie. To nie jest złośliwość ani błąd projektowy — to bezpośrednia konsekwencja tego, co algorytm zobaczył.
Polski dokłada do tego własną cechę: fleksję. Jedno pojęcie występuje u nas w kilkunastu formach — dokument, dokumentu, dokumentowi, dokumentem, dokumentach. Każda z nich jest osobną sekwencją znaków, a więc każda z osobna jest rzadsza niż angielskie document, które w każdym kontekście wygląda tak samo. Rzadsza sekwencja to gorsze miejsce w słowniku, a gorsze miejsce to więcej tokenów.
Do tego dochodzą znaki diakrytyczne, które w części słowników zajmują więcej niż jedną jednostkę.
Efekt jest taki, że ten sam tekst po polsku ma zauważalnie więcej tokenów niż po angielsku. Nie podaję mnożnika, bo różni się on między modelami i między rodzajami tekstu — i dlatego w aneksie na dole jest kod, którym policzysz to na własnych treściach zamiast wierzyć czyjejś liczbie.
Konsekwencje są trzy i wszystkie praktyczne. Płacisz więcej za tę samą treść, bo rozliczenie idzie za token. Szybciej zapełniasz okno kontekstu, więc mieści się w nim mniej materiału. A przy agencie, który wykonuje wiele kroków i przy każdym wysyła cały kontekst od nowa, różnica narasta z każdą iteracją.
Co jeszcze wynika z tokenizacji
Kilka zachowań modelu, które wyglądają na głupotę, ma tu swoje źródło.
Model nie policzy liter w słowie. Skoro słowo mogło wejść jako jeden numer, model nie ma dostępu do informacji, z jakich znaków się składa — tak samo jak ty nie widzisz składu chemicznego, patrząc na numer katalogowy. To najczęściej przytaczany przykład rzekomej niedorzeczności modeli, a jest po prostu skutkiem tego, że pracują one na innej jednostce niż my.
Model gubi się w rymach i grach słownych. Z tego samego powodu — wewnętrzna budowa słowa jest dla niego niewidoczna, o ile akurat nie rozpadło się na drobne kawałki.
Ten sam prompt kosztuje różnie w różnych modelach. Nie dlatego, że cennik jest inny, tylko dlatego, że słownik jest inny. Przy porównywaniu ofert dostawców trzeba liczyć tokeny właściwym słownikiem, a nie przeliczać z jednego na drugi.
To dotyczy też twojej strony
Warto połączyć to z tym, o czym pisaliśmy w kontekście agent-readiness. Kiedy agent pobiera twoją stronę, cała jej zawartość przechodzi przez dokładnie ten sam tokenizer.
Rozdęty HTML, powtarzalna nawigacja w każdym podstronie, kod JavaScript wpleciony w treść, trzy warianty menu i stopka z pięćdziesięcioma linkami — to wszystko zamienia się w tokeny tak samo jak tekst merytoryczny. Zajmuje miejsce w oknie kontekstu i kosztuje. Różnica między czystym a zaśmieconym szablonem przestaje być kwestią estetyki, a staje się kwestią tego, ile z twojej treści w ogóle dotrze do modelu, zanim skończy się budżet.
Więcej o gospodarowaniu tym budżetem jest w artykule o oknie kontekstu i context rot z serii o context engineeringu.
Jak to sprawdzić u siebie
Poniższe kilkanaście linii policzy tokeny w tym samym tekście po polsku i po angielsku. Biblioteka tiktoken działa lokalnie, bez klucza API i bez wysyłania czegokolwiek na zewnątrz.
import tiktoken
enc = tiktoken.get_encoding("o200k_base")
pary = [
("Zamówienie zostało przekazane do realizacji.",
"The order has been sent for processing."),
("Skontaktujemy się z Państwem w ciągu dwóch dni roboczych.",
"We will contact you within two business days."),
]
for pl, en in pary:
t_pl, t_en = len(enc.encode(pl)), len(enc.encode(en))
print(f"PL {t_pl:3} EN {t_en:3} ({t_pl/t_en:.2f}x) {pl[:40]}")Podmień przykłady na własne treści — najlepiej na fragment, który realnie wysyłasz do modelu w produkcji. Wynik z krótkich zdań bywa mylący, więc weź co najmniej kilka akapitów.
Drugie ćwiczenie, jeszcze bardziej wymowne: wypisz sam podział, żeby zobaczyć, gdzie przebiegają granice.
for token in enc.encode("Przekazaliśmy dokumentację księgową"):
print(repr(enc.decode([token])), end=" ")Zobaczysz, że polskie końcówki fleksyjne odrywają się na osobne kawałki. To jest ta różnica, przeliczona na złotówki w twoim rachunku.
Uwaga na koniec: nazwa kodowania musi odpowiadać modelowi, którego używasz — słownik z jednego modelu nie mówi nic o koszcie w innym. Dla modeli otwartych tokenizer pobierzesz razem z modelem.
Co dalej
Wiemy już, skąd biorą się numery. Pozostaje pytanie, jak numer staje się znaczeniem — bo to nie tokenizer nadaje sens, tylko warstwa zaraz za nim. To tam „auto” i „samochód” lądują blisko siebie, mimo że prawie nie mają wspólnych liter.
O tym jest artykuł trzeci: Embeddingi — czym jest znaczenie dla maszyny.
