Дель Бао, Викас Кумар: инженер-программист, Ads ML Infra
Зак Драч: инженер-менеджер, Ads ML Infra

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

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

Некоторые типичные сценарии использования пользовательских функций:

  • Извлекайте рекламу, используя сигналы встраивания пользователей, основанные на недавних и прошлых внедренных пинах (мы сопоставляем каждый пин в N-мерное векторное пространство, называемое встраиванием PinSage) с различными окнами сеансов.
  • Повышайте релевантность рекламы с учетом интересов пользователей, определяемых поисковыми запросами. Сигнал формируется путем сбора нескольких значимых категорий интересов пользователя из поисковых запросов с помощью алгоритма FastText за короткий / длительный период времени и применения их для ранжирования на других поверхностях, например, в домашней ленте.

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

С момента запуска платформа завоевала популярность во всей компании и позволила несколько вариантов использования для взаимодействия с создателями, поиска рекламы, покупок при поиске и ранжирования в поиске. Система надежно генерирует и обслуживает пользовательские сигналы в режиме реального времени в масштабе Pinterest с минимальными затратами на инфраструктуру.

Здесь мы подробнее расскажем, как мы разработали систему для достижения этих целей.

За кулисами того, что мы построили

Столпы платформы пользовательских сигналов

Пять столпов платформы пользовательских сигналов:

  1. Своевременность. Постоянство цикла обратной связи о событии имеет решающее значение для показа свежего контента. Возьмем, к примеру, «Черную пятницу» - представьте себе ошибочный опыт, когда пиннер покупает пару джинсов, а затем получает рекламные объявления о покупке той же пары.
  2. Гибкий пользовательский контекст. Пользовательский контекст описывает любую релевантную информацию, которая может быть использована для характеристики ситуации пользователя. Контент Pinterest адаптирован к пользовательскому контексту. Процесс адаптации может быть основан на двух типах информации: краткосрочные идеи, которые показывают намерения, и долгосрочные идеи, которые включают демографические данные, поведение и предпочтения с течением времени. Это требует, чтобы платформа с API разработчика имела богатую семантику сеанса.
  3. Масштабируемость. Pinterest получает от пользователей 1,2 миллиона событий в секунду. Масштабная персонализация - это вызов, поэтому наша система должна рассматривать каждого Pinneras как отдельную личность, а не как часть аудитории. Это означает, что вычислительные ресурсы распределяются на уровне пользователя, а не целевой группе пользователей.
  4. Скорость разработчика. Pinterest - это компания, ориентированная на данные, и мы полагаемся на эксперименты и A / B-тестирование для принятия ключевых решений. Практики машинного обучения полагаются на правильную абстракцию для реализации и проверки своих алгоритмов на платформе.
  5. Простота сборки. Система имеет множество путей выборки данных, чтобы сформировать окончательный сигнал. Обычно это включает асинхронный код и сложную обработку фьючерсов / обещаний. Мы хотим выбрать правильный фреймворк для построения базовой инфра-логики, чтобы сделать код простым и читаемым.

Есть несколько конструктивных соображений, которые помогут повысить производительность сервиса и ускорить разработку.

Универсальный материализатор

Материализатор отвечает за объединение внешних данных с пользовательскими событиями. Мы стремимся к разработке универсального контейнера материализатора, чтобы облегчить разработчикам усилия по написанию кода. Другая цель - снизить затраты на выборку данных, чтобы добиться минимальных задержек при обработке событий. Это необходимо для достижения своевременности обработки событий в масштабе Pinterest.

Мы применяем принцип разделения проблем: разделение спецификаций запросов и выполнение выборки на два уровня. Запрос функции выражается в виде источника данных, ключа запроса и ключа функции. Сантехника данных приводится в действие механизмом исполнения. Добавление новой функции сводится к тому, чтобы просто указать спецификацию запроса через API-интерфейсы материализатора, для чего требуется всего несколько строк кода.

Агрегация с отслеживанием состояния

Агрегация - это вычисление статистики из сеанса пользовательских событий. Имея 50 тыс. Запросов в секунду на сигнал, система не может масштабироваться с полным пересчетом всех событий пользователя, особенно в контексте долгосрочного пользователя, например, 90 дней. Таким образом, агрегатор принимает модель инкрементальных вычислений с промежуточным состоянием в удаленном хранилище состояний.

Модель имеет два преимущества по сравнению с повторным вычислением каждого события во время запроса:

  • Хранилище событий имеет ограничение ресурса для сохраняемых событий (обычно семь дней). При инкрементальных вычислениях исторические события пользователя сохранялись в состоянии агрегирования. Платформа способна подавать сигналы, которые могут фиксировать долгосрочные предпочтения пользователей.
  • Задержка значительно улучшена, поскольку предыдущие вычисления сохранялись в состоянии.

