Процессор модели мира даёт CTM чувство себя и помогает, например, предсказывать действия себя и не себя, и т.п. И когда в бродкастах CTM обнаруживает, что “думает” про себя, то процессор модели мира помечает “CTM” в своих моделях как сознательную (и рассылает эту информацию всем процессорам). В целом CTM выучивает репрезентацию себя (“CTM” в кавычках) и это похоже на теорию схемы внимания Грациано (https://www.facebook.com/grigory.sapunov/posts/pfbid0faTh2u9t3GmZmgFdSzGE2WVmbHZ71ryYZHD9LpktkckJCNRTGU37p48zHTWj6enZl). Не уверен, что я до конца это прочувствовал, надо попереваривать.

CTM может “переживать” различные феномены, связанные с сознанием. В предыдущей работе (https://www.worldscientific.com/doi/abs/10.1142/S2705078521500028) авторы объяснили чувства боли и удовольствия в CTM. В этой работе они рассматривают три феномена, связанных со зрением: Blindsight, Inattentional Blindness, Change Blindness. А также обсуждают сны и свободу воли.

В общем, отличное чтение на подумать. Было бы интересно собрать какую-нибудь систему по этим принципам.

Connections in the CTM to and from an LTM processor.

Sketches of models: Baars' GWT model (left) and the CTM (right).

Продолжим формат рассуждений о разном вместо разбора одной научной статьи.

Сегодня про фреймворки.

На днях в Business Insider появилась статья про то, что гугловый фреймворк TensorFlow проиграл битву PyTorch и что Гугл по-тихому начинает замещать TF внутри на новый фреймворк JAX. Английская версия (https://www.businessinsider.com/facebook-pytorch-beat-google-tensorflow-jax-meta-ai-2022-6) за пейволлом, но есть испанская (https://www.businessinsider.es/como-vencio-pytorch-tensorflow-obligando-google-apostar-jax-1077147) и машинный перевод в браузере :) Кстати о птичках, у нас в Intento есть плагин для Chrome, который позволяет переводить веб вообще любыми движками, включая кастомизированные и с различными улучшениями на нашей стороне. Правда, пока это больше история для международных энтерпрайзов, но вдруг вы один из них (https://inten.to/office-productivity-campaign/) :)

Так вот, про статью, ЛеКун вот тоже это откомментировал на днях (https://twitter.com/ylecun/status/1538419932475555840?t=kVabgC60pO6LJPjkmvVqmQ&s=19). Из интересных мыслей здесь то, что тренды в research предшествуют трендам в индустрии (https://twitter.com/ylecun/status/1538426726283345925?s=20&t=ym1AS4v8eYVnfkV57tyy5Q).

В статье нет каких-либо серьёзных комментариев от Гугла и в этом смысле её нельзя воспринимать как истину в последней инстанции. Но совершенно определённо это всё не пустое.

TensorFlow очень большой и тяжёлый продакшн-ориентированный фреймворк. Он включает обширную коллекцию различных библиотек, а также вынужден тащить за собой сколько-то легаси. TF 2.0 это существенный прогресс относительно TF 1.0, которым пользоваться было реально тяжело, код был очень многословным, все эти эстиматоры, составление полного графа перед началом каких-либо вычислений и т.п., в общем это было не сильно удобно. PyTorch массово дал возможность работы с динамическими графами, хотя он был не первым. До него были менее известный DyNet и чуть более известный Chainer. Была и в TF 1.0 попытка сделать какую-то динамику, библиотека Fold, но это было на любителя и далеко до идеала. После PyTorch в TF 2.0 появился eager execution, по моему ощущению это одна из наиболее заметных для всех инноваций, наряду с включением в систему TF библиотеки Keras как основного высокоуровневого языка для создания нейросетей.

Сейчас в экосистеме TF есть большие истории типа продакшн ориентированного TensorFlow Extended (TFX, https://www.tensorflow.org/tfx/guide), мобильно- и edge-ориентированного TFLite (https://www.tensorflow.org/lite), браузерного (и не только) TF.js (https://www.tensorflow.org/js), да и в самом TF, что в Core (https://www.tensorflow.org/api_docs), что рядом (https://www.tensorflow.org/resources/libraries-extensions) библиотек поприбавилось. В общем TF продолжает развиваться, вот недавно в мае вышел TF 2.9 (https://blog.tensorflow.org/2022/05/whats-new-in-tensorflow-29.html) с разными интересными штуками типа оптимизации под CPU (наконец на них не забивают!), поддержкой виндового линукса WSL2, включая GPU (!), и новым API для распределённых вычислений. Но при этом Гугл вынужден поддерживать и TF 1, текущая версия 1.15 (https://www.tensorflow.org/versions/r1.15/api_docs).

Пока TF шёл своей дорогой, PyTorch реально полюбили очень многие, особенно среди исследователей. По первости продакшн часть в PT отставала, но там уже давно появился model serving (https://pytorch.org/blog/model-serving-in-pyorch/), развивается аналог TFX для продакшна (https://pytorch.org/torchx/latest/), да и NVIDIA Triton (https://github.com/triton-inference-server) вроде тоже норм всё поддерживает для инференса.

PyTorch не стоит на месте, из свежестей, например, есть поддержка новых процессоров Apple (https://pytorch.org/blog/introducing-accelerated-pytorch-training-on-mac/), поддержка ускорителей через AMD ROCm (https://pytorch.org/blog/pytorch-for-amd-rocm-platform-now-available-as-python-package/), решения для мобильных и edge устройств (https://pytorch.org/blog/pytorch-1.9-released/#beta-mobile-interpreter), новые доменно-специфичные библиотеки, например, для рекомендательных систем (https://github.com/pytorch/torchrec) и т.д.

По популярности на StackOverflow PyTorch продолжает расти, а TF стагнирует (https://cdn.businessinsider.es/sites/navi.axelspringer.es/public/styles/950/public/media/image/2022/06/stack-overflow-jax-pytorch-2731129.jpg?itok=tWd7JSeN). HuggingFace Transformers изначально была pytorch-transformers (а ещё раньше pytorch-pretrained-bert, что красивая история про последовательные обобщения и универсализацию), сейчас она поддерживает TF 2.0 (и забегая вперёд, JAX!), но цифры говорят о многом: 33693 PT моделей против всего 2874 TF моделей (и снова забегая вперёд 6757 моделей JAX!).

Так вот, JAX. Параллельно в Гугле (изначально в Google Brain) родился новый фреймворк JAX (https://github.com/google/jax), наследник экспериментальной библиотеки AutoGrad (https://github.com/hips/autograd). Про JAX я уже писал полтора года назад (https://moocaholic.medium.com/jax-a13e83f49897), он уже тогда был интересным.

JAX довольно быстро пошёл в массы, и вот уже и DeepMind перешёл на него и активно развивает экосистему (https://www.deepmind.com/blog/using-jax-to-accelerate-our-research), и гугловые статьи всё больше выходят на JAX, те же ViT (https://news.1rj.ru/str/gonzo_ML/434), MLP-Mixer (https://news.1rj.ru/str/gonzo_ML/776), или вот недавно выпустили T5x (https://github.com/google-research/t5x). EleutherAI обучает свои большие GPT-like модели на JAX (https://arankomatsuzaki.wordpress.com/2021/06/04/gpt-j/), HuggingFace добавил поддержку моделей на JAX и их уже больше, чем TF-моделей. Ну и вообще различных модулей на базе JAX на гитхабе с каждым днём всё больше (https://github.com/search?l=Python&q=JAX&type=Repositories). Есть уже много всего, и для дифференцируемой физики, и для эволюционных вычислений, и для федеративного обучения, you name it. В репорте State of AI 2021 на JAX тоже обратили внимание (https://docs.google.com/presentation/d/1bwJDRC777rAf00Drthi9yT2c9b0MabWO5ZlksfvFzx8/edit#slide=id.gebb7f5a4fd_3_884).

JAX при этом минималистичен, он содержит богатое ядро и систему преобразований в функциональном стиле, а остальное навешивается модулями. Так, например, там нет даталодеров (и не нужно, потому что спокойно можно взять любимый даталодер из TF/PT), нет высокоуровневой нейросетевой библиотеки по типу Keras (зато есть Flax от Гугла и Haiku от DeepMind), нет оптимизаторов (есть библиотека Optax) и т.п. Нет пока и важной части про деплой в продакшн, но с одной стороны помним про фразу ЛеКуна, что сначала инновации появляются в research части, а с другой уже есть всякие конверторы jax2tf, JAX to TFLite, поддержка в AWS SageMaker.

Постороен JAX в функциональной парадигме, что круто и, кажется, является одной из причин такой хорошей модульности. Вообще функционального программирования в DL не хватало, хотя, казалось бы, это очень подходящая парадигма для DL. Что интересно, вычисление градиентов реализовано через трансформацию функции с помощью, например, grad(). Вы получаете на выходе другую функцию (!), в которую можно передать параметры (веса в случае нейросетей), для которых вы и хотите вычислить градиент. Есть отдельное преобразование для JIT-компиляции под названием jit(), vmap() для авто-батчинга, и pmap() для распараллеливания. Появляется ещё новый xmap(). И всё это можно комбинировать как хочется. Две производные через grad(), потом автобатчинг через vmap() и компиляция через jit()? Легко. Причём как бы для обычных программ на Python с NumPy. И конечно с поддержкой GPU и TPU. Говорят, правда, что в GPU меньше инвестировали пока, а также оно не поддерживает GPU от AMD (но это отдельная старая боль почти везде в DL).

И вот хочу заметить, что это всё полезно не только в Deep Learning, а, например, для физических симуляций может быть полезно не меньше. Что подтверждается немалым числом фреймворков на базе JAX для различных физических задач, от механики, до движения частиц или моделирования океана. Единственная потенциальная засада с физикой, это что в JAX по умолчанию везде float32, точности которого может быть недостаточно. Но на float64 можно переключиться, если бэкенд поддерживает (хорошие GPU норм поддерживают, чего не скажешь о TPU или об игровых GPU, но это тоже отдельная тема, надо уже обновить старый пост про GPU: https://blog.inten.to/hardware-for-deep-learning-part-3-gpu-8906c1644664).

JAX в чём-то перекликается с Julia, хотя и неоднозачно. У обоих/обеих есть JIT, есть богатый autodiff, области применения где-то близкие. Но вот для тех, кто хочет оставаться в экосистеме питона, JAX это прям сила. 💪

В общем да, JAX прекрасен, мне лично он давно и очень нравится, и по всяким косвенным признакам действительно его в Гугле начинают использовать чаще. И на мой взгляд вполне реальным будущим может оказаться какой-то гибрид JAX и TF. От JAX вся мощь по части моделей, обучения и экспериментов, а от TF различная обвязка и дополнительные сервисы (загрузка данных, деплой, дебаггинг, мобильные устройства, сжатие моделей -- хотя сжатие вполне вписывается в тему про трансформации, так что оно наверное в JAX будет). Ну или не от TF, а от PyTorch. Или от обоих, где что лучше, так тоже можно :)

Интересно, что сейчас пошла движуха в PyTorch по реализации там JAX-подобных преобразований (https://github.com/pytorch/functorch). JAX даёт гибкость, которую не даёт PyTorch и авторы последнего это признают, некоторые вещи в PyTorch делать не очень тривиально (https://github.com/pytorch/functorch#why-composable-function-transforms). Но замечу ещё, что всё же оба олдскульных фреймворка TF и PT (блин, уже и TF/PT олдскульные, где там старые добрые Caffe/Theano/Torch и т.п., молчу уже про PyBrain2 и прочих) таки навязывают скорее объектно-ориентированную парадигму, чего совсем не делает JAX. Да, поверх JAX есть более объектно-ориентированные библиотеки, но это не единственный доступный путь.

Ну вот как-то так. Будущее обещает быть интересным.

JAX

Emergent Abilities of Large Language Models
Jason Wei, Yi Tay, Rishi Bommasani, Colin Raffel, Barret Zoph, Sebastian Borgeaud, Dani Yogatama, Maarten Bosma, Denny Zhou, Donald Metzler, Ed H. Chi, Tatsunori Hashimoto, Oriol Vinyals, Percy Liang, Jeff Dean, William Fedus
Статья: https://arxiv.org/abs/2206.07682
Пост в блоге: https://ai.googleblog.com/2022/11/characterizing-emergent-phenomena-in.html

Свежая работа про эмерджентные свойства больших языковых моделей. Здесь эмерджентными свойствами считают такие, которые не проявляются на малых размерах модели, а появляются в более крупных моделях только после превышения какого-то порога. Поэтому их нельзя получить экстраполяцией.

Почему это важно? Потому что скорее всего при дальнейшем скейлинге проявятся ещё какие-то свойства, не наблюдаемые сейчас.

Есть интересное наблюдение, что с одной стороны scaling laws для больших языковых (и не только) моделей дают довольно простую степенную модель улучшения какой-либо метрики (обычно лосс), но с другой стороны, аналогичного скейлинга по улучшению качества на какой-нибудь конкретной задаче часто нет. Правда в работе https://arxiv.org/abs/2109.10686 показали, что скейлить надо правильно, тогда и ситуация здесь выправляется. Но это не отменяет наличия эмерджентных свойств.

Свойства эти проявляются интересно — до какого-то значения параметра скейлинга перформанс на выбранной задаче обычно в районе случайного, затем после превышения этого порога происходит фазовый переход и перформанс становится существенно лучше.

Параметром скейлинга может выступать количество вычислений (FLOPS), число параметров сети, размер датасета. Это три наиболее частых параметра. В работе берут первый, FLOPS. Также есть графики в зависимости от числа параметров, потому что часто они связаны — на более тяжёлую модель и вычислений тратят пропорционально больше (но это не всегда, Chinchilla, например, выбивается из такого подхода, там на сравнительно лёгкую модель потратили вычислений как на большую Gopher, потому что датасет был сильно больше). В общем, правильную прокси-метрику для обнаружения эмерджентности ещё надо найти, а пока так.

Сначала эмерджентность ищут в режиме работы с большой предобученной языковой моделью и последующим её промптингом (задавая в модель правильный текст-затравку с задачей, который она продолжит и, hopefully, даст ответ, этот режим активно использовался в GPT-3). То есть файнтюнинга нет, модель после предобучения заморожена. Промптинг часто бывает few-shot, когда в промпте даётся несколько примеров решения задачи.

Способность решать задачу через few-shot prompting эмерджентная и не проявляется до определённого размера модели. Авторы показали это на восьми задачах (4 задачи из BIG-Bench, TruthfulQA, Grounded conceptual mappings, Multi-task NLU, Word in Context) и пяти моделях (GPT-3, Gopher, Chinchilla, LaMDA, PaLM).

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

Один из таких примеров — это multi-step reasoning или chain-of-thought prompting, когда проблема решается через последовательность промежуточных шагов. Он начинает превосходить обычный промптинг только начиная с какого-то порога, примерно 100B параметров.

Другая техника, instruction following, вместо нескольких примеров подаёт в модель инструкцию по решению задачи. Модель файнтюнится на смеси задач, поданных в виде инструкций, а потом применяется к новой задаче, которой не видела. Эта техника улучшает качество тоже где-то со 100B параметров (хотя сейчас появились и модели поменьше, с которыми тоже ок).

Задачи на сложение больших чисел и выполнение программ можно улучшить, если файнтюнить модель на получение промежуточных результатов (это называется “scratchpad”). Тут в зависимости от задачи порог 40-100М параметров.

Что всё это значит? Предсказать, что какая-то из этих способностей возникнет, по маленьким моделям нереально (по крайней мере по обобщённым графикам скейлинга). И наверняка если скейлить модели дальше, то обнаружатся и другие эмерджентные свойства, которых сейчас не видно. В наборе бенчмарков BIG-Bench есть ещё задачи, которые даже самые большие модели пока не осиливают и они вероятные кандидаты на улучшение через дальнейший скейлинг. Ровно такая история случилась с бенчмарком Word in Context (WiC), с которым не справлялась самая большая GPT-3, и автор статьи написал, что вероятно авторегрессионная языковая модель для такой задачи не подходит и нужна двунаправленная модель. Но затем появилась авторегрессионная огромная модель PaLM на 540B параметров и она смогла.

Причина эмерджентности — это отдельный вопрос на миллион. Для каких-то задач можно найти интуицию, почему оно может происходить. Например, для задач с последовательностью шагов логично, если глубина модели будет являться функцией от этого числа шагов. Также логично, что модель должна быть побольше, если надо запомнить всего побольше (например, базу фактов). Но в общем случае неясно. Не удивлюсь, если итоговое объяснение будет через Kahn-Kalai conjecture (https://www.quantamagazine.org/elegant-six-page-proof-reveals-the-emergence-of-random-structure-20220425/).

Нельзя среди прочего исключать, что метрики выбраны таким образом, что по ним не видны инкрементальные улучшения, а виден только финальный прорыв, когда модель уже решила конечную задачу. Такова, например, метрика про точное совпадение со строкой. Но это вряд ли полное объяснение, потому что качество промежуточных шагов тоже может внезапно скакнуть. Вообще, есть тут что-то близкое к гроккингу (https://news.1rj.ru/str/gonzo_ML/831). В приложении смотрят на cross-entropy loss, и эта метрика действительно постепенно улучшается, но по ней невозможно предсказать, когда и почему наступит сингулярность эмерджентность по более высокоуровневой метрике.

Отдельное важное наблюдение состоит в том, что масштаб (в смысле scale) это не главный и единственный фактор, и меньшая по размеру модель вполне может достичь тех же результатов с другой архитектурой, более качественными данными или более хитрой обучающей процедурой. Как пример, UL2 на 20B параметров (https://arxiv.org/abs/2205.05131) достигает того же качества, что и GPT-3 на 175B (https://news.1rj.ru/str/gonzo_ML/305), вероятно потому, что обучение у неё более хитрое. Ну и вообще, как только теорема существования доказана (способность продемонстрирована), начинается инжиниринг по получению этой способности в меньших моделях. Так, к примеру, было с instruction-based finetuning, в котором InstructGPT с 1.3B параметров в итоге превзошла ранние модели на 68B.

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

Есть во всеми этими феноменами и риски. Например, риск экстракции данных из модели, эта способность тоже похожа на эмерджентную. Ну и много других рисков есть у больших моделей.

Интересный сдвиг также происходит и в социологической плоскости. С ростом масштаба моделей поменялся и способ использования этих моделей. Мы всё больше движемся к универсальным моделям, которые могут решать различные задачи. Вся тема про foundation models (https://blog.inten.to/foundation-models-b89e7610057) во многом про это. Тоже своего рода эмерджентность, но не та.

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

Ну и конечно нельзя не запостить это: