̶с̶а̶м̶̶о̶изолента мёбиуса

Мои знакомые сейчас собирают "Last Translation Benchmark" — заведомо сложный бенчмарк задач перевода. Сложность проверяется следующим образом: каждый пример прогоняется через десяток моделей, и нужно, чтобы не более пары из них дали правильный перевод. Языки могут быть какие угодно.

Если у вас есть примеры таких сложных текстов для языков, с которыми вы работаете, предлагаю туда их загнать) Если добавить 10+ примеров в ближайшие пару недель, можно стать соавтором статьи про этот бенчмарк — ну и заодно привлечь к языку немножко внимания.

https://last-translation-benchmark.vilda.net/

У меня наконец-то дошли руки научиться, как обновлять веб-приложение https://bouquet.metademolab.com для добавления переводов в бенчмарк BOUQuET, и я там починил пару мелких багов.
Если вы вдруг тоже через него добавляете переводы (или собираетесь это делать), и у вас есть обратная связь, пишите мне напрямую)

С тех пор, как я ещё в 2023 выкладывал тьюториал по дообучению моделей NLLB, я был уверен, что их токенайзер основан на алгоритме unigram (ибо так говорила и всё ещё говорит документация на huggingface). И подходил к модификации словаря токенов соответственно. Недавно решил ещё раз залезть в токенайзер, и оказалось — там всё-таки BPE.

В чём принципиальная разница? Оба алгоритма сначала разделяют текст на «слова» регулярками, а потом каждое слово разбивают на subword tokens. Но Unigram при этом перебирает абсолютно все способы покрыть слово токенами из своего словаря, и выбирает самый вероятный (согласно собственной «недомарковской» вероятностной модели, где токены не зависят друг от друга — отсюда и название). А BPE идёт строго «снизу вверх»: разбивает слово на атомарные единицы (юникодные байты или буквы), а потом рекурсивно склеивает пары соседних токенов в один, если такая замена есть в его словаре. То есть словарь BPE состоит не только из мешка токенов, но и из графа попарных склеек (merges), выстраивающего эти токены из атомов. Это делает словарь BPE несколько расточительным: если там есть какой-то длинный токен, то должна быть и пара более коротких токенов, из которых он склеивается, даже если они не используются ни в каких других комбинациях. Если неаккуратно удалить такие «неиспользуемые» токены из словаря, то другие, полезные токены станут недостижимыми для алгоритма склейки. Если добавить новые токены, но не вывести их из уже используемого графа склеек, то они тоже будут недостижимы. Поэтому если просто пытаться складывать или вычитать словари, как в модели unigram, это может работать очень криво. К примеру: в варианте NLLB, куда я пытался добавлять токены для эрзянского, больше 2к новых токенов оказались недостижимыми и неиспользуемыми.

Правильный подход к манипуляции со словарями BPE — работать с деревьями склеек напрямую. При сокращении такого словаря надо обрезать сразу целые ветки графа склеек (ну или только листья), а не произвольные токены. Ну а при его расширении надо делать continued BPE training, то есть образовывать новые токены, склеивая пары уже имеющихся, как мы это делали в проекте OMT (в случае с NLLB, где BPE делается не над байтами, а над буквами в качестве базовых единиц, бывает ещё нужно добавить в словарь новые буквы). Это несложно имплементировать самостоятельно, но если хочется готового решения, могу порекомендовать пакет tokenizer-extension и идущую с ним в комплекте статью Teaching Old Tokenizers New Words: Efficient Tokenizer Adaptation for Pre-trained Models, где объясняется, почему манипулировать словарями BPE стоит именно так. Там есть ещё что доделать полезного, но основные нужные примитивы уже на месте.

Очень лениво заниматься абсолютно всем. То ли я выгорел, то ли вконец офранцузился, то ли просто начинаю стареть — так или иначе, браться за любую задачу максимально влом. Как по работе, так и вне её.