На рисунке ниже показана парадигма вычислений.

Разделение просмотра / агрегирования

Представление - это клиентский уровень, который отвечает за легкое преобразование состояния. Мы разделяем представление и агрегатор для соответствия двум требованиям: гибкий пользовательский контекст и масштабируемость.

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

Кинжал и абстракция API

Разработка базовой инфраструктуры также должна быть простой: основная логика созданной нами инфраструктуры во многом зависит от зависимостей данных: внешних источников данных для материализации, последовательностей событий и состояния удаленного агрегатора и т. Д. каноническая модель программирования для этого типа фреймворка основана на принципе проектирования dependency_inversion_principle. Внедрение зависимостей - это концепция передачи зависимости (службы или данных) объекту, который будет ее использовать. Мы применяем Dagger2, легкий фреймворк асинхронного ввода-вывода, исходный код которого открыт Google и Square, чтобы удовлетворить эту потребность.

С другой стороны, кривая обучения для Dagger2 относительно высока, поэтому, как платформа для разработчиков, мы делаем наш API-интерфейс разработчика независимым от кинжала. Конкретно,

Агрегатор и View API

Совместимость: архитектура

Путь событий к пользовательскому сигналу

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

Это начинается с взаимодействия пользователя с веб-сайтом Pinterest, такого как нажатие на маркер или создание поисковых запросов, которые затем возвращаются на серверную часть и отслеживаются с разрешения пользователей. Необработанное событие взаимодействия является легким, чтобы сделать отслеживание возможным для инфраструктуры. Следующим шагом будет обогащение их обширной информацией о контенте (например, пин имеет различные категории для обозначения интересующей его темы). С помощью расширенных событий конвейер может дополнительно уплотнять временную последовательность событий до компактного представления мгновенной, краткосрочной и / или долгосрочной склонности пользователя. Это преобразование достигается с помощью различных алгоритмов агрегирования и передовых алгоритмов машинного обучения.

Вот диаграмма, показывающая, как все компоненты сочетаются друг с другом. Мы возьмем двухкомпонентную архитектуру: асинхронная (автономная) обработка, управляемая событиями, и онлайн-обработка.

Асинхронная обработка, управляемая событиями

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

  • Kafka: сообщения журнала, полученные из Kafka, содержат сокращенную информацию, такую ​​как идентификатор пользователя, pinid и тип действия.
  • Материализация: - это процесс, который берет событие пользователя и обогащает его функциями контента (функции контактов, функции запросов и т. д.) из внешних источников данных.
  • Материализованное хранилище событий: материализованные пользовательские события записываются в хранилище данных временной последовательности. Он действует как посредник между автономной обработкой и онлайн-запросом.

Обработка времени обслуживания

Агрегация происходит онлайн во время запроса

  • Агрегация: агрегирование может дополнительно принимать предварительно вычисленное состояние и инкрементный набор пользовательских событий из хранилища событий для вычисления пользовательских функций. На этом этапе мы разрабатываем набор API-интерфейсов и создаем уровень, чтобы отделить пространство алгоритма машинного обучения от вычислительного механизма.

Полученные результаты

Почти реальность

Производительность сервера для масштабируемости

Скорость разработки и простота сборки

Мы представили основную инфраструктуру за месяц благодаря внедрению платформы Dagger2. На разработку пяти сигналов у трех инженеров ушло около двух недель, чтобы активизировать некоторые из наших наиболее важных инициатив по поиску и ранжированию рекламы.

Что дальше

Затем мы разработаем новую архитектуру обработки данных, чтобы переместить агрегацию во время события и объединить пользовательские сигналы в Pinterest в эту инфраструктуру реального времени.

Благодарности: огромное спасибо Сияну Се за консультации по дизайну, Нин Чжан, Шу Чжан, Иран Чжао, Тянбин Сю, Нишант Рой и всю команду Ads ML Infra, а также Джорджу Ю, Сэ Вон Джанг, Цинсянь Лай, Коннелл Донахи, Годун Хан, Джессика Чан, Саураб Джоши, Сихан Ван, которые помогли в улучшении и расширении инфраструктуры.

Мы также хотели бы выразить особую благодарность Аруну Прасаду, Итону Чжоу и Бо Чжао из группы персонализации контента и Джону Чжэн, Пихуэй Вэй, Супэн Гэ, Пэйфэн Инь, Кристал Ли, Сяофан Чен из группы поиска рекламы за наше сотрудничество с разработать и внедрить на платформу первоначальный пакет пользовательских сигналов.

Мы создаем первую в мире систему визуальных открытий. Более 320 миллионов человек по всему миру используют Pinterest, чтобы мечтать, планировать и готовиться к тому, чем они хотят заниматься в жизни. Присоединяйтесь к нам!