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

Я хочу, чтобы вы задали себе один вопрос и честно на него ответили. Когда в последний раз вы получали настоящее удовольствие от программирования? Оглядываясь назад, я понимаю, что не испытывал подобных ощущений, наверное… уже лет десять. Удовольствия у меня не было ни от JavaScript, ни от Python, ни от Ruby или C — ни от чего. Когда я говорю «удовольствие» — я имею в виду ощущения человека, которого во время работы над неким проектом переполняет искренний восторг. Этот человек постоянно ловит себя на такой мысли: «Ох, ну какая ж круть. Поверить не могу, что моя безумная идея и правда сработала!».

Например, я писал маленькую игру-«рогалик». У меня была такая идея: «Готов поспорить, что у меня получиться воспользоваться этим вашим алгоритмом Дейкстры для соединения комнат при генерировании карты, сначала инвертируя карту, а потом его запуская. Вероятно, мне удастся прокопать отличнейшие туннели между комнатами». То было благословенное время, когда я пытался справиться с этой задачей, и при этом не чувствовал, что C++ мне мешает. Мне тогда удалось решить эту задачу, попутно многому научившись. Потом у меня появилась такая мысль: «Интересно, получится мне взять пользовательский интерфейс, сделанный на FTXUI, и просто напрямую его отрендерить в окно визуализации SFML?». Как и следовало ожидать, у меня всё отлично получилось. И хотя это было не так уж и сложно, я по ходу дела много узнал о том, как в C++ обрабатывается юникод. Ни одна из этих задач лёгкой не была, но все их, в принципе, можно было решить, и я не могу напридумывать себе достаточно много «подводных камней», которыми C++ мог бы помешать мне сделать то, что я хочу. Это — то, что я называю «удовольствием».

Это — статья о том, как команда Media Ingestion компании Airbnb создала цифровые открытки для групповых путешествий. Открытки было решено задействовать в летнем выпуске платформы 2024 года. В проекте использовался новый алгоритм подбора материалов под различные туристические направления. Здесь же применялись возможности платформы по обработке изображений и локализованных текстов.

Готовясь к летнему выпуску Airbnb 2024 года, команда Media Ingestion взяла на себя интереснейшую задачу. Она заключалась в разработке надёжной системы для создания цифровых открыток. Это должны были быть открытки, выглядящие, как изделия ручной работы, и при этом отражающие особенности самых разных уголков мира. Отправка открытки — это прекрасный способ приглашать гостей в групповое путешествие, и, в то же время, держать в курсе происходящего семью и друзей. Система требовала нового подхода к сопоставлению открыток со всеми возможными местами проживания, которые гости бронируют на Airbnb. Эта система должна была очень быстро создавать открытки, причём — не только на всех наших клиентских платформах (iOS, Android, Web), но и в разных системах обмена сообщениями, которые находятся за пределами приложения Airbnb. И всё это должно было делаться без отступления от высоких стандартов графического дизайна компании.

Эта статья посвящена тому, как в Airbnb, пользуясь технологиями глубокого обучения, вычисляют показатели восприятия бренда на основе данных, полученных из социальных сетей.

Netflix продолжает расширять бизнес и диверсифицироваться в различных направлениях, вроде доставки видео по запросу и гейминга. В результате всё важнее становятся технологии, обеспечивающие загрузку временных (темпоральных) данных в системы компании и их хранение. Речь идёт об огромных объёмах данных, измеряемых петабайтами. А задержки доступа к этим данным должны укладываться в миллисекунду. В предыдущих материалах мы рассказывали о нашем слое абстракции для хранения данных типа «ключ-значение», и о платформе, реализующий возможности шлюза данных. И то и другое — это неотъемлемые части подсистемы, отвечающей в Netflix за работу с данными. Система хранения данных типа «ключ-значение» — это гибкое и хорошо масштабируемое решение для работы со структурированными данными соответствующего формата. А шлюз данных — это платформа, которая даёт компании базовую инфраструктуру, обеспечивающую защиту, настройку, развёртывание компонентов, ориентированных на работу с данными.

Наша компания — Netflix — способна организовывать бесперебойную, высококачественную потоковую передачу видео миллионам пользователей благодаря своей надёжной глобальной серверной инфраструктуре. В самом центре этой инфраструктуры лежит множество онлайновых распределённых баз данных. Среди них — Apache Cassandra — NoSQL-СУБД, известная высокой доступностью и хорошей масштабируемостью. Cassandra играет роль опорной технологии для множества самых разных возможностей Netflix: от механизма входа пользователя в систему — до хранения истории просмотренных материалов и до поддержки аналитики реального времени и прямых трансляций.

Со временем появлялись новые базы данных типа «ключ-значение» (Key-Value, KV), владельцы сервисов вводили в строй новый функционал. В результате мы столкнулись с массой сложностей, связанных с неправильным использованием хранилищ данных. Во-первых — разработчикам сложно оперировать такими понятиями, как производительность хранилищ данных, согласованность и устойчивость данных. Ведь речь идёт о взаимодействии со сложной системой глобальных масштабов, представленной множеством хранилищ. Во-вторых — разработчикам приходилось постоянно переучиваться, осваивая новые подходы к моделированию данных и распространённые, но очень важные паттерны доступа к данным. В перечень сложностей, встающих перед разработчиками, входят высокие задержки, которым подвержен небольшой процент запросов, находящихся в «хвосте» распределения задержек (tail latency) и идемпотентность операций. Тут же можно упомянуть и поддержку работы «широких» разделов хранилищ с множеством строк, и работу в условиях, когда для хранения данных применяется единственный «толстый» столбец, и медленную пагинацию ответов. Кроме того — наши системы были связаны с множеством собственных API разных баз данных — с API, которые постоянно развивались, и в которых иногда появлялись изменения, нарушающие обратную совместимость. Всё это привело к тому, что инженеры, в масштабах всей организации, тратили много времени на поддержку и оптимизацию механизмов доступа к данным наших микросервисов.

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). Обратный поиск переворачивает с ног на голову стандартный подход к выполнению запросов: вместо того, чтобы искать документы, которые соответствуют запросу, он направлен на поиск запросов, соответствующих документу.