Проблема низкоресурсных языков в машинном переводе
Почему перевод между 1600+ языками намного сложнее, чем MT с английским в центре, и как новые подходы сокращают разрыв.

По всей планете говорят примерно на 7000 языках. Google Translate поддерживает около 130 из них. Большинство коммерческих систем машинного перевода хорошо справляются с менее чем 30. Если вы говорите на йоруба, кечуа или кхмерском, ваш опыт с машинным переводом варьируется от «едва пригодно» до «смешно неправильно». Неприятная правда в том, что большая часть прогресса в NLP за последнее десятилетие была ориентирована на английский, и разрыв между языками с большим и малым объёмом ресурсов становится всё шире, а не уже.
Недавний рывок Meta в сторону омниязычного машинного перевода, охватывающего более 1600 языков, — одна из самых амбициозных попыток это изменить. Но технические сложности, с которыми сталкиваются при этом, вскрывают фундаментальные допущения, заложенные в то, как мы строим языковые модели, и показывают, почему простое масштабирование не решает проблему.
Что делает язык «низкоресурсным»
В исследованиях машинного перевода «высокоресурсная» языковая пара означает наличие миллионов параллельных предложений — текстов, профессионально переведённых между этими двумя языками. Английский–французский, английский–китайский, английский–испанский: у этих пар огромные параллельные корпуса из парламента ЕС, ООН, новостных организаций и десятилетий профессионального перевода. Модели, обученные на этих парах, работают на удивление хорошо.
«Низкоресурсный» язык может иметь несколько тысяч параллельных предложений или не иметь их вовсе. Фон (на нём говорят около 2 миллионов человек в Бенине) практически не имеет параллельных данных с английским. Бамбара (на нём говорят около 14 миллионов человек в Мали) располагает чуть большим объёмом, но всё равно на порядки меньше того, что нужно традиционным системам MT. Для многих языков самый крупный доступный текстовый корпус — это перевод Библии и, может быть, несколько статей из Википедии.
Разрыв в ресурсах — это не только вопрос объёма данных, но и их разнообразия. Даже когда параллельный текст для низкоресурсного языка существует, он обычно сосредоточен в религиозных текстах или государственных документах. Модель учится переводить формальную, повторяющуюся прозу, но разваливается на разговорной речи, технической терминологии или на всём, что выходит за рамки узкого домена, на котором её обучали.
Почему нельзя просто масштабироваться
Интуиция современного машинного обучения такова: больше данных, больше модель, лучше результат. Для задач, ориентированных на английский, это сработало впечатляюще. Модели в духе GPT, обученные на триллионах английских токенов, выдают удивительно связный текст. Но у этого подхода есть три критических слабости применительно к MT для низкоресурсных языков.
- Данных попросту нет. Нельзя собрать параллельный текст фон–английский из интернета, если никто никогда не публиковал его в значительных объёмах. Веб-скрейпинг, на котором держится большинство крупномасштабных обучающих наборов для MT, по своей природе смещён в сторону языков с большим присутствием в сети.
- Токенизация ломается. Большинство языковых моделей используют токенизаторы, обученные преимущественно на английском (или на горстке высокоресурсных языков). Если пропустить амхарскую письменность или бирманский текст через BPE-токенизатор, обученный на английском, он раздробит символы на неоправданно длинные последовательности токенов. Одно амхарское слово может занимать 8–12 токенов. Это значит, что модель тратит большую часть контекстного окна на кодирование входа и почти не остаётся ресурса на то, чтобы его понять.
- У трансферного обучения есть пределы. Многоязычные модели вроде mBERT или XLM-R показывают, что обучение на множестве языков может помочь низкоресурсным — модель перенимает структурное сходство. Но этот перенос сильнее всего между родственными языками. Модель, хорошо знающая французский, может передать часть этих знаний гаитянскому креольскому. Китайскому или навахо — почти ничего.
Проблема языка-посредника
Большинство систем MT, которые заявляют о поддержке сотен языков, на самом деле пропускают всё через английский. Нужно перевести с суахили на тайский? Система переводит суахили → английский → тайский. Такой подход «через посредника» практичен: достаточно построить модели перевода только на английский и с английского. Но он приводит к накапливающимся ошибкам и к тонкой форме культурного выравнивания.
Когда перевод идёт через английский, теряются понятия, которые не ложатся на английский чисто. В японском уровни вежливости закодированы в формах глагола. В йоруба тональные различия меняют смысл. В тамильском есть инклюзивное и эксклюзивное «мы» (включает ли оно слушателя). Когда всё это проходит через английское «горлышко», информация теряется: английский этих различий не кодирует, и у модели нет способа их сохранить.
Прямой перевод между парами неанглийских языков — например, с суахили на тайский без обхода через английский — сохраняет больше информации. Но построить модели прямого перевода для каждой возможной пары комбинаторно невозможно. При 1600 языках понадобилось бы 2,56 миллиона направленных пар. Даже если обрабатывать напрямую только 100 самых распространённых языков, это всё равно 9900 пар.
Как современные подходы отличаются
Нынешнее поколение массово многоязычных моделей MT устроено принципиально иначе, чем стратегия с посредником. Вместо отдельных моделей для каждой языковой пары они обучают одну модель, которая одновременно усваивает общее представление для всех языков. Ключевые нововведения делятся на несколько категорий.
Токенизация, не зависящая от языка
Проблему токенизатора решают, обучая токенизаторы на сбалансированных многоязычных корпусах, а не на корпусах с перевесом в английский. Подход Meta использует посимвольный резервный механизм, который не даёт ни одному языку получить патологически длинные последовательности токенов. Модели SentencePiece, обученные с явным балансом языков, дают гораздо более справедливую токенизацию: предложение на йоруба и английское предложение похожего смысла занимают примерно одинаковое число токенов.
Это важнее, чем кажется. Если ваш токенизатор в 4 раза менее эффективен для языка X, модель фактически располагает в 4 раза меньшей ёмкостью для его обработки. Исправление токенизации — самое эффективное улучшение для качества работы с низкоресурсными языками.
Добыча параллельных данных из открытого интернета
Один из самых изобретательных технических вкладов — автоматизированный майнинг параллельных данных. Идея такова: обучаем многоязычный энкодер предложений, который отображает предложения с любого языка в общее пространство эмбеддингов. Затем обходим веб и ищем предложения на разных языках, которые попадают в близкие векторы — скорее всего, это переводы друг друга.
Этот приём, впервые реализованный в инструментах вроде LASER и развитый в более свежих работах, извлёк сотни миллионов параллельных предложений из веб-краулов вроде CCNet и OSCAR. Данные шумные: возможно, 20–30% извлечённых пар действительно параллельны, но эвристики фильтрации повышают точность, а большой объём компенсирует шум. Для некоторых языков такой автоматизированный майнинг дал больше параллельных данных, чем все предыдущие наборы, собранные вручную, вместе взятые.
Обратный перевод и самообучение
Обратный перевод — это техника, при которой существующая (несовершенная) модель MT переводит одноязычный текст на целевой язык, а затем полученные синтетические параллельные пары используются для обучения лучшей модели. Это бутстрэппинг, и работает он удивительно хорошо.
Цикл выглядит так: обучаем начальную модель на любых имеющихся параллельных данных → переводим ей одноязычный корпус → отфильтровываем плохие переводы → переобучаем на объединённых реальных и синтетических данных → повторяем. Каждая итерация улучшает модель, а улучшенная модель создаёт лучшие синтетические данные, которые помогают следующей итерации. Для языков, где вы начинаете всего с нескольких тысяч параллельных предложений, обратный перевод может фактически умножить объём обучающих данных в 10–50 раз.
# Simplified back-translation loop
def back_translate_cycle(model, parallel_data, monolingual_target, rounds=3):
for round in range(rounds):
# Generate synthetic source from monolingual target text
synthetic_pairs = []
for target_sent in monolingual_target:
source_sent = model.translate(target_sent, direction='reverse')
score = model.score_pair(source_sent, target_sent)
if score > QUALITY_THRESHOLD:
synthetic_pairs.append((source_sent, target_sent))
# Combine real and synthetic data
combined = parallel_data + synthetic_pairs
# Retrain model on combined data
model = train_mt_model(combined)
print(f'Round {round+1}: {len(synthetic_pairs)} synthetic pairs added')
print(f'BLEU score: {evaluate(model, test_set)}')
return model
Оценка сложнее, чем кажется
Оценки BLEU — стандартная метрика качества MT — серьёзно подводят для низкоресурсных языков. BLEU измеряет совпадение n-грамм между выходом модели и эталонным переводом. Для английского она работает достаточно хорошо, потому что у английского относительно фиксированный порядок слов и ограниченная морфология. Но для агглютинативных языков, таких как турецкий или финский, где одно слово может передавать то, что в английском выражается целой фразой, BLEU штрафует корректные переводы, использующие другие морфологические формы.
Есть и проблема эталонов: кто пишет референсные переводы, с которыми сравнивается результат? Для высокоресурсных языков есть профессиональные переводчики. Для многих низкоресурсных «золотые» эталонные переводы были сделаны миссионерами, государственными переводчиками, работающими в официальном регистре, или аспирантами. Такие эталоны могут быть технически верными, но стилистически неестественными, и модель, которая выдаёт более естественные переводы, на деле получает более низкие баллы.
Новые метрики вроде COMET и BLEURT используют нейросети для оценки качества перевода и лучше коррелируют с человеческими оценками. Но обучены они тоже в основном на данных высокоресурсных языков, поэтому могут плохо обобщаться на языки с очень другой структурой. Некоторые команды начали проводить человеческую оценку с носителями для своих самых важных языковых пар, но это не масштабируется до 1600 языков.
Культурные и этические аспекты
Создание MT для 1600 языков — это не только инженерная задача. Здесь возникают вопросы о том, кто получает пользу, кто решает, как представлены языки, и что происходит, когда модели закрепляют неверные или предвзятые переводы.
Для многих исчезающих языков основные носители — пожилые члены общин в сельской местности. Они не те, кто пользуется API машинного перевода. Непосредственными бенефициарами чаще оказываются исследователи, НКО и правительства, что может быть как хорошо (лучший доступ к информации), так и проблематично (слежка, принудительная ассимиляция) — в зависимости от контекста. История MT для коренных языков, разработанного без участия сообществ, достаточно тяжёлая.
Есть и вопрос стандартизации языка. У многих низкоресурсных языков значительная диалектная вариативность и нет единой «стандартной» формы. Когда модель MT выбирает один диалект в качестве канонического (обычно тот, что лучше всего представлен в обучающих данных), она неявно маргинализирует носителей других диалектов. Это не гипотеза: так уже происходит с более обеспеченными ресурсами языками. Модели арабского MT обычно хорошо справляются с современным стандартным арабским, но спотыкаются на египетском, левантийском или гульфском диалектах, на которых реально говорят сотни миллионов людей.
Что это значит для разработчиков
Если вы создаёте ПО для глобальной аудитории, состояние MT имеет практические последствия для архитектурных решений и решений о продукте.
- Не считайте качество MT одинаковым везде. Ваше приложение может использовать Google Translate или похожий API для локализации. Для французского качество отличное. Для амхарского оно может быть на грани пригодности. Тестируйте с носителями каждый язык, который вы заявляете как поддерживаемый, а не только топ-10.
- Проектируйте с учётом сбоев MT. Показывайте пользователям исходный текст рядом с переводом. Давайте им помечать плохие переводы. Не скрывайте, что контент машинный, — пользователи всё равно это поймут, и доверие к вам упадёт сильнее, если вы выдавали его за качество человеческого перевода.
- Учитывайте «налог на токены». Если вы используете языковые модели (не только MT) в многоязычном контексте, помните, что неанглийские языки потребляют больше токенов. Ваше контекстное окно на 4K вмещает заметно меньше текста на тайском или арабском, чем на английском. Планируйте бюджет соответственно.
- Инвестируйте в многоязычные тестовые данные. Самая сложная часть поддержки низкоресурсных языков — не модель, а понимание того, верен ли ваш результат. Налаживайте отношения с носителями, которые могут проверять качество. Автоматические метрики будут вводить вас в заблуждение.
Что дальше
Движение к омниязычному MT действительно захватывает, несмотря на все оговорки. Пять лет назад создание модели перевода для языка с 10 000 параллельных предложений было бы исследовательской диковинкой. Сегодня такие техники, как обратный перевод, многоязычный перенос и автоматизированный майнинг параллельных данных, делают это осуществимым — не идеально, но пригодно для использования.
Оставшиеся задачи в не меньшей степени социальные, чем технические. Получение обучающих данных для исчезающих языков требует партнёрства с сообществами, а не просто веб-скрейпинга. Оценка качества в масштабе требует новых метрик и участия носителей. Чтобы инструменты MT действительно служили сообществам, которые говорят на этих языках, а не просто отмечали галочку «покрытие», нужна постоянная работа в диалоге с ними.
Но направление верное. Язык не должен быть барьером для доступа к информации, и сам факт, что мы пытаемся строить системы перевода для 1600 языков, а не оптимизируем одни и те же 30 снова и снова, — это заметный сдвиг приоритетов. Инженерия сложна. Одна только проблема токенизации потребовала лет, чтобы её правильно выявить и решить. Но для миллиардов людей, языки которых индустрия технологий игнорировала, эта работа важнее очередного процентного пункта улучшения BLEU для английского–французского.


