Jak modele LLM widzą tekst: czego mój system i18n nauczył mnie o ekonomii tokenów

Kiedy budowałem system tłumaczeń i18n dla mojej strony, odkryłem, że przetłumaczenie 1500-słownego angielskiego wpisu blogowego na koreański zużywało 2,8x więcej tokenów niż angielskie źródło. Ta sama treść semantyczna, to samo znaczenie, ale 2,8x wyższy koszt API. Japoński wynosił 2,4x. Chiński tradycyjny 2,1x. Hiszpański 1,15x. Ekonomia tokenów treści wielojęzycznych zaskoczyła mnie, ponieważ nie rozumiałem, jak działają tokenizery.¹

TL;DR

Tokenizacja przekształca czytelny dla człowieka tekst w tokeny numeryczne przetwarzane przez modele językowe. Po przetłumaczeniu 27 wpisów blogowych na 6 języków dysponuję rzeczywistymi danymi kosztowymi: pisma niełacińskie zużywają 2-3x więcej tokenów na jednostkę semantyczną niż angielski. Interaktywny wizualizator poniżej pozwala wkleić tekst w dowolnym języku i zobaczyć rozkład tokenów. Zrozumienie tokenizacji pomogło mi precyzyjnie zaplanować budżet mojego potoku tłumaczeń, zoptymalizować prompty w celu redukcji kosztów o 35% oraz zdiagnozować problem z formatowaniem, w którym koreańskie tłumaczenia traciły strukturę markdown, ponieważ tokenizer dzielił znaczniki przypisów na granicach tokenów.

Moje dane o kosztach tokenów i18n

Przetłumaczyłem 27 wpisów blogowych na 6 języków przy użyciu Claude. Jakość tłumaczenia wymagała modeli klasy Opus (nigdy tańszych modeli — lekcja, którą wyniosłem, gdy Haiku produkował tłumaczenia brzmiące jak wynik maszynowy). Zużycie tokenów w poszczególnych językach mnie zaskoczyło:

Języki z pismem łacińskim (hiszpański, niemiecki, francuski) pozostały w zakresie 20% od angielskiego. Języki CJK i Hangul skoczyły 2-3x. Różnica kosztowa kumuluje się przy 27 wpisach × 6 języków = 162 tłumaczeniach.²

Dlaczego ta różnica istnieje

Większość tokenizerów (BPE, używane zarówno przez Claude, jak i GPT-4) jest trenowana głównie na tekście angielskim. Angielskie słowa mają zoptymalizowane reprezentacje tokenowe, ponieważ dane treningowe zawierają więcej angielskiego niż jakiegokolwiek innego języka. Popularne angielskie słowa („the”, „and”, „is”) mapują się na pojedyncze tokeny. Koreańskie bloki sylabiczne, japońskie kanji i znaki chińskie często dzielą się na 2-3 tokeny na poziomie bajtów, ponieważ tokenizer napotkał je rzadziej podczas treningu.³

Efekt jest systematyczny, nie losowy. Każde tłumaczenie na koreański kosztuje około 2,8x więcej niż odpowiednik angielski. Mogę precyzyjnie planować budżet, ponieważ mnożnik jest spójny.

Błąd tokenizacji

