Perceiver IO: A General Architecture for Structured Inputs & Outputs
Jaegle et al. [DeepMind]
arxiv.org/abs/2107.14795
Новый "длинный" трансформер от DeepMind с простой архитектурой.
Идея: вместо того, чтобы в attention считать
Проблема: теперь хиддены не соответствуют токенам и непонятно как делать какой-нибудь MLM. Решают так: на выходе из сети берут ещё одну латентную матрицу (например
Так как это DeepMind, они широко поэкспериментировали с применениями: обучили BERT, Optical Flow, RL-агента StarCraft. Везде заменили трансформер на Perceiver IO. TL;DR - везде улушчения по качеству при меньших FLOPS и памяти.
Самый интересный для NLP результат, это что Perceiver IO можно применять на последовательностях символов/байтов и говорить что первый слой как бы выучивает токенизацию за нас.
Jaegle et al. [DeepMind]
arxiv.org/abs/2107.14795
Новый "длинный" трансформер от DeepMind с простой архитектурой.
Идея: вместо того, чтобы в attention считать
query = W @ x, заменим его на латентные (не зависящие от инпута x) обучаемые вектора query = Q. Тогда первый слой будет потреблять seq x queries времени и памяти, а все остальные queries x queries, делая трансформер линейным по длине последовательности в первом слое и константным в остальных слоях.Проблема: теперь хиддены не соответствуют токенам и непонятно как делать какой-нибудь MLM. Решают так: на выходе из сети берут ещё одну латентную матрицу (например
seq x hidden) и считают attention с ней. На выходе получаются вектора, которые можно ассоциировать с токенами, архитектура есть на картинке выше. Дальше с этими векторами можно делать то же, что мы делаем с аутпутом трансформера.Так как это DeepMind, они широко поэкспериментировали с применениями: обучили BERT, Optical Flow, RL-агента StarCraft. Везде заменили трансформер на Perceiver IO. TL;DR - везде улушчения по качеству при меньших FLOPS и памяти.
Самый интересный для NLP результат, это что Perceiver IO можно применять на последовательностях символов/байтов и говорить что первый слой как бы выучивает токенизацию за нас.
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
Курс по геометрическому 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 — модель для генерации кода от 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
https://twitter.com/DeadMoneyDuke/status/1425890180783906821/photo/1
Пример моего решения. Я ничего не знал про difflib. Нашёл один пример использования .get_opcodes на stackoverflow. Мой первый сабмишшен не прошёл (тк я не прочитал докстринг и не угадал семантику i1, i2, j1, j2), после этого я удалил всё что находится в цикле и попросил Codex сгенерировать решение. Оно прошло сразу же.
Сайт с хорошо (и красиво) аннотированными имплементациями трансформера, compressive transformer 🔥, KNN-LM и другими интересными архитектурами.
nn.labml.ai
nn.labml.ai
Forwarded from эйай ньюз
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. Кода пока нет, но должен появиться тут.
Новая статейка от 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 и файнтюнится.
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
www.youtube.com/watch?v=0JlB9gufTw8
YouTube
∞-former: Infinite Memory Transformer (aka Infty-Former / Infinity-Former, Research Paper Explained)
#inftyformer #infinityformer #transformer
Vanilla Transformers are excellent sequence models, but suffer from very harsch constraints on the length of the sequences they can process. Several attempts have been made to extend the Transformer's sequence length…
Vanilla Transformers are excellent sequence models, but suffer from very harsch constraints on the length of the sequences they can process. Several attempts have been made to extend the Transformer's sequence length…
А 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 учит довольно общие фичи, полезные для разных языков. Было бы конечно итересно увидеть тут какой-нибудь японский, жаль не завезли.
Souza et al, [University of Campinas]
arxiv.org/abs/2109.01942
Авторы заметили, что любая предтренировка помогает мультиязычному трансферу. Например если мы возьмём вьетнамский BERT и зафайнтюним его на португальскую задачу, это будет конечно хуже, чем использовать португальский BERT, но сильно лучше, чем ели не предтренировыват модель вообще.
Экспериментировали с английским, немецким, португальским и вьетнамским. Специально подобрали модели так, чтобы они были натренированы и зафайнюнены примерно на одинаковом количестве данных. Интересно, что качество трансфера слабо зависит от языка — то есть если вы файнюните с немецкого на португальский или с английского метрики будут довольно близки друг к другу.
Ещё одна статья в копилку тех, кто подтверждает что MLM учит довольно общие фичи, полезные для разных языков. Было бы конечно итересно увидеть тут какой-нибудь японский, жаль не завезли.
XLM-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 по ссылки из статьи нету.
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, что подтверждает гипотезу о том, что это просто эффект длины тренировочных текстов.
Provilkov and Malinin [Yandex Research]
arxiv.org/abs/2109.06253
Есть известная проблема, что при больших beam size системы машинного перевода начинают генерировать более короткие и зачастую неправильные переводы. Этому можно противостоять, если нормализовать вероятности beam search на длину текста, но в чём причина такого поведения?
Ответ банальный, но зато интуитивно понятный. Авторы статьи проанализировали ошибки и увидели, что BELU перевода начинает резко падать, когда перевод длиннее среднего перевода в обучающей выборке. Прямо на графике видно, что примерно после этого числа ошибка начинает расти. Совпадение? Не думаю.
Для решения проблемы предлагают простой метод аугментации — конкатенировать тексты и переводы друг с другом, просто рандомно семплируя их (называется MSR на графике). Это повышает BLEU в общем, но в особенности сильно виден эффект на больших beam size, что подтверждает гипотезу о том, что это просто эффект длины тренировочных текстов.
