Токенизация — это преобразование текста, кода или другой последовательности символов в токены, то есть минимальные элементы, с которыми модель реально работает. Для LLM это базовый этап перед эмбеддингами и генерацией: модель видит не «слова», а идентификаторы токенов. Метод нужен почти всегда, когда вы считаете длину контекста, режете документы для RAG или оцениваете стоимость API. Но токенизация не равна пониманию языка: она не определяет смысл, по-разному работает в разных моделях и плохо подходит как единственный способ обработки там, где критично сохранить точные символы, позиции, форматирование или доменные структуры вроде таблиц, артикулов и исходного кода.
Простыми словами
Если упростить, токенизация превращает человеческий текст в детали конструктора, из которых модель собирает вход. Иногда токен совпадает со словом, но в современных языковых моделях чаще это часть слова, знак пунктуации, пробел, число или служебный символ. Поэтому русское слово вроде «непредсказуемость» может распасться на несколько токенов, а короткая строка с датой, эмодзи, URL или фрагментом кода — занять неожиданно много места в контексте.
Практический вывод простой: длину промпта, размер чанка и бюджет контекста нужно считать не по символам и не по словам, а по токенам именно того токенизатора, который использует целевая модель. Один и тот же абзац в разных моделях может занимать разное число токенов, потому что у них разные словари, правила нормализации и способы разбиения текста.
Как это работает
Современный токенизатор обычно делает несколько шагов. Сначала он нормализует текст: приводит Unicode к ожидаемой форме, иногда меняет пробелы, регистр или специальные символы. Затем применяет правила предварительного разбиения: отделяет знаки пунктуации, числа, пробельные сегменты или байтовые последовательности. После этого вступает в работу модель токенизации — например, BPE, WordPiece или Unigram в духе SentencePiece. Она выбирает из словаря такие фрагменты, чтобы покрыть входную строку последовательностью токенов.
| Этап | Что происходит | Что важно на практике |
|---|---|---|
| Нормализация | Текст приводится к ожидаемому виду | Даже визуально одинаковие строки могут токенизироваться по-разному из-за Unicode и пробелов |
| Предварительное разбиение | Выделяются базовые сегменты: слова, знаки, числа, байты | Пунктуация, спецсимволы и смешение кириллицы с латиницей часто меняют длину в токенах |
| Выбор токенов из словаря | Строка покрывается подсловами или байтовыми единицами | Редкие слова, OCR-шум и длинные идентификаторы дробятся сильнее |
| Преобразование в ID | Каждому токену сопоставляется числовой идентификатор | Именно ID получает модель; далее добавляются служебные токены и позиции |
После токенизации элементы превращаются в числа. Уже эти числа подаются в модель, где сопоставляются с эмбеддингами и позициями. Для чатов и некоторых пайплайнов к ним добавляются специальные токены: начало последовательности, конец, разделители ролей, маркеры инструкций. Из-за этого «голый» текст и фактическое число токенов в API не всегда совпадают один к одному: часть бюджета съедает служебная обвязка.
Основные схемы
- Word-level — токеном считается целое слово. Подход прост, но плохо покрывает редкие формы и раздувает словарь.
- Subword — токеном становится часть слова. Это основной компромисс для современных LLM: словарь остается конечным, а редкие слова можно собрать из фрагментов.
- Byte-level — текст разбирается на уровне байтов или близких к ним единиц. Такой вариант устойчивее к незнакомым символам, но иногда делает последовательности длиннее.
Для русского языка это особенно важно из-за богатой морфологии: склонения, приставки, суффиксы и составные формы часто распадаются на несколько подсловных токенов. Поэтому нельзя заранее предположить токенизацию «на глаз», даже если текст кажется коротким.
Зачем нужно
Без токенизации языковая модель не может работать с текстом как с вычислимой последовательностью. Но для практики важнее другое: токены определяют почти все операционные ограничения LLM-системы.
- Контекстное окно. Лимиты модели задаются в токенах, а не в символах. Если вы ошиблись с оценкой, часть контекста будет обрезана.
- Стоимость и задержка. Во многих API учет идет по входным и выходным токенам. Чем точнее вы их считаете, тем лучше прогнозируете расход и время ответа.
- Chunking для RAG. Резать документы нужно по токенам целевой модели, иначе одни чанки будут пустыми по смыслу, а другие не влезут в окно.
- Качество промптов. Служебные инструкции, формат ответа и few-shot примеры тоже занимают токены. Их приходится балансировать с полезным контентом.
- Работа с многоязычными данными. Одинаковый по длине текст на разных языках может занимать разный токен-бюджет.
Именно поэтому токенизация — не «низкоуровневая деталь», а инженерный параметр. От нее зависят нарезка корпуса, кеширование подсказок, стратегия усечения и даже выбор модели для конкретного пайплайна.
Пример
Допустим, вы делаете RAG-помощника по договорам. Пользователь задает вопрос по PDF, а система подмешивает в промпт релевантные фрагменты документа. Частая ошибка — резать файл по фиксированному числу символов. Для человека такой кусок выглядит аккуратно, но для модели он может оказаться слишком длинным или, наоборот, слишком коротким по токенам.
- Выберите целевую модель и используйте ее штатный токенизатор для всех расчетов.
- Посчитайте служебный бюджет: системный промпт, правила ответа, форматирование сообщений и запас под генерацию.
- Оцените доступный размер документа по формуле
бюджет_чанка = окно_модели - служебные_токены - токены_запроса - запас_на_ответ. - Делите текст по токенам, а не по символам, и оставляйте небольшой overlap между соседними чанками.
- Проверяйте, что номера пунктов, суммы, даты и ссылки на статьи не разрываются на границах чанков.
| Плохой подход | Рабочий подход |
|---|---|
| Резать PDF по 3000 символов | Резать по токенам конкретной модели |
| Считать только текст пользователя | Учитывать системные инструкции и запас на ответ |
| Игнорировать OCR-шум и таблицы | Очищать документ и проверять токен-бюджет после нормализации |
| Полагаться на один универсальный чанк для всех моделей | Пересчитывать чанки при смене модели или токенизатора |
Такой подход не делает RAG «умнее» сам по себе, но резко снижает ошибки от переполнения окна, обрезания контекста и нерелевантных фрагментов. На практике это одна из самых дешевых оптимизаций качества.
Заблуждения и ограничения
- «Токен равен слову». Нет. Одно слово может быть одним токеном, несколькими токенами или, реже, частью более крупного шаблона.
- «Если два текста одинаковы по символам, то и по токенам они одинаковы». Нет. Пробелы, переносы, Unicode-формы, смешение языков и спецсимволы заметно влияют на разбиение.
- «Можно считать длину по символам и этого достаточно». Только для очень грубой прикидки. Для продакшн-систем это источник ошибок.
- «Токенизация понимает смысл». Нет. Она кодирует форму входа, а не его интерпретацию.
- «Один удачный чанкинг подойдет всем моделям». Нет. При смене токенизатора токен-бюджет и границы разбиения нужно пересчитывать.
Когда одного уровня токенизации недостаточно
- Точные символьные позиции. Если нужно сохранить офсеты для подсветки, редлайн-сравнения, юридических правок или аннотаций, требуется отдельное выравнивание между символами и токенами.
- Доменные форматы. Для исходного кода, таблиц, логов, химических формул и артикулов часто нужны дополнительные правила сегментации, иначе теряется структура.
- Грязный OCR. Ошибки распознавания, лишние пробелы и мусорные символы раздувают число токенов и ухудшают поиск.
- Секреты и идентификаторы. Хэши, токены доступа, серийные номера и длинные ID лучше обрабатывать осторожно: они могут дробиться неинформативно и засорять контекст.
- Сравнение разных моделей. Сопоставлять «длину промпта» между моделями без учета их токенизаторов некорректно.
Иными словами, токенизация необходима, но недостаточна. Для надежной системы ее нужно сочетать с очисткой данных, структурным парсингом, нормализацией доменных сущностей и контролем качества на реальных примерах.
Частые вопросы
Чем токен отличается от слова?
Слово — это лингвистическая единица для человека. Токен — техническая единица словаря модели. Одно слово может раскладываться на несколько токенов, а знаки пунктуации и пробелы тоже могут учитываться отдельно.
Нужно ли токенизировать текст заранее, если API делает это само?
Для отправки запроса вручную обычно нет: API выполнит токенизацию. Но для планирования чанкинга, оценки стоимости, усечения длинных документов и тестирования промптов считать токены заранее необходимо.
Почему русский текст часто оказывается длиннее в токенах, чем ожидается?
Из-за морфологии, сложных словоформ, смешения кириллицы с латиницей, чисел, сокращений и доменных вставок вроде URL или кода. На глаз это почти не предсказывается.
Можно ли переносить один и тот же чанкинг между моделями?
Только приблизительно. Если вы меняете модель, нужно пересчитать длины и проверить границы чанков новым токенизатором, иначе вы получите искажение контекста или лишние переполнения.
Что важнее для RAG: размер чанка или overlap?
Оба параметра важны. Размер чанка определяется токен-бюджетом модели, а overlap помогает не терять смысл на границах. Начинать нужно с бюджета в токенах, а overlap подбирать по типу документа и качеству ретривера.
Связанные понятия
- Контекстное окно — максимальное число токенов, которое модель может обработать за один проход.
- BPE — алгоритм подсловной токенизации, который строит словарь из частых слияний символов или фрагментов.
- SentencePiece — семейство токенизаторов и инструментов для обучения подсловных моделей, часто применяемое в многоязычных системах.
- Embedding — векторное представление токена или последовательности токенов, которое модель использует для вычислений.
- Chunking — разбиение длинных документов на части, обычно с учетом токен-бюджета и overlap.
- Специальные токены — служебные элементы вроде начала, конца, разделителей ролей и других маркеров формата.