Почему токенизатор неправильно разбивает слова

Заглавие этого материала отчасти иллюстрирует то, как текст воспринимает большая языковая модель: в виде фрагментов слов, поделенных по принципам, далеким от грамматики и норм русского языка.

Именно эта специфика порождает целый ряд ограничений, которые пользователи ошибочно приписывают «недоразвитости» искусственного интеллекта (в особенности компактных локальных LLM): неспособность корректно подсчитать символы в слове, сбои в базовой арифметике, искажение редких имен собственных и двукратную переплату за русскоязычные промпты при одинаковом смысловом объеме.

Отсюда же берут начало и менее очевидные феномены: от невероятной эффективности инструкций формата «рассуждай пошагово» до внезапной деградации ответов из-за единственного пробела на конце запроса.

Корень всех этих явлений кроется в самом первом звене пайплайна — модуле, который обучается совершенно отдельно от основной нейросети и которому в обучающих материалах обычно уделяют от силы пару строк. Разберем механику его работы детально.

Нейросети не воспринимают буквы напрямую

Начнем с базового, но фундаментального принципа. Когда пользователь отправляет сообщение «привет», архитектура трансформера не видит этих букв. На вход поступает обычное целое число — например, 15 043.

В архитектуре модели находится матрица эмбеддингов — масштабный массив, где за каждым элементом словаря закреплена отдельная строка-вектор. Токен представляет собой лишь индекс нужной строки. Входящий текст транслируется в цепочку чисел, каждое из которых извлекает соответствующий вектор, после чего все вычисления производятся исключительно в векторном пространстве.

Токенизатор служит мостом между строками символов и миром чисел. Его функционал предельно утилитарен: у него есть зафиксированный словарь фрагментов и набор правил для разбивки текста. Никакой семантической обработки он не выполняет.

Хорошей метафорой здесь служит набор магнитов с надписями на холодильнике: запас элементов строго ограничен, причем на одних нанесены целые слова, на других — морфемы или отдельные буквы. Ваша цель — составить заданное предложение, израсходовав минимальное число магнитов. При этом сам набор заготовок сформирован заранее третьей стороной.

В этом и заключается ключевое ограничение: размер словаря фиксирован (как правило, от 32 000 до 256 000 записей). При этом в данный лимит необходимо уложить лексику всех существующих языков, языки программирования, верстку, спецсимволы, эмодзи и научные обозначения.

Первая интуитивная идея — опуститься на посимвольный уровень. Это гарантирует стопроцентное покрытие при крошечном словаре. Однако длина входных последовательностей многократно возрастает: пара абзацев превращается в тысячи шагов, а вычислительная сложность механизма внимания (self-attention) растет квадратично относительно длины контекста.

Вторая крайность — кодировать слова целиком. Последовательности становятся предельно компактными, но любое незнакомое слово неминуемо превратится в метку <unk> (unknown). Сеть не сможет ни понять его, ни воспроизвести. Для синтетических языков вроде русского с их богатейшей парадигмой словоизменения такой подход фатален.

Оптимальный путь лежит посередине — оперировать подсловами (subwords). Остается лишь понять, по какому принципу определять их границы.

BPE: классический алгоритм сжатия на службе современной лингвистики

Метод Byte Pair Encoding (BPE) был предложен Филипом Гейджем еще в 1994 году для компрессии файлов — об архитектурах вроде GPT в то время никто даже не помышлял.

Логика работы BPE предельно проста:

1. разбить исходный массив текстов на базовые символы;

2. вычислить наиболее часто встречающуюся пару смежных элементов;

3. объединить их в единую сущность и занести в словарь;

4. циклически повторять процедуру до достижения целевого объема словаря.

В 2015 году концепцию адаптировали для нейросетевого перевода, и сегодня она лежит в основе подавляющего большинства LLM. По сути, тренировка токенизатора — это процедура архивации гигантского массива текстов.

Наглядный пример работы

Разберем процесс на синтетическом примере из четырех слов с указанной частотностью:

низ × 4

низкий × 3

низко × 2

нить × 3

На стартовом этапе текст дробится на символы:

н и з × 4

н и з к и й × 3

н и з к о × 2

н и т ь × 3

Подсчитываем комбинации соседних знаков. Биграмма «н + и» встречается во всех позициях: 4 + 3 + 2 + 3 = 12 раз, что превышает любые другие варианты. Производим слияние:

[ни] з × 4

[ни] з к и й × 3

[ни] з к о × 2

[ни] т ь × 3

На следующей итерации лидерство переходит к паре «ни + з»: 4 + 3 + 2 = 9 повторений. Объединяем:

[низ] × 4

[низ] к и й × 3

[низ] к о × 2

[ни] т ь × 3

Результат совпадает с морфемным членением: выделился корень «низ». Однако следующей по популярности связкой оказывается «низ + к» (3 + 2 = 5 вхождений). Выполняем новое слияние:

[низ] × 4

[низк] и й × 3

