ChatGPT nie czyta tekstu tak jak Ty. Nie widzi słów. Nie rozumie zdań. Przed przetworzeniem, cały input jest dzielony na tokeny – małe fragmenty tekstu które mogą być całym słowem, częścią słowa, a nawet pojedynczym znakiem. To nie jest technikalia którą możesz ignorować – tokenizacja bezpośrednio wpływa na koszty użycia API, na długość odpowiedzi które możesz dostać, na to dlaczego model czasem dziwnie tnie słowa w innych językach niż angielski.
Po latach pracy z API różnych modeli językowych, mierzenia kosztów, optymalizowania promptów – nauczyłem się że zrozumienie tokenizacji to różnica między efektywnym wykorzystaniem budżetu a przepalaniem pieniędzy na nieoptymalne queries. Dla kogoś kto płaci $0.03 za 1000 tokenów, różnica między 500 a 1000 tokenów w prompcie to real money w skali tysięcy requestów.
Ten artykuł wyjaśnia czym są tokeny, jak działa tokenizacja, dlaczego polski jest “droższy” niż angielski i jak optymalizować użycie żeby nie przepłacać.
Czym jest token – definicja bez żargonu
Token to podstawowa jednostka tekstu którą model przetwarza. Ale uwaga – token NIE równa się słowo. W języku angielskim jedno słowo może być jednym tokenem (“cat”), dwa tokeny (“computer” może być “comput” + “er”), a czasem słowo jest częścią większego tokenu. W polskim przez bogatą odmianę i diakrytyki – większość słów to więcej niż jeden token.
Przykład tokenizacji (GPT-4): “Sztuczna inteligencja zmienia świat” może zostać podzielone na: [“Sztucz”, “na”, ” inte”, “ligen”, “cja”, ” zmienia”, ” świat”]. Model nie widzi słowa “inteligencja” – widzi cztery oddzielne tokeny które statystycznie często występują razem w tej kolejności. To fundamentalnie wpływa na to jak model “rozumie” tekst – operuje na fragmentach, nie całościach.
Dlaczego nie po prostu słowa? Bo vocabulary based na słowach byłby gigantyczny – miliony słów w różnych językach, formach, odmianach. Tokenizacja pozwala modelowi operować na znacznie mniejszym vocabulary (około 50k-100k tokenów) które pokrywa praktycznie cały język przez kombinacje. To kompromis między efficiency a precision.
Byte Pair Encoding – algorytm za tokenizacją
Najpopularniejszy algorytm tokenizacji w LLM to BPE (Byte Pair Encoding). Działa iteracyjnie: zaczyna od pojedynczych znaków jako tokenów, potem łączy najczęściej występujące pary w nowe tokeny, powtarza proces aż osiągnie desired vocabulary size.
Praktyczny przykład jak BPE buduje vocabulary: w danych treningowych słowo “computer” występuje miliony razy. Algorytm zauważa że “com” często występuje razem, robi z tego token. Potem widzi że “comput” częste – kolejny token. “computer” super częste – finalny token. Rzadsze słowo jak “computational” może być podzielone na “comput” + “ational” bo “ational” też jest common suffix używany w wielu słowach.
Rezultat: częste słowa w języku treningu (głównie angielskim) stają się pojedynczymi tokenami. Rzadkie słowa, technical terms, foreign words – są dzielone na mniejsze fragmenty. To wyjaśnia dlaczego model lepiej radzi sobie z popularnym językiem niż ze specjalistyczną terminologią – specialist terms są rozbite na więcej tokenów, każda predykcja kolejnego tokenu to miejsce na potencjalny błąd.
Dlaczego język ma znaczenie: polski vs angielski
Tokenizacja jest optimized dla języka dominant w danych treningowych – czyli angielskiego. To ma konkretne konsekwencje dla innych języków:
Polski jest “droższy” tokenowo: Ten sam tekst w polskim zajmuje około 1.5-2x więcej tokenów niż analogiczny w angielskim. Dlaczego? Bogata odmiana (słowo “komputer” ma formy “komputera”, “komputerowi”, “komputerem” itd.), diakrytyki (ą, ć, ę, ł, ń, ó, ś, ź, ż), dłuższe słowa średnio. Każda z tych wersji może być osobnym tokenem lub wymagać więcej tokenów do reprezentacji.
Konkretny przykład z mojego testingu: prompt 200 słów po angielsku = ~250 tokenów. Ten sam prompt przetłumaczony na polski = ~400 tokenów. To 60% więcej. Jeśli płacisz per token w API – 60% drożej za to samo. W skali tysięcy requestów to significant cost.
Model “wolniej myśli” po polsku: Każdy dodatkowy token to dodatkowa operacja obliczeniowa. Więcej tokenów = wolniejsza generacja. Zauważalne szczególnie przy długich promptach i długich odpowiedziach – polska konwersacja będzie physical slower niż angielska o podobnej długości content.
Context window “mniejsze” efektywnie: GPT-4 ma limit 128k tokenów. Brzmi dużo – to około 96k słów angielskich. Ale dla polskiego? Około 60-70k słów. Efektywnie masz mniejsze okno kontekstowe operując w polskim niż w angielskim, choć technical limit ten sam.
Jak liczyć tokeny – praktyczne narzędzia
Zanim wyślesz request do API, warto wiedzieć ile tokenów zużyjesz. Szczególnie że płacisz per token – zarówno za input jak output:
OpenAI Tokenizer: Oficjalne narzędzie na platform.openai.com/tokenizer. Wklejasz tekst, pokazuje dokładną tokenizację jak model ją widzi. Must-have dla każdego kto serio pracuje z API. Możesz zobaczyć które słowa są expensive tokenowo.
Tiktoken (Python library): Oficjalna biblioteka OpenAI do liczenia tokenów programatically. Niezbędna jeśli budujesz aplikację – możesz przed wysłaniem requestu check czy prompt mieści się w limicie, estimate koszty, optymalizować.
Rough estimation: Dla angielskiego: 1 słowo ≈ 1.3 tokenu średnio. Dla polskiego: 1 słowo ≈ 2-2.5 tokenu. Nie precise ale daje ballpark. 100 słów polskiego tekstu ≈ 200-250 tokenów typically.
Praktyczny workflow: piszesz prompt → sprawdzasz tokenizację → optymalizujesz jeśli za długi → wysyłasz request. Szczególnie ważne dla aplikacji production gdzie tysiące requestów = każdy zaoszczędzony token to saved money.
Wpływ na koszty API – konkretne liczby
OpenAI pricing (grudzień 2024) dla GPT-4 Turbo: $0.01 per 1k input tokens, $0.03 per 1k output tokens. Brzmi tanio? W skali robi różnicę.
Scenario: aplikacja która dla każdego użytkownika generuje personalizowaną odpowiedź. Average prompt 500 tokenów (po polsku), average response 1000 tokenów. Cost per response: (500 * $0.01 / 1000) + (1000 * $0.03 / 1000) = $0.005 + $0.03 = $0.035. Nie dużo? Ale 1000 users dziennie = $35/dzień = $1050/miesiąc = $12,600/rok. Zoptymalizujesz prompt do 300 tokenów i response do 700 tokenów – już oszczędzasz ~40% czyli ~$5000/rok.
Drugi przykład: przetwarzanie dokumentów. Masz 1000 PDF contracts, średnio 50 stron każdy. Ekstrahujesz tekst, wysyłasz do GPT-4 do analizy. 50 stron ≈ 15,000 słów ≈ 30,000 tokenów w polskim. Input cost: 30,000 * $0.01 / 1000 = $0.30 per dokument. 1000 dokumentów = $300 tylko input. Plus output (summary, analysis) może łatwo $0.50 total per document = $500 total. Czy możesz to zoptymalizować? Absolutely – przetwórz dokumenty żeby usunąć boilerplate, extract tylko relevantne sekcje, zmniejszysz token count może o 50%.
Optymalizacja tokenowa – praktyczne techniki
Konkretne sposoby żeby używać mniej tokenów bez utraty quality:
Usuń zbędne whitespace i formatowanie: Nadmiarowe spacje, newlines, tabs – wszystko to tokeny. Przed wysłaniem do API, normalize whitespace. “\n\n\n” to 3 tokeny, “\n” to 1.
Skróć prompty do essentials: “Proszę, czy mógłbyś dla mnie bardzo uprzejmie wygenerować szczegółowe podsumowanie…” vs “Podsumuj:”. Drugi używa 80% mniej tokenów, działa equally well. Model nie potrzebuje uprzejmości ani pełnych zdań – zwięzłe instrukcje wystarczą.
Używaj angielskiego dla technical parts: Jeśli część promptu to technical terms (nazwy funkcji, zmienne, technical concepts), użyj angielskiego. “function calculateTotalPrice()” vs “funkcja obliczająca całkowitą cenę” – pierwszy tańszy tokenowo i mniej ambiguous dla modelu.
Batch processing zamiast individual requests: Zamiast 100 requestów po 100 tokenów, jeden request z 10,000 tokenów. Często taniej bo avoid multiple small requests overhead plus możesz zoptymalizować wspólne elementy (system prompt shared).
Cache system prompts: Jeśli używasz tego samego długiego system promptu dla wielu requestów, niektóre API (jak Claude) oferują prompt caching – płacisz full price tylko pierwszy raz, kolejne razy cached prompt jest znacznie tańszy.
Token limits i jak z nimi żyć
Każdy model ma maximum tokens per request – suma inputu i outputu. GPT-4 Turbo: 128k. Claude: 200k. Gemini: varies by version. Co robisz kiedy Twój use case exceeds limit?
Chunking: Podziel długi dokument na mniejsze chunks, przetwórz osobno, potem aggregate wyniki. Example: 500-page legal document. Dzielisz na 50-page chunks, każdy analyze osobno, potem syntezujesz findings. Requires careful design żeby nie zgubić kontekstu między chunks.
Summarization cascading: Dla bardzo długich tekstów: najpierw summarize każdy rozdział, potem summarize summaries. Recursive approach który condenses gigantyczne teksty do manageable size. Tracisz detale ale zachowujesz główne points.
Selective extraction: Zamiast wysyłać cały dokument, extract tylko relevantne sekcje. Use keyword search, regex, lub prostszy ML model żeby identify które części dokumentu są istotne dla Twojego pytania, wyślij tylko te.
Vector databases + RAG: Dla bardzo large knowledge bases: podziel na chunks, stwórz embeddings, przechowuj w vector database. Query time: znajdź most relevant chunks, tylko te wyślij do LLM. To retrieve-then-read approach, nie read-everything.
Przyszłość tokenizacji
Tokenizacja current generation LLM nie jest idealna. Kilka directions rozwoju:
Character-level models: Zamiast tokenów, bezpośrednio characters. Eliminuje problemy z rzadkimi słowami, różnymi językami, technical terms. But requires much longer sequences = more compute. Trade-off między universality a efficiency.
Multilingual tokenization: Specialized tokenizers optimized dla multiple languages equally, nie tylko angielskiego. Zmniejszy penalty dla non-English languages.
Adaptive tokenization: Dynamically adjust tokenization based na content – technical text uses technical vocab, casual conversation uses different tokenization. More efficient representation.
Tokenizacja to technical detail który ma real-world consequences – na koszty, performance, jakie języki są supported well. Understanding tokens nie jest optional jeśli serio pracujesz z LLM, szczególnie w production gdzie costs matter. Każdy zaoszczędzony token to zaoszczędzone pieniądze, szybsza response, efektywniejsze wykorzystanie context window.
