Токенизация в LLM: сравнение эффективности BPE и WordPiece

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

В сравнении BPE и WordPiece часто ищут универсального победителя. Такого вывода сами алгоритмы не дают: они по-разному строят словарь подслов, а результат зависит от корпуса, размера словаря, языка и конкретной реализации. Поэтому для разработчика важнее понять, что именно объединяет каждый метод и как это отражается на прикладной задаче. Токенизация в LLM — это часть архитектуры обработки текста, а оценивать её эффективность следует в контексте всей модели.

Как BPE и WordPiece собирают словарь

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

Различие начинается с критерия объединения. BPE (Byte Pair Encoding) на обучении ищет наиболее частую соседнюю пару токенов и объединяет её в новый элемент словаря. Затем процесс повторяется. Если в корпусе часто встречается одна и та же комбинация символов или подслов, у неё появляется шанс стать отдельным токеном. Критерий здесь — абсолютная частота пары.

WordPiece тоже наращивает словарь, объединяя части слов, однако при выборе пары использует оценку, учитывающую частоты её компонентов. В упрощённой записи score можно представить так:

score(AB) = freq(AB) / (freq(A) * freq(B))

Здесь freq(AB) — частота совместного появления пары, а freq(A) и freq(B) — частоты отдельных элементов. Такой показатель помогает оценить, насколько характерно совместное появление пары относительно распространённости её частей. Следовательно, WordPiece ориентируется не только на то, сколько раз встретилась комбинация, но и на её соотношение с частотами компонентов.

Важно читать формулу WordPiece именно как упрощённое объяснение критерия, а не как полное описание реализации. Подробности обучения имеют значение: они определяют, какие именно пары попадут в словарь и в каком порядке. При этом и для BPE итоговый словарь зависит от обучающего корпуса и настроек токенизатора. Один и тот же алгоритм, применённый к разным данным, может дать разное разбиение.

BPE спрашивает, какая пара встречается чаще. WordPiece оценивает, насколько совместное появление пары показательно относительно частот её частей.

Что меняет байтовый уровень

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

BBPE используется в современных генеративных моделях, включая GPT-2, Llama и DeepSeek. Это не означает, что все эти модели имеют одинаковый словарь или идентичный процесс токенизации. Общее здесь — байтовый вариант подхода BPE, а конкретное представление текста и состав словаря определяются моделью.

У WordPiece в семействе BERT есть заметный маркер: продолжения слова, которые не стоят в его начале, могут отмечаться префиксом ##. Например, если слово разбито на несколько частей, маркер помогает отличить продолжение от начала нового слова. Это правило относится к представлению токенов в соответствующих токенизаторах; его нельзя автоматически переносить на все варианты BPE. В разных BPE-токенизаторах для обозначения границ и пробелов применяются свои соглашения, например префиксы пробела или специальные маркеры.

Для пользователя эти детали обычно скрыты интерфейсом. Для разработчика они важны при подготовке данных, подсчёте длины запросов и сопоставлении токенизатора с моделью. Если модель ожидает конкретный формат входа, подмена токенизатора меняет не просто способ нарезки текста, но и соответствие между токенами и теми представлениями, на которых модель обучалась.

Русский язык, длина входа и стоимость обработки

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

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

Для оценки практической эффективности полезно смотреть на несколько связанных параметров:

• Длина представления. Один и тот же русский текст может превращаться в разное число токенов в зависимости от словаря и правил разбиения. Сравнивать имеет смысл на репрезентативном наборе своих запросов, а не на нескольких вручную выбранных фразах.
• Состав входных данных. Разговорный текст, техническая документация, код, продуктовые названия и пользовательские опечатки дают разные профили токенов. Среднее по одному корпусу может скрыть проблемы в другом.
• Лимит контекста. Модель принимает последовательность токенов, а не символов. Если токенизатор дробит нужные документы на более длинные последовательности, в тот же лимит контекста помещается меньше исходного текста.
• Оплата API. Если тариф привязан к числу входных и выходных токенов, их количество влияет на стоимость запроса. Экономию нельзя оценить заранее только по названию алгоритма: требуется измерить токенизацию реальных данных и учесть условия конкретного сервиса.
• Скорость обработки. Число токенов может влиять на вычислительную нагрузку, но скорость генерации зависит также от модели, оборудования, библиотек и реализации. Сам по себе BPE или WordPiece не задаёт универсального преимущества по скорости инференса.

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

