kazRush обошла NLLB 3.3B по BLEU при модели в 17 раз меньше

В машинном переводе легко попасть в дорогую ловушку: собрать побольше данных, взять модель покрупнее и ждать, что качество вырастет само. Команда экспериментальных технологий AI VK проверила этот рецепт на русско-казахском переводе — и получила более полезный вывод. Модель kazRush на 197 млн параметров обошла NLLB 3.3B по BLEU и chrF при переводе с русского на казахский. Сработал не масштаб сам по себе, а связка из аккуратно подготовленного корпуса, компактного токенизатора и архитектуры, подобранной под объём данных.

Сначала данные, потом параметры

Исходный корпус собрали из OPUS, KazParC, WMT и Turkic Interlingua. До фильтрации получилось около 12,3 млн пар предложений. После удаления мусора, проверки языков и выравнивания осталось 9 054 960 пар.

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

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

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

Компактная модель вместо гонки размеров

Для двух языков обучили общий SentencePiece-токенизатор на 8 000 подсловных единиц. Вариант на 16 000 показал немного худший результат. Это важное напоминание: большой словарь не всегда полезен, особенно для языка с богатой морфологией и ограниченным корпусом.

Основой модели стал Transformer с энкодером и декодером в стиле T5, но без готовых весов. Итоговая конфигурация получила 12 слоёв в энкодере и декодере, скрытое состояние размером 512 и feed-forward-блоки размером 4 096. Всего — около 197 млн параметров.

Авторы сравнили её с T5-Small, T5-Base и T5-Large. Модель на 738 млн параметров не стала лучшей: для направления «русский — казахский» она получила BLEU 15,8, тогда как kazRush — 16,2. По chrF результат составил 51,9 против 51,6, по COMET — 0,8836 против 0,8804. Иными словами, почти четырёхкратное увеличение числа параметров не окупилось.

Где результат действительно силён

На FLORES+ devtest kazRush сравнили с семейством NLLB. В переводе с русского на казахский модель получила BLEU 16,2 и chrF 51,8, превзойдя NLLB 3.3B с показателями 15,6 и 50,7. При этом по COMET крупная NLLB осталась впереди: 0,889 против 0,883. Поэтому говорить о безусловной победе нельзя — разные метрики оценивают разные свойства перевода.

В обратном направлении kazRush также обошла NLLB distilled 600M, но уступила версиям NLLB на 1,3 и 3,3 млрд параметров. Это специализированный инструмент, а не универсальная замена большим мультиязычным моделям.

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