Иногда до начала эксперимента не удаётся оценить то, какого размера должна быть выборка, способная обеспечить его нормальное проведение. Для решения этой проблемы можно провести последовательный тест или A/A‑тест. Но последовательные тесты обычно отличаются меньшей чувствительностью и оказывают отклоняющее влияние на статистическую оценку эффекта воздействия. A/A‑тесты увеличивают длительность экспериментов, не гарантируя при этом того, что найденный в итоге размер выборки окажется корректным. В этом материале мы представим основные моменты из нашей недавней публикации (Precision‑based designs for sequential randomized experiments, Mattias Nordin, Mårten Schultzberg, 2024), в которой мы представляем альтернативный метод, названный нами «fixed‑power design» (схема эксперимента с фиксированной статистической мощностью). При применении схем с фиксированной статистической мощностью эксперимент начинают, не имея оценки размера выборки. Необходимый размер выборки находят, опираясь на имеющиеся данные о текущих результатах эксперимента. Эксперимент останавливают в тот момент, когда текущий размер выборки оказывается больше необходимого размера выборки. Мы покажем, что эксперименты с фиксированной статистической мощностью можно анализировать, используя стандартные методы без какой‑либо коррекции. Точечные оценки оказываются непротиворечивыми, а доверительные интервалы эффекта воздействия обладают асимптотическим номинальным покрытием. Не все формы «подглядывания» приводят к увеличению частоты появления ложноположительных выводов на основе выборки фиксированного размера.

Этот материал посвящён ускорению обучения моделей с использованием бессерверных заданий. В частности, речь пойдёт о том, как запускать обучение с применением Pytorch, GPU и платформы Vertex.

Pinterest поддерживает формирование отчётов по метрикам рекламных объявлений внешних рекламодателей и расчёт рекламных бюджетов в реальном времени. Всё это основано на потоковых конвейерах обработки данных, созданных с помощью на Apache Flink. Доступность заданий (job) Flink для пользователей находится на уровне 99-го перцентиля. Но время от времени некоторые задачи (task) «валятся» под ударами неприятных ошибок, вызванных утечками прямой памяти (Out-Of-Memory, OOM), возникающими сразу в нескольких операторах. Выглядит это примерно так:

В этом материале мы опишем систему для заблаговременного предотвращения оттока рекламодателей, основанную на машинном обучении (ML, Machine Learning). Прототип системы создан на основе данных организаций малого и среднего бизнеса (Small & Medium Business, SMB), с которыми работает Pinterest. Результаты изначального эксперимента говорят о том, что мы, с высокой вероятностью, можем обнаруживать возможный уход рекламодателей. Это, в свою очередь, способно помочь нашим торговым партнёрам. Система, подобная нашей, может достичь лучших результатов, чем обычный подход, когда пытаются вернуть уже ушедшего клиента.

За последние несколько лет те, кто занимается в Netflix направлением Content Engineering, перевели множество служб компании на использование федеративной платформы GraphQL. Этот процесс продолжается и сегодня. Применение федерации GraphQL даёт командам, отвечающим за различные предметные области, новые возможности. Теперь они могут, независимо от других команд, создавать и использовать собственные графовые службы, относящихся к сфере их деятельности (Domain Graph Service, DGS). Команды, кроме того, могут связывать свои предметные области с другими областями в унифицированной схеме GraphQL, доступ к которой даёт федеративный шлюз.

Давайте, в качестве примера, рассмотрим три главнейшие сущности этого графа.

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

В любом случае — успешная работа в сфере машинного обучения держится на систематическом применении итеративного подхода к экспериментам и на исследовании моделей. Именно здесь ML‑специалисты часто сталкиваются с беспорядком. Учитывая то, как много путей они могут избрать, им тяжело бывает удержать в поле зрения то, что они уже попробовали, и то, как это отразилось на эффективности работы моделей. Более того — ML‑эксперименты могут требовать много времени. С ними сопряжён риск пустой траты денег на повторные запуски тех экспериментов, результаты которых уже известны.

