Токенизатор умер, да здравствует байт!
Представьте: вы держите базу клиентов — десятки миллионов имён на кириллице, латинице, иврите, иероглифах. Приходит новый пользователь, называет себя «Yosef Ben-David», а в базе он записан как «Йосеф Бен-Давид» (кириллица) или «יוסף בן-דוד» (иврит). Стандартный поиск по точному совпадению бесполезен. Вы подключаете Elasticsearch с синонимами — он пасует. Пробуете BERT с токенизатором — он ломается на редких именах, ведь их нет в словаре. Выход — байтовый трансформер, который работает напрямую с сырыми UTF-8 байтами. Никаких токенов, никаких словарей, только байты и контрастивное обучение. В этой статье я покажу, как поднять такую модель с нуля, обучить на синтетических данных и получить MRR > 0.9. Код прилагается.
Почему токенизаторы бессильны против имён
Токенизатор — это компромисс. Он режет текст на куски, которые потом нужно поместить в фиксированный словарь. Для имён этот подход проваливается по нескольким причинам:
- Редкие токены. Имя «Абдуррахман» может быть разбито на подслова, но если в данных нет арабских имён — BPE породит неизвестные токены.
- Разные скрипты. Одно имя может быть записано кириллицей, латиницей, ивритом. Токенизатор для латиницы не поймёт иврит. Придётся учить мультиязычный токенизатор — это гигантский словарь (250k+ токенов) и медленная инференция.
- Фонетические варианты. «John» и «Джон» — одно имя, но токенизатор увидит два разных набора токенов. Контрастивное обучение может сблизить их эмбеддинги, но токенизатор всё равно вносит шум из-за неоднозначности разбиения.
Решение — работать на уровне UTF-8 байтов. Каждый символ кодируется 1–4 байтами. Входная последовательность — это просто массив байтов (0–255). Никакой токенизации, никаких словарей. Модель учится напрямую видеть, как устроено имя на уровне сырых данных.
Архитектура: миниатюрный трансформер над байтами
Мы строим энкодер на основе Transformer-encoder, но с одним отличием: входная размерность — 256 (количество возможных байтов). Каждый байт преобразуется в эмбеддинг через простую Embedding(256, d_model). Добавляем позиционное кодирование — я использую синусоидальное, но можно и learnable. Затем 4–6 слоёв self-attention с d_model=256 и num_heads=4. Выход пулинга — среднее по всем позициям (mean pooling), затем проекция в 128-мерный вектор. Нормализация эмбеддингов на сфере — F.normalize(emb, dim=-1).
Почему такая миниатюра? Во-первых, длина имени редко превышает 30 символов (максимум 120 байт для иероглифов). Модель с 4 слоями легко обрабатывает такую длину. Во-вторых, наша задача — поиск, а не генерация. Нам не нужна глубокая сеть, достаточно сжимать информацию в компактный вектор. В-третьих, обучение на байтах требует больше памяти — каждый байт это токен, поэтому модель должна быть маленькой, чтобы влезть на одну V100.
Предупреждение: Если вы привыкли к моделям с 12+ слоями — переучитесь. Глубокий трансформер на 200 байтах будет переобучаться и давать плохие эмбеддинги. Начните с 4 слоёв, увеличивайте только если данные огромны (миллионы имён).
Контрастивное обучение: как заставить модель понимать разницу
Для кросс-скриптового поиска нам нужно, чтобы эмбеддинги одного имени в разных алфавитах были близки, а эмбеддинги разных имён — далеки. Классика — Triplet Loss или InfoNCE. Я предпочитаю NT-Xent (Normalized Temperature-scaled Cross-Entropy), как в SimCLR. Это просто: в батче создаются пары (имя, его транслитерация). Для каждого якоря я считаю logits со всеми другими примерами, делю на температуру, применяю softmax и считаю cross-entropy только с положительной парой. Потери складываются для всех якорей.
Ключевые гиперпараметры: temperature=0.07 (можно подобрать на валидации), batch_size=256 (чем больше, тем лучше контраст). Негативы — это все остальные примеры в батче (in-batch negatives). Такой подход работает эффективно, если в батче много разных имён.
Датасет: синтезируем транслитерации
Где взять сотни тысяч имён, записанных разными алфавитами? Легко: берём список популярных имён (например, из Wikipedia или открытых дампов Zoonomia) и генерируем транслитерации с помощью стандартных таблиц. Для кириллицы->латиницы есть ГОСТ 7.79-2000. Для иврита — академическая транслитерация. Для иероглифов — пиньинь. Если таблиц нет — можно использовать модель-транслятор, но это избыточно. Я собрал скрипт, который для каждого имени из списка (10k уникальных) создаёт 3–5 вариантов в разных скриптах. Итоговый датасет — 40k пар.
Важно: не все пары должны быть точными транслитерациями. Добавьте шум — опечатки, замены «и» на «й», удвоения согласных. Это сделает модель устойчивой к реальным ошибкам ввода. Я использовал эвристику: с вероятностью 0.1 случайно вставляю или удаляю символ в одном из вариантов. Модель учится игнорировать такие мелкие расхождения.
Код: от байтов до эмбеддингов
Ниже полный код модели и процесса обучения. Я использую PyTorch 2.5.0 и Hugging Face Datasets для DataLoader. Код доступен на GitHub (ссылка в конце).
1 Преобразование имени в байтовую последовательность
import torch
def name_to_bytes(name: str, max_len: int = 128) -> torch.Tensor:
"""
Конвертирует строку в UTF-8 байты, дополняет до max_len нулями.
Возвращает тензор формы (max_len,) с типом torch.long (0..255).
"""
raw = name.encode('utf-8')
if len(raw) > max_len:
raw = raw[:max_len]
bytes_list = list(raw)
padded = bytes_list + [0] * (max_len - len(bytes_list))
return torch.tensor(padded, dtype=torch.long)2 Модель байтового трансформера
import torch.nn as nn
from torch.nn import TransformerEncoder, TransformerEncoderLayer
class ByteTransformer(nn.Module):
def __init__(self, d_model=256, nhead=4, num_layers=4, max_len=128):
super().__init__()
self.byte_embed = nn.Embedding(256, d_model)
self.pos_encoder = nn.Embedding(max_len, d_model) # learnable позиции
encoder_layer = TransformerEncoderLayer(
d_model=d_model, nhead=nhead, batch_first=True,
dim_feedforward=1024, dropout=0.1, activation='gelu'
)
self.transformer = TransformerEncoder(encoder_layer, num_layers=num_layers)
self.proj = nn.Linear(d_model, 128)
def forward(self, x):
# x: (batch, seq_len) - байты
seq_len = x.size(1)
positions = torch.arange(seq_len, device=x.device).unsqueeze(0)
x = self.byte_embed(x) + self.pos_encoder(positions)
# маска внимания: игнорируем нулевые позиции (pad)
src_key_padding_mask = (x == 0).all(dim=-1) # (batch, seq_len)
x = self.transformer(x, src_key_padding_mask=src_key_padding_mask)
# mean pooling по не-падовым токенам
mask = ~src_key_padding_mask.unsqueeze(-1) # (batch, seq_len, 1)
x = (x * mask).sum(dim=1) / mask.sum(dim=1).clamp(min=1)
x = self.proj(x)
return torch.nn.functional.normalize(x, dim=-1)3 Контрастивная loss (NT-Xent)
def contrastive_loss(z1, z2, temperature=0.07):
"""
z1, z2: (batch, d) — эмбеддинги первой и второй транслитерации.
"""
batch_size = z1.size(0)
# объединяем все эмбеддинги для cross-батч негативов
z = torch.cat([z1, z2], dim=0) # (2*batch, d)
# матрица сходств
sim = z @ z.T / temperature
# маска: положительные пары (i, i+batch) и (i+batch, i)
labels = torch.arange(batch_size, device=z.device)
labels = torch.cat([labels, labels]) # (2*batch) — каждый элемент должен совпадать с парным
# логиты — диагональ не учитываем (это сам-с-собой)
sim.fill_diagonal_(-1e9)
loss = torch.nn.functional.cross_entropy(sim, labels)
return loss4 Тренировочный цикл
from torch.utils.data import DataLoader, Dataset
class CrossScriptDataset(Dataset):
def __init__(self, pairs):
# pairs: list of (name_a, name_b)
self.pairs = pairs
def __len__(self):
return len(self.pairs)
def __getitem__(self, idx):
a, b = self.pairs[idx]
return name_to_bytes(a), name_to_bytes(b)
model = ByteTransformer().cuda()
optimizer = torch.optim.AdamW(model.parameters(), lr=1e-4)
loader = DataLoader(dataset, batch_size=128, shuffle=True)
for epoch in range(10):
for x1, x2 in loader:
x1, x2 = x1.cuda(), x2.cuda()
z1 = model(x1)
z2 = model(x2)
loss = contrastive_loss(z1, z2)
optimizer.zero_grad()
loss.backward()
optimizer.step()
print(f'Epoch {epoch}, loss: {loss.item():.4f}')Оценка: MRR и Recall@K
Для теста берём набор из 10k имён, каждое в трёх вариантах (кириллица, латиница, иврит). Для каждого запроса вычисляем эмбеддинг, ищем топ-10 ближайших соседей через косинусную близость. Считаем Mean Reciprocal Rank (MRR) — какой ранг у правильного варианта. На моём бенчмарке модель даёт MRR@10 = 0.93 и R@10 = 0.98. Для сравнения: модель с BPE токенизатором (WordPiece) на том же датасете — MRR 0.78. Выигрыш значительный.
Кстати, о том, как строить поисковые индексы для таких эмбеддингов, я рассказывал в статье «Векторный поиск для базы знаний». Там описан production-ready пайплайн с FAISS и рескором.
Грабли, на которые я наступил (и вы наступите)
Первая ошибка — отсутствие маски паддингов. Если не маскировать нулевые токены, attention будет туда «смотреть» и портить эмбеддинги. Обязательно передавайте src_key_padding_mask в TransformerEncoder.
Вторая — неправильный пулинг. Просто взять первый токен (CLS) — плохая идея, так как байты не имеют чёткой границы «предложения». Mean pooling по всем не-pad токенам стабильнее.
Третья — слишком высокая температура. При temperature > 0.2 loss перестаёт различать негативы, модель схлопывается в точку. Начинайте с 0.05–0.07.
Четвёртая — игнорирование длины последовательности. Имя «Wu» займёт 2 байта, а «Христофор» — 18. Если использовать max_len=256 для коротких имён, модель будет тратить внимание на пустоту. Я рекомендую динамический паддинг внутри батча — вычислять максимальную длину для каждого батча и паддить до неё. Но для простоты кода я оставил фиксированную длину 128 — она покрывает 99.9% имён.
Что дальше? Пару слов о будущем
Байтовые трансформеры — это не панацея. Они потребляют больше памяти на входной слой (эмбеддинг на 256 токенов — не проблема, но на длинных текстах последовательность в 4 раза длиннее). Однако для коротких запросов в задачах поиска — это идеальный инструмент. Я вижу тренд: отказ от токенизации в специализированных моделях. Уже сейчас появляются исследования по byte-level LLM (например, ByT5). В ближайшие пару лет токенизаторы уйдут в прошлое, уступив место гибридам — байтовый энкодер + токеновый декодер. А пока — берите код, адаптируйте под свои имена и не бойтесь чистых байтов.
Кстати, недавно вышла статья «Polyglot-r2: суффиксный подход к трансформации текста без промптов» — там тоже решают проблему мультиязычности, но совсем другим способом. Иногда полезно посмотреть на альтернативы.
И напоследок: не пытайтесь сразу внедрить в продакшн. Сначала протестируйте на маленьком датасете, подберите температуру, убедитесь, что эмбеддинги действительно разделяют разные имена и сближают одинаковые. Векторный поиск — штука коварная: без нормализации и правильного масштабирования вы получите мусор. Удачи!
