Что нетипично для DeepMind, они ещё и код выложили. К сожалению он на Jax и Haiku, но зато написан довольно аккуратно.

Geometric Deep Learning

Курс по геометрическому Deep Learning от исследователей из ICL, NYU, DeepMind, Universiteit van Amsterdam, Qualcomm и других.

Что такое геометрический DL? Это обобщение нейросеток на более сложные стркутуры, такие как графы или какие-то другие вещи с внутренними симметриями. Я в основном видел его применения в социальных графах, молекулярном DL (а-ля alpha fold), и 3D-computer vision со всякими point clouds (означает: беспилотные автомобили).

Выглядит интересно, все записи лекций и слайды доступны бесплатно.

Курс: geometricdeeplearning.com/lectures/
Первая (вводная) лекция: https://youtu.be/PtA0lg_e5nA

Пару часов назад прошёл OpenAI Codex Challenge и я даже занял там 53 место 🎉

Мы уже обозревали Codex — модель для генерации кода от OpenAI несколько недель назад. Теперь хочется поговорить о впечатлениях после взаимодействия с моделью.

Во-первых Codex это реально магия. Многие задачки были специально сформулированы в довольно специфичной области (например задача парсинга python-кода) или на API, который ты постоянно забываешь (как работать с ISO-датами в pandas). В двух задачках после написания где-то половины решения, Codex завершал его за меня. В двух других задачках он написал весь код, после того, как я перекопировал условие задачи в docstring функции.

Но теперь о более интересном.

В одной из задачек, решение на 99% написанное Codex прошло почти все тесты. Ключевое слово тут "почти". Этот баг можно было бы спокойно незаметить и считать, что функция полностью работает. Он лишь проявлялся в одном из тест-кейсов и вроде бы этот тест-кейс даже не был заточен на этот баг. При этом сам баг был довольно простым и можно было бы поймать заранее, если бы я писал код с нуля.

Мораль: последние несколько лет мы всё чаще видим большие системы (Google, AWS, Cloudflare) падающие из-за мелких и редких багов. Если из-за Codex я упустил такой мелкий и редкий баг в 1 задаче из 5, насколько часто это будет случаться, когда подобными системами будет пользоваться большинство разработчиков (что, я думаю, неизбержно)?

Пример решения задачки с помощью Codex. Весь код сгененирован по названию функции и докстрингу.

https://twitter.com/DeadMoneyDuke/status/1425890180783906821/photo/1

Пример моего решения. Я ничего не знал про difflib. Нашёл один пример использования .get_opcodes на stackoverflow. Мой первый сабмишшен не прошёл (тк я не прочитал докстринг и не угадал семантику i1, i2, j1, j2), после этого я удалил всё что находится в цикле и попросил Codex сгенерировать решение. Оно прошло сразу же.

Сайт с хорошо (и красиво) аннотированными имплементациями трансформера, compressive transformer 🔥, KNN-LM и другими интересными архитектурами.

nn.labml.ai

Finetuned Language Models Are Zero-Shot Learners (FLAN)

Новая статейка от Google Research о языковой модели на 137-миллиардов параметров, которая превосходит GPT-3 (few-shot) на различных задачах в zero shot сценарии.

🗯Идея. Предлагается новый метод файнтьюнинга, называемый "instruction tuning". Тут авторы используют идею, что NLP задачи могут быть описаны человеческими словами. Например, “Is the sentiment of this movie review positive or negative?” или “Translate ‘how are you’ into Chinese.” Итак, берется предобученный трансформер на 137-миллиардов параметров (состоит только из декодера), и файнтьюнится на пачке задач с текстовыми инструкциями. После этого его тестируют на новых задачах, также описанных текстом.

✔️Результат. FLAN модель (137 миллиардов параметров) после "instruction tuning" уделывает GPT-3 (175 миллиардов параметров) на 19 из 25 новых языковых задачах.

Статья на arxiv.  Кода пока нет, но должен появиться тут.

∞-former: Infinite Memory Transformer
Martins et al.
arxiv.org/abs/2109.00301

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

Пайплайн выглядит вот так:
1. берём токены, эмбеддим, а дальше аппроксимируем получившуюся матрицу с помощью K базисных функций, точнее как X = B @ F, где B - матрица размера N на K, а F - это K базисных функций
2. берём матрицу B и считаем keys и values для attention с помощью линейных проекций
3. далее мы хотим получить непрерывный attention, который мы моделируем с помощью гауссианы N(mu, sigma). Для этого считаем mu и sigma как attention между keys и queries плюс ещё одно линейное преобразование плюс sigmoid (для mu) или softplus (для sigma^2)
4. теперь делаем взвешенное усреднение values с весами полученными от гаусианы, то есть условное матожидание. Авторы мало про это пишут, скорее всего есть какие-то аналитические решения для матожидания радиальных функций, которые тут использутся.
5. последний шаг — сделать всё это n_heads раз и потом смешать все головы с помощью линейного слоя. Это помогает избавиться от того, что у гаусиана унимодальна (у неё только один пик) и после смешивания нескольких разных гаусиан наш attention может смотреть на несколько разных кусков текста.