С помощью трекера экспериментов, вроде neptune.ai, можно скрупулёзно логировать сведения об экспериментах и сравнивать результаты разных попыток. Это позволяет выяснять то, какие настройки гиперпараметров и наборы данных вносят положительный вклад в эффективность работы моделей.

Но запись метаданных — это лишь половина секрета успешного ML‑моделирования. Нужно ещё иметь возможность проведения экспериментов таким образом, который позволяет быстро получать нужные результаты. Многие команды дата‑сайентистов, в основе рабочих процессов которых лежит система Git, сочли CI/CD‑платформы идеальным решением.

В этой статье мы исследуем вышеописанный подход к управления ML‑экспериментами и поговорим о том, в каких ситуациях его применение оправдано. Мы уделим основное внимание платформе GitHub Actions — системе, интегрированной в GitHub. Но освещённые здесь идеи применимы и к другим CI/CD‑фреймворкам. TL;DR под катом.

В Netflix было сделано много нового со времён выхода предыдущих материалов, посвящённых роли тех, кто отвечает за направление Content Engineering, в реализации поиска по нашему федеративному графу (federated graph). А именно, в первой статье мы идентифицировали проблему и рассказали об использовании инфраструктуры индексирования данных, а во второй мы углубились в вопрос о том, как мы пользуемся очередями. Мы дали доступ к Studio Search для всех инженеров компании, а не только для тех, кто занимается направлением Content Engineering, и переименовали этот проект в Graph Search. С Graph Search интегрировано более 100 приложений. В рамках этой системы поддерживается примерно 50 индексов. Мы продолжаем расширять её функционал. Как было обещано в предыдущем материале, здесь мы расскажем о том, как мы, объединив усилия с одной из команд, отвечающих за Studio Engineering, создавали обратный поиск (reverse search). Обратный поиск переворачивает с ног на голову стандартный подход к выполнению запросов: вместо того, чтобы искать документы, которые соответствуют запросу, он направлен на поиск запросов, соответствующих документу.

Если вы посещали занятия по статистике — вы, возможно, проходили тему «общая теория меры». Там могла идти речь о мере и об интеграле Лебега, а так же — об их связи с другими способами интегрирования. Если на ваших занятиях много внимания уделялось математике (так было у меня), то на них вы вполне могли познакомиться с теоремой Каратеодори о продолжении меры и даже с основами теории операторов на гильбертовых пространствах, а так же — с преобразованиями Фурье и много с чем ещё. Большинство этих математических конструкций нацелено на доказательство одной из самых важных теорем, на которой основана огромная часть статистики. Речь идёт о центральной предельной теореме (ЦПТ).

ЦПТ утверждает, что для широкого класса того, что мы называем в математике «случайными величинами» (которые представляют собой результаты проведения некоего эксперимента, включающего в себя элемент случайности), до тех пор, пока они удовлетворяют определённым условиям (как может показаться — простым), их среднее значение сходится к случайной величине определённого типа, который называют «нормальным» или «Гауссовым».

Написание запросов для решения аналитических задач — это основное занятие тех, кто работает с данными Pinterest. Но подбор подходящих данных и преобразование описания проблемы в корректный и эффективный SQL‑код могут оказаться непростыми делами. Ведь речь идёт о среде, которая быстро меняется, и о значительных объёмах данных, разбросанных по разным местам.

Однажды я наткнулся на вот эту потрясающую статью (здесь я о ней порассуждал), которая навела меня на одну мысль. Как я подошёл бы к задаче разработки тайника для передачи сообщений? И, если уж мы об этом заговорили — подумаем о том, что нам нужно от подобной системы.

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

За последние три года размер данных 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‑пакета, но оказалось, что речь идёт именно о библиотеке.

Если вы достаточно часто работаете в командной оболочке/терминале — это значит, что со временем история команд станет вашим личным хранилищем знаний, вашим справочником по командам и по документации. Возможность эффективно пользоваться этим личным хранилищем полезной информации может сильно повысить продуктивность вашего труда. Поэтому представляю вашему вниманию несколько советов относительно того, как оптимизировать настройки истории оболочки и как пользоваться этим инструментом на полную мощность.