Тем не менее, есть три задачи (все – в статусе хобби), до которых, возможно, в ближайшие пару месяцев у меня дотянуться ручки:
1) Сделать лидерборд современных моделей по FLORES+, наподобие того, что мы недавно сделали для BOUQuET — чтобы для языков, добавленных во FLORES, но не вошедших в Букет, тоже была оценка наилучших доступных моделек.
2) Попробовать обучить свою COMET-подобную модельку для оценки качества перевода (настолько мультиязычную, насколько можно) и поучаствовать с ней в WMT2026.
3) Попробовать обучить хорошую базовую модель (хотя бы для перевода, а в идеале и для других задач) для нахско-дагестанских языков (чеченского, ингушского, лезгинского, даргинского, аварского).

Буду писать, что получилось, по мере прогресса.
Если есть желание как-то в этом поучаствовать, или просто дать какой-нибудь совет или просьбу, то пишите)

Пост про путешествия, а не про NLP: моя супруга Дарина (inst @cloudberrin) в этом году снова организует классные роуд-трипы в красивые и отдалённые места.

Уже в июле будут заполярная Норвегия и Исландия; осенью — Памирский тракт и Доломитовы Альпы.
Расписание и подробности на сайте plamenproject.com/travel.

Смотрите, подписывайтесь, и делитесь со знакомыми, которым потенциально было бы интересно в такое путешествие вписаться 🙃

Три маленьких апдейта по датасету BOUQuET (напомню, что это наш бенчмарк для мультиязычного перевода, более разнообразный, чем FLORES, и включающий на данный момент 275 разновидности языков):

1. Мы поменяли лицензию со специальной метовской на CC-BY-4.0. Мелочь, но для некоторых организаций, готовых добавлять туда новые языки, это было важно.

2. Мы выложили интерактивный лидерборд с почти всеми моделями, которые мы оценивали в статье Omnilingual MT (и ещё парочкой новых семейств). В отличие от самой статьи, тут можно посмотреть скоры для любой из 1062 языковых пар.

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

Надеюсь, лидерборд получится достаточно живым и будет время от времени пополняться новыми модельками.

Как вы знаете, я участвую в Open Language Data Initiative: мы занимается поддержкой датасетов FLORES+ и Seed и помогаем желающим добавить туда новые языки или улучшить качество имеющихся переводов.

В этом году, как и прежде, мы организуем shared task при конференции WMT26. Идея такая: вы вносите какой-то вклад (добавление или правки) в наши или любые другие открытые мультиязычные датасеты и пишете про это короткую статью, которая публикуется на WMT/EMNLP. Это может быть хорошим пиаром для вас и вашего языка, а также неплохим способом зайти с ноги в мир академического NLP, если вам такое интересно. Дедлайн — август 2026.

Подробнее про всё это — в нашем англоязычном посте на substack. Кстати, подписывайтесь на него, или рекомендуйте вашим знакомым, которым могли бы такие новости быть интересны)

Бонус: вот как выглядят ChrF++ скоры для перевода с английского на 1560 языков нашего библейского бенчмарка и в обратную сторону (чуть-чуть сглаженные для читабельности).
Видно, что OMT-NLLB уже в принципе близка к задаче понимания всех этих языков, а OMT-LLaMA неплохо продвинулась по пути генерации более чем тысячи из них.
Все остальные модели курят в сторонке.

(2/2, начало)

Но хоть ChrF++ и условно пригодна для сравнения, какая из моделей лучше переводит, по её абсолютным значениям нельзя в общем случае судить, плох перевод или хорош (только относительно: больше значит лучше), плюс сравнение её значений для перевода на разные языки абсолютно бессмысленно (с разных языков на один и тот же — норм, т.к. переводы сравниваются с одним и тем же референсом). Для межъязыковых сравнений нужны хорошо откалиброванные обучаемые метрики, типа xCOMET и MetricX. В статье OMT мы время от времени репортили обе, плюс нашу новую метрику на основе эмбеддингов OmniSONAR: BLASER 3.