Для бюджета API важен измеренный расход токенов на собственных запросах. Название алгоритма само по себе цену не предсказывает.

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

Словарь и качество ответов модели

Токенизатор не понимает смысл слова в человеческом смысле. Он переводит строку в последовательность идентификаторов, каждому из которых модель сопоставляет обученное представление. Уже модель обрабатывает эту последовательность с учётом контекста. Поэтому способ разбиения влияет на формат входа, но сам по себе не определяет, будет ли ответ точным, полезным или связным.

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

Однако подсловное разбиение также имеет пределы. Если важное для задачи название распадается на непривычные части, модель всё ещё может обработать строку, но качество зависит от её обучающих данных и контекста. По одному числу фрагментов нельзя заключить, что конкретное слово стало для модели непонятным; столь же неверно считать, что один токен гарантирует правильную работу с термином. Для оценки предметных задач нужны тесты на тех данных, с которыми продукт будет работать.

Размер словаря и качество ответов связаны через обучение, а не через простое правило «больше — лучше». Изменение токенизатора без соответствующего обучения модели не превращает готовую LLM в более эффективную систему: её параметры сформированы под конкретное кодирование текста. Поэтому при выборе готового API обычно сравнивают модели целиком, а при обучении собственной модели рассматривают токенизатор как часть совместного проектирования корпуса, словаря и архитектуры.

Почему WordPiece труднее воспроизвести

Для WordPiece есть дополнительный нюанс, связанный с воспроизводимостью. Google не публиковал в открытом доступе исходный код алгоритма обучения WordPiece, хотя реализация разбиения доступна. Это различие важно: токенизатор, который применяет уже готовый словарь к тексту, и процедура, которая этот словарь обучает, — разные части системы.

Если исходная процедура обучения недоступна, исследователи и разработчики могут опираться на описания алгоритма и доступные реализации, но не всегда могут воспроизвести все детали исходного обучения. Это усложняет точное сравнение с другой системой, когда неизвестны или различаются корпус, правила предобработки и параметры построения словаря. Само отсутствие открытого кода не доказывает ни недостаток качества WordPiece, ни превосходство конкурирующего метода. Оно ограничивает прозрачность воспроизведения.

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

Где применяются методы и как выбирать

В моделях семейства BERT, включая DistilBERT и MobileBERT, используется WordPiece. Большинство современных авторегрессионных генеративных моделей опирается на варианты BPE. Авторегрессионная модель формирует последовательность по шагам, опираясь на уже выданные токены; именно такой режим широко применяется в генеративных чат-моделях. Эти примеры показывают распространённость подходов, но не образуют рейтинга качества.

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

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

При интерпретации результата следует удерживать границы сравнения. Меньшее число токенов может быть полезным для контекста или тарификации, но оно не доказывает лучшую генерацию. Более длинная последовательность может потребовать больше вычислений, однако измеренная скорость зависит от программного стека и оборудования. А высокая частота фрагмента в корпусе обучения ещё не гарантирует, что модель качественно ответит на вопрос о редком термине.

В итоге BPE и WordPiece решают близкую задачу разными критериями построения словаря. BPE ориентируется на частоту объединяемой пары; WordPiece учитывает её частоту относительно частот отдельных компонентов. В современных генеративных системах широко представлены варианты BPE, тогда как WordPiece закрепился в моделях семейства BERT. Для разработчика продукта главный вопрос состоит не в том, какой алгоритм звучит эффективнее, а в том, как конкретная модель токенизирует нужные данные и что это меняет в качестве, контексте, скорости и расходах.

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