[низк] о × 2

[ни] т ь × 3

Обратите внимание на этот шаг.

BPE механически объединил корень «низ» с суффиксом «-к-», сформировав неделимый блок «низк». С академической точки зрения это абсурдно, но для математической оптимизации полностью оправдано: частотность высокая, выигрыш в длине очевиден.

В реальных системах число таких слияний достигает сотен тысяч. Итогом обучения становятся два ключевых файла, доступных в репозиториях open-source моделей: vocab.json (список токенов с их числовыми ID) и merges.txt (хронологический реестр объединений). Очередность здесь критична, поскольку при обработке текста правила применяются строго в том порядке, в каком они формировались.

ИИ‑роутер — доступ к 300+ моделям из одной панели

Подключите OpenAI‑совместимый шлюз по единому API‑ключу. Настраивайте сквозную аналитику, отслеживайте лимиты и квотируйте ресурсы.

Запустить ИИ‑роутер →

Процесс токенизации инференса

Важно подчеркнуть: этап сбора статистики и построения правил происходит лишь единожды при компиляции словаря. В процессе диалога с моделью динамического пересчета частотностей нет.

Входящий запрос дробится на элементарные знаки, после чего к ним последовательно применяются зафиксированные правила из merges.txt.

По этой причине неизвестные слова склеиваются из случайных доступных осколков. Если передать нашему учебному токенизатору слово «низкоуровневый», он выделит токен «низк», а оставшуюся часть превратит в россыпь отдельных символов, поскольку правил для их сборки в словаре нет.

В промышленных моделях наблюдается ровно то же: специализированный сленг, редкие фамилии, технические коды и артикулы дробятся на бессмысленный для человека мозаичный набор подстрок.

Суть в том, что алгоритм руководствуется чистой статистикой встречаемости, а не языковой логикой. Он не оперирует понятиями префиксов или суффиксов, реагируя только на математическую вероятность соседства байтов.

Английскому языку в этой схеме повезло благодаря типологии: компактные и универсальные аффиксы позволяют BPE делить слова практически по канонам грамматики (например, walking превращается в walk + ing). Это удачное следствие структуры языка, а не заслуга алгоритма.

Русская морфология куда сложнее: изобилие флексий и словоформ размывает частотность конкретных сочетаний, а доля кириллического сегмента в обучающих датасетах обычно не превышает нескольких процентов.

В результате границы разбивки оказываются непредсказуемыми: слово «переписал» способно разделиться на «перепис» и «ал», тогда как форма «переписывать» сохранится целиком. Интуитивной лингвистической логики в этом искать не стоит.

Байтовое представление вместо символьного

Актуальные решения (например, Byte-level BPE) строятся на базе байтов UTF-8. Это исключает возникновение токенов <unk> для любых редких символов или эмодзи: базовый алфавит состоит из 256 возможных байтовых значений, из которых конструируется любой контент.

Однако специфика кодировки UTF-8 такова: латиница кодируется 1 байтом, кириллица требует 2 байта, иероглифика — 3, а эмодзи — 4. Русскоязычные слова изначально имеют вдвое большую длину в байтах, а с учетом доминирования английского корпуса при обучении слияний на кириллицу выделяется меньше правил. Как итог: эквивалентный по объему и смыслу текст на русском расходует в 2–3 раза больше токенов.

Это приводит к ощутимым практическим последствиям:

• стоимость работы через API возрастает кратно;

• эффективная вместимость контекстного окна снижается в 2–3 раза относительно спецификаций;

• лимит max_tokens исчерпывается заметно быстрее;

• скорость генерации (время до полного ответа) пропорционально падает.

Для редких языков Азии или Африки этот дисбаланс еще критичнее и может достигать десятикратных масштабов. Формируется архитектурный «лингвистический налог»: чем ниже доля языка в глобальной сети, тем выше накладные расходы на обработку каждого предложения.

Токен как элементарный шаг рассуждения

Генерация происходит авторегрессионно — строго по одному токену за шаг. На каждую итерацию выделяется строго определенное число матричных перемножений в рамках прямого прохода (forward pass).

Вычислительный бюджет жестко детерминирован числом генерируемых токенов. Модель лишена возможности «сделать паузу» и выполнить больше циклов над сложным фрагментом без генерации токена. Единственный способ нарастить объем вычислений — сформировать более длинную последовательность.

Это фундаментальное свойство объясняет многие практические приемы промпт-инжиниринга:

Почему эффективен Chain-of-Thought («думай шаг за шагом»)? Заставляя модель выписывать промежуточные выводы, вы кратно увеличиваете доступный ей вычислительный ресурс: каждый сгенерированный токен рассуждения дает дополнительный проход сквозь слои трансформера.

Почему требование «ответь кратко» снижает качество решения? Ограничение ответа одним словом сокращает весь вычислительный бюджет до единственного прямого прохода. В отличие от человека, обладающего скрытым внутренним диалогом, модель способна «думать» исключительно через токены, выводимые в контекст.