Логика BLASER 3 та же, что и в моём старом BLASER 2: берём замороженные эмбеддинги исходного текста и перевода, и маленькой MLP нейронкой предсказываем на их основе человеческую оценку качества. Но в отличие от предыдущей модели, для BLASER 3 мы использовали человеческие оценки, полученные из разных источников и по разным протоколам: XSTS и XSTS+R+P (наши собственные протоколы), DA, ESA, MQM, SQM (данные из кампаний WMT и не только). И поскольку таргетов много и друг к другу они не приводимые, то модель обучили многоголовую, по голове на протокол. Модель получилась неплохой: на тестовых данных с MQM разметкой она не сильно уступала xCOMET и MetricX (несмотря на более простую архитектуру), а на данных с нашей новой XSTS+R+P разметкой значительно превосходила их (в первую очередь, думаю, из-за мультиязычности нового SONAR).

Теперь про протокол XSTS+R+P. Это доработанная версия нашего старого протокола XSTS, оценивающего смысловую точность по пятибалльной шкале. Доработка — учёт в явном виде двух новых факторов: регистра R, то есть стиля текстов (уровень формальности и т.п.), и контекста параграфов P, из которых взяты исходные предложения. Этим протоколом мы разметили (т.е. заказали человеческую разметку у вендоров) много переводов текстов из BOUQuET. В первом раунде разметки мы использовали относительно несложные языки (сложных в букете особо и не было тогда), но генерировали переводы большим количеством разнообразных систем, и отбирали их так, чтобы были представлены разные уровни качества. Частично эти данные использовали и для обучения BLASER 3. Ко второму раунду у нас уже были и модели OMT-Llama, и переводы BOUQuET на более сложные языки, и нам хотелось узнать, насколько хорошо OMT-Llama перформит относительно бейзлайнов. Поэтому для каждого предложения и направления размечали один перевод OMT-Llama (но иногда обычной Llama 70B с OMTшным RAG) и один перевод сильной моделью-бейзлайном (чаще всего Gemma 3; коммерческие модели не брали из-за ограничений на условия использования). В совокупности за оба раунда набралось 236К разных оцененных переводов для 161 разных пар языков: самый мультиязычный из подобных датасетов, и один из самых крупных. Обозвали этот сборный датасет Met-BOUQuET. С его помощью ещё долго можно будет оценивать, как хорошо работают разные метрики качества машинного перевода для сложных языков.

Например, выяснилось, что при переводе на сложный язык часто проявляется проблема off-target translations: модели тупо переводят не на тот язык. И ни MetricX, ни XCOMET, ни BLASER обычно такие ошибки не видят! Поэтому для всех трёх метрик (и для многих других, которые мы бенчмаркали), полезным оказалось домножать их скоры (перемасштабированные, в случае MetricX) на скоры модели для определения языка (мы использовали GlotLID), чтобы таким образом штрафовать off-target переводы. С помощью Met-BOUQuET пользу от этого действа оказалось легко показать экспериментально.

Подчеркну, что хоть мы пока (?) и не выложили модели OMT в открытый доступ, но BOUQuET с его 275 языками и Met-BOUQuET доступны тут: huggingface.co/datasets/facebook/bouquet. Можно бенчмаркать на них ваши модели для перевода и для оценки качества, соответственно! Скорее всего, мы опубликуем и детальные лидерборды, и возможно код для их воспроизведения, так что из этого, надеюсь, может получиться живой бенчмарк в духе MTEB. И таким образом, через бенчмаркинг, мы хотя бы косвенно поспособствуем развитию крайне мультиязычного перевода 🙃

Пост про оценку качества перевода в проекте Omnilingual MT.

Для чего вообще заморачиваться с методами оценки качества?

1) Точность бенчмаркинга: когда перевод довольно плохой, все метрики адекватно реагируют на улучшения, но по мере насыщения качества, они начинают показывать в разные стороны. Например, на топ-50 языках TranslateGemma (которая на них специализируется) обходит обычную Gemma по MetricX, но уступает ей по ChrF++ (которая в целом хуже коррелирует с человеческим пониманием качества перевода). Но MetricX, в свою очередь, сильно деградирует при переводе на малоресурсные языки. И приходится выбирать...

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