Podczas mojej pierwszej partii tłumaczeń na koreański przetłumaczone wpisy utraciły całe formatowanie markdown: odniesienia do przypisów ([^1]) zniknęły, bloki kodu straciły znaczniki języka, a znaczniki nagłówków (##) zlały się z tekstem głównym.

Diagnoza zajęła godzinę. Przyczyna źródłowa: mój prompt tłumaczeniowy mówił „Przetłumacz ten wpis blogowy na koreański” bez określenia zachowania formatowania. Tokenizer dzielił składnię markdown na granicach tokenów inaczej w kontekście koreańskim niż angielskim. Model potraktował [^1] jako treść do tłumaczenia, a nie znacznik strukturalny.

Rozwiązanie: dodałem jawne ograniczenia do mojego promptu tłumaczeniowego:

Preserve all markdown formatting exactly:
- Keep [^N] footnote references unchanged
- Keep ``` code fences with language tags unchanged
- Keep ## heading markers unchanged
- Keep **bold** and *italic* markers unchanged

Każde ograniczenie eliminowało jeden tryb awarii. Lista ograniczeń stała się dłuższa niż sama instrukcja tłumaczenia — wzorzec, który opisuję w moim frameworku inżynierii promptów OODA.⁴

Czym są tokeny

Od znaków do tokenów

Naiwne podejście do przetwarzania tekstu traktowałoby każdy znak jako jednostkę wejściową. „Hello world” staje się 11 znakami. Przetwarzanie na poziomie znaków rejestruje każdy szczegół, ale produkuje ekstremalnie długie sekwencje: dokument o 1000 słów to około 5000 znaków.⁵

Przetwarzanie na poziomie słów redukuje długość sekwencji, ale zawodzi na nieznanych słowach. Słownik na poziomie słów o 50 000 wpisach nie przetworzy „unfathomability”, chyba że dokładnie to słowo pojawiło się w danych treningowych.

Tokenizacja na podwyrazach znajduje złoty środek. Popularne słowa („the”, „and”) pozostają pojedynczymi tokenami. Rzadkie słowa dzielą się na fragmenty podwyrazowe. „Unfathomability” dzieli się na [“un”, “fath”, “om”, “ability”], gdzie każdy fragment pojawia się wystarczająco często, aby mieć wytrenowaną reprezentację.

Byte-Pair Encoding (BPE)

BPE, używane przez Claude i GPT-4, zaczyna od pojedynczych bajtów i iteracyjnie łączy najczęstsze sąsiadujące pary:⁶

1. Zacznij od pojedynczych znaków: [l, o, w, e, r]
2. Najczęstsza para: (l, o) → scalenie do [lo, w, e, r]
3. Najczęstsza para: (e, r) → scalenie do [lo, w, er]
4. Najczęstsza para: (lo, w) → scalenie do [low, er]
5. Najczęstsza para: (low, er) → scalenie do [lower]

Końcowy słownik zawiera wszystkie oryginalne bajty plus każdy scalony token, zazwyczaj 50 000-100 000 wpisów. Angielskie słowa dominują wśród scalonych tokenów, ponieważ angielski dominuje w danych treningowych.

Jak zoptymalizowałem swoje prompty

Po odkryciu różnicy w kosztach tokenów zoptymalizowałem swój potok tłumaczeń, redukując koszty o 35%:

Optymalizacja 1: Grupowanie według rodziny językowej

Języki z pismem łacińskim (hiszpański, francuski, niemiecki) mają podobieństwa strukturalne. Grupuję prompt tłumaczeniowy, aby generować wszystkie trzy w jednym wywołaniu API, gdy wpis źródłowy jest wystarczająco krótki, by zmieścić się w oknie kontekstowym wraz ze wszystkimi trzema wynikami. Współdzielony kontekst (źródło angielskie) jest opłacany raz zamiast trzech razy.⁷

Optymalizacja 2: Deduplikacja ograniczeń

Mój oryginalny prompt tłumaczeniowy powtarzał ograniczenia dla każdego języka. Zoptymalizowana wersja definiuje ograniczenia raz i stosuje je do wszystkich wyników:

# Constraints (apply to ALL translations below):
- Preserve markdown structure, footnotes, code blocks
- Keep proper nouns in English
- Adapt idioms, don't transliterate

# Translate the following post into: Spanish, French, German

Sekcja ograniczeń zużywa tokeny raz. Alternatywa (powtarzanie ograniczeń per język) zużywa 3x więcej.

Optymalizacja 3: Zwięzłe instrukcje

Mój oryginalny prompt używał 340 tokenów instrukcji. Po optymalizacji: 180 tokenów. Redukcja o 47% kumuluje się przy 162 tłumaczeniach.

Języki CJK odnoszą mniejsze korzyści z optymalizacji promptów, ponieważ tokeny wyjściowe (samo tłumaczenie) dominują w kosztach. Wynik jest z natury dłuższy pod względem tokenów, niezależnie od tego, jak zwięzłe są instrukcje.⁸

Zastosowania praktyczne

Szacowanie kosztów

Przybliżona heurystyka dla tekstu angielskiego: 1 token to około 0,75 słowa, czyli około 4 znaki. Dokument o 1000 słów zużywa około 1333 tokenów. Dla treści nieanglojęzycznych należy zastosować mnożnik językowy z mojej tabeli powyżej.⁹

Tokenizacja kodu

Kod tokenizuje się inaczej niż proza. Popularne słowa kluczowe (def, return, if) mapują się na pojedyncze tokeny. Nazwy zmiennych dzielą się w zależności od częstotliwości:

# "def calculate_total(items):" splits approximately as:
# ["def", " calculate", "_total", "(", "items", "):", ]

Spójne konwencje nazewnictwa redukują liczbę tokenów. Moja infrastruktura hooków używa konwencji verb-noun.sh (git-safety-guardian, recursion-guard, blog-quality-gate). Spójny wzorzec pomaga tokenizerowi przewidywać i efektywnie scalać popularne podwyrazy.

Debugowanie nieoczekiwanego zachowania

Kiedy model generuje nieoczekiwany wynik, tokenizacja może wyjaśnić przyczynę. Mój koreański błąd formatowania wystąpił, ponieważ tokenizer dzielił [^1] inaczej w kontekście koreańskim niż angielskim. Zrozumienie wzorca podziału doprowadziło bezpośrednio do rozwiązania (jawne ograniczenia zachowania formatowania).

Kluczowe wnioski

Dla inżynierów korzystających z API LLM: - Należy zmierzyć koszty tokenów per język przed podjęciem zobowiązania do wsparcia wielojęzycznego; języki CJK kosztują 2-3x więcej na jednostkę semantyczną niż angielski - Optymalizacja instrukcji promptów (zwięzłe sformułowania, zdeduplikowane ograniczenia) daje 30-50% redukcji kosztów w potokach tłumaczeniowych o dużym wolumenie - Należy przetestować tokenizację terminów domenowych i składni markdown przed wdrożeniem produkcyjnym; nieoczekiwane podziały powodują błędy formatowania

Dla menedżerów produktu planujących budżet funkcji AI: - Wsparcie języków nieanglojęzycznych kosztuje 1,5-3x więcej za wywołanie API niż angielski; budżet wielojęzycznych funkcji AI powinien uwzględniać mnożnik językowy, a nie zryczałtowaną stawkę per język - Limity okna kontekstowego dotykają języków CJK nieproporcjonalnie; okno 200K tokenów mieści o 40% mniej treści koreańskiej niż angielskiej

Źródła