За последние три года размер данных Notion увеличился в 10 раз из‑за роста количества пользователей и объёмов контента, с которым они работают. Удвоение этого показателя происходило каждые 6–12 месяцев. Нам нужно было справиться со стремительным ростом размеров данных, соответствуя при этом постоянно растущим требованиям, которые выдвигали критически важные сценарии использования наших продуктов и аналитических систем. Особенно это справедливо в применении к новым функциям Notion AI. Для того чтобы решить эти задачи нам нужно было создать озеро данных Notion и обеспечить его масштабирование. Вот как мы это сделали.

Можно ли реализовать механизм внутреннего внимания, потребляющий гораздо меньше ресурсов, чем обычно?

Говорят, что механизм внимания плохо переносит работу с последовательностями большой длины. Это — идея, которая встречалась любому, кто потратил достаточно много времени, занимаясь трансформерами и механизмом внутреннего внимания. Это, одновременно, и так, и не так. С одной стороны — с этим сталкивался каждый, кто пытался увеличить размеры контекста своей модели, натыкаясь при этом на то, что модель начинала работать с сильным скрипом. С другой стороны — возникает такое ощущение, что практически каждую неделю выходит новая эталонная модель, которая характеризуется новыми размерами контекста, бьющими все рекорды. (Контекстное окно Gemini составляет 2 миллиона токенов!)

Есть много хитроумных методов, вроде RingAttention, которые позволяют обучать модели с очень большими размерами контекста на мощных распределённых системах. Но сегодня меня интересует всего один простой вопрос: «Как далеко можно зайти, применяя лишь механизм линейного внимания?».

В начале 2020 года у приложения Pinterest для iOS часто возникала серьёзная проблема, связанная с нехваткой памяти (у нас есть материал об этом). Тогда мы поняли, что у нас нет ни достаточно подробных сведений о работе приложений, ни хорошей системы, позволяющей анализировать подобные сведения в целях мониторинга приложений и решения проблем.

Было у вас когда‑нибудь такое: вы обучали модель, которую считали хорошей, а потом, на реальных данных, эта модель с треском проваливалась? Если так — это значит, что вы совсем не одиноки. Машинное обучение наполнено сложными процессами, управляя которыми очень легко сделать что‑то такое, совсем неочевидное, что приведёт к переобучению модели. Я работаю в сфере машинного обучения около 20 лет. Я видел много примеров вышеописанной ситуации, что подтолкнуло меня к написанию материала «Как избежать „подводных камней“ машинного обучения: руководство для академических исследователей». Этот материал был попыткой уберечь других людей от известных мне проблем машинного обучения.

Не знаю — нужно ли вступление к статье, посвящённой ускорению машинного обучения (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, что противоречило цели типизации аргументов функции.