Pushy — это WebSocket‑сервер Netflix, который поддерживает долговременные WebSocket‑соединения с устройствами, на которых работает приложение Netflix. Благодаря этому данные с бэкенд‑сервисов можно отправлять на устройства по мере необходимости. При таком подходе нет нужды в постоянного опроса сервисов устройствами. За последние несколько лет Pushy пережил огромный рост, превратившись из сервиса для негарантированной доставки сообщений в неотъемлемую часть экосистемы Netflix. В этом материале вы узнаете о том, как мы развивали и масштабировали сервер Pushy, стремясь к тому, чтобы он хорошо справлялся со своими текущими обязанностями, и к тому, чтобы подготовить его к будущим нагрузкам. Он поддерживает сотни миллионов одновременных WebSocket‑подключений, доставляет адресатам сотни тысяч сообщений в секунду и удерживает стабильный уровень надёжности доставки сообщений в 99,999%.

Команды подразделения Netflix Compute and Performance Engineering регулярно анализируют происшествия, связанные с падением производительности программ, работающих в нашей многоарендной среде. Первый шаг такого анализа заключается определении того, что является источником проблемы: приложение или инфраструктура. Надо отметить, что подобные изыскания часто усложняет одна неприятность, известная как проблема «шумного соседа» («noisy neighbor»). На нашей многоарендной вычислительной платформе Titus «шумный сосед» представляет собой контейнер или системный сервис, который интенсивно использует серверные ресурсы, что приводит к падению производительности близких к нему контейнеров. Обычно мы уделяем особое внимание использованию CPU, так как именно за этот ресурс чаще всего борются наши рабочие нагрузки и их «шумные соседи».

Этот материал посвящён исследованию восстановления текстов из текстовых эмбеддингов.

Рост популярности векторных баз данных

В последние годы наблюдается стремительное развитие генеративного искусственного интеллекта. Это привело к тому, что многие компании спешат внедрить соответствующие ИИ-инструменты в свои бизнес-процессы. Один из самых распространённых способов это сделать заключается в создании ИИ-систем, которые отвечают на вопросы, имеющие отношение к информации, которую можно найти в некоей базе данных, хранящей документы. Большинство решений этой задачи основано на подходе, называемом «генерация с дополненной выборкой»

Статистическая значимость похожа на автокафе научно‑исследовательского мира. Подъезжаешь к исследованию, забираешь свой «бургер значимости», и — бабах — у тебя в руках оказывается вкусный вывод, которым можно поделиться с друзьями. Применение показателей статистической значимости удобно не только с точки зрения читателей научных статей. Они облегчают жизнь и самим исследователям. Зачем долго и мучительно что‑то объяснять, когда можно вместо этого ограничиться парой простых слов?

Но не так всё просто.

Сталкивались вы когда-нибудь с ошибкой при просмотре потокового видео на Netflix? Может — неожиданно останавливался или вовсе не запускался фильм, который вас заинтересовал? В первой части этой серии статей мы рассказали о методологии тестирования канареечных релизов, применяемой к показателям, которые представлены непрерывными потоками данных. Среди таких показателей — «задержка воспроизведения» (play‑delay). Вот комментарий одного из читателей:

«А что если выход нового релиза не связан с изменениями в функционале воспроизведения и потоковой передачи видео? Например — что если в новом релизе будет изменено что-то, ответственное за вход пользователя в систему? Тестируя такой релиз вы, как и в других случаях, так же будете наблюдать за метрикой «задержка воспроизведения»?»

Привет, Хабр! Из этой статьи вы узнаете про применение последовательного A/B‑тестирования в Netflix.

Это — первый материал из серии статей, посвящённой использованию анализа данных и машинного обучения (Machine Learning, ML) в Netflix. Мы применяем то, о чём собираемся рассказать, совершенствуя автоматизацию оперативной деятельности. Делается это ради повышения производительности и экономической эффективности задач, связанных с обработкой больших данных. В понятие «автоматизация оперативной деятельности», кроме прочих, входят следующие операции: диагностика систем, исправление сбоев, конфигурирование, настройка, масштабирование, отладка, тестирование. Всё это — та база, от которой зависит успешность современных платформ, ориентированных на обработку данных. В этом материале речь пойдёт о нашем проекте Auto Remediation, направленном на автоматическое восстановление задач после сбоев. В соответствующую систему интегрированы классификатор ошибок, основанный на правилах, используемый в настоящий момент, и ML‑служба. Цель этой системы заключается в автоматическом восстановлении работоспособности заданий, с которыми что‑то случилось. Мы развернули систему Auto Remediation в продакшне для того, чтобы исправлять с её помощью ошибки заданий Spark. Это — ошибки, связанные с настройками памяти, и неклассифицированные ошибки. Система доказала свою эффективность. Так — было автоматически исправлено 56% ошибок, связанных с памятью, на 50% снижены расходы, вызванные всеми ошибками. Мы, кроме того, видим в Auto Remediation большой потенциал для дальнейшего развития.

Иногда до начала эксперимента не удаётся оценить то, какого размера должна быть выборка, способная обеспечить его нормальное проведение. Для решения этой проблемы можно провести последовательный тест или 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 часто возникала серьёзная проблема, связанная с нехваткой памяти (у нас есть материал об этом). Тогда мы поняли, что у нас нет ни достаточно подробных сведений о работе приложений, ни хорошей системы, позволяющей анализировать подобные сведения в целях мониторинга приложений и решения проблем.