Я не могу сказать, что проблему оценки качества крайне мультиязычного перевода мы вполне решили. Поэтому базовой метрикой качества мы выбрали старый добрый ChrF++: всё равно на массово мультиязычных бенчмарках (220 языков в FLORES+, 275 в BOUQuET, 1560 в нашем непубличном библейском датасете) эта метрика далека от насыщения, а значит, достаточно информативна. Ну и да, она не очень точна (по крайней мере, на уровне отдельных предложений), но по крайней мере не таит в себе никаких неожиданностей или предвзятостей. Кстати, сразу оговорюсь, что мы использовали не corpus-level формулу для ChrF++, а среднее арифметическое из sentence-level значений.

Вот, для примера, скоры ChrF++ для перевода 275 языков BOUQuET на английский и в обратную сторону. Говорят сами за себя!

(1/2, продолжение)

Пишу третий длиннопост про OMT — и буду очень рад ответить на связанные и не очень вопросы; если у вас таковые имеются, не стесняйтесь, welcome в комментарии 🙃

(2/2, начало)

Но когда мы поменяли энкодер-учитель со старого SONAR на новый, возникла непредвиденная сложность: модель-ученик стала осваивать новые языки сильно хуже. Похоже, новое пространство оказалось более сложным для запихивания туда нового языка. Пришлось много повозиться с рецептом обучения, добавив кроме MSE два контрастных лосса, причём с разными параметрами для «старых» и «новых» языков, и тем самым слегка изменить пространство. Но в итоге новые языки добавились неплохо, и даже на старых качество чуть-чуть выросло (самодистилляция улучшает кросс-язычность), и в итоге новый омниязычный энкодер торжественно объявили остальным — и дофайнтюнили декодер под него. А потом ещё надистиллировали энкодер в более маленькие (основной 1.5B, дочерние без большой просадки качества до 230M) и в энкодер речи.

Поскольку выяснилось, что переводит новый OmniSONAR очень неплохо со всех ~1600 языков, на которых мы замеряли, на 200 поддержанных языков, то мы (довольно спонтанно!) решили сделать из него модель для перевода, назвав её OMT-NLLB. Сперва идея была в том, чтобы просто улучшить декодер, добавив в его обучение (с уже замороженным энкодером) моноязычных данных (с задачей реконструкции) вдобавок к уже имеющимся параллельным. Но посмотрев, как выросло качество перевода в результате этого (оказывается, с очень хорошим омни-энкодером декодер был "узким местом"!), мы решили, что в эту модель надо инвестировать ещё. И сделали это, заменив представление энкодера с одного-вектора-на-предложение на один-вектор-на-токен, убрав таким образом bottleneck и вернув механизм старого доброго cross-attention. Подробнее эту процедуру описала Белен, основной автор этого подпроекта. Получившаяся в результате модель за счёт очень сильной кросс-язычности в энкодере лучше понимает длинный хвост языков (где-то после 700 первых), чем OMT-Llama, а за счёт хорошо адаптированного декодера — очень неплохо генерирует большинство языков из первых 200.

Ещё один кусочек статьи, выполненный моим стажёром Гийемом, исследовал, насколько у моделей SONAR хорошие представления для токенов. Оказались, что достаточно хорошие: несмотря на отсутствие какого-либо обучающего сигнала на уровне токенов, они неплохо годятся для задач word alignment в парах параллельных предложений и для кросс-язычного переноса в задачах sequence tagging. Ну и если добавить небольшой self-supervised сигнал как раз на word alignment, то эти свойства ещё и усиливаются. А это значит, что не обязательно использовать эмбеддинги SONAR (как старого, так и нового) именно на уровне предложений — в зависимости от задачи, можно агрегировать эмбеддинги токенов для сегментов другой длины, типа для слов или словосочетаний, и полученные представления будут тоже весьма кросс-язычными.