Почему модели с расширенным рассуждением (reasoning) дороже в эксплуатации? Дело не в фундаментальной смене архитектуры, а в том, что сеть целенаправленно обучена выстраивать масштабный внутренний черновик перед формулировкой финального ответа.

Зачем в промптах иногда используют филлерные токены? Исследования подтверждают: принудительная генерация цепочки пустых символов перед ответом может повышать точность решения. Это работает как вычислительная пауза, дающая сети возможность произвести дополнительные матричные операции.

Почему сеть не способна исправить собственную ошибку на лету? Сгенерированный токен немедленно включается во входной контекст следующего шага. Если начало формулировки оказалось ошибочным, все последующие токены будут вынужденно подстраиваться под уже сформированный текст.

Археология токенизатора: следы обучающих выборок

Словарь токенизатора хранит в себе отпечаток данных, на которых он строился, подобно геологическому срезу.

Пример первый: глитч-токены. В начале 2023 года исследователи выявили в словарях GPT-2 и GPT-3 аномальные токены вроде SolidGoldMagikarp или petertodd. Попытка заставить сеть повторить их приводила к резким сбоям или галлюцинациям.

Причина оказалась в рассинхронизации данных: токенизатор обучался на неочищенном массиве (где часто встречались юзернеймы с Reddit), а сама LLM проходила обучение на отфильтрованном корпусе, лишенном этих строк. В результате векторные эмбеддинги таких токенов остались в исходном псевдослучайном состоянии. При столкновении с ними сеть попадает в неисследованную область скрытого пространства с непредсказуемым поведением.

Пример второй: спам-токены в GPT-4o. После релиза GPT-4o с расширенным словарем на 200 000 позиций исследователи из Принстона проанализировали наиболее длинные китайские токены. Более 90% из топ-100 оказались спам-паттернами с сомнительных ресурсов, и лишь единицы соответствовали живой разговорной речи.

Это наглядно показало, что этап фильтрации данных токенизатора был тщательно проведен для английского сегмента, но пропущен для китайского, зафиксировав спам-конструкции на уровне словаря.

Главный вывод: токенизатор — автономный компонент со своей историей данных, которая может существенно отличаться от обучающей выборки самой нейросети.

Неочевидные артефакты поведения моделей

Понимание работы токенизатора моментально проясняет множество распространенных вопросов:

Необъективность метрики «токенов в секунду». Популярный показатель в бенчмарках вводит в заблуждение: у моделей с крупным словарем каждый токен содержит больше символов. 50 токенов/сек в словаре на 128k дадут ощутимо больший объем текста, чем те же 50 токенов/сек при 32k. Объективное сравнение возможно только в символах или словах.

Префиксные пробелы. В BPE пробел обычно привязывается к началу следующего слова: «привет» и «_привет» — это два принципиально разных токена. Если запрос завершается висячим пробелом, распределение вероятностей следующего токена искажается, что ухудшает итоговый ответ.

Сбои в вычислениях. Когда число 1234 дробится на 123 и 4, а 5678 — на 567 и 8, сеть оперирует абстрактными индексами без понимания позиционных разрядов. По этой причине современные архитектуры принудительно сегментируют числа по отдельным цифрам или фиксированным группам.

Проблема подсчета букв (кейс со «strawberry»). Для модели входящее слово — это ID токена, а не массив букв. Требовать от нее посчитать конкретный символ — все равно что просить человека назвать значение байта в сжатом изображении: данные присутствуют на низком уровне, но скрыты за абстракцией.

Стихосложение и фонетика. Лишенная фонетического и побуквенного восприятия, модель рифмует исключительно на основе статистического паттерна совместной встречаемости слов на концах строк, что периодически приводит к срыву рифмы при сохранении ритма.

Токенизация программного кода. Токенизаторы с акцентом на код включают отдельные токены для серий пробелов (по 4, 8, 12 символов отступа). Без такой оптимизации отступы в Python расходуют по токену на пробел, существенно удорожая контекст.

Почему не существует идеального решения

Казалось бы, логично внедрить классический морфологический парсер. Однако на практике возникает ряд непреодолимых препятствий:

• морфология строго привязана к конкретному языку, в то время как модель обязана универсально обрабатывать код, разметку и любые символы;

• возникает контекстная омонимия («печь» как глагол или существительное), тогда как токенизация должна оставаться строго детерминированной и обратимой;

• морфологический подход уступает по коэффициенту сжатия, увеличивая длину последовательностей и удорожая вычисления.

Существует и радикальная альтернатива — безтокенизаторные архитектуры (byte-level models). Они устраняют проблему глитч-токенов, языкового неравенства и морфемных швов, предоставляя сети прямой доступ к отдельным символам. Расплатой за это становится резкий рост длины входных данных и колоссальные вычислительные затраты. Поэтому в промышленной разработке BPE пока остается безальтернативным стандартом.

 

Источник