Результаты: на wikitext-103 превосходит TransformerXL и Compressive Transformer. Также придумали процедуру "обесконечивания" обычных трансформеров, где обычный attention дополняется бесконечным attention и файнтюнится.

Видосик от Yannic Kilcher c обзором бесконечноформера
www.youtube.com/watch?v=0JlB9gufTw8

А Jax начинает выглядеть неплохо. Всё-таки надо будет написать на нём что-то посерьёзнее полносвязной сетки, посмотреть как оно в жизни.

​​On the ability of monolingual models to learn language-agnostic representations
Souza et al, [University of Campinas]
arxiv.org/abs/2109.01942

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

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

Ещё одна статья в копилку тех, кто подтверждает что MLM учит довольно общие фичи, полезные для разных языков. Было бы конечно итересно увидеть тут какой-нибудь японский, жаль не завезли.

​​XLM-E: Cross-lingual Language Model Pre-training via ELECTRAXLM-E: Cross-lingual Language Model Pre-training via ELECTRA
Chi et al. [Microsoft]
arxiv.org/abs/2106.16138

Помните XLM-R? BERT-like модельку, где MLM делали на парах [предложение] [SEP] [перевод] и таким образом обучали классную мультиязычную модель?

В этой статье сделали то же самое, но c задачкой ELECTRA, где модель не заменет MASK на пропущенные слова, а пытается детектировать какие слова оригинальные, а какие подменённые (просто бинарная классификация). Подменой слов занимается другая модель, которая учится как BERT.

По результатам XLM-E показывает 100-кратное уменьшение FLOPS для предобучения и заметный буст в cross-lingual zero-shot transfer. Приятно читается, жалко только что кода XLM-E по ссылки из статьи нету.

​​Multi-Sentence Resampling: A Simple Approach to Alleviate Dataset Length Bias and Beam-Search Degradation
Provilkov and Malinin [Yandex Research]
arxiv.org/abs/2109.06253

Есть известная проблема, что при больших beam size системы машинного перевода начинают генерировать более короткие и зачастую неправильные переводы. Этому можно противостоять, если нормализовать вероятности beam search на длину текста, но в чём причина такого поведения?

Ответ банальный, но зато интуитивно понятный. Авторы статьи проанализировали ошибки и увидели, что BELU перевода начинает резко падать, когда перевод длиннее среднего перевода в обучающей выборке. Прямо на графике видно, что примерно после этого числа ошибка начинает расти. Совпадение? Не думаю.

Для решения проблемы предлагают простой метод аугментации — конкатенировать тексты и переводы друг с другом, просто рандомно семплируя их (называется MSR на графике). Это повышает BLEU в общем, но в особенности сильно виден эффект на больших beam size, что подтверждает гипотезу о том, что это просто эффект длины тренировочных текстов.

Иллюстрация метода аугментации

The Importance of Deconstruction
slideslive.com/38938218/the-importance-of-deconstruction

Очень хорошее выступление на NeurIPS 2020, где обсуждают как пишутся ML статьи, чем это отличается от физики и что нужно поменьше доверять хитрым архитектурам. Много хороших примеров с тем, как сложные и интересные методы с хитрыми архитектурами сводились к условному KNN и простому препроцессингу.

​​Fine-Tuned Transformers Show Clusters of Similar Representations Across Layers
Phang et al.
arxiv.org/abs/2109.08406

Интересная находка, что после файнтюнинга RoBERTa векторы CLS разных слоёв начинают быть похожи друг на друга. Точнее, условно первые 8 слоёв очень сильно похожи друг на друга и последние 16.  Таких блоков немного, обычно 2-3 штуки. Авторы предполагают что это намекает на то, что модель игнорирует много слоёв, так как их фичи неполезны для задачи. Тестировали на SuperGLUE и нескольких других датасетах. До файтнюнинга такой структуры нету. Нашли похожее поведение в ALBERT и в ELECTRA, но в ELECTRA оно проявлено совсем слабо.

После этого авторы решили просто выключить "неиспользуемые" слои и посмотреть как после этого будет работать сетка. Выяснилось, что если делать это аккуратно, качество практически не меняется.