А вообще, с моей точки зрения, один из самых важных научных результатов Omnilingual SONAR — демонстрация, что для моделей-энкодеров мультиязычность может быть не проклятием, а даже наоборот, благословением. Оказалось, что чем больше добавлять в обучение энкодера языков, тем лучше он будет понимать новые (не виденные при обучении) языки за счёт роста способности к межъязыковому обобщению, и более того, во многих случаях качество растёт даже на уже виденных языках! Ну или по крайней мере, не очень сильно падает (см. эксперименты в разделе 8.2 статьи). И хотя мы (пока?) не можем выложить OmniSONAR в открытый доступ, я надеюсь, что наша статья подстегнёт других разработчиков текстовых энкодеров делать их настолько мультиязычными, насколько возможно.

Теперь рассказ про Omnilingual SONAR. Статья, на самом деле — «комплексный обед» из минимум пяти разных проектов, но я поведаю только про парочку из них.

Напомню, что SONAR (оригинальная версия) — это текстовый энкодер предложений (1 предложение => 1 вектор) в общее пространство для 200 языков, и декодер, восстанавливающий предложения из этого пространства. В паре они могут работать как переводчик, плюс сходство пары эмбеддингов хорошо коррелирует со сходством соответствующей предложений по смыслу: полезно для семантического поиска и для оценки качества перевода или параллельных обучающих данных.

Идея впихнуть в пространство SONAR побольше языков (обучив новый, более мультиязычный энкодер для того же пространства) была у меня давно — статья про CharSONAR была ранней попыткой, и её хотелось масштабировать на максимальное число языков (используя те же параллельные данные, что я собирал для OMT-LLaMA). В целом, дело нехитрое: обучить энкодер-ученик, используя MSE loss относительно энкодера-учителя, как мы уже делали и знали, что оно работает.

Параллельно с этим, коллеги решили переделать само пространство SONAR. Ещё за год до этого, в проекте LCM, мы поняли, что оно далеко от идеала: соседним эмбеддингам часто соответствуют сильно разные по смыслу предложения, разные по смыслу но похожие по форме предложения различаются недостаточно чётко, представления для кода и математических выражений так себе. В результате наши LCM вышли так себе качеству (проблемы SONAR были не единственной причиной, но наверное основной), и мы даже не стали релизить их веса (хотя тогда ещё была возможность это делать).

Новый SONAR (для всё тех же 200 языков, унаследованных от NLLB) строили с учётом всех этих проблем:
a) Добавили в обучающие данные примеры «неестественных» языков: фрагменты программного кода на 7 языках и математических формул, спаренные с их описаниями на английском.
b) В качестве базовой модели взяли не NLLB, а Llama3 1B: расширили ей словарь токенами из 200 языков, и инициализировали этим и энкодер, и декодер.
c) Поменяли пулинг в энкодере с mean на cls, чтобы сделать эмбеддинги менее буквальными и более семантическими. Для этого же выкинули задачу denoised autoencoding (задачу перевода оставили).
d) Заменили MSE loss на contrastive loss (с софтмаксом, как для энкодеров типа LaBSE). Отрицательные примеры брали как из других предложений в батче, так и из адверсариально сгенерированных парафраз на английском, отличающихся небольшими, но важными деталями. Причём для этих двух видов примеров считали два разных софтмакса, с разной температурой и отступами.

Всё это улучшило структуру пространства эмбеддингов: похожие по смыслу примеры стали ближе, а непохожие — дальше. Модель стала лучше искать соответствие смысла по тексту (и научилась искать по коду), стала переводить между 200 языками лучше чем NLLB-200, и сильно поднялась по сравнению с оригинальным SONAR в прикладных задачах из MTEB (типа классификации текстов).

Параллельно с этими экспериментами, мы потренировались «натягивать» пространство старого энкодера SONAR на энкодер-ученик, обучаемый на параллельных данных для «всех» языков, собранных нами для OMT-Llama. Разных кодов языков там было больше 4200, но большинство из них были представлены ничтожным числом примеров, плюс один и тот же язык часто обозначался более чем одним кодом (несмотря на мои старания их унифицировать), так что сколько языков модель видела точно, мы не знаем. В любом случае, обучался энкодер хорошо: на нашем библейском тестовом датасете мы видели, что он нормально понимает практически все 1560 языков оттуда. В посте Янниса, который в основном занимался этим омниязычным расширением, есть ещё любопытные детали.

