Tokenization

Суть

Модель не видит «буквы» или «слова» напрямую — она видит токены из фиксированного словаря. Каждый шаг генерации — это выбор следующего токена из распределения вероятностей по всему словарю (см. Sampling Parameters).

Зачем это нужно

Два наивных подхода плохи:

• По символам — последовательности слишком длинные, моделям тяжело, и в один символ не заложить смысл.
• По словам — словарь взрывается (слов слишком много), а распределение вероятностей ограничено размером словаря.

BPE — компромисс: токены получаются осмысленными (часто это слова, приставки, суффиксы, корни) и при этом словарь компактный.

Как работает

• Старт с символов; алгоритм берёт пары (2 символа), затем тройки и т.д., каждый раз добавляя в словарь самую частотную комбинацию из корпуса.
• Процесс идёт, пока не достигнут целевой размер словаря (в материале — пример 100 000).
• Один токен ≠ одно слово: короткое предложение может стать 3 токенами, длинное слово — несколькими.
• Размер словаря напрямую влияет на то, из скольких вариантов модель выбирает следующий токен.
• Алгоритмы: BPE (GPT, Claude, Llama), WordPiece (BERT), SentencePiece (современный вариант). У каждой модели свой токенизатор и словарь — они идут в комплекте и не взаимозаменяемы (словарь обычно в tokenizer.json).
• Спец-токены (пример из BERT): [CLS] (начало), [SEP] (разделитель), [MASK] (маска), [PAD] (выравнивание), [UNK] (неизвестное).
• Размеры словарей: BERT-base 30 522, GPT-2 50 257, GPT-3/4 ~100 000, Llama 3 128 000.
• Русский «дороже» по токенам: BPE строит словарь из самых частотных сегментов преимущественно англоязычного корпуса → английские слова часто = 1 токен, а кириллица дробится на более мелкие куски. Tip: технические/system-инструкции иногда выгоднее держать на английском (экономия ~30% токенов), а ответ просить на русском. Но это не догма — качество и требования к ответу важнее экономии; доменно-важный русский контент не переводят насильно ради токенов.
• Цифры fertility (кириллица, прокси): по исследованию токенизации для украинского/кириллицы — кириллический текст даёт 1.88 ток/слово (Llama 3.1) … 3.32–3.45 (GPT-3.5/4, Claude 3); в узких доменах (законы/наука) до **4.4**; словари ≥100k токенов устойчивее. Это прокси для RU (данные на украинском/кириллице), не прямой RU-бенчмарк размера чанка.
• Проверка стоимости на практике: расход токенов проверяют через tokenizer / usage в ответе API / budget-трекер; локальная оценка через tiktoken и аналоги — отдельная hands-on задача (см. открытый вопрос).

Пример

"мама мыла раму"  →  ["мама", " мыла", " раму"]   # 3 токена
"токенизация"     →  ["токен", "из", "ация"]       # дробится на части

Как посчитать токены заранее

Ключевое правило: токенизатор должен быть тот же, что у модели. Оценки вида «символы делить на четыре» дают ошибку в разы на русском тексте, коде и разметке, а токенизаторы разных семейств моделей несовместимы между собой — один и тот же текст даёт разное число токенов.

Практически это значит: для open-weight моделей берут токенизатор прямо из репозитория модели (библиотека tokenizers / transformers — он лежит рядом с весами); для проприетарных используют то, что даёт провайдер — отдельную библиотеку токенизации (tiktoken для моделей OpenAI) или API подсчёта токенов, если библиотеки нет. Для смешанного парка проще считать через провайдерский API, чем поддерживать зоопарк локальных токенизаторов.

Зачем это нужно до запроса, а не после: проверить, что промпт влезает в окно (Context Window), оценить стоимость до отправки и поставить лимит на вход (Agent CostControl) — все три задачи требуют числа заранее, потому что после ответа платить уже поздно.

Связано с

• Embeddings — каждый токен дальше превращается в вектор
• Transformer — токены-векторы подаются в архитектуру
• Context Window — окно меряется именно в токенах, биллинг тоже