Команда AI VK под руководством разработчика Ани Лебедевой завершила работу над kazRush — специализированной системой перевода в паре «русский—казахский», созданной с нуля, а не дообученной на основе крупных мультиязычных моделей. Проект изначально ориентировался на прикладное направление с русского на казахский, однако обратная модель была обучена в том же пайплайне, поскольку к моменту её создания корпус и инфраструктура обработки данных уже существовали. Итоговая конфигурация насчитывает примерно 197 миллионов параметров, и именно она принесла первое место в своём треке на воркшопе LoResMT 2026, проводимом при конференции EACL. Работа велась вокруг открытых данных, а не проприетарных переводов, что делает результат воспроизводимым и полезным для дальнейших исследований в области малоресурсных языковых пар.

Исходный корпус составил около 12,3 миллиона пар предложений до фильтрации, собранных из всех доступных открытых ресурсов. Данные WMT добавили государственные, юридические, институциональные и новостные тексты, а ресурсы OPUS — субтитры и выступления TED, что расширило тематическое покрытие. При объединении датасетов для каждой записи сохранялась метка источника, и это решение оказалось практически ценным: когда странность повторялась в тысячах строк, метка позволяла быстро определить, какой корпус её принёс. Очистка была разделена на общую, обязательную для всех данных, и отдельные правила для конкретных корпусов, что дало гибкость без потери контроля над качеством.

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

Нетривиальная часть очистки касалась проверки чисел: последовательности цифр извлекались с обеих сторон и сравнивались как множества, а не как упорядоченные списки, поскольку грамматика допускает разный порядок чисел в оригинале и переводе. При несовпадении пара отправлялась на ручную проверку, а не удалялась автоматически, так как числа могут корректно записываться разными способами — цифрами в источнике и словами в переводе. Если проверка подтверждала, что тексты не являются переводами друг друга, пара исключалась. Отдельная проблема обнаружилась после первой итерации обучения: перевод всегда начинался с заглавной буквы независимо от регистра исходного предложения, что оказалось следствием данных — в корпусе нашлось 237 859 русских предложений, начинавшихся со строчной буквы, и модель усвоила это как норму. Исправление потребовало нормализации регистра, чтобы перевод сохранял формат исходного текста, что важно для пользователей, переводящих фрагменты, а не целые предложения.

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

Для российского рынка и государственных сервисов русско-казахская пара имеет практическое значение: она востребована в образовании, медиа, документообороте и повседневной коммуникации. Наличие миллионов носителей языка не означает наличия сопоставимого количества качественных параллельных пар, и открытый характер проекта kazRush снижает барьер для организаций, которые не могут позволить себе проприетарные переводческие API или не хотят передавать чувствительные тексты внешним сервисам. Специализированная модель с 197 миллионами параметров дешевле в инференсе, чем крупные мультиязычные аналоги, и её можно развернуть локально, что важно для регуляторных и инфраструктурных требований. Отраслевая реакция на подобные проекты обычно связана с вопросами воспроизводимости и лицензирования данных, и здесь открытость корпуса и пайплайна играет в пользу команды.

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