(1/2, продолжение)

(2/2, начало)

Одна из причин, почему мы стали делать перевод на базе LLM — чтобы можно было использовать few-shot примеры для тех языков, которые модель выучила не очень хорошо, или для каких-то сложных предметных областей. Поиск примеров в параллельном корпусе сделали частично по всеязычным эмбеддингам OmniSONAR (про них в следующем посте), частично по словам (ибо для многих языков эмбеддинги не идеальны). Для поиска по словам пришлось «переизбрести» ранжирование TF-IDF, добавив в него попытку сделать так, чтобы найденные тексты в совокупности покрывали все слова текста-запроса. Плюс для переранжирования примеров использовали смесь разных сигналов качества (ибо хорошие примеры лучше плохих, но плохие лучше, чем никакие). Выяснилось, что добытые подобным образом примеры дают большой буст к качеству перевода с трудного языка на легкий, и умеренный – с лёгкого на трудный. Но всё сильно зависит от того, сколько примеров в базе для поиска, насколько они релевантны тестовому датасету, и насколько пересекаются с тем, что модель уже видела в ходе обучения.

В целом, рискну заявить, что в первом приближении задачу «машинного перевода для всех языков» модели OMT-LLaMA решили: они худо-бедно могут понимать и генерировать больше тыщи языков (согласно вышеупомянутому библейскому бенчмарку), а для плохо подержанных языков всегда можно нарастить качество с помощью RAG, небольшого дообучения на специализированном датасете, или их комбинации (она обычно работают лучше, чем что-то одно), если для них появились данные. Если бы нам дали заопенсорсить OMT-LLaMA, то я бы их сейчас абсолютно всем рекомендовал в качестве базовой модели для машинного перевода. Но увы, на данный момент это не очень светит. Хорошая новость, впрочем, что при наличии вычислительных ресурсов воспроизвести их будет не очень сложно.

В следующих постах расскажу про OmniSONAR, OMT-NLLB, и как мы всё это оценивали.

Как обещал, рассказываю подробнее про Omnilingual machine translation (OMT). Сегодняшний — про то, как мы делали модели OMT-LLaMA.

