Не знаю — нужно ли вступление к статье, посвящённой ускорению машинного обучения (Machine Learning, ML)?
Ускорение обучения моделей — это именно то, в чём нуждаются все ML‑инженеры. Более быстрое обучение модели означает ускорение экспериментов, что, в свою очередь, ведёт к ускорению выпуска новых версий программных продуктов. Кроме того — чем выше скорость обучения — тем меньше ресурсов нужно на каждую итерацию обучения модели. Поэтому предлагаю перейти сразу к делу.
По большому счёту, самая первая и самая важная оптимизация, которую можно применить к любой современной системе машинного обучения, заключается в том, чтобы реализовать в этой системе пакетную обработку данных (batching). Для того чтобы получить результат работы системы (inference, инференс) в пакетном режиме — ей, вместо одного элемента входных данных, отправляют N таких элементов. Чаще всего никаких дополнительных нагрузок на систему это не создаёт. Формирование инференса для каждого из элементов, входящих в пакет размера N, занимает в точности столько же времени, сколько нужно для обработки одного элемента входных данных. Почему это так? На первый взгляд может показаться, что обработка пакета данных не может обойтись без некоторых накладных затрат ресурсов. В конце концов — оборудованию приходится выполнять в N раз больше действий.
Если прибегнуть к простейшей модели работы нейронной сети, то получится, что некоторая дополнительная нагрузка на систему, всё же, создаётся. Для выполнения пакетных вычислений нужно выполнить в N раз больше операций. И, на самом деле, если попробовать это на CPU, то окажется, что так оно и есть (среднее время формирования вывода для ResNet-50, Colab).
Итак, вы хотите улучшить эффективность работы своей модели глубокого обучения. Как подойти к такой задаче? Народ в таких случаях часто набрасывается на «сборную солянку» из всяких хитрых приёмов, которые, вроде бы, кому‑то когда‑то помогли, или хватает что‑то, встреченное в каком‑нибудь твите, вроде «Используйте операции, изменяющие исходные данные! Задайте значение None для градиентов! Устанавливайте PyTorch 1.10.0, но ни в коем случае не 1.10.1!».
Понятно — почему люди часто прибегают к таким вот спонтанным действиям в подобных ситуациях. Ведь «эффективность работы» современных систем, их «производительность» (в особенности — систем глубокого обучения) часто кажутся нам понятиями, которые ближе к алхимии, чем к науке. Тем не менее — рассуждения о производительности, в основе которых лежат базовые принципы работы компьютерных систем, способны устранить надобность в широком круге «магических» приёмов и в результате значительно облегчить путь к решению проблемы.
Шёл 2022 год. Я обратил внимание на новый интересный проект CUTLASS, отличающийся очень высокой скоростью выполнения операций умножения матриц. Я взял большую задачу по умножению матриц — 8192 x 8192 x 8192, и померял производительность в PyTorch, где используется библиотека cuBLAS.
В последние недели я, работая в системах с установленным дистрибутивом Debian Sid, столкнулся с несколькими странностями, связанными с liblzma (это — часть пакета xz). При входе в систему с использованием SSH очень сильно нагружался процессор, Valgrind выдавал ошибки. И вот я, наконец, нашёл причину всего этого: в основной репозиторий xz и в tar‑архивы xz был встроен бэкдор.
Сначала я подумал, что это — взлом Debian‑пакета, но оказалось, что речь идёт именно о библиотеке.
Если вы достаточно часто работаете в командной оболочке/терминале — это значит, что со временем история команд станет вашим личным хранилищем знаний, вашим справочником по командам и по документации. Возможность эффективно пользоваться этим личным хранилищем полезной информации может сильно повысить продуктивность вашего труда. Поэтому представляю вашему вниманию несколько советов относительно того, как оптимизировать настройки истории оболочки и как пользоваться этим инструментом на полную мощность.
Мой отец эмигрировал из Колумбии в Северную Америку, когда ему было 18. Сделал он это в поисках лучшей жизни. Для меня и моего брата это значило — проводить много времени на уличном холоде. Отец выбрал путь улучшения своей судьбы через улучшение того, что его окружает. Меня и брата «добровольно» завербовали в помощники по работам над принадлежащими нам постройками.
Именно так значительную часть подростковых лет я провёл, чиня изгороди, роя ямы, строя перекрытия и навесы. И если я чему и научился, занимаясь всеми этими строительными делами, так это тому, что реальность обладает удивительным количеством деталей.
В подвижном мире развивающихся нейросетевых архитектур главную роль играет эффективность работы моделей. Тонкая настройка сетей под конкретные задачи предусматривает интеграцию в них априорных знаний. Делается это посредством стратегических корректировок архитектур сетей. Это — процедура, выходящая за рамки подстройки параметров. Речь идёт о внедрении в нейросеть информации, которая позволит сети понять то, что нужно её создателю. Один из способов это сделать заключается в использовании априорных знаний геометрического характера. Именно этому и посвящена данная статья.
В этом материале мы поговорим об устройстве компонента‑декодера в системах машинного обучения, построенных по архитектуре «трансформер», уделив особое внимание отличию декодера от энкодера. Уникальной особенностью декодеров является то, что они похожи на циклы. Они, по своей природе, итеративны, что контрастирует с линейными принципами обработки данных, на которых основаны энкодеры. В центре декодера находятся две модифицированные формы механизма внимания: механизм множественного внимания с маскировкой (masked multi‑head attention) и механизм множественного внимания энкодера‑декодера (encoder‑decoder multi‑head attention).
Слой множественного внимания с маскировкой в декодере обеспечивает последовательную обработку токенов. Благодаря такому подходу предотвращается воздействие последующих токенов на сгенерированные токены. Маскировка важна для поддержки порядка следования и согласованности сгенерированных данных. Взаимодействие между выходом декодера (из слоя множественного внимания с маскировкой) и выходом энкодера организовано с помощью механизма множественного внимания энкодера‑декодера. Этот последний шаг даёт декодеру доступ к входным данным.
Мы, кроме того, продемонстрируем реализацию этих концепций с использованием Python и NumPy. Мы создали простой пример перевода предложения с английского языка на португальский. Практическая демонстрация обсуждаемых здесь идей поможет проиллюстрировать работу внутренних механизмов декодера в трансформерах и позволит лучше понять роль декодеров в больших языковых моделях (Large Language Model, LLM).
Приходилось вам копипастить фрагменты вспомогательного кода между проектами, попадая в ситуацию, когда несколько версий одного и того же набора команд оказывались в разных репозиториях? Или, может, вам надо было делать pull‑запросы к десяткам проектов после того, как было изменено имя GCP‑корзины, где вы храните данные?
Подобные ситуации возникают в ML‑командах слишком часто. Тяжесть их последствий варьируется от мелких неудобств для отдельного разработчика до нарушения работы целой команды, которая оказывается не в состоянии вовремя выдать код, над которым трудится. К счастью, эти проблемы поддаются исправлению.
Предлагаю погрузиться в тему монорепозиториев. Это — архитектура, широко применяемая в ведущих технологических компаниях наподобие Google. Поговорим о том, как монорепозитории способны улучшить ваши рабочие процессы, связанные с машинным обучением. Монорепозитории дают тем, кто их выбирает, много полезного. Это, несмотря на то, что есть у них и недостатки, делает их привлекательным выбором для управления сложными ML‑экосистемами.
Сначала мы кратко обсудим сильные и слабые стороны монорепозиториев, поговорим о том, почему они — это отличное архитектурное решение для ML‑команд, коснёмся того, как их используют в крупных технологических компаниях. В итоге у нас появится представление о том, как воспользоваться возможностями системы сборки кода Pants для организации ML‑репозиториев при построении надёжной CI/CD‑системы для сборки проектов.
А теперь — в путь — к оптимизации управления проектами в сфере машинного обучения.
Одно из самых увлекательных дел, которое счастливая случайность может подкинуть учёному‑информатику — это сложная социотехническая задача из области, переживающей процесс цифровой трансформации. В моём случае это была задача подсчёта рыб. Недавно я работал в роли консультанта в сфере экологии, уделяя основное внимание подсчёту рыб, проплывающих через крупные плотины гидроэлектростанций. Занимаясь этим большим проектом, я узнал о том, как управляют системами создания наборов данных, в работе которых участвует человек, как координируют функционирование таких систем. Кроме этого я узнал о тех сложностях и неожиданностях, которые сопутствуют тому, кто пытается осмыслить результаты исследований и поделиться ими с теми, кому они интересны.
Блокноты Jupyter — это, уже довольно давно, один из самых неоднозначных инструментов в среде дата‑сайентистов. Одни яро критикуют Jupyter, другие горячо поддерживают этот проект. Но, тем не менее, многие согласятся с тем, что блокноты Jupyter, при правильном их использовании, могут быть очень ценным инструментом. Именно этому и посвящена данная статья — вторая в серии моих материалов про науку о данных и машинное обучение. Я поделюсь здесь методическими рекомендациями по использованию Jupyter Notebook для разведочного анализа данных.
Но для начала нам надо ответить на вопрос о том, почему блокноты Jupyter обосновались именно в научном сообществе. Когда тема Data Science была у всех на слуху, блокноты Jupyter ещё ничего из себя не представляли. До них у нас был IPython, интерактивная оболочка для Python, которую встраивали в различные IDE, вроде Spyder. Эти IDE пытались подражать работе RStudio или Matlab. Подобные инструменты получили широкое распространение среди исследователей.
В 2014 году из среды IPython вырос проект Jupyter. Масштабы его использования очень быстро стали просто огромными, чему, в основном, способствовали исследователи, которые перенесли в бизнес‑среду то, чем пользовались, занимаясь наукой. Но те подходы к использованию блокнотов, которые хороши для научных учреждений, не всегда нормально переносятся на анализ данных, проводимый в обычных организациях. Часто бывает так, что дата‑сайентистам, взятым на работу сразу после университета, очень сложно выдать то, что от них ожидают в бизнесе. Речь идёт о структуре аналитических разработок и об оформлении их результатов.
Некоторые компании, защищая свои системы от несанкционированного доступа, используют изолированные компьютерные сети, или полностью обходятся без сетей. Работа в таких системах может быть сопряжена со сложностями, но нельзя сказать, что в них невозможно разрабатывать программные проекты. А особую важность в подобных ситуациях имеет подбор подходящего инструмента для контроля версий наподобие Git.
Система контроля версий Git вполне благополучно работает без удалённого репозитория. Такова её природа. При таком подходе можно создавать ветви репозитория, можно индексировать файлы и коммитить их в репозиторий. Всё выглядит так же, как и при обычной работе.
Я потратил неделю, копаясь во внутренностях MySQL/MariaDB вместе с ещё примерно 80 разработчиками. Хотя MySQL и MariaDB — это, по большей части, одно и то же (я ещё к этому вернусь), я сосредоточился именно на MariaDB.
Раньше я никогда сам не собирал MySQL/MariaDB. В первый день «недели хакерства» я смог наладить локальную сборку MariaDB и твикнул код так, что запрос SELECT 23 возвращал 213. Сделал я и другой твик — такой, что запрос SELECT 80 + 20 возвращал 60. На второй день я смог заставить заработать простую UDF на C, благодаря которой запрос SELECT mysum(20, 30) давал 50.
Остаток недели я потратил, пытаясь разобраться с тем, как сделать минимальный движок для хранения данных в памяти. Именно о нём я и расскажу. Это — 218 строк кода на C++.
Консоль бодро оповестила меня о завершении работы скрипта. Его задача заключалась в поиске учётных данных для доступа к Firebase, которые лежали в открытом доступе и принадлежали одному из сотен недавно появившихся ИИ‑стартапов.
Скрипт шёл по общедоступному списку сайтов с использованием домена верхнего уровня .ai. Программа парсила данные сайтов (и любые.js‑бандлы, на которые находила ссылки) в поиске переменных, которые обычно используются для настройки подключения к Firebase.
Когда я пытаюсь обойтись без *args и **kwargs в сигнатурах функций, это не всегда можно сделать, не вредя удобству использования API. Особенно — когда надо писать функции, которые обращаются к вспомогательным функциям с одинаковыми сигнатурами.
Типизация *args и **kwargs всегда меня расстраивала, так как их нельзя было заблаговременно снабдить точными аннотациями. Например, если и позиционные, и именованные аргументы функции могут содержать лишь значения одинаковых типов, можно было поступить так:
def foo(*args: int, **kwargs: bool) -> None:
...
Применение такой конструкции указывает на то, что args — это кортеж, все элементы которого являются целыми числами, а kwargs — это словарь, ключи которого являются строками, а значения имеют логический тип.
Но нельзя было адекватно аннотировать *args и **kwargs в ситуации, когда значения, которые можно передавать в качестве позиционных и именованных аргументов, могут, в разных обстоятельствах, относиться к различным типам. В таких случаях приходилось прибегать к Any, что противоречило цели типизации аргументов функции.
Сегодня я расскажу о том, как был подготовлен материал об одиночестве, «24 hours in an invisible epidemic», опубликованный на платформе Pudding.
Всё началось с моей одержимости материалами Американского обследования использования времени (American Time Use Survey, ATUS). Каждый год в ходе соответствующего мероприятия проводится опрос десятков тысяч американцев. Им предлагают проследить за одним днём своей жизни. Полученные данные позволяют получить некие общие показатели и, при желании, добраться до каждого респондента и узнать о том, чем занимался именно он.
Этот материал посвящён тому, как добавлять собственные данные в предварительно обученные LLM (Large Language Model, большая языковая модель) с применением подхода, основанного на промптах, который называется RAG (Retrieval‑Augmented Generation, генерация ответа с использованием результатов поиска).
Большие языковые модели знают о мире многое, но не всё. Так как обучение таких моделей занимает много времени, данные, использованные в последнем сеансе их обучения, могут оказаться достаточно старыми. И хотя LLM знакомы с общеизвестными фактами, сведения о которых имеются в интернете, они ничего не знают о ваших собственных данных. А это — часто именно те данные, которые нужны в вашем приложении, основанном на технологиях искусственного интеллекта. Поэтому неудивительно то, что уже довольно давно и учёные, и разработчики ИИ‑систем уделяют серьёзное внимание вопросу расширения LLM новыми данными.
До наступления эры LLM модели часто дополняли новыми данными, просто проводя их дообучение. Но теперь, когда используемые модели стали гораздо масштабнее, когда обучать их стали на гораздо больших объёмах данных, дообучение моделей подходит лишь для совсем немногих сценариев их использования. Дообучение особенно хорошо подходит для тех случаев, когда нужно сделать так, чтобы модель взаимодействовала бы с пользователем, используя стиль и тональность высказываний, отличающиеся от изначальных. Один из отличных примеров успешного применения дообучения — это когда компания OpenAI доработала свои старые модели GPT-3.5, превратив их в модели GPT-3.5-turbo (ChatGPT). Первая группа моделей была нацелена на завершение предложений, а вторая — на общение с пользователем в чате. Если модели, завершающей предложения, передавали промпт наподобие «Можешь рассказать мне о палатках для холодной погоды», она могла выдать ответ, расширяющий этот промпт: «и о любом другом походном снаряжении для холодной погоды?». А модель, ориентированная на общение в чате, отреагировала бы на подобный промпт чем‑то вроде такого ответа: «Конечно! Они придуманы так, чтобы выдерживать низкие температуры, сильный ветер и снег благодаря…». В данном случае цель компании OpenAI была не в том, чтобы расширить информацию, доступную модели, а в том, чтобы изменить способ её общения с пользователями. В таких случаях дообучение способно буквально творить чудеса!
Двадцать лет назад Джоэл Спольски написал: «Не существует такой штуки, как «обычный текст». Если имеется строка, но неизвестно, какую кодировку символов она использует — смысла в этой строке нет. Больше нельзя спрятать голову в песок и притвориться, что «обычный» текст имеет кодировку ASCII.»
Многое изменилось за 20 лет. В 2003 году главный вопрос звучал так: «Что это за кодировка?». В 2023 году такой вопрос больше не стоит: с вероятностью в 98% это — UTF-8. Наконец то! Можно снова спрятать голову в песок!
Уже лет 50, со времён выхода первого издания «Языка программирования Си» Кернигана и Ритчи, известно, что «числа с плавающей запятой» одинарной точности имеют размер 32 бита, а числа двойной точности — 64 бита. Существуют ещё и 80-битные числа расширенной точности типа «long double». Эти типы данных покрывали почти все нужды обработки вещественных чисел. Но в последние несколько лет, с наступлением эпохи больших нейросетевых моделей, у разработчиков появилась потребность в типах данных, которые не «больше», а «меньше» существующих, потребность в том, чтобы как можно сильнее «сжать» типы данных, представляющие числа с плавающей запятой.
Я, честно говоря, был удивлён, когда узнал о существовании 4-битного формата для представления чисел с плавающей запятой. Да как такое вообще возможно? Лучший способ узнать об этом — самостоятельно поработать с такими числами. Сейчас мы исследуем самые популярные форматы чисел с плавающей запятой, создадим с использованием некоторых из них простую нейронную сеть и понаблюдаем за тем, как она работает.