Конечная цель — сделать AI, который бы умел решать любые задачи на любых языках, но в качестве промежуточной цели мы выбрали задачу перевода, по двум причинам. Во-первых, она совмещает два ключевых навыка: понимание и осмысленную генерацию; если модель их освоила, то можно считать, что она владеет языком. Во-вторых, с практической точки зрения, модель-переводчик можно совместить с моделью, не знающей язык, но умеющей в другие задачи: или во время обучения (переведя обучающие данные на нужный язык), или во время инференса (сделав каскад из моделей. Поэтому MT.

За этот проект агитировали в основном я и Марта, и когда его одобрили, мы стали его лидами: я больше по технической стороне, Марта – по научной. В начале проекта в OMT было ещё два постоянных участника: Яннис занимался всеязычным энкодером предложений (который в итоге влился в Omnilingual SONAR) и позже BLASER3, а Эдуардо экспериментировал с пост-обучением, имплементировал бейзлайны, и в целом работал со мной над OMT-LLaMA. Остальные участники проекта помогали эпизодически или присоединились позднее (в частности, Андреа с back-translation и общей оптимизацией обучения, Кевин с майнингом параллельных текстов и скейлингом моделей, Артём с RAG).

Одним из решений, которые я принял рано, было НЕ экспериментировать с архитектурами (как это принято в FAIR, по крайней мере в нашей части), а использовать готовую и популярную архитектуру Llama3, уже поддержанную в vllm и других фреймворках для инференса — чтобы готовые модели проще было потом внедрять или дообучать в других средах (как в итоге и оказалось: коллеги дообучили OMT-LLaMA на внутренних данных и успешно применяют для перевода в приложениях Меты). Из всей архитектуры Llama3 мы поменяли только токенайзер: удвоили словарь (новые BPE токены обучали на 2000+ языках, для которых были тексты на тот момент) и обновили pre-tokenizing expression (регулярку, разбивающую текст на «слова», к которым собственно и применяется BPE) с тем, чтобы она узнавала больше разных письменностей и считала диакритические знаки частью слова, а не разделителями. Для нового SONAR, кстати говоря, использовали похожее обновление токенайзера, но с другими параметрами.

В качестве исходных моделей для OMT-LLaMA взяли LLaMA3 трёх размеров: 1B, 3B, 8B. После обновления словаря, модели сначала «продолжили предобучать» на массивных и не очень чистых данных, а потом дообучили более маленьким и чистым датасетом с разнообразными инструкциями: сначала обычный файнтюнинг, потом еще опциональный RL. Для continual pretraining использовали практически полностью публично доступные данные (кроме пары датасетов, наскрэпленных коллегами в предыдущих проектах: NLLB-200 и MMS): наполовину веб-документы для обычного языкового моделирования, наполовину параллельные тексты (предложения, слова из словарей, или намайненные переведенные абзацы). Подробный список источников я перечислять не буду, там больше сотни датасетов разного объёма (созданных в том числе читателями этого канала!), но самый мультиязычный из них — переводы Библии (в основном на базе ebible, плюс несколько источников поменьше); из них, кстати, собрали и тестовый датасет на 1560 языков. Из синтетических данных включили как раз намайненные из веба параллельные абзацы, плюс back-translated предложения из веба. Основной источник веб-текстов – наша «домашняя» пересборка fineweb2, с другими фильтрами и немножко другой классификацией языков.

Датасет для пост-обучения был вдохновлен преимущественно TowerBlocks; мы собрали похожий микс с большим количеством языков, включив туда, в частности, гугловский SMOL и наш новый внутренний seed-датасет Medley, который пока, к сожалению, тоже не удаётся заопенсорсить. Эти же данные (только непосредственно MT часть, без других задач) использовались и для финальной RL стадии (где мы для простоты использовали в качестве награды только простые метрики типа ChrF++; эксперименты с более сложными наградами всё ещё впереди).

(1/2, продолжение)

Таки вышли две статьи по проекту, над которым я работал последний года-полтора.
Omnilingual machine translation и Omnilingual SONAR — про семейства моделек для перевода ВСЕХ языков и про всеязычные энкодеры текста и речи, соответственно.

Сами модели нам пока опубликовать не разрешили, но разрешили выложить обновление бенчмарка BOUQuET – там теперь 275 языкоидов; больше, чем во FLORES+.

Пост с подробностями будет чуть позже)

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

К сожалению, за этот год у нас (FAIR) успело смениться руководство, политика, и мировоззрение, и проект нас заставили свернуть. Самое обидное, что и уже полученные модельки и датасеты не разрешили ни опубликовать, ни продолжать развивать для внутреннего использования. Потому что теперь, видите ли, все должны заниматься superintelligence, то есть строить одну большую всемогущую модель, которая захватит мир.

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

Ну и если вы вдруг знаете контору, которая занимается этим всем, ищет инженеров/исследователей, и умеет нанимать людей во Франции, то мне это интересно 🙃

🚀 Turkic languages translation challenge at LoResMT'2026

We invite MT & low-resource NLP teams to a new shared task on translating Turkic languages under realistic low-data conditions.

🔹 Language Pairs:
Russian-Bashkir (available now!)
English-Chuvash (available now!)
Russian-Kazakh
English-Tatar (available now!)
Russian-Kyrgyz

Other language pairs will be available shortly.

🎯 Why join?
Turkic languages are morphology-rich, dialectally diverse, under-served in MT. This task targets real impact: cultural representation while advancing transfer learning and morphology-aware models.

📦 Data
We provide test data only, while you can use any publicly available data for training.

📏 Evaluation: chrF++

🗓 Key dates
Evaluation: Dec 1, 2025 - Jan 11, 2026
System description due: Jan 27, 2026
Workshop: LoResMT (co-located with EACL 2026, Maroc)

🔗 Ready to join?
https://ods.ai/tracks/turkic-lores-mt

Join us — let’s make Turkic languages more connected! 